Autentikasi Privacy Pass untuk pencarian Kagi

 (blog.kagi.com)
2 poin oleh GN⁺ 2025-02-14 | 1 komentar | Bagikan ke WhatsApp
  • Kagi Search memperkenalkan autentikasi Privacy Pass untuk memverifikasi hak akses pencarian berbayar tanpa menghubungkan permintaan pencarian secara langsung ke akun
  • Metode ini memisahkan pembuatan token dan penggunaan token, sehingga Kagi dapat memverifikasi validitasnya tetapi tidak dapat melacak balik pengguna atau waktu pembuatannya hanya dari token
  • Target awalnya adalah paket Professional, Ultimate, Family, Team yang mencakup pencarian tanpa batas, sementara Trial dan Starter yang memiliki batas jumlah pencarian tidak disertakan karena masih ada masalah kehilangan token dan penggunaan berlebih
  • Dapat langsung digunakan di Orion, aplikasi Kagi Android, serta ekstensi Chrome dan Firefox, tetapi Safari belum didukung karena keterbatasan API ekstensi
  • Hanya dengan token saja sulit menghubungkan pencarian dengan akun, tetapi side channel seperti alamat IP, fingerprint browser, pola pencarian berulang masih ada sehingga penggunaan Tor atau VPN disarankan

Autentikasi Privacy Pass ditambahkan ke Kagi Search

  • Kagi memperkenalkan autentikasi Privacy Pass ke Kagi Search sekaligus merilis layanan onion Tor
  • Privacy Pass adalah protokol autentikasi yang memungkinkan klien membuktikan hak akses tanpa membuat server dapat mengidentifikasi pengguna mana yang terhubung
  • Sebagai mesin pencari berbayar, Kagi perlu memverifikasi hak pencarian, tetapi melalui fitur ini Kagi menambahkan jaminan teknis agar permintaan pencarian tidak terhubung ke akun tertentu
  • Implementasinya berangkat dari implementasi Rust Privacy Pass oleh Raphael Robert, dan kodenya dipublikasikan di kagisearch/privacypass-extension

Paket dan klien yang didukung

  • Privacy Pass pertama kali disediakan bagi pengguna paket pencarian tanpa batas Professional, Ultimate, Family, Team
  • Paket Trial dan Starter saat ini belum didukung
    • Kedua paket tersebut memiliki batas jumlah pencarian bulanan
    • Jika token yang dibuat hilang, misalnya karena ekstensi dihapus, pengalaman pengguna bisa memburuk
    • Karena saat token digunakan Kagi tidak dapat mengetahui akun atau paketnya, secara teoretis penggunaan token melebihi jumlah pencarian yang diizinkan bisa terjadi
  • Klien yang didukung adalah sebagai berikut
  • Pengguna yang memakai ekstensi Kagi Search lama perlu memperbarui ke versi terbaru atau menonaktifkannya untuk menghindari masalah kompatibilitas
    • Firefox 0.7.6
    • Chrome 1.2.2.5

Alur autentikasi Privacy Pass

  • Privacy Pass membagi autentikasi menjadi dua tahap: pembuatan token dan penggunaan token
  • Pada tahap pembuatan token, pengguna membuktikan hak untuk membuat token dengan cookie sesi Kagi
    • Dari sudut pandang server, token yang dibuat tidak dapat dibedakan dari token acak
    • Token tidak dapat dilacak ke pengguna yang membuatnya maupun ke token lain yang dibuat oleh pengguna yang sama
  • Saat melakukan permintaan pencarian, satu token yang sudah dibuat sebelumnya dikirimkan untuk membuktikan hak akses
    • Server hanya memverifikasi bahwa token tersebut pernah dibuat secara valid
    • Token tidak dapat dihubungkan ke tahap pembuatan tertentu
  • Token bersifat sekali pakai
    • Server melacak token yang sudah dipakai untuk mencegah penggunaan ulang
    • Klien juga tidak boleh mengirim token yang sama dua kali agar dua tahap penggunaan yang berbeda tidak dapat dikaitkan
  • Token memiliki masa berlaku tetap, sehingga token yang terlalu lama harus dibuat ulang

