Kagi Search के लिए Privacy Pass ऑथेंटिकेशन

 (blog.kagi.com)
2 पॉइंट द्वारा GN⁺ 2025-02-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Kagi Search ने Privacy Pass ऑथेंटिकेशन पेश किया है ताकि paid search अधिकारों की पुष्टि करते हुए भी search requests को सीधे account से न जोड़ा जाए
  • यह तरीका token creation और token usage को अलग करता है, ताकि Kagi validity verify कर सके लेकिन सिर्फ token के आधार पर user या creation time को trace back न कर सके
  • शुरुआती target unlimited search वाले Professional, Ultimate, Family, Team plans हैं; search quota limits वाले Trial और Starter को token loss और overuse की समस्याओं के कारण बाहर रखा गया है
  • इसे Orion, Kagi Android app, और Chrome/Firefox extensions से सीधे इस्तेमाल किया जा सकता है; Safari अभी extension API constraints के कारण supported नहीं है
  • केवल tokens से searches और accounts को जोड़ना मुश्किल है, लेकिन IP address, browser fingerprint, repeated search patterns जैसे side channels बने रहते हैं, इसलिए Tor या VPN का उपयोग recommended है

Kagi Search में जोड़ा गया Privacy Pass ऑथेंटिकेशन

  • Kagi ने Kagi Search में Privacy Pass ऑथेंटिकेशन पेश करते हुए साथ में Tor onion service भी जारी की है
  • Privacy Pass एक authentication protocol है जिसमें client access rights साबित करता है, लेकिन server यह identify नहीं कर पाता कि कौन सा user connect हुआ है
  • Paid search engine होने के कारण Kagi को search entitlement verify करना पड़ता है, लेकिन इस feature के जरिए वह search requests को किसी specific account से न जोड़ने की technical guarantee जोड़ता है
  • implementation ने Raphael Robert के Rust Privacy Pass implementation को starting point बनाया, और code kagisearch/privacypass-extension पर public है

Supported plans और clients

  • Privacy Pass पहले unlimited search plans, यानी Professional, Ultimate, Family, Team users को उपलब्ध कराया गया है
  • Trial और Starter plans अभी supported नहीं हैं
    • इन दोनों plans में monthly search count limited है
    • extension delete करने आदि से generated tokens खो जाएं तो user experience खराब हो सकता है
    • Kagi token use के समय account या plan नहीं जान सकता, इसलिए theory में allowed search count से ज्यादा tokens इस्तेमाल हो सकते हैं
  • Supported clients ये हैं
  • मौजूदा Kagi Search extension इस्तेमाल करने वाले users को compatibility issues से बचने के लिए latest version पर update करना या disable करना होगा
    • Firefox: 0.7.6
    • Chrome: 1.2.2.5

Privacy Pass का authentication flow

  • Privacy Pass authentication को दो चरणों में बांटता है: token creation और token usage
  • token creation stage में user Kagi session cookie के जरिए token बनाने का अधिकार साबित करता है
    • server के नजरिए से generated tokens random tokens से अलग नहीं दिखते
    • tokens को उन्हें बनाने वाले user या उसी user द्वारा बनाए गए अन्य tokens से trace नहीं किया जा सकता
  • search request के समय access right साबित करने के लिए पहले से बनाया गया एक token submit किया जाता है
    • server केवल यह confirm करता है कि वह token valid रूप से कभी generated हुआ था
    • token को किसी specific creation stage से link नहीं किया जा सकता
  • tokens single-use होते हैं
    • server पहले से इस्तेमाल किए गए tokens को track करके duplicate use रोकता है
    • client को भी वही token दो बार submit नहीं करना चाहिए, ताकि अलग-अलग usage stages link न हों
  • tokens की fixed lifetime होती है, इसलिए बहुत पुराने tokens को फिर से generate करना पड़ता है

