Kagi Arama için Privacy Pass kimlik doğrulaması

 (blog.kagi.com)
2 puan yazan GN⁺ 2025-02-14 | 1 yorum | WhatsApp'ta paylaş
  • Kagi Search, ücretli arama yetkisini doğrularken arama isteklerini doğrudan hesapla ilişkilendirmemek için Privacy Pass kimlik doğrulamasını kullanıma sundu
  • Bu yöntem, token oluşturma ile token kullanımını ayırarak Kagi'nin geçerliliği doğrulamasını sağlıyor, ancak yalnızca tokene bakarak kullanıcıyı veya tokenin ne zaman oluşturulduğunu geriye dönük izleyememesini amaçlıyor
  • İlk aşamada hedef kitle, sınırsız arama içeren Professional, Ultimate, Family, Team planları; arama kotası olan Trial ve Starter ise token kaybı ve fazla kullanım sorunları nedeniyle kapsam dışı bırakıldı
  • Özellik, doğrudan Orion, Kagi Android uygulaması ve Chrome·Firefox uzantılarında kullanılabiliyor; Safari ise uzantı API kısıtları nedeniyle henüz desteklenmiyor
  • Yalnızca token üzerinden arama ile hesabı ilişkilendirmek zor olsa da, IP adresi, tarayıcı parmak izi, tekrar eden arama kalıpları gibi yan kanallar varlığını sürdürüyor; bu nedenle Tor veya VPN kullanımı öneriliyor

Kagi Search'e eklenen Privacy Pass kimlik doğrulaması

  • Kagi, Kagi Search'e Privacy Pass kimlik doğrulamasını eklerken Tor onion service adresini de birlikte duyurdu
  • Privacy Pass, istemcinin erişim yetkisini kanıtlamasını sağlarken sunucunun hangi kullanıcının bağlandığını tespit edemediği bir kimlik doğrulama protokolüdür
  • Ücretli bir arama motoru olan Kagi'nin arama yetkisini doğrulaması gerekir; bu özellikle birlikte arama isteklerini belirli bir hesapla ilişkilendirmemeye yönelik teknik bir güvence de eklenmiş oldu
  • Uygulama, Raphael Robert'in Rust Privacy Pass uygulamasını başlangıç noktası olarak aldı ve kod kagisearch/privacypass-extension deposunda yayımlandı

Desteklenen planlar ve istemciler

  • Privacy Pass ilk olarak sınırsız arama planları olan Professional, Ultimate, Family, Team kullanıcılarına sunuluyor
  • Trial ve Starter planları şu anda desteklenmiyor
    • Bu iki planda aylık arama sayısı sınırlı
    • Uzantının silinmesi gibi durumlarda oluşturulan tokenlerin kaybolması kullanıcı deneyimini olumsuz etkileyebilir
    • Kagi, token kullanım anında hesabı veya planı bilemediği için, teorik olarak izin verilen arama sayısından fazla token kullanımı mümkün hale gelebilir
  • Desteklenen istemciler şunlar
  • Mevcut Kagi Search uzantısını kullananların, uyumluluk sorunlarını önlemek için en son sürüme güncellemesi veya uzantıyı devre dışı bırakması gerekiyor
    • Firefox: 0.7.6
    • Chrome: 1.2.2.5

Privacy Pass'in kimlik doğrulama akışı

  • Privacy Pass, kimlik doğrulamayı token oluşturma ve token kullanımı olmak üzere iki aşamaya ayırır
  • Token oluşturma aşamasında kullanıcı, Kagi oturum çereziyle token oluşturma yetkisini kanıtlar
    • Oluşturulan tokenler, sunucu açısından rastgele tokenlerden ayırt edilemez
    • Tokenler, onları oluşturan kullanıcıya veya aynı kullanıcının oluşturduğu diğer tokenlere kadar izlenemez
  • Arama isteği sırasında erişim yetkisini kanıtlamak için önceden oluşturulmuş bir token gönderilir
    • Sunucu yalnızca bu tokenin geçerli şekilde oluşturulmuş olduğunu doğrular
    • Tokeni belirli bir oluşturma aşamasıyla ilişkilendiremez
  • Tokenler tek kullanımlıktır
    • Sunucu, daha önce kullanılmış tokenleri takip ederek tekrar kullanımı engeller
    • İstemci de aynı tokeni iki kez göndermemelidir; böylece farklı kullanım aşamaları birbiriyle ilişkilendirilemez
  • Tokenlerin sabit bir ömrü vardır; çok eski tokenler yeniden oluşturulmalıdır