Model implementasi Kagi dan properti keamanan

  • Model deployment Kagi mengikuti struktur standar Privacy Pass Shared Origin, Attester, Issuer
    • Kagi menjalankan sekaligus peran Attester, Issuer, dan Origin
    • Pengguna menjalankan peran klien melalui ekstensi browser Privacy Pass atau dukungan bawaan Orion
  • Setelah dipasang dan secara berkala sesudahnya, ekstensi membuat dan menyimpan banyak token
  • Saat mencari, pengguna dapat memilih lewat toggle apakah ingin autentikasi memakai cookie sesi yang ada atau token Privacy Pass
  • Ada tiga properti perlindungan untuk pengguna
    • Ketakterhubungan pembuatan-penggunaan: Kagi tidak dapat menghubungkan token yang dikirim saat pencarian ke tahap pembuatan token tertentu
    • Ketakterhubungan penggunaan-penggunaan: Kagi tidak dapat mengetahui hanya dari token apakah dua pencarian berbeda berasal dari pengguna yang sama
    • Pencegahan pembajakan penggunaan: penyadap yang mengamati proses pembuatan token tidak dapat mencuri dan memakai token hanya dari informasi itu
  • Ada juga properti yang melindungi Kagi
    • Token yang dibuat secara sah akan lolos verifikasi Kagi
    • Klien jahat tidak dapat memalsukan token valid baru meskipun mengetahui token yang dibuat dengan benar

Fitur yang berkurang dalam mode Privacy Pass

  • Dalam mode Privacy Pass, Kagi tidak dapat mengidentifikasi pengguna sehingga pengaturan akun tidak dapat diterapkan
  • Kagi menyediakannya sebagai pilihan antara “privasi umum dan fitur penuh” atau “privasi maksimal dan fitur inti”
  • Kagi Assistant tidak dapat digunakan dengan Privacy Pass pada saat peluncuran
    • Kagi Assistant hanya tersedia untuk anggota Ultimate
    • Dalam Privacy Pass tidak ada informasi akun untuk memverifikasi paket apa yang digunakan
  • Pada saat peluncuran, Privacy Pass hanya dipakai untuk autentikasi Kagi Search
  • Dalam beberapa minggu berikutnya, Kagi berencana memperluas dukungan ke layanan berikut
    • Kagi Assistant
    • Kagi Translate dan Kagi Maps
    • Kagi Universal Summarizer dan Ask questions about page
  • Untuk saat ini, layanan-layanan tersebut mengharuskan Privacy Pass dinonaktifkan

Side channel dan penggunaan Tor

  • Privacy Pass mencegah keterhubungan antara pembuatan token dan penggunaan token hanya dari token itu sendiri, tetapi tidak dapat sepenuhnya memodelkan seluruh interaksi online secara matematis
  • Server yang berniat jahat dapat mencoba melacak klien melalui informasi side channel
    • Jika seseorang mengulangi pencarian yang sama dan sangat spesifik setiap hari pada waktu yang sama, pencarian-pencarian itu bisa diduga berasal dari orang yang sama
    • Sinyal seperti user-agent browser dan alamat IP adalah informasi di luar Privacy Pass
    • Jika dari IP yang sama ada permintaan penggunaan token segera setelah permintaan pembuatan token, kemungkinan keduanya dianggap berasal dari individu yang sama
  • RFC 9576 merekomendasikan pemisahan waktu antara pembuatan dan penggunaan token, atau pemisahan lokasi melalui layanan anonimisasi seperti Tor
  • Ekstensi Privacy Pass Kagi dan implementasi bawaan Orion menghapus header HTTP dan cookie untuk membuat fingerprint browser seseragam mungkin
  • Kagi menyediakan alamat onion yang dapat diakses langsung dari jaringan Tor
  • Jika hanya menggunakan Tor, alamat IP memang tersembunyi, tetapi bila masih login tanpa Privacy Pass pencarian secara teoretis tetap bisa dihubungkan ke satu akun
  • Jika Tor dan Privacy Pass dipakai bersama, Kagi hanya mengetahui bahwa pencarian tersebut berasal dari pengguna yang sebelumnya diverifikasi berhak menerima token, tanpa mengetahui akun atau lokasinya