Kagi implementation model और security properties

  • Kagi का deployment model Privacy Pass standard के Shared Origin, Attester, Issuer structure को follow करता है
    • Kagi Attester, Issuer और Origin तीनों roles निभाता है
    • users Privacy Pass browser extension या Orion built-in support के जरिए client role निभाते हैं
  • extension installation के बाद और फिर periodically बड़ी संख्या में tokens generate करके store करता है
  • search करते समय user toggle से चुन सकता है कि existing session cookie से authenticate करना है या Privacy Pass token से
  • user protection properties तीन हैं
    • creation-use unlinkability: Kagi search के दौरान submitted token को किसी specific token creation stage से link नहीं कर सकता
    • use-use unlinkability: Kagi केवल tokens के आधार पर यह नहीं जान सकता कि दो अलग-अलग searches उसी user से आई हैं या नहीं
    • usage theft prevention: token creation process observe करने वाला eavesdropper केवल उस information से token चुरा कर use नहीं कर सकता
  • इसमें Kagi को protect करने वाली properties भी शामिल हैं
    • सही तरीके से generated tokens Kagi verification pass करते हैं
    • malicious client, correctly generated token जानने के बावजूद, नया valid token forge नहीं कर सकता

Privacy Pass mode में कम होने वाले features

  • Privacy Pass mode में Kagi user को identify नहीं कर सकता, इसलिए account settings लागू नहीं कर सकता
  • Kagi इसे users के लिए “regular privacy और full functionality” या “maximum privacy और core functionality” के बीच choice के रूप में देता है
  • launch के समय Kagi Assistant Privacy Pass में उपलब्ध नहीं है
    • Kagi Assistant सिर्फ Ultimate members को दिया जाता है
    • Privacy Pass में account information नहीं होती, इसलिए यह verify नहीं किया जा सकता कि कौन सा plan है
  • launch के समय Privacy Pass केवल Kagi Search authentication के लिए इस्तेमाल होता है
  • Kagi अगले कुछ हफ्तों में support को इन services तक expand करने की योजना रखता है
    • Kagi Assistant
    • Kagi Translate और Kagi Maps
    • Kagi Universal Summarizer और Ask questions about page
  • अभी इन services का इस्तेमाल करने के लिए Privacy Pass disable करना होगा

Side channels और Tor का उपयोग

  • Privacy Pass केवल token के आधार पर token creation और usage को link करना असंभव बनाता है, लेकिन online interaction को पूरी तरह mathematical model से explain नहीं किया जा सकता
  • malicious server side channel information से client को track करने की कोशिश कर सकता है
    • अगर हर दिन एक ही समय पर वही specific searches repeat की जाएं, तो अंदाजा लगाया जा सकता है कि searches एक ही व्यक्ति से आई हैं
    • browser user-agent, IP address जैसे signals Privacy Pass के बाहर की information हैं
    • अगर उसी IP से token creation request के तुरंत बाद token usage request आती है, तो उसे उसी व्यक्ति की request माना जा सकता है
  • RFC 9576 token creation और usage को time-wise अलग करने, या Tor जैसी anonymization service से space-wise अलग करने की recommendation करता है
  • Kagi का Privacy Pass extension और Orion built-in implementation HTTP headers और cookies हटाकर browser fingerprint को जितना हो सके uniform बनाने के लिए process करता है
  • Kagi Tor network से direct access के लिए onion address देता है
  • केवल Tor इस्तेमाल करने से IP address छिप जाता है, लेकिन Privacy Pass के बिना logged-in state में searches theory में एक single account से जुड़ सकती हैं
  • Tor और Privacy Pass को साथ इस्तेमाल करने पर Kagi केवल यह जानता है कि search उस user से आई है जिसे पहले token पाने का अधिकार verify किया गया था; account या location नहीं जानता

Token count, performance और storage

  • unlimited search plan users एक epoch, यानी एक महीने में 2,000 tokens generate कर सकते हैं
  • अतिरिक्त tokens चाहिए हों तो support@kagi.com पर request कर सकते हैं
  • 500 search tokens generate करने में आम consumer laptop पर लगभग 1 सेकंड की computation लगती है
    • server connection और response time के कारण कुछ seconds और लग सकते हैं
    • extension install के समय यह जहां तक संभव हो background में किया जाता है
  • एक token 216 bytes का होता है, और प्रति token creation request storage लगभग 100KiB होता है
  • current token verification server केवल us-central1 region में deployed है, और Kagi launch के तुरंत बाद इसे expand करने की योजना रखता है