Kagi'nin uygulama modeli ve güvenlik özellikleri

  • Kagi'nin dağıtım modeli, Privacy Pass standardındaki Shared Origin, Attester, Issuer yapısını izler
    • Kagi; Attester, Issuer ve Origin rollerinin tamamını üstlenir
    • Kullanıcı ise Privacy Pass tarayıcı uzantısı veya Orion'un yerleşik desteği üzerinden istemci rolünü üstlenir
  • Uzantı, kurulumdan sonra ve sonrasında periyodik olarak çok sayıda token oluşturup saklar
  • Kullanıcı, arama sırasında mevcut oturum çereziyle mi yoksa Privacy Pass tokeniyle mi kimlik doğrulayacağını bir anahtarla seçebilir
  • Kullanıcıyı koruyan üç özellik bulunur
    • Oluşturma-kullanım bağsızlığı: Kagi, arama sırasında gönderilen tokeni belirli bir token oluşturma aşamasıyla ilişkilendiremez
    • Kullanım-kullanım bağsızlığı: Kagi, iki farklı aramanın aynı kullanıcıdan gelip gelmediğini yalnızca tokenlere bakarak anlayamaz
    • Kullanımın ele geçirilmesini önleme: Token oluşturma sürecini gözlemleyen bir dinleyici, yalnızca bu bilgiyle tokeni çalıp kullanamaz
  • Kagi'yi koruyan özellikler de vardır
    • Doğru şekilde oluşturulmuş tokenler Kagi doğrulamasından geçer
    • Kötü niyetli bir istemci, doğru oluşturulmuş bir tokeni bilse bile yeni geçerli tokenler sahteleyemez

Privacy Pass modunda azalan işlevler

  • Privacy Pass modunda Kagi kullanıcıyı tanıyamadığı için hesap ayarları uygulanamaz
  • Kagi bunu, “genel gizlilik ve tam işlevsellik” ile “maksimum gizlilik ve temel işlevler” arasında kullanıcının seçim yapabildiği bir yapı olarak sunuyor
  • Kagi Assistant, çıkış anında Privacy Pass ile kullanılamıyor
    • Kagi Assistant yalnızca Ultimate üyelerine sunuluyor
    • Privacy Pass'te hesap bilgisi olmadığı için hangi planın kullanıldığını doğrulamak mümkün değil
  • Çıkış anındaki Privacy Pass yalnızca Kagi Search kimlik doğrulaması için kullanılıyor
  • Kagi, desteği önümüzdeki haftalarda şu hizmetlere de genişletmeyi planlıyor
    • Kagi Assistant
    • Kagi Translate ve Kagi Maps
    • Kagi Universal Summarizer ve Ask questions about page
  • Şu anda bu hizmetleri kullanmak için Privacy Pass devre dışı bırakılmalı

Yan kanallar ve Tor kullanımı

  • Privacy Pass, yalnızca token üzerinden token oluşturma ile kullanımı ilişkilendirmeyi engeller; ancak tüm çevrimiçi etkileşimi matematiksel bir modelle tamamen açıklayamaz
  • Kötü niyetli bir sunucu, istemciyi yan kanal bilgileriyle izlemeye çalışabilir
    • Her gün aynı saatte aynı spesifik aramaları tekrar etmek, bu aramaların aynı kişiden geldiği yönünde tahmine yol açabilir
    • Tarayıcı user-agent bilgisi ve IP adresi gibi sinyaller, Privacy Pass'in dışındaki bilgilerdir
    • Aynı IP'den token oluşturma isteğinden hemen sonra token kullanım isteği gelirse, bunların aynı kişiye ait olduğu düşünülebilir
  • RFC 9576, token oluşturma ile kullanımı zamansal olarak ayırmayı veya Tor gibi anonimleştirme hizmetleriyle mekânsal olarak ayırmayı öneriyor
  • Kagi'nin Privacy Pass uzantısı ve Orion'daki yerleşik uygulama, HTTP başlıkları ve çerezleri kaldırarak tarayıcı parmak izini mümkün olduğunca tekdüze hale getirmeye çalışıyor
  • Kagi, Tor ağı üzerinden doğrudan erişilebilen bir onion adresi sunuyor
  • Yalnızca Tor kullanıldığında IP adresi gizlenir; ancak Privacy Pass olmadan giriş yapılmışsa aramalar teorik olarak tek bir hesaba bağlanabilir
  • Tor ile Privacy Pass birlikte kullanıldığında Kagi yalnızca, ilgili aramanın daha önce token alma yetkisi doğrulanmış bir kullanıcıdan geldiğini bilir; hesabı veya konumu bilemez