Jumlah token, performa, dan ruang penyimpanan

  • Pengguna paket pencarian tanpa batas dapat membuat 2.000 token per epoch, yaitu satu bulan
  • Jika membutuhkan token tambahan, pengguna dapat memintanya ke support@kagi.com
  • Pembuatan 500 token pencarian membutuhkan sekitar 1 detik komputasi pada laptop konsumen biasa
    • Karena waktu koneksi dan respons server, proses ini bisa memakan beberapa detik tambahan
    • Saat ekstensi dipasang, proses ini dilakukan di latar belakang sebisa mungkin
  • Satu token berukuran 216 byte, dan ruang penyimpanan per permintaan pembuatan token sekitar 100KiB
  • Saat ini server verifikasi token hanya dideploy di region us-central1, dan Kagi berencana memperluasnya segera setelah peluncuran

Alasan personalisasi dan pengaturan dibatasi

  • Dalam pencarian Privacy Pass, Kagi tidak mengetahui siapa penggunanya sehingga tidak dapat memberikan hasil yang disesuaikan dengan pengaturan kustom pengguna
  • Kagi sempat meninjau opsi mengirim pengaturan kecil seperti (language, region, safe-search) pada tiap permintaan, tetapi saat ini menilai hal itu dapat sangat mengurangi anonimitas
  • Dalam analisis contoh, pengguna yang mengirim pengaturan bahasa tertentu seperti Lang 10 dapat otomatis kehilangan jaminan ketakterhubungan penggunaan-penggunaan ketika jumlah pengguna Privacy Pass sekitar 1.000 orang
  • Kagi menilai estimasi ini mungkin terlalu konservatif, tetapi untuk saat ini tidak mengaktifkan tingkat personalisasi dasar bagi pengguna autentikasi Privacy Pass
  • Pengaturan pencarian manual sebagian masih bisa diterapkan dengan menambahkan bangs ke kueri pencarian
    • Misalnya, menambahkan !de di depan kueri akan melakukan pencarian wilayah Jerman
  • Jika menginginkan pengalaman pencarian yang sepenuhnya dipersonalisasi, pengguna harus memakai metode login lama dan menonaktifkan Privacy Pass

Batasan Safari, jendela privat, dan lainnya

  • Privacy Pass tidak menggunakan blockchain
    • Ia menggunakan kurva eliptik, fungsi hash, dan struktur verifiable oblivious pseudorandom function
    • Token tidak dibuat, disimpan, atau diperdagangkan di blockchain
  • Di jendela privat Chrome dan Firefox, pembuatan token tidak berfungsi
    • Pembuatan token memerlukan akses ke cookie sesi
    • Di jendela privat, ekstensi tidak dapat mengakses cookie sesi
    • Di Orion, pembuatan token tetap berfungsi di jendela privat
  • Meski Privacy Pass diaktifkan, karena cara kerja TCP/IP Kagi tetap dapat melihat alamat IP dari permintaan pencarian
    • Jika khawatir soal paparan alamat IP, disarankan menggunakan Tor atau VPN tepercaya
  • Semua token kedaluwarsa pada tengah malam hari pertama bulan X+2, dengan acuan bulan pembuatan X
    • Cara ini dipilih untuk menghindari masalah ketika tanggal kedaluwarsa yang mirip dari token yang dibuat pada saat yang sama dipakai untuk mengidentifikasi beberapa pencarian
  • Safari saat ini belum didukung
    • Menurut pemahaman Kagi, API ekstensi Safari tidak mendukung penghapusan cookie dari permintaan
    • Jika cookie tidak dapat dihapus, autentikasi akan tetap dilakukan dengan akun yang sedang login
    • Jika menginginkan pengalaman native serupa berbasis WebKit, Orion Browser yang sudah mengintegrasikan Privacy Pass dapat menjadi alternatif

