Kagi 검색을 위한 Privacy Pass 인증

 (blog.kagi.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Kagi Search는 유료 검색 권한을 확인하면서도 검색 요청을 계정과 직접 연결하지 않기 위해 Privacy Pass 인증을 도입함
  • 이 방식은 토큰 생성과 토큰 사용을 분리해, Kagi가 유효성은 검증하되 토큰만으로 사용자나 생성 시점을 역추적하지 못하게 함
  • 초기 대상은 무제한 검색이 포함된 Professional, Ultimate, Family, Team 플랜이며, 검색량 제한이 있는 Trial과 Starter는 토큰 분실·초과 사용 문제가 남아 제외됨
  • Orion, Kagi Android 앱, Chrome·Firefox 확장에서 바로 사용할 수 있고, Safari는 확장 API 제약 때문에 아직 지원되지 않음
  • 토큰만으로는 검색과 계정을 연결하기 어렵지만, IP 주소·브라우저 핑거프린트·반복 검색 패턴 같은 사이드 채널은 남아 Tor나 VPN 사용이 권장됨

Kagi Search에 추가된 Privacy Pass 인증

  • Kagi는 Kagi Search에 Privacy Pass 인증을 도입하면서 Tor onion service도 함께 공개함
  • Privacy Pass는 클라이언트가 접근 권한을 증명하되, 서버가 어떤 사용자가 접속했는지 식별하지 못하게 하는 인증 프로토콜임
  • 유료 검색 엔진인 Kagi는 검색 권한 확인이 필요하지만, 이 기능을 통해 검색 요청을 특정 계정과 연결하지 않는 기술적 보장을 추가함
  • 구현은 Raphael Robert의 Rust Privacy Pass 구현을 출발점으로 삼았고, 코드는 kagisearch/privacypass-extension에 공개됨

지원 플랜과 클라이언트

  • Privacy Pass는 먼저 무제한 검색 플랜인 Professional, Ultimate, Family, Team 사용자에게 제공됨
  • Trial과 Starter 플랜은 현재 지원되지 않음
    • 두 플랜은 월간 검색 수가 제한되어 있음
    • 확장 삭제 등으로 생성된 토큰을 잃으면 사용자 경험이 나빠질 수 있음
    • Kagi는 토큰 사용 시점에 계정이나 플랜을 알 수 없어, 이론적으로 허용 검색 수보다 많은 토큰 사용이 가능해질 수 있음
  • 지원 클라이언트는 다음과 같음
  • 기존 Kagi Search 확장을 쓰는 사용자는 호환성 문제를 피하려면 최신 버전으로 업데이트하거나 비활성화해야 함
    • Firefox는 0.7.6
    • Chrome은 1.2.2.5

Privacy Pass의 인증 흐름

  • Privacy Pass는 인증을 토큰 생성과 토큰 사용 두 단계로 나눔
  • 토큰 생성 단계에서는 사용자가 Kagi 세션 쿠키로 토큰 생성 권한을 증명함
    • 생성된 토큰은 서버 관점에서 무작위 토큰과 구별되지 않음
    • 토큰은 생성한 사용자나 같은 사용자가 만든 다른 토큰으로 추적될 수 없음
  • 검색 요청 때는 미리 만든 토큰 하나를 제출해 접근 권한을 증명함
    • 서버는 해당 토큰이 유효하게 생성된 적이 있다는 사실만 확인함
    • 토큰을 특정 생성 단계와 연결할 수 없음
  • 토큰은 1회용임
    • 서버는 이미 사용된 토큰을 추적해 중복 사용을 막음
    • 클라이언트도 같은 토큰을 두 번 제출하지 않아야 서로 다른 사용 단계가 연결되지 않음
  • 토큰에는 고정 수명이 있어, 너무 오래된 토큰은 새로 생성해야 함

Kagi 구현 모델과 보안 속성

  • Kagi의 배포 모델은 Privacy Pass 표준의 Shared Origin, Attester, Issuer 구조를 따름
    • Kagi가 Attester, Issuer, Origin 역할을 모두 수행함
    • 사용자는 Privacy Pass 브라우저 확장이나 Orion 기본 지원을 통해 클라이언트 역할을 수행함
  • 확장은 설치 후와 이후 주기적으로 많은 수의 토큰을 생성해 저장함
  • 사용자는 검색 시 기존 세션 쿠키로 인증할지, Privacy Pass 토큰으로 인증할지 토글로 선택함
  • 사용자 보호 속성은 세 가지임
    • 생성-사용 비연결성: Kagi는 검색 시 제출된 토큰을 특정 토큰 생성 단계와 연결할 수 없음
    • 사용-사용 비연결성: Kagi는 서로 다른 두 검색이 같은 사용자에게서 온 것인지 토큰만으로 알 수 없음
    • 사용 탈취 방지: 토큰 생성 과정을 관찰한 도청자가 그 정보만으로 토큰을 훔쳐 사용할 수 없음
  • Kagi를 보호하는 속성도 포함됨
    • 정상적으로 생성된 토큰은 Kagi 검증을 통과함
    • 악의적 클라이언트는 올바르게 생성된 토큰을 알고 있어도 새 유효 토큰을 위조할 수 없음

Privacy Pass 모드에서 줄어드는 기능

  • Privacy Pass 모드에서는 Kagi가 사용자를 식별할 수 없어 계정 설정을 적용할 수 없음
  • Kagi는 이를 “일반 프라이버시와 전체 기능” 또는 “최대 프라이버시와 핵심 기능” 사이에서 사용자가 선택하는 구조로 제공함
  • Kagi Assistant는 출시 시점에 Privacy Pass에서 사용할 수 없음
    • Kagi Assistant는 Ultimate 멤버에게만 제공됨
    • Privacy Pass에서는 계정 정보가 없어 어떤 플랜인지 검증할 수 없음
  • 출시 시점의 Privacy Pass는 Kagi Search 인증에만 쓰임
  • Kagi는 이후 몇 주 안에 다음 서비스로 지원을 확대할 계획임
    • Kagi Assistant
    • Kagi Translate와 Kagi Maps
    • Kagi Universal Summarizer와 Ask questions about page
  • 현재 이들 서비스를 쓰려면 Privacy Pass를 비활성화해야 함

사이드 채널과 Tor 사용

  • Privacy Pass는 토큰만으로 토큰 생성과 사용을 연결할 수 없게 하지만, 온라인 상호작용 전체를 수학적 모델로 완전히 설명할 수는 없음
  • 악의적 서버는 사이드 채널 정보로 클라이언트를 추적하려 할 수 있음
    • 매일 같은 시간에 같은 구체적 검색을 반복하면 검색들이 같은 사람에게서 왔다고 추정될 수 있음
    • 브라우저 user-agent, IP 주소 같은 신호는 Privacy Pass 바깥의 정보임
    • 같은 IP에서 토큰 생성 요청 직후 토큰 사용 요청이 오면 같은 개인의 요청으로 볼 가능성이 있음
  • RFC 9576은 토큰 생성과 사용을 시간적으로 분리하거나, Tor 같은 익명화 서비스로 공간적으로 분리할 것을 권장함
  • Kagi의 Privacy Pass 확장과 Orion 기본 구현은 HTTP 헤더와 쿠키를 제거해 브라우저 핑거프린트를 가능한 한 균일하게 만들도록 처리함
  • Kagi는 Tor 네트워크에서 직접 접근할 수 있는 onion 주소를 제공함
  • Tor만 쓰면 IP 주소는 숨겨지지만, Privacy Pass 없이 로그인한 상태에서는 검색이 이론적으로 단일 계정에 연결될 수 있음
  • Tor와 Privacy Pass를 함께 쓰면 Kagi는 해당 검색이 이전에 토큰을 받을 권한을 검증한 사용자에게서 왔다는 점만 알며, 계정이나 위치는 알 수 없음

토큰 수, 성능, 저장 공간

  • 무제한 검색 플랜 사용자는 한 epoch, 즉 한 달에 2,000개 토큰을 생성할 수 있음
  • 추가 토큰이 필요하면 support@kagi.com으로 요청할 수 있음
  • 500개 검색 토큰 생성에는 일반 소비자용 노트북에서 약 1초의 연산이 필요함
    • 서버 접속과 응답 시간 때문에 몇 초가 더 걸릴 수 있음
    • 확장 설치 시 가능한 한 백그라운드에서 수행됨
  • 토큰 하나는 216바이트이며, 토큰 생성 요청당 저장 공간은 약 100KiB임
  • 현재 토큰 검증 서버는 us-central1 리전에만 배포되어 있고, Kagi는 출시 직후 확장할 계획임

개인화와 설정이 제한되는 이유

  • Privacy Pass 검색에서는 Kagi가 사용자를 알 수 없어, 사용자의 커스텀 설정에 맞춘 결과를 제공할 수 없음
  • Kagi는 요청마다 (language, region, safe-search) 같은 작은 설정을 보내는 방안을 검토했지만, 현재는 익명성이 크게 줄어들 수 있다고 판단함
  • 예시 분석에서 특정 언어 설정인 Lang 10을 보내는 사용자는 Privacy Pass 사용자가 약 1,000명일 때 사용-사용 비연결성 보장을 자동으로 잃을 수 있음
  • Kagi는 이 추정이 지나치게 보수적일 수 있다고 보지만, 현재는 Privacy Pass 인증 사용자에게 기본 개인화 수준을 활성화하지 않음
  • 수동 검색 설정은 검색어에 bangs를 붙여 일부 적용할 수 있음
    • 예를 들어 !de를 검색어 앞에 붙이면 독일 지역 검색을 수행함
  • 완전한 개인화 검색 경험을 원하면 기존 로그인 방식을 사용하고 Privacy Pass를 비활성화해야 함

Safari·사생활 보호 창 등 제약

  • Privacy Pass는 블록체인을 사용하지 않음
    • 타원곡선, 해시 함수, 검증 가능한 망각 의사난수 함수 구조를 사용함
    • 토큰은 블록체인에서 생성·저장·거래되지 않음
  • Chrome·Firefox 사생활 보호 창에서는 토큰 생성이 동작하지 않음
    • 토큰 생성에는 세션 쿠키 접근이 필요함
    • 사생활 보호 창에서는 확장이 세션 쿠키에 접근할 수 없음
    • Orion에서는 사생활 보호 창에서도 토큰 생성이 동작함
  • Privacy Pass를 켜도 TCP/IP 동작 방식 때문에 Kagi는 검색 요청의 IP 주소를 볼 수 있음
    • IP 주소 노출이 걱정되면 Tor 또는 신뢰하는 VPN 사용을 권장함
  • 모든 토큰은 생성된 달 X 기준으로 X+2월 첫날 자정에 만료됨
    • 같은 시점에 생성된 토큰들의 비슷한 만료일이 여러 검색을 식별하는 데 쓰이는 문제를 피하기 위한 방식임
  • Safari는 현재 지원되지 않음
    • Safari 확장 API가 요청에서 쿠키를 제거하는 기능을 지원하지 않는 것으로 Kagi는 파악하고 있음
    • 쿠키를 제거하지 못하면 로그인 계정으로 계속 인증됨
    • WebKit 기반의 비슷한 네이티브 경험을 원하면 Privacy Pass가 통합된 Orion Browser를 대안으로 쓸 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Kagi가 이제 Privacy Pass를 쓰는 건 좋고, 회사 자체도 전반적으로 괜찮아 보임
    다만 Kagi는 내가 한동안 작업했던 IETF 초안 [1]과 Rust 구현 [2]을 사실상 가져가서, 그 위에 얇은 래퍼 [3]를 만든 뒤 “Kagi의 Privacy Pass 구현”이라고 부르고 있음
    나에게 어느 정도 크레딧은 줬어야 맞다고 봄. IETF 작업과 오픈소스 소프트웨어 작업은 대부분 자발적이고 무급이며, 근무 시간 밖에서 이뤄지는 경우가 많음. 이런 식으로 대우받으면 동기부여가 안 됨. 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 구현”은 RFC나 프로토콜 구현 자체가 아니라, 그 기능을 Kagi의 서버와 클라이언트에 통합한 부분을 가리키는 것 같음. RFC는 글에서도 인정하고 있음
    • Kagi가 “raphaelrobert에게 크레딧”을 추가하거나, 라이선스 사본을 코드 어딘가에 넣으면 준수한 것이 되는지 궁금함
      내 오픈소스가 실제로 사용된 적은 없고 보통 MIT 라이선스로 배포해서, 다른 그룹이나 조직이 실제로 라이선스를 어떻게 준수하는지 알고 싶음
    • 2025년 2월 14일 동부시간 오후 12시 15분쯤 README 헤더를 캡처했을 때 이렇게 적혀 있었음

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      이건 확실히 느낌이 좋지 않음. 다만 Kagi 쪽 사람들이 “raphaelrobert/privacypass용 Crystal Lang 래퍼를 구현한 핵심 라이브러리”처럼 더 정확하게 바꾸는 데 열려 있을 것 같음. 의도적이라기보다는 동작하게 만드는 데 집중하다가 문구를 다시 읽어볼 사람을 붙이지 못했을 가능성이 큼

  • 멋짐. 내가 쓰는 서비스가 자기 자신보다 사용자에게 이득이 되는 일을 실제로 하는 걸 보는 건 드문데, 예상 밖이지만 아주 기분 좋은 놀라움임
    이 확장이 브라우저 문맥을 자동으로 이해해서 더 잘 통합되면 좋겠음. 즉 일반 모드에서는 내 세션을 쓰고, 비공개 브라우징 모드(browser.extension.inIncognitoContext)에서는 내가 따로 뭔가 하지 않아도 Privacy Pass로 인증해주면 좋겠음
    Orion은 GNU/Linux 버전이 없어서 쓰지 않음

    • 이런 일이 드물어진 이유는 이 분야의 대부분 회사, 사실 많은 기술 회사들이 한 사용자 그룹에게 무언가를 제공한 뒤 그 결과를 다른 사용자 그룹에게 팔아 수익을 내는 양면 시장 모델을 써왔기 때문임
      실제 매출을 만드는 쪽은 후자이기 때문에, 기본적으로 전자 그룹의 이익과 후자 그룹의 이익이 충돌하고 전자에게 적대적인 구조가 되기 쉬움
      Kagi나 다른 새 기술 회사들이 신선한 건, 이 모델을 버리고 자신들이 서비스하고 매출을 얻는 그룹을 하나로 둔 “옛날식” 모델로 돌아갔기 때문임
    • Linux용 Orion 작업을 어제 시작했음
    • 이 방식의 단점은 큰 네트워크 위에 있지 않다면 IP 주소만으로도 익명성이 깨질 수 있다는 것임
      Kagi는 사용자가 로그인했다는 걸 알고 있고, 사용자가 비공개 창에서 민감한 검색을 하면 그 검색들을 연결할 수 있음. 모드를 빠르게 오가는 건 바람직하지 않음
    • 혹시 몰랐다면, 2024년 말쯤 팟캐스트에서 Orion Linux 버전을 계획 중이라고 발표했음
    • Kagi를 쓰다 보면 올바른 선택을 하는 데 익숙해짐. 정말 별다른 실수가 없었다는 게 놀라울 정도임
      내 Kagi 티셔츠도 그랬으면 좋겠음. 두 번째 세탁에서 밑단이 풀려서 이제 잠옷 겸 마당일용 셔츠가 됨. 교체용 무료 셔츠 쿠폰을 받긴 했지만 아직 배송은 안 됨

  • 글에서도 암시하지만, 계정 없이 Privacy Pass를 살 수 있는 상점이 있으면 말이 됨
    어떤 암호화폐, 아마 Monero를 지원해야 하고, GNU Taler 같은 것도 그 기술이 언젠가 쓸 만해지면 지원하면 좋겠음

    • Kagi는 Bitcoin을 받지만, 창업자 Vlad가 포럼에서 이 옵션을 쓰는 사람이 너무 적어서 Monero 지원에 투자할 의미가 없다고 말했음
    • 계정 없이 토큰을 파는 제3자 상점이 이상적인 해법이라는 데 동의하지만, 계정이 없으면 Kagi를 쓸 만하게 만드는 기능들, 예를 들어 특정 도메인을 결과에서 제거하거나 특정 결과 유형의 우선순위를 올리는 기능을 놓치게 됨

  • 이게 결국 로그를 안 남긴다고 가정하는 프라이버시인지 궁금함. 시비 걸려는 게 아니라 이 부분을 진짜로 이해 못하겠음
    사용자 A가 Kagi에 토큰을 요청하고 Kagi가 “좋아, 토큰 500개 줄게”라고 한다고 하자. Kagi가 방금 사용자 A에게 준 토큰 500개를 기록하면, 나중에 그중 하나가 사용될 때 그 토큰이 사용자 A에게 배정됐다는 걸 알 수 있는 것 아닌가?
    물론 Kagi가 이 데이터를 보관하지 않으면 토큰 자체는 유효/무효만 표시되고 “Y일에 사용자 A에게 준 유효 토큰”으로 남지 않으니 괜찮겠지만, 그게 전부 맞나? 내가 뭔가 오해하고 있는 건가?

    • 서버가 토큰을 생성하는 게 아니라 클라이언트가 토큰을 생성함. 서버는 그 토큰이 생성 권한을 받은 클라이언트가 만든 것인지 검증할 수 있어야 하지만, 어떤 클라이언트가 만든 것인지는 알 수 없어야 함. 적어도 부채널 정보 없이는 그래야 함

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      이 원시 기법이 얼마나 검증됐는지는 잘 모르겠지만, 적어도 서버가 클라이언트에게 토큰을 나눠주고는 누구에게 줬는지 모르는 척하는 것보다는 훨씬 더 많은 구조가 있어 보임
      참고 논문: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • Privacy Pass 문서 [0]가 이 부분을 다루지만, 주로 논문 안쪽에서 더 깊게 설명됨. 핵심은 서버가 돌려준 토큰이 클라이언트가 다시 보내는 수정된 토큰과 연결 불가능하다는 것이라고 봄
      서버는 어떤 사용자들에게 토큰 A, B, C를 돌려줬고 나중에 토큰 X, Y, Z를 받았다는 건 알 수 있음. X, Y, Z가 유효하다는 것도 알지만, 자신이 발급한 토큰과의 대응 관계는 모름. 여기에는 타원곡선 암호가 쓰임
      [0] https://privacypass.github.io/
    • 아이디어는 토큰이 어떤 계정에도 연결되지 않는다는 것임. 익명 토큰임
    • Privacy Pass 토큰의 전제를 이해하지 못한 것 같음
      핵심은 서버가 어떤 토큰이 어느 클라이언트에 속하는지 모른다는 것임. 서버가 토큰을 생성하지 않음

  • 내가 항상 봤던 Kagi의 가장 큰 결함이 이제 해결됐음. 제품을 거의 모두에게 매력적으로 만들기 위해 듣고 작업해줘서 고마움

  • 아직 Kagi를 쓰지 않는 사람들이 가장 크게 불평하는 것 중 하나가 로그인과 결제 정보를 요구하는 데 따른 프라이버시 우려임
    나는 그 부분을 걱정하던 쪽은 아니지만, 실제로 걱정했던 사람들에게 이 변화가 어느 정도로 우려를 덜어주는지 궁금함

    • 나는 그 걱정을 하던 쪽이고, 검색 엔진에 로그인한다는 게 아직도 믿기 어려울 정도임. 물론 이제 얼마나 많은 사람이 그렇게 하는지는 알고 있음
      시스템을 간단히 검증해본 뒤라면 이제 가입할 가능성이 꽤 높음
    • 암호가 Kagi가 말한 대로 동작한다고 가정하면, 이 방식은 검색 요청을 계정 정보와 완전히 분리해줌. 계정이 여러 개의 검색 토큰을 만들고, 각 검색 요청마다 토큰 하나를 소비하는 구조임
      토큰은 기기에서 생성되고, 사용되기 전까지 기기를 떠나지 않으므로 이론상 Kagi가 토큰만 보고 어떤 계정이 그 토큰을 만들었는지 알 방법이 없음. 지문 추적이나 IP 연관까지 해결하지는 못하지만, Firefox와 Chrome용 플러그인이 지문 추적을 줄이려는 조치를 한다고 함. 이건 Google이나 DuckDuckGo를 그냥 쓰는 것보다 나쁘지도 좋지도 않고, 정말 프라이버시를 원하면 Tor에서도 동작함
      토큰을 전혀 공유하지 않고 어떻게 합법성을 증명하는지는 확실치 않지만, 아마 어떤 ~~영지식 증명~~ 같은 것이 들어가 있을 것임
      수정: 영지식 증명은 아니고 블라인드 서명인 듯함

  • Kagi 쪽 누군가가 토큰 테이블에 토큰을 생성한 사용자와 그 SessionCookie를 담는 새 열을 추가하는 걸 막는 게 뭔지 모르겠음
    원래 토큰 생성자와 아주 쉽게 연결될 수 없는 이유가 보이지 않음

    • 구현자임. Privacy Pass의 “발급” 프로토콜 중에 클라이언트가 서버가 처리할 “메시지”를 생성함. 서버의 출력은 클라이언트에게 돌아가고, 클라이언트는 이 출력을 더 수정해서 최종 토큰을 만듦
      마지막 클라이언트 수정 단계에서 이 토큰들이 무작위화되기 때문에, 서버는 해당 토큰이 어떤 발급 과정에 속했는지 식별할 수 없게 됨
      정말 멋진 점은 서버가 자기 단계에서 나쁜 짓을 하려 해도 여전히 그렇다는 것임. 그래서 사용자는 클라이언트 소프트웨어만 신뢰하면 되고, 우리는 이를 오픈소스로 공개했음: https://github.com/kagisearch/privacypass-extension
      몇몇 사람이 블라인드 서명을 말하고 있는데, 실제로 Privacy Pass는 이를 구성 요소로 활용할 수 있음. 다만 정확히 말하면 Kagi에서는 “망각 의사난수 함수”(OPRF)에 기반한 “Privately Verifiable Tokens”(https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...)를 쓰고 있고, 개인적으로는 OPRF가 블라인드 서명보다 더 멋지다고 봄
    • 인용한 논문 [1]인 암호학적 익명 토큰 프로토콜 논문에서 설명하는 내용 같음. 단순한 평문 토큰이 아님
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      Cloudflare도 같은 걸 구현했던 것 같음. 적어도 HN 댓글들이 같은 논문을 링크하고 있음
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
    • 토큰은 클라이언트에서 “생성”되고, 서버는 그 로컬 생성 토큰이 “유효”해지기에 충분한 정보만 클라이언트에게 줌. 그러면서도 그 토큰을 특정 검증 시도와 연결할 수 없음
    • 나도 정확히 그 질문을 떠올렸음. 서버 쪽 신뢰에 의존할 수는 없으니, 내가 뭔가 오해한 건지 궁금함
    • 내가 제대로 이해했다면 “Privacy Pass”는 블라인드 서명을 쓰기 때문에, TokenResponse에 들어 있는 토큰과 검색 질의에 제공되는 토큰을 서로 연관시킬 수 없음

  • 이게 실제로 동작하긴 하나? 토큰은 한 번만 사용할 수 있으니 현실적으로 클라이언트가 특정 검색 세션 안에서 토큰을 생성하고 사용하는 루프를 돌게 될 텐데, 그러면 쌍을 연결하기가 아주 쉬워짐. 글에서도 이렇게 말함

    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는 공간을 무작위화해주겠지만 시간은 어떡하나? 그래서 “아래를 보라”는 부분을 봤는데 관련 내용을 못 찾았음. 충분한 요청량이 있으면 클라이언트들이 시간상 서로를 가려준다는 아이디어인가?
    또 Tor도 세션을 계속 새로 만들지 않는 한 공간을 무작위화하는 데 한계가 있음. 내가 알기로 루프는 세션 동안 고정되고, 세션을 다시 만드는 데는 10초 정도 걸림. 그럼 정말 공간을 무작위화한다고 볼 수 있나?

    • 토큰 요청 하나가 N개의 토큰을 만들 수 있음. 우리는 N = 500으로 설정해뒀기 때문에, 대부분 사용자는 꽤 드물게만 새 토큰을 요청하게 됨

  • 정말 멋지고 훌륭한 작업임
    예전에 Privacy Pass와 비슷한 블라인드 서명 인증을 만들어본 적이 있는데, 다중 기기 접근을 어떻게 처리할지 궁금함
    아마 다른 기기에서 토큰 접근 권한을 잃는 문제를 완화하려고 무제한 검색 사용자에게만 먼저 출시한 것으로 이해함. 장기 계획에 대한 아이디어가 있는지 궁금함. 예전에 이런 시스템을 만들 때는 항상 종단간 암호화 동기화와 묶어야 했음. 이건 최종 사용자에게 번거로울 뿐 아니라, 저장소 업데이트와 블라인드 검색 요청을 서로 연관시킬 여지도 생김
    어쨌든 정말 대단하고, 이제 Kagi를 그냥 신뢰하는 게 아니라 신뢰할 필요가 없다는 걸 검증할 수 있게 되어 더 기대됨

    • 맞음, 다중 기기는 확실히 쉽지 않음. 몇 가지 아이디어를 실험해봤지만 명확한 답이 있는 문제는 아님
      지금은 속도 제한을 통해 각 기기가 독립적으로 토큰을 생성하는 방식으로 Privacy Pass를 여러 기기에서 쓸 수 있게 하고 있음. 어떻게 흘러가는지 보고 사용자 피드백을 들은 뒤 다시 설계판으로 돌아갈 예정임

  • 이게 Cloudflare가 클라이언트의 CAPTCHA 우회를 허용하려고 쓰던 것과 같은 Privacy Pass인가? 그렇다면 이 시스템의 정말 깔끔한 응용임. 유료 서비스에 익명으로 인증하는 데 쓸 수 있다는 생각은 해본 적이 없었음

답변달기