Token sayısı, performans ve depolama alanı

  • Sınırsız arama planı kullanıcıları, bir epoch yani bir ay içinde 2.000 token oluşturabilir
  • Ek token gerekirse support@kagi.com adresinden talep edilebilir
  • 500 arama tokeni oluşturmak, tipik bir tüketici dizüstü bilgisayarında yaklaşık 1 saniyelik hesaplama gerektirir
    • Sunucu bağlantısı ve yanıt süresi nedeniyle birkaç saniye daha sürebilir
    • Bu işlem, uzantı kurulumu sırasında mümkün olduğunca arka planda yapılır
  • Bir token 216 bayttır ve token oluşturma isteği başına depolama alanı yaklaşık 100KiB'tir
  • Şu anda token doğrulama sunucusu yalnızca us-central1 bölgesinde dağıtılmış durumda; Kagi bunu lansmandan hemen sonra genişletmeyi planlıyor

Kişiselleştirme ve ayarların sınırlı olmasının nedeni

  • Privacy Pass ile yapılan aramalarda Kagi kullanıcıyı tanıyamadığı için, kullanıcının özel ayarlarına göre uyarlanmış sonuçlar sunamaz
  • Kagi, her istekte (language, region, safe-search) gibi küçük ayarları göndermeyi değerlendirdi; ancak şu aşamada bunun anonimliği ciddi biçimde azaltabileceği sonucuna vardı
  • Örnek analizde, belirli bir dil ayarı olan Lang 10 değerini gönderen kullanıcılar, Privacy Pass kullanıcı sayısı yaklaşık 1.000 olduğunda kullanım-kullanım bağsızlığı güvencesini otomatik olarak kaybedebilir
  • Kagi, bu tahminin aşırı muhafazakâr olabileceğini düşünüyor; ancak şu anda Privacy Pass kimlik doğrulaması kullananlara varsayılan kişiselleştirme düzeyini etkinleştirmiyor
  • Manuel arama ayarları, sorguya bang eklenerek kısmen uygulanabilir
    • Örneğin arama ifadesinin başına !de eklemek Almanya bölgesi için arama yapar
  • Tam kişiselleştirilmiş arama deneyimi isteniyorsa mevcut giriş yöntemi kullanılmalı ve Privacy Pass devre dışı bırakılmalıdır

Safari, gizli pencere ve diğer kısıtlar

  • Privacy Pass blockchain kullanmaz
    • Eliptik eğriler, hash fonksiyonları ve doğrulanabilir unutkan sözde rastgele fonksiyon yapıları kullanır
    • Tokenler blockchain üzerinde oluşturulmaz, saklanmaz veya alınıp satılmaz
  • Chrome ve Firefox'un gizli pencerelerinde token oluşturma çalışmaz
    • Token oluşturmak için oturum çerezine erişim gerekir
    • Gizli pencerelerde uzantıların oturum çerezine erişimi yoktur
    • Orion'da ise gizli pencerelerde de token oluşturma çalışır
  • Privacy Pass açık olsa bile TCP/IP çalışma biçimi nedeniyle Kagi arama isteğinin IP adresini görebilir
    • IP adresinin görünmesi endişe veriyorsa Tor veya güvenilen bir VPN kullanılması önerilir
  • Tüm tokenler, oluşturuldukları ay X kabul edilirse X+2 ayının ilk günü gece yarısında sona erer
    • Bu yöntem, aynı zamanda oluşturulan tokenlerin benzer son kullanma tarihlerinin birden fazla aramayı tanımlamak için kullanılmasını önlemeyi amaçlar
  • Safari şu anda desteklenmiyor
    • Kagi'nin tespitine göre Safari uzantı API'si isteklerden çerez kaldırmayı desteklemiyor
    • Çerezler kaldırılamazsa kimlik doğrulama giriş yapılmış hesap üzerinden devam eder
    • WebKit tabanlı benzer bir yerel deneyim istenirse, Privacy Pass entegrasyonuna sahip Orion Browser alternatif olarak kullanılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-14