Bacaan terkait

1 komentar

 
GN⁺ 2025-02-14
Pendapat Hacker News

  • Bagus bahwa Kagi kini memakai Privacy Pass, dan perusahaannya sendiri secara umum terlihat cukup baik
    Namun Kagi pada dasarnya mengambil draf IETF [1] dan implementasi Rust [2] yang sempat saya kerjakan cukup lama, lalu membuat wrapper tipis [3] di atasnya dan menyebutnya “implementasi Privacy Pass milik Kagi”
    Menurut saya, semestinya mereka memberi saya kredit sampai batas tertentu. Pekerjaan IETF dan perangkat lunak open source sebagian besar bersifat sukarela dan tidak dibayar, serta sering dilakukan di luar jam kerja. Diperlakukan seperti ini membuat motivasi hilang. Kagi seharusnya bisa lebih baik
    [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...

    • Sejujurnya, “implementasi Privacy Pass milik Kagi” yang disebut dalam tulisan itu tampaknya bukan merujuk pada implementasi RFC atau protokol itu sendiri, melainkan bagian yang mengintegrasikan fungsi tersebut ke server dan klien Kagi. RFC juga diakui dalam tulisannya
    • Saya penasaran apakah Kagi akan dianggap patuh jika menambahkan “kredit untuk raphaelrobert”, atau menaruh salinan lisensinya di suatu tempat dalam kode
      Open source saya sendiri belum pernah benar-benar dipakai dan biasanya saya rilis dengan lisensi MIT, jadi saya ingin tahu bagaimana grup atau organisasi lain benar-benar mematuhi lisensi dalam praktiknya
    • Saat saya mengambil tangkapan layar header README sekitar pukul 12.15 siang Waktu Timur pada 14 Februari 2025, tertulis seperti ini

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      Ini jelas terasa kurang enak. Namun orang-orang Kagi tampaknya akan terbuka untuk mengubahnya menjadi sesuatu yang lebih akurat, seperti “library inti yang mengimplementasikan wrapper Crystal Lang untuk raphaelrobert/privacypass”. Kemungkinan besar ini bukan disengaja, melainkan mereka terlalu fokus membuatnya berfungsi dan tidak sempat meminta seseorang membaca ulang redaksinya

  • Keren. Jarang melihat layanan yang saya gunakan benar-benar melakukan sesuatu yang lebih menguntungkan pengguna daripada dirinya sendiri; ini kejutan yang tak terduga tetapi sangat menyenangkan
    Saya berharap ekstensi ini bisa memahami konteks browser secara otomatis agar integrasinya lebih baik. Artinya, di mode biasa ia memakai sesi saya, dan di mode penjelajahan privat (browser.extension.inIncognitoContext) ia mengautentikasi dengan Privacy Pass tanpa saya perlu melakukan apa pun secara terpisah
    Saya tidak memakai Orion karena tidak ada versi GNU/Linux

    • Alasan hal seperti ini makin jarang adalah karena sebagian besar perusahaan di bidang ini, bahkan banyak perusahaan teknologi, selama ini memakai model pasar dua sisi: menyediakan sesuatu kepada satu kelompok pengguna, lalu menjual hasilnya kepada kelompok pengguna lain untuk menghasilkan pendapatan
      Karena pihak yang benar-benar menghasilkan pendapatan adalah kelompok kedua, pada dasarnya kepentingan kelompok pertama dan kedua mudah berbenturan, dan strukturnya cenderung bermusuhan terhadap kelompok pertama
      Yang terasa segar dari Kagi dan perusahaan teknologi baru lainnya adalah mereka meninggalkan model ini dan kembali ke model “gaya lama”, yaitu kelompok yang mereka layani sekaligus sumber pendapatan mereka adalah satu kelompok yang sama
    • Pekerjaan untuk Orion versi Linux dimulai kemarin
    • Kekurangan pendekatan ini adalah, jika Anda tidak berada di atas jaringan yang besar, alamat IP saja bisa merusak anonimitas
      Kagi tahu bahwa pengguna sudah login, dan jika pengguna melakukan pencarian sensitif di jendela privat, Kagi bisa mengaitkan pencarian-pencarian itu. Berpindah cepat antar-mode bukan hal yang disarankan
    • Kalau belum tahu, sekitar akhir 2024 mereka mengumumkan di sebuah podcast bahwa versi Orion untuk Linux sedang direncanakan
    • Kalau memakai Kagi, Anda jadi terbiasa melihat pilihan yang benar. Mengejutkan sekali bahwa hampir tidak ada kesalahan berarti
      Semoga kaus Kagi saya juga begitu. Pada cucian kedua, kelim bawahnya lepas, jadi sekarang menjadi kaus untuk tidur sekaligus kerja di halaman. Saya memang mendapat kupon kaus pengganti gratis, tetapi belum dikirim

  • Seperti yang juga diisyaratkan dalam tulisan, masuk akal jika ada toko tempat membeli Privacy Pass tanpa akun
    Mereka perlu mendukung suatu cryptocurrency, mungkin Monero, dan alangkah baiknya juga mendukung sesuatu seperti GNU Taler jika teknologinya suatu hari menjadi cukup layak dipakai

    • Kagi menerima Bitcoin, tetapi pendirinya, Vlad, mengatakan di forum bahwa terlalu sedikit orang memakai opsi ini sehingga tidak masuk akal untuk berinvestasi pada dukungan Monero
    • Saya setuju bahwa toko pihak ketiga yang menjual token tanpa akun adalah solusi ideal, tetapi tanpa akun Anda akan kehilangan fitur-fitur yang membuat Kagi layak dipakai, misalnya menghapus domain tertentu dari hasil atau menaikkan prioritas jenis hasil tertentu

  • Saya penasaran apakah ini pada akhirnya adalah privasi yang mengandalkan asumsi bahwa log tidak disimpan. Bukan bermaksud mendebat, saya benar-benar tidak memahami bagian ini
    Misalkan pengguna A meminta token ke Kagi, lalu Kagi berkata, “Oke, saya beri 500 token.” Jika Kagi mencatat 500 token yang baru saja diberikan kepada pengguna A, bukankah nanti saat salah satunya digunakan, Kagi bisa tahu bahwa token itu dialokasikan ke pengguna A?
    Tentu saja, kalau Kagi tidak menyimpan data ini, token itu sendiri hanya ditandai valid/tidak valid dan tidak tersisa sebagai “token valid yang diberikan kepada pengguna A pada hari Y”, jadi tidak masalah. Tapi apakah memang hanya itu? Apakah saya salah paham?

    • Server bukan yang membuat token; klienlah yang membuat token. Server harus bisa memverifikasi bahwa token itu dibuat oleh klien yang mendapatkan otorisasi untuk membuatnya, tetapi tidak boleh bisa mengetahui klien mana yang membuatnya. Setidaknya begitu jika tidak ada informasi side-channel

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      Saya tidak tahu seberapa teruji primitif ini, tetapi setidaknya tampaknya ada struktur yang jauh lebih banyak daripada server membagikan token ke klien lalu pura-pura tidak tahu memberikannya kepada siapa
      Makalah referensi: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • Dokumentasi Privacy Pass [0] membahas bagian ini, tetapi penjelasan yang lebih mendalam terutama ada di dalam makalahnya. Intinya, menurut saya, token yang dikembalikan server tidak dapat dikaitkan dengan token yang dimodifikasi dan dikirim kembali oleh klien
      Server bisa tahu bahwa ia mengembalikan token A, B, C kepada sejumlah pengguna, lalu kemudian menerima token X, Y, Z. Server juga tahu bahwa X, Y, Z valid, tetapi tidak tahu korespondensinya dengan token yang diterbitkannya. Kriptografi kurva eliptik digunakan di sini
      [0] https://privacypass.github.io/
    • Idenya adalah token tidak terhubung ke akun mana pun. Itu adalah token anonim
    • Sepertinya Anda belum memahami asumsi dasar token Privacy Pass
      Intinya adalah server tidak tahu token mana milik klien yang mana. Server tidak membuat token

  • Kekurangan terbesar Kagi yang selalu saya lihat sekarang sudah teratasi. Terima kasih karena telah mendengarkan dan mengerjakannya agar produk ini menarik bagi hampir semua orang

  • Salah satu keluhan terbesar dari orang-orang yang belum memakai Kagi adalah kekhawatiran privasi karena harus login dan memberikan informasi pembayaran
    Saya sendiri bukan termasuk yang mengkhawatirkan bagian itu, tetapi saya penasaran seberapa jauh perubahan ini meredakan kekhawatiran orang-orang yang memang benar-benar khawatir

    • Saya termasuk yang mengkhawatirkannya, dan sampai sekarang masih terasa sulit dipercaya harus login ke mesin pencari. Tentu saja saya tahu sekarang berapa banyak orang yang melakukannya
      Setelah memverifikasi sistemnya secara sederhana, kemungkinan besar sekarang saya akan mendaftar
    • Dengan asumsi kriptografinya bekerja seperti yang Kagi katakan, pendekatan ini sepenuhnya memisahkan permintaan pencarian dari informasi akun. Strukturnya adalah akun membuat beberapa token pencarian, lalu satu token dikonsumsi untuk setiap permintaan pencarian
      Token dibuat di perangkat dan tidak meninggalkan perangkat sampai digunakan, jadi secara teori Kagi tidak punya cara untuk mengetahui akun mana yang membuat token itu hanya dari tokennya. Ini tidak menyelesaikan fingerprinting atau korelasi IP, tetapi katanya plugin untuk Firefox dan Chrome mengambil langkah-langkah untuk mengurangi fingerprinting. Ini tidak lebih buruk maupun lebih baik daripada sekadar memakai Google atau DuckDuckGo, dan kalau benar-benar menginginkan privasi, ini juga berjalan di Tor
      Saya tidak yakin bagaimana mereka membuktikan keabsahan tanpa membagikan token sama sekali, tetapi mungkin ada semacam ~~zero-knowledge proof~~ di dalamnya
      Sunting: sepertinya bukan zero-knowledge proof, melainkan blind signature

  • Saya tidak tahu apa yang mencegah seseorang di pihak Kagi menambahkan kolom baru ke tabel token yang berisi pengguna yang membuat token dan SessionCookie-nya
    Saya tidak melihat alasan mengapa token itu tidak bisa sangat mudah dikaitkan dengan pembuat aslinya

    • Saya implementornya. Dalam protokol “issuance” Privacy Pass, klien membuat “pesan” yang akan diproses server. Output server dikembalikan ke klien, lalu klien memodifikasi lagi output ini untuk membuat token final
      Karena token-token ini diacak pada tahap modifikasi terakhir oleh klien, server tidak lagi bisa mengidentifikasi token tersebut termasuk proses issuance yang mana
      Bagian yang benar-benar keren adalah hal ini tetap berlaku bahkan jika server mencoba berbuat curang pada tahapnya sendiri. Jadi pengguna hanya perlu memercayai perangkat lunak klien, dan kami telah membukanya sebagai open source: https://github.com/kagisearch/privacypass-extension
      Beberapa orang menyebut tanda tangan buta, dan memang Privacy Pass dapat memanfaatkannya sebagai komponen. Namun tepatnya, di Kagi kami memakai “Privately Verifiable Tokens”(https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...) yang berbasis “Oblivious Pseudorandom Function” (OPRF), dan secara pribadi saya menganggap OPRF lebih keren daripada tanda tangan buta
    • Sepertinya ini yang dijelaskan dalam makalah protokol token anonim kriptografis yang dikutip [1]. Ini bukan sekadar token teks biasa
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      Cloudflare sepertinya juga pernah mengimplementasikan hal yang sama. Setidaknya komentar-komentar HN menautkan makalah yang sama
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
    • Token “dibuat” di sisi klien, dan server hanya memberi klien informasi yang cukup agar token yang dibuat secara lokal itu menjadi “valid”. Namun token itu tetap tidak bisa dikaitkan dengan upaya verifikasi tertentu
    • Saya juga terpikir pertanyaan yang persis sama. Kita tidak bisa bergantung pada kepercayaan di sisi server, jadi saya penasaran apakah saya salah paham
    • Jika saya memahaminya dengan benar, “Privacy Pass” memakai tanda tangan buta, sehingga token yang ada di TokenResponse dan token yang diberikan pada kueri pencarian tidak bisa saling dikaitkan

  • Apakah ini benar-benar berfungsi dalam praktik? Token hanya bisa dipakai sekali, jadi secara realistis klien akan menjalankan loop membuat dan memakai token dalam sesi pencarian tertentu, dan itu membuat pemasangan keduanya sangat mudah. Tulisannya juga mengatakan begini

    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 akan mengacak ruang, tapi bagaimana dengan waktu? Jadi saya melihat bagian “lihat di bawah”, tetapi tidak menemukan pembahasan terkait. Apakah idenya, jika volume permintaan cukup besar, klien-klien akan saling menyamarkan dari sisi waktu?
    Selain itu, Tor pun punya batasan dalam mengacak ruang kecuali terus-menerus membuat sesi baru. Setahu saya, circuit tetap selama sesi, dan membuat ulang sesi butuh sekitar 10 detik. Kalau begitu, apakah itu benar-benar bisa dianggap mengacak ruang?

    • Satu permintaan token dapat membuat N token. Kami menetapkan N = 500, jadi sebagian besar pengguna hanya akan meminta token baru cukup jarang

  • Ini benar-benar keren dan pekerjaan yang luar biasa
    Dulu saya pernah membuat autentikasi tanda tangan buta yang mirip Privacy Pass, dan saya penasaran bagaimana kalian menangani akses multi-perangkat
    Saya berasumsi ini diluncurkan terlebih dahulu hanya untuk pengguna pencarian tak terbatas agar mengurangi masalah kehilangan akses token di perangkat lain. Saya penasaran apakah ada ide untuk rencana jangka panjang. Saat dulu membuat sistem seperti ini, saya selalu harus mengaitkannya dengan sinkronisasi terenkripsi end-to-end. Itu bukan hanya merepotkan bagi pengguna akhir, tetapi juga membuka kemungkinan untuk mengaitkan pembaruan penyimpanan dengan permintaan pencarian buta
    Bagaimanapun, ini benar-benar hebat, dan saya makin antusias karena sekarang kita bisa memverifikasi bahwa kita tidak perlu memercayai Kagi begitu saja, melainkan tidak perlu memercayainya

    • Benar, multi-perangkat jelas tidak mudah. Kami sudah bereksperimen dengan beberapa ide, tetapi ini bukan masalah yang punya jawaban jelas
      Untuk saat ini, kami memungkinkan Privacy Pass dipakai di beberapa perangkat dengan cara setiap perangkat membuat token secara independen melalui pembatasan laju. Kami akan melihat bagaimana perkembangannya, mendengar masukan pengguna, lalu kembali ke papan desain

  • Apakah ini Privacy Pass yang sama seperti yang dipakai Cloudflare untuk mengizinkan klien melewati CAPTCHA? Kalau ya, ini penerapan sistem yang benar-benar rapi. Saya tidak pernah terpikir bahwa ini bisa dipakai untuk autentikasi anonim ke layanan berbayar