Personalization और settings सीमित क्यों हैं

  • Privacy Pass search में Kagi user को नहीं जानता, इसलिए user की custom settings के मुताबिक results नहीं दे सकता
  • Kagi ने हर request के साथ (language, region, safe-search) जैसी छोटी settings भेजने का तरीका consider किया, लेकिन फिलहाल माना कि इससे anonymity काफी कम हो सकती है
  • example analysis में Lang 10 जैसी specific language setting भेजने वाला user, Privacy Pass users करीब 1,000 होने पर, use-use unlinkability guarantee अपने-आप खो सकता है
  • Kagi मानता है कि यह estimate शायद बहुत conservative हो, लेकिन अभी Privacy Pass authenticated users के लिए default personalization level enable नहीं करता
  • manual search settings कुछ हद तक search term में bangs जोड़कर apply की जा सकती हैं
    • जैसे !de को search term से पहले लगाने पर German region search किया जाता है
  • अगर fully personalized search experience चाहिए, तो existing login method इस्तेमाल करना और Privacy Pass disable करना होगा

Safari, private browsing windows आदि limitations

  • Privacy Pass blockchain का उपयोग नहीं करता
    • यह elliptic curves, hash functions, और verifiable oblivious pseudorandom function structure का इस्तेमाल करता है
    • tokens blockchain पर generate, store या trade नहीं होते
  • Chrome/Firefox private browsing windows में token creation काम नहीं करता
    • token creation के लिए session cookie access चाहिए
    • private browsing windows में extensions session cookies access नहीं कर सकते
    • Orion में private browsing window में भी token creation काम करता है
  • Privacy Pass on करने पर भी TCP/IP के काम करने के तरीके के कारण Kagi search request का IP address देख सकता है
    • अगर IP address exposure की चिंता है तो Tor या trusted VPN इस्तेमाल करने की recommendation है
  • सभी tokens अपने creation month X के आधार पर X+2 महीने के पहले दिन midnight पर expire होते हैं
    • यह उसी समय generated tokens की similar expiry dates का उपयोग कई searches को identify करने में होने वाली समस्या से बचने का तरीका है
  • Safari अभी supported नहीं है
    • Kagi की समझ के मुताबिक Safari extension API requests से cookies हटाने वाला feature support नहीं करता
    • cookies नहीं हटाई जा सकीं तो authentication logged-in account से ही चलता रहेगा
    • WebKit-based similar native experience चाहिए तो Privacy Pass integrated Orion Browser को alternative के रूप में इस्तेमाल किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-14