Hacker News yorumları

  • Kagi’nin artık Privacy Pass kullanması güzel; şirketin kendisi de genel olarak iyi görünüyor.
    Ancak Kagi, bir süredir üzerinde çalıştığım IETF taslağını [1] ve Rust uygulamasını [2] fiilen alıp, onun üzerine ince bir sarmalayıcı [3] yapmış ve buna “Kagi’nin Privacy Pass uygulaması” diyor.
    Bana bir ölçüde kredi vermeleri gerekirdi diye düşünüyorum. IETF çalışmaları ve açık kaynak yazılım çalışmaları çoğunlukla gönüllü, ücretsiz ve çoğu zaman mesai saatleri dışında yapılıyor. Böyle muamele görmek motivasyon kırıcı. Kagi daha iyisini yapabilir.
    [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...

    • Dürüst olmak gerekirse yazıda geçen “Kagi’nin Privacy Pass uygulaması” RFC’nin ya da protokol uygulamasının kendisinden değil, bu özelliğin Kagi’nin sunucuları ve istemcileriyle entegrasyonundan bahsediyor gibi görünüyor. Yazıda RFC de kabul ediliyor.
    • Kagi’nin “raphaelrobert’e kredi” eklemesinin ya da lisansın bir kopyasını kodun bir yerine koymasının uyumluluk için yeterli olup olmayacağını merak ediyorum.
      Benim açık kaynak kodum fiilen hiç kullanılmadı ve genelde MIT lisansıyla dağıtıyorum; bu yüzden başka grupların ya da kuruluşların lisansa pratikte nasıl uyduğunu bilmek isterim.
    • 14 Şubat 2025 Doğu Saati ile yaklaşık 12:15’te README başlığını yakaladığımda şöyle yazıyordu:

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      Bu kesinlikle iyi hissettirmiyor. Yine de Kagi tarafındaki insanların bunu “raphaelrobert/privacypass için Crystal Lang sarmalayıcısını uygulayan çekirdek kütüphane” gibi daha doğru bir ifadeye çevirmeye açık olacağını düşünüyorum. Kasıtlı olmaktan çok, muhtemelen çalışır hâle getirmeye odaklanıp metni yeniden okuyacak birini dahil edememişlerdir.

  • Harika. Kullandığım bir hizmetin, kendisinden çok kullanıcının yararına olan bir şeyi gerçekten yaptığını görmek nadir; beklenmedik ama çok hoş bir sürpriz.
    Bu eklenti tarayıcı bağlamını otomatik olarak anlayıp daha iyi entegre olursa güzel olur. Yani normal modda oturumumu kullansın, gizli gezinme modunda (browser.extension.inIncognitoContext) ise ben ayrıca bir şey yapmadan Privacy Pass ile kimlik doğrulasın isterim.
    Orion’un GNU/Linux sürümü olmadığı için kullanmıyorum.

    • Bunun nadirleşmesinin nedeni, bu alandaki çoğu şirketin, hatta birçok teknoloji şirketinin, bir kullanıcı grubuna bir şey sunup ortaya çıkan sonucu başka bir kullanıcı grubuna satarak gelir elde eden iki taraflı pazar modeli kullanmış olması.
      Gerçek geliri yaratan taraf ikincisi olduğu için, temelde ilk grubun çıkarları ile ikinci grubun çıkarları çatışıyor ve yapı kolayca ilk gruba düşmanca hâle gelebiliyor.
      Kagi’nin ve diğer yeni teknoloji şirketlerinin ferah hissettirmesinin nedeni, bu modeli bırakıp hizmet verdikleri ve gelir elde ettikleri grubu tek tutan “eski usul” modele dönmeleri.
    • Linux için Orion üzerinde çalışmaya dün başladık.
    • Bu yöntemin dezavantajı, büyük bir ağın üzerinde değilseniz yalnızca IP adresiyle bile anonimlik bozulabilir.
      Kagi kullanıcının oturum açtığını biliyor ve kullanıcı gizli pencerede hassas aramalar yaparsa bu aramaları ilişkilendirebilir. Modlar arasında hızlıca gidip gelmek iyi bir fikir değil.
    • Belki bilmiyorsunuzdur; 2024 sonlarına doğru bir podcast’te Orion Linux sürümünü planladıklarını duyurdular.
    • Kagi’yi kullanınca doğru tercihi yapmaya alışıyorsunuz. Gerçekten kayda değer bir hata yapmamış olmaları şaşırtıcı.
      Keşke Kagi tişörtüm için de aynısı geçerli olsaydı. İkinci yıkamada etek ucu söküldü, artık pijama ve bahçe işi tişörtü oldu. Yedek ücretsiz tişört kuponu aldım ama henüz gönderilmedi.

  • Yazıda da ima edildiği gibi, hesap olmadan Privacy Pass satın alınabilecek bir mağaza olması mantıklı olur.
    Bir kripto parayı, muhtemelen Monero’yu desteklemesi gerekir; GNU Taler gibi şeyler de o teknoloji bir gün kullanılabilir hâle gelirse desteklense iyi olur.

    • Kagi Bitcoin kabul ediyor, ancak kurucu Vlad forumda bu seçeneği kullanan kişi sayısı çok az olduğu için Monero desteğine yatırım yapmanın anlamlı olmadığını söylemişti.
    • Hesap olmadan token satan üçüncü taraf bir mağazanın ideal çözüm olduğuna katılıyorum; ancak hesap olmayınca Kagi’yi kullanışlı kılan özellikleri kaçırıyorsunuz: örneğin belirli alan adlarını sonuçlardan kaldırmak ya da belirli sonuç türlerinin önceliğini yükseltmek gibi.

  • Bunun nihayetinde log tutulmadığı varsayımına dayanan bir gizlilik olup olmadığını merak ediyorum. Laf atmak için söylemiyorum; bu kısmı gerçekten anlayamıyorum
    Diyelim ki kullanıcı A, Kagi’den token istiyor ve Kagi de “tamam, sana 500 token vereyim” diyor. Kagi az önce kullanıcı A’ya verdiği 500 token’ı kaydederse, daha sonra bunlardan biri kullanıldığında o token’ın kullanıcı A’ya atanmış olduğunu anlayamaz mı?
    Elbette Kagi bu veriyi saklamazsa token’ın kendisi yalnızca geçerli/geçersiz olarak işaretlenir ve “Y gününde kullanıcı A’ya verilen geçerli token” olarak kalmaz; o zaman sorun olmaz. Ama mesele tamamen bu mu? Bir şeyi yanlış mı anlıyorum?

    • Token’ı sunucu üretmiyor; token’ı istemci üretiyor. Sunucunun, token’ın üretme yetkisi almış bir istemci tarafından oluşturulduğunu doğrulayabilmesi gerekiyor; ama hangi istemcinin oluşturduğunu bilmemesi gerekiyor. En azından yan kanal bilgileri olmadan durum böyle olmalı

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      Bu ilkel yöntemin ne kadar doğrulanmış olduğunu pek bilmiyorum, ama en azından sunucunun istemciye token dağıtıp sonra kime verdiğini bilmiyormuş gibi yapmasından çok daha fazla yapısı var gibi görünüyor
      Referans makale: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • Privacy Pass belgeleri [0] bu kısmı ele alıyor, ama daha derin açıklama ağırlıklı olarak makalenin içinde. Bence kilit nokta, sunucunun döndürdüğü token’ın istemcinin tekrar gönderdiği değiştirilmiş token ile ilişkilendirilememesi
      Sunucu, bazı kullanıcılara A, B, C token’larını döndürdüğünü ve daha sonra X, Y, Z token’larını aldığını bilebilir. X, Y, Z’nin geçerli olduğunu da bilir; ama bunların kendi verdiği token’larla hangi eşleşmeye sahip olduğunu bilmez. Burada eliptik eğri kriptografisi kullanılıyor
      [0] https://privacypass.github.io/
    • Fikir şu: token’lar hiçbir hesaba bağlı değil. Bunlar anonim token’lar
    • Privacy Pass token’larının varsayımını anlamamışsınız gibi görünüyor
      Esas nokta, sunucunun hangi token’ın hangi istemciye ait olduğunu bilmemesi. Token’ı sunucu üretmiyor

  • Kagi’de her zaman gördüğüm en büyük eksik artık çözülmüş oldu. Ürünü neredeyse herkes için cazip hâle getirmek adına dinleyip üzerinde çalıştığınız için teşekkürler

  • Kagi’yi hâlâ kullanmayan insanların en büyük şikâyetlerinden biri, giriş ve ödeme bilgisi istemesinin yarattığı gizlilik endişeleri
    Ben bu konuda endişelenen tarafta değildim, ama gerçekten endişelenen insanlar için bu değişikliğin kaygıyı ne ölçüde azalttığını merak ediyorum

    • Ben o konuda endişelenen taraftaydım ve bir arama motoruna giriş yapmak hâlâ inanılması güç geliyor. Elbette artık kaç kişinin bunu yaptığını biliyorum
      Sistemi kısaca doğruladıktan sonra artık kaydolma ihtimalim epey yüksek
    • Kriptografinin Kagi’nin söylediği gibi çalıştığını varsayarsak, bu yöntem arama isteklerini hesap bilgilerinden tamamen ayırıyor. Hesap birden fazla arama token’ı oluşturuyor ve her arama isteğinde bir token tüketiliyor
      Token’lar cihazda oluşturuluyor ve kullanılana kadar cihazdan ayrılmıyor; dolayısıyla teorik olarak Kagi’nin yalnızca token’a bakarak o token’ı hangi hesabın oluşturduğunu bilmesinin bir yolu yok. Parmak izi takibi ya da IP ilişkilendirmesini çözmüyor, ancak Firefox ve Chrome eklentilerinin parmak izi takibini azaltmaya yönelik önlemler aldığı söyleniyor. Bu, Google ya da DuckDuckGo’yu doğrudan kullanmaktan ne daha kötü ne de daha iyi; gerçekten gizlilik istiyorsanız Tor’da da çalışıyor
      Token’ı hiç paylaşmadan meşruiyetin nasıl kanıtlandığından emin değilim, ama muhtemelen bir tür ~~sıfır bilgi kanıtı~~ gibi bir şey vardır
      Düzenleme: Sıfır bilgi kanıtı değil, kör imza gibi görünüyor

  • Kagi tarafında birinin token tablosuna token’ı oluşturan kullanıcıyı ve onun SessionCookie’sini içeren yeni sütunlar eklemesini neyin engellediğini bilmiyorum
    Bunun özgün token oluşturucuyla çok kolay ilişkilendirilememesi için bir neden göremiyorum

    • Uygulayan kişiyim. Privacy Pass’in “issuance” protokolü sırasında istemci, sunucunun işleyeceği bir “mesaj” oluşturur. Sunucunun çıktısı istemciye geri döner; istemci de bu çıktıyı daha da değiştirerek nihai token’ı oluşturur
      Son istemci değiştirme adımında bu token’lar rastgeleleştirildiği için, sunucu söz konusu token’ın hangi issuance sürecine ait olduğunu belirleyemez hale gelir
      Asıl harika olan, sunucu kendi adımında kötü niyetli bir şey yapmaya çalışsa bile bunun hâlâ geçerli olması. Bu yüzden kullanıcının yalnızca istemci yazılımına güvenmesi yeterli; biz de bunu açık kaynak olarak yayımladık: https://github.com/kagisearch/privacypass-extension
      Bazı kişiler kör imzalardan bahsediyor; gerçekten de Privacy Pass bunları bir yapı taşı olarak kullanabilir. Ancak tam olarak söylemek gerekirse Kagi’de “Oblivious Pseudorandom Function”a (OPRF) dayalı “Privately Verifiable Tokens”(https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...) kullanıyoruz ve kişisel olarak OPRF’nin kör imzadan daha havalı olduğunu düşünüyorum
    • Alıntıladığınız makalede [1], yani kriptografik anonim token protokolü makalesinde anlatılan şeye benziyor. Basit bir düz metin token değil
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      Cloudflare de sanırım aynı şeyi uygulamıştı. En azından HN yorumları aynı makaleye bağlantı veriyor
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 yorum)
    • Token istemcide “oluşturulur”; sunucu, yerel olarak oluşturulan bu token’ın “geçerli” hale gelmesi için yeterli bilgiyi istemciye verir. Bunu yaparken de o token’ı belirli bir doğrulama denemesiyle ilişkilendiremez
    • Ben de tam olarak bu soruyu düşündüm. Sunucu tarafındaki güvene dayanamayacağımıza göre, acaba bir şeyi yanlış mı anladım diye merak ediyorum
    • Doğru anladıysam “Privacy Pass” kör imza kullandığı için, TokenResponse içindeki token ile arama sorgusunda sunulan token birbiriyle ilişkilendirilemiyor

  • Bu gerçekten çalışıyor mu? Token’lar yalnızca bir kez kullanılabildiği için pratikte istemci belirli bir arama oturumu içinde token oluşturup kullanan bir döngüye girecek; bu durumda çiftleri eşleştirmek çok kolaylaşır. Yazıda da şöyle deniyor

    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 mekânı rastgeleleştirir, peki ya zaman ne olacak? Bu yüzden “aşağıya bakın” kısmına baktım ama ilgili bir şey bulamadım. Yeterli istek hacmi varsa istemcilerin zaman açısından birbirlerini gizlemesi fikri mi var?
    Ayrıca Tor da oturumu sürekli yeniden oluşturmadığınız sürece mekânı rastgeleleştirmede sınırlı. Bildiğim kadarıyla devre oturum boyunca sabit kalıyor ve oturumu yeniden oluşturmak yaklaşık 10 saniye sürüyor. O halde gerçekten mekânı rastgeleleştiriyor denebilir mi?

    • Tek bir token isteği N adet token oluşturabilir. Biz N = 500 olarak ayarladık; bu yüzden çoğu kullanıcı oldukça seyrek şekilde yeni token isteyecek

  • Gerçekten çok havalı ve harika bir iş
    Daha önce Privacy Pass’e benzer kör imza kimlik doğrulaması yapmıştım; çoklu cihaz erişimini nasıl ele alacağınızı merak ediyorum
    Muhtemelen başka cihazlarda token erişimini kaybetme sorununu azaltmak için önce yalnızca sınırsız arama kullanıcılarına sunduğunuzu anlıyorum. Uzun vadeli plana dair bir fikriniz var mı merak ediyorum. Geçmişte böyle sistemler yaptığımda bunu her zaman uçtan uca şifreli senkronizasyonla bağlamak zorunda kalıyordum. Bu son kullanıcı için zahmetli olmanın yanı sıra, depolama güncellemeleriyle kör arama isteklerini birbiriyle ilişkilendirme ihtimali de yaratıyor
    Her hâlükârda gerçekten müthiş; artık Kagi’ye sadece güvenmek yerine güvenmek zorunda olmadığımızı doğrulayabilecek olmak beni daha da heyecanlandırıyor

    • Evet, çoklu cihaz kesinlikle kolay değil. Birkaç fikri denedik ama bunun net bir cevabı olan bir problem olduğunu söyleyemem
      Şimdilik hız sınırlaması yoluyla her cihazın bağımsız olarak token oluşturmasına izin vererek Privacy Pass’i birden fazla cihazda kullanılabilir kılıyoruz. Nasıl gittiğine bakıp kullanıcı geri bildirimlerini dinledikten sonra yeniden çizim masasına döneceğiz

  • Bu, Cloudflare’ın istemcilerin CAPTCHA’yı atlamasına izin vermek için kullandığı Privacy Pass ile aynı şey mi? Öyleyse bu sistemin gerçekten temiz bir uygulaması. Ücretli bir serviste anonim kimlik doğrulama için kullanılabileceğini hiç düşünmemiştim