Hacker News की रायें

  • अच्छा है कि Kagi अब Privacy Pass इस्तेमाल कर रहा है, और कंपनी भी कुल मिलाकर ठीक लगती है
    लेकिन Kagi ने असल में IETF draft [1] और Rust implementation [2], जिन पर मैं कुछ समय से काम कर रहा था, ले लिए, उसके ऊपर एक पतला wrapper [3] बनाया और उसे “Kagi का Privacy Pass implementation” कह रहा है
    मुझे लगता है कि मुझे कुछ हद तक credit दिया जाना चाहिए था। IETF का काम और open source software का काम ज़्यादातर स्वैच्छिक और unpaid होता है, और अक्सर काम के घंटों के बाहर किया जाता है। इस तरह का व्यवहार motivation नहीं देता। Kagi इससे बेहतर कर सकता है
    [1] https://datatracker.ietf.org/doc/draft-ietf-privacypass-batc...
    [2] https://github.com/raphaelrobert/privacypass
    [3] https://github.com/kagisearch/privacypass-lib/blob/e4d6b354d...

    • ईमानदारी से, लेख में जिस “Kagi के Privacy Pass implementation” की बात है, वह RFC या protocol implementation खुद नहीं, बल्कि उस functionality को Kagi के server और client में integrate करने वाले हिस्से की ओर इशारा लगता है। लेख में RFC को acknowledge भी किया गया है
    • सोच रहा हूँ कि अगर Kagi “raphaelrobert को credit” जोड़ दे, या code में कहीं license की copy रख दे, तो क्या compliance पूरी हो जाएगी
      मेरा open source असल में कभी इस्तेमाल नहीं हुआ है और मैं आम तौर पर MIT license के तहत release करता हूँ, इसलिए जानना चाहता हूँ कि दूसरे groups या organizations असल में license compliance कैसे करते हैं
    • 14 फरवरी 2025 को Eastern Time के करीब दोपहर 12:15 बजे README header capture किया था, तब उसमें यह लिखा था

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      यह निश्चित रूप से अच्छा impression नहीं देता। हालांकि लगता है कि Kagi के लोग इसे “raphaelrobert/privacypass के लिए Crystal Lang wrapper implement करने वाली core library” जैसे ज़्यादा सटीक wording में बदलने के लिए तैयार होंगे। यह शायद जानबूझकर नहीं था, बल्कि संभव है कि वे इसे काम कराने पर केंद्रित थे और wording फिर से पढ़ने के लिए किसी को नहीं लगा पाए

  • शानदार। मैं जिन services का इस्तेमाल करता हूँ, उनमें किसी service को अपने से ज़्यादा users के फायदे के लिए सच में कुछ करते देखना दुर्लभ है; यह unexpected है, लेकिन बहुत अच्छा surprise है
    अच्छा होगा अगर यह extension browser context को automatically समझकर और बेहतर integrate हो जाए। यानी normal mode में मेरा session इस्तेमाल करे, और private browsing mode (browser.extension.inIncognitoContext) में मेरे अलग से कुछ किए बिना Privacy Pass से authenticate कर दे
    Orion का GNU/Linux version नहीं है, इसलिए मैं उसे इस्तेमाल नहीं करता

    • ऐसी चीज़ें दुर्लभ इसलिए हो गई हैं क्योंकि इस क्षेत्र की ज़्यादातर companies, बल्कि कई tech companies, two-sided market model इस्तेमाल करती रही हैं—एक user group को कुछ देती हैं और फिर उसके परिणाम दूसरे user group को बेचकर revenue कमाती हैं
      असली revenue बाद वाले group से आता है, इसलिए by default पहले group के हित और बाद वाले group के हित टकराते हैं और structure पहले group के लिए hostile बनने की ओर झुकता है
      Kagi और दूसरी नई tech companies ताज़गी भरी इसलिए लगती हैं क्योंकि उन्होंने यह model छोड़कर उस “पुराने style” model पर वापसी की है, जिसमें वे जिस group को service देती हैं और जिससे revenue कमाती हैं, वह एक ही होता है
    • Linux के लिए Orion पर काम कल शुरू किया है
    • इस approach की कमी यह है कि अगर आप किसी बड़े network के ऊपर नहीं हैं, तो सिर्फ IP address से भी anonymity टूट सकती है
      Kagi जानता है कि user logged in है, और अगर user private window में sensitive searches करता है, तो वे searches link की जा सकती हैं। modes के बीच जल्दी-जल्दी switch करना अच्छा नहीं है
    • अगर आपको पता नहीं था, तो 2024 के अंत के आसपास podcast में announce किया गया था कि Orion Linux version plan में है
    • Kagi इस्तेमाल करते हुए सही choices करने की आदत पड़ जाती है। सच में हैरानी होती है कि उनसे खास गलतियाँ नहीं हुईं
      काश मेरी Kagi T-shirt के साथ भी ऐसा होता। दूसरी धुलाई में उसका bottom hem खुल गया, और अब वह pajama/yard-work shirt बन गई है। replacement free shirt coupon तो मिला है, लेकिन delivery अभी नहीं हुई

  • जैसा लेख में भी संकेत है, अगर account के बिना Privacy Pass खरीदने की दुकान हो तो बात समझ में आती है
    किसी cryptocurrency, शायद Monero, को support करना चाहिए, और GNU Taler जैसी चीज़ भी, अगर वह technology कभी usable हो जाए, तो support करना अच्छा होगा

    • Kagi Bitcoin accept करता है, लेकिन founder Vlad ने forum में कहा कि इस option का इस्तेमाल करने वाले इतने कम हैं कि Monero support में invest करने का कोई मतलब नहीं है
    • मैं सहमत हूँ कि बिना account tokens बेचने वाली third-party दुकान ideal solution होगी, लेकिन account न होने पर आप वे features खो देंगे जो Kagi को उपयोगी बनाते हैं, जैसे किसी खास domain को results से हटाना या किसी खास result type की priority बढ़ाना

  • मुझे हैरानी है कि क्या यह आखिरकार लॉग न रखने की धारणा पर आधारित privacy है। मैं बहस नहीं कर रहा, बस सच में यह हिस्सा समझ नहीं पा रहा हूँ
    मान लें कि user A Kagi से token मांगता है और Kagi कहता है, “ठीक है, तुम्हें 500 tokens देता हूँ।” अगर Kagi ने अभी user A को दिए गए उन 500 tokens को record कर लिया, तो बाद में उनमें से कोई एक इस्तेमाल होने पर क्या उसे यह पता नहीं चल जाएगा कि वह token user A को assign किया गया था?
    बेशक अगर Kagi यह data store नहीं करता, तो token खुद सिर्फ valid/invalid के रूप में दिखेगा और “Y तारीख को user A को दिया गया valid token” बनकर नहीं रहेगा, इसलिए ठीक होगा, लेकिन क्या बात बस इतनी ही है? क्या मैं कुछ गलत समझ रहा हूँ?

    • server token generate नहीं करता, बल्कि client token generate करता है। server को यह verify कर पाने में सक्षम होना चाहिए कि token उस client ने बनाया है जिसे generate करने की अनुमति मिली थी, लेकिन उसे यह नहीं पता चलना चाहिए कि किस client ने बनाया था। कम से कम side-channel जानकारी के बिना तो ऐसा ही होना चाहिए

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      मुझे नहीं पता यह primitive कितना verified है, लेकिन कम से कम ऐसा लगता है कि इसमें server द्वारा client को token बांटकर फिर यह दिखावा करने से कहीं ज्यादा structure है कि उसे नहीं पता किसे दिया था
      संदर्भ paper: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • Privacy Pass docs [0] इस हिस्से को cover करते हैं, लेकिन मुख्य रूप से paper के अंदर इसे ज्यादा गहराई से समझाया गया है। core बात यह लगती है कि server द्वारा लौटाया गया token, client द्वारा फिर भेजे गए modified token से link नहीं किया जा सकता
      server यह जान सकता है कि उसने कुछ users को token A, B, C लौटाए और बाद में token X, Y, Z प्राप्त किए। उसे यह भी पता है कि X, Y, Z valid हैं, लेकिन अपने द्वारा issue किए गए tokens से उनका correspondence नहीं जानता। इसमें elliptic-curve cryptography इस्तेमाल होती है
      [0] https://privacypass.github.io/
    • idea यह है कि token किसी भी account से link नहीं होता। यह anonymous token है
    • लगता है आपने Privacy Pass token की premise नहीं समझी
      core बात यह है कि server नहीं जानता कि कौन सा token किस client का है। server token generate नहीं करता

  • Kagi की सबसे बड़ी कमी, जो मुझे हमेशा दिखती थी, अब हल हो गई है। product को लगभग सभी के लिए आकर्षक बनाने के लिए सुनने और इस पर काम करने के लिए धन्यवाद

  • जो लोग अभी Kagi इस्तेमाल नहीं करते, उनकी सबसे बड़ी शिकायतों में से एक login और payment information मांगने से जुड़ी privacy concerns है
    मैं खुद उस हिस्से को लेकर चिंतित नहीं था, लेकिन जानना चाहता हूँ कि जिन लोगों को वाकई चिंता थी, उनके लिए यह बदलाव कितनी हद तक चिंता कम करता है

    • मैं उन्हीं लोगों में था जिन्हें यह चिंता थी, और search engine में login करना मुझे अब भी लगभग अविश्वसनीय लगता है। हालांकि अब मुझे पता है कि कितने लोग ऐसा करते हैं
      system को थोड़ा verify कर लेने के बाद, अब मेरे signup करने की संभावना काफी ज्यादा है
    • अगर cryptography Kagi के बताए अनुसार काम करती है, तो यह तरीका search requests को account information से पूरी तरह अलग कर देता है। account कई search tokens बनाता है, और हर search request पर एक token consume होता है
      tokens device पर generate होते हैं और इस्तेमाल होने तक device से बाहर नहीं जाते, इसलिए theoretically Kagi के पास सिर्फ token देखकर यह जानने का कोई तरीका नहीं है कि वह token किस account ने बनाया। यह fingerprint tracking या IP correlation को solve नहीं करता, लेकिन कहा गया है कि Firefox और Chrome plugins fingerprint tracking को कम करने के उपाय करते हैं। यह सिर्फ Google या DuckDuckGo इस्तेमाल करने से न बेहतर है न बदतर, और अगर सच में privacy चाहिए तो यह Tor पर भी काम करता है
      tokens को बिल्कुल share किए बिना legitimacy कैसे prove की जाती है, यह मुझे पक्का नहीं पता, लेकिन शायद इसमें किसी तरह का ~~zero-knowledge proof~~ शामिल होगा
      edit: zero-knowledge proof नहीं, बल्कि शायद blind signature है

  • मुझे समझ नहीं आता कि Kagi की तरफ़ से किसी को token table में नई columns जोड़ने से क्या रोकता है, जिनमें token बनाने वाले user और उसका SessionCookie रखा जाए
    यह नहीं दिखता कि इसे मूल token creator से बहुत आसानी से link क्यों नहीं किया जा सकता

    • मैं implementer हूँ। Privacy Pass के “issuance” protocol के दौरान client एक “message” बनाता है जिसे server process करता है। server का output client को वापस जाता है, और client इस output को और modify करके final token बनाता है
      आख़िरी client modification step में ये tokens randomize हो जाते हैं, इसलिए server यह identify नहीं कर पाता कि वह token किस issuance process से जुड़ा था
      सच में कमाल की बात यह है कि server अगर अपने step में कुछ गलत करने की कोशिश करे, तब भी यही रहता है। इसलिए user को सिर्फ़ client software पर भरोसा करना होता है, और हमने इसे open source कर दिया है: https://github.com/kagisearch/privacypass-extension
      कुछ लोग blind signatures की बात कर रहे हैं, और असल में Privacy Pass इन्हें building block के रूप में इस्तेमाल कर सकता है। लेकिन सटीक रूप से कहें तो Kagi में हम “Oblivious Pseudorandom Function” (OPRF) पर आधारित “Privately Verifiable Tokens”(https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...) इस्तेमाल कर रहे हैं, और निजी तौर पर मुझे OPRF blind signatures से ज़्यादा शानदार लगता है
    • यह quoted paper [1], cryptographic anonymous token protocol paper, में समझाई गई चीज़ जैसा लगता है। यह कोई simple plaintext token नहीं है
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      लगता है Cloudflare ने भी वही implement किया था। कम से कम HN comments उसी paper को link कर रहे हैं
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
    • token client पर “generate” होता है, और server client को सिर्फ़ इतनी जानकारी देता है कि वह locally generated token “valid” बन सके। फिर भी उस token को किसी specific verification attempt से link नहीं किया जा सकता
    • मेरे मन में भी बिलकुल वही सवाल आया था। server-side trust पर निर्भर नहीं रह सकते, इसलिए सोच रहा हूँ कि क्या मैं कुछ गलत समझ रहा हूँ
    • अगर मैंने सही समझा है तो “Privacy Pass” blind signatures इस्तेमाल करता है, इसलिए TokenResponse में मौजूद token और search query में दिए जाने वाले token को आपस में associate नहीं किया जा सकता

  • क्या यह सच में काम करता है? token सिर्फ़ एक बार इस्तेमाल हो सकता है, तो practically client किसी specific search session के अंदर token generate और use करने का loop चलाएगा, और तब pairs को link करना बहुत आसान हो जाएगा। लेख में भी ऐसा कहा गया है

    For this reason, it is highly recommended to separate token generation and redemption in time, or “in space” (by using an anonymizing service such as Tor when redeeming tokens, see below).
    Tor space को randomize कर देगा, लेकिन time का क्या? इसलिए “नीचे देखें” वाला हिस्सा देखा, पर संबंधित content नहीं मिला। क्या idea यह है कि पर्याप्त request volume हो तो clients समय के हिसाब से एक-दूसरे को cover कर लेंगे?
    और Tor की भी space randomize करने में limits हैं, जब तक आप session लगातार नया न बनाते रहें। मेरी जानकारी में loop session के दौरान fixed रहता है, और session दोबारा बनाने में करीब 10 seconds लगते हैं। तो क्या इसे वाकई space randomize करना कह सकते हैं?

    • एक token request N tokens बना सकती है। हमने N = 500 set किया है, इसलिए ज़्यादातर users को नए tokens काफ़ी कम ही request करने पड़ेंगे

  • यह सच में बहुत cool और शानदार काम है
    मैंने पहले Privacy Pass जैसी blind signature authentication बनाई थी, और सोच रहा हूँ कि multi-device access को कैसे handle करेंगे
    मेरा अंदाज़ा है कि दूसरे devices पर token access खोने की समस्या को कम करने के लिए इसे पहले सिर्फ़ unlimited search users के लिए launch किया गया है। long-term plan को लेकर कोई idea है क्या? जब मैंने पहले ऐसे systems बनाए थे, तो हमेशा उन्हें end-to-end encrypted sync के साथ जोड़ना पड़ता था। यह end user के लिए परेशानी भरा तो है ही, साथ ही storage updates और blind search requests को आपस में correlate करने की गुंजाइश भी पैदा करता है
    ख़ैर, सच में कमाल है, और अब Kagi पर बस भरोसा करने के बजाय यह verify कर पाना कि भरोसा करने की ज़रूरत नहीं है, मुझे और excited कर रहा है

    • सही है, multi-device पक्का आसान नहीं है। हमने कुछ ideas experiment किए हैं, लेकिन यह ऐसा problem नहीं है जिसका clear answer हो
      अभी हम rate limiting के ज़रिए हर device को independently tokens generate करने देकर Privacy Pass को कई devices पर इस्तेमाल करने लायक बना रहे हैं। देखेंगे कि यह कैसे चलता है, users की feedback सुनेंगे, और फिर drawing board पर वापस लौटेंगे

  • क्या यह वही Privacy Pass है जिसे Cloudflare clients को CAPTCHA bypass allow करने के लिए इस्तेमाल करता था? अगर हाँ, तो यह इस system का सच में बहुत साफ़-सुथरा application है। मैंने कभी नहीं सोचा था कि paid service में anonymously authenticate करने के लिए इसे इस्तेमाल किया जा सकता है

    • Privacy Pass जिस cryptography [1] पर based है, वह दरअसल Ecash[2] से आई है, तो आख़िरकार बात एक full circle हो गई
      [1] https://www.petsymposium.org/2018/files/papers/issue3/popets...
      [2] https://en.m.wikipedia.org/wiki/Ecash
    • सही। लेकिन मेरी जानकारी में Cloudflare ने Privacy Pass trial run बंद कर दिया था
      मुझे याद है कि Safari ही इसे natively implement करने वाला इकलौता browser था, लेकिन अब लगता है Orion भी support करता है