Xác thực Privacy Pass cho tìm kiếm Kagi

 (blog.kagi.com)
2 điểm bởi GN⁺ 2025-02-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kagi Search đã giới thiệu xác thực Privacy Pass để xác minh quyền tìm kiếm trả phí mà không liên kết trực tiếp yêu cầu tìm kiếm với tài khoản
  • Cách này tách riêng tạo token và sử dụng token, cho phép Kagi xác minh tính hợp lệ nhưng không thể truy ngược người dùng hoặc thời điểm tạo chỉ dựa trên token
  • Đối tượng ban đầu là các gói Professional, Ultimate, Family, Team có tìm kiếm không giới hạn; Trial và Starter có giới hạn lượt tìm kiếm nên bị loại trừ do vẫn còn vấn đề mất token và dùng vượt mức
  • Có thể dùng trực tiếp trong Orion, ứng dụng Kagi Android, tiện ích Chrome và Firefox; Safari chưa được hỗ trợ do hạn chế API tiện ích
  • Chỉ với token thì khó liên kết tìm kiếm với tài khoản, nhưng vẫn còn các kênh phụ như địa chỉ IP, fingerprint trình duyệt, mẫu tìm kiếm lặp lại, nên khuyến nghị dùng Tor hoặc VPN

Xác thực Privacy Pass được thêm vào Kagi Search

  • Kagi đã đưa xác thực Privacy Pass vào Kagi Search, đồng thời công bố cả Tor onion service
  • Privacy Pass là giao thức xác thực cho phép client chứng minh quyền truy cập, trong khi server không thể nhận diện người dùng nào đang kết nối
  • Là một công cụ tìm kiếm trả phí, Kagi cần kiểm tra quyền tìm kiếm, nhưng tính năng này bổ sung bảo đảm kỹ thuật rằng các yêu cầu tìm kiếm không bị liên kết với một tài khoản cụ thể
  • Phần triển khai lấy bản triển khai Rust Privacy Pass của Raphael Robert làm điểm khởi đầu, và mã nguồn được công bố tại kagisearch/privacypass-extension

Các gói và client được hỗ trợ

  • Privacy Pass trước tiên được cung cấp cho người dùng các gói tìm kiếm không giới hạn Professional, Ultimate, Family, Team
  • Các gói Trial và Starter hiện chưa được hỗ trợ
    • Hai gói này có số lượt tìm kiếm hằng tháng bị giới hạn
    • Nếu mất token đã tạo do xóa tiện ích, trải nghiệm người dùng có thể trở nên kém đi
    • Vì Kagi không biết tài khoản hay gói tại thời điểm sử dụng token, về lý thuyết có thể dùng số token vượt quá số lượt tìm kiếm được phép
  • Các client được hỗ trợ như sau
  • Người dùng đang dùng tiện ích Kagi Search hiện có cần cập nhật lên phiên bản mới nhất hoặc vô hiệu hóa để tránh vấn đề tương thích
    • Firefox là 0.7.6
    • Chrome là 1.2.2.5

Luồng xác thực của Privacy Pass

  • Privacy Pass chia xác thực thành hai bước: tạo token và sử dụng token
  • Ở bước tạo token, người dùng chứng minh quyền tạo token bằng cookie phiên Kagi
    • Từ góc nhìn của server, token được tạo ra không thể phân biệt với token ngẫu nhiên
    • Token không thể bị truy vết về người dùng đã tạo ra nó hoặc về các token khác do cùng người dùng tạo
  • Khi gửi yêu cầu tìm kiếm, người dùng nộp một token đã tạo sẵn để chứng minh quyền truy cập
    • Server chỉ xác nhận rằng token đó từng được tạo hợp lệ
    • Không thể liên kết token với một bước tạo token cụ thể
  • Token là dùng một lần
    • Server theo dõi các token đã dùng để ngăn sử dụng trùng lặp
    • Client cũng không được gửi cùng một token hai lần để các bước sử dụng khác nhau không bị liên kết với nhau
  • Token có thời hạn cố định, nên token quá cũ phải được tạo mới

Mô hình triển khai và thuộc tính bảo mật của Kagi

  • Mô hình triển khai của Kagi tuân theo cấu trúc Shared Origin, Attester, Issuer trong tiêu chuẩn Privacy Pass
    • Kagi đảm nhiệm cả vai trò Attester, Issuer và Origin
    • Người dùng đóng vai trò client thông qua tiện ích trình duyệt Privacy Pass hoặc hỗ trợ tích hợp sẵn trong Orion
  • Sau khi cài đặt và định kỳ về sau, tiện ích tạo và lưu trữ một số lượng lớn token
  • Khi tìm kiếm, người dùng chọn bằng công tắc xem sẽ xác thực bằng cookie phiên hiện có hay bằng token Privacy Pass
  • Có ba thuộc tính bảo vệ người dùng
    • Không liên kết tạo-sử dụng: Kagi không thể liên kết token được gửi khi tìm kiếm với một bước tạo token cụ thể
    • Không liên kết sử dụng-sử dụng: Kagi không thể biết chỉ dựa trên token rằng hai lượt tìm kiếm khác nhau có đến từ cùng một người dùng hay không
    • Chống đánh cắp khi sử dụng: kẻ nghe lén quan sát quá trình tạo token không thể chỉ dựa vào thông tin đó để đánh cắp và sử dụng token
  • Cũng bao gồm các thuộc tính bảo vệ Kagi
    • Token được tạo đúng cách sẽ vượt qua xác minh của Kagi
    • Client độc hại, dù biết một token được tạo đúng cách, cũng không thể giả mạo token hợp lệ mới

Các tính năng bị giảm trong chế độ Privacy Pass

  • Trong chế độ Privacy Pass, Kagi không thể nhận diện người dùng nên không thể áp dụng cài đặt tài khoản
  • Kagi cung cấp điều này như một lựa chọn giữa “quyền riêng tư thông thường và đầy đủ tính năng” hoặc “quyền riêng tư tối đa và các tính năng cốt lõi”
  • Tại thời điểm ra mắt, Kagi Assistant không dùng được với Privacy Pass
    • Kagi Assistant chỉ được cung cấp cho thành viên Ultimate
    • Trong Privacy Pass không có thông tin tài khoản, nên không thể xác minh thuộc gói nào
  • Tại thời điểm ra mắt, Privacy Pass chỉ được dùng cho xác thực Kagi Search
  • Kagi dự định mở rộng hỗ trợ sang các dịch vụ sau trong vài tuần tới
    • Kagi Assistant
    • Kagi Translate và Kagi Maps
    • Kagi Universal Summarizer và Ask questions about page
  • Hiện tại, để dùng các dịch vụ này cần vô hiệu hóa Privacy Pass

Kênh phụ và sử dụng Tor

  • Privacy Pass khiến việc liên kết tạo token và sử dụng token chỉ dựa trên token trở nên bất khả thi, nhưng không thể mô tả hoàn toàn toàn bộ tương tác trực tuyến bằng một mô hình toán học
  • Server độc hại có thể cố theo dõi client bằng thông tin kênh phụ
    • Nếu mỗi ngày lặp lại cùng một tìm kiếm cụ thể vào cùng một thời điểm, có thể suy đoán các lượt tìm kiếm đó đến từ cùng một người
    • Các tín hiệu như user-agent của trình duyệt và địa chỉ IP là thông tin nằm ngoài Privacy Pass
    • Nếu yêu cầu tạo token và ngay sau đó là yêu cầu sử dụng token đến từ cùng một IP, có thể xem đó là yêu cầu của cùng một cá nhân
  • RFC 9576 khuyến nghị tách biệt thời gian giữa tạo và sử dụng token, hoặc tách biệt không gian bằng dịch vụ ẩn danh như Tor
  • Tiện ích Privacy Pass của Kagi và triển khai tích hợp sẵn trong Orion xử lý bằng cách loại bỏ HTTP header và cookie để làm fingerprint trình duyệt đồng nhất nhất có thể
  • Kagi cung cấp địa chỉ onion có thể truy cập trực tiếp từ mạng Tor
  • Chỉ dùng Tor thì địa chỉ IP được ẩn, nhưng nếu đăng nhập mà không có Privacy Pass, về lý thuyết các tìm kiếm vẫn có thể bị liên kết với một tài khoản duy nhất
  • Khi dùng Tor cùng Privacy Pass, Kagi chỉ biết rằng lượt tìm kiếm đó đến từ một người dùng trước đây đã được xác minh là có quyền nhận token, chứ không biết tài khoản hay vị trí

Số lượng token, hiệu năng và dung lượng lưu trữ

  • Người dùng gói tìm kiếm không giới hạn có thể tạo 2.000 token trong một epoch, tức một tháng
  • Nếu cần thêm token, có thể yêu cầu qua support@kagi.com
  • Việc tạo 500 token tìm kiếm cần khoảng 1 giây tính toán trên laptop phổ thông
    • Có thể mất thêm vài giây do kết nối server và thời gian phản hồi
    • Khi cài tiện ích, thao tác này được thực hiện trong nền nhiều nhất có thể
  • Mỗi token có dung lượng 216 byte, và dung lượng lưu trữ cho mỗi yêu cầu tạo token là khoảng 100KiB
  • Hiện server xác minh token chỉ được triển khai ở khu vực us-central1, và Kagi dự định mở rộng ngay sau khi ra mắt

Vì sao cá nhân hóa và cài đặt bị hạn chế

  • Trong tìm kiếm Privacy Pass, Kagi không biết người dùng là ai nên không thể cung cấp kết quả theo cài đặt tùy chỉnh của người dùng
  • Kagi đã cân nhắc gửi các cài đặt nhỏ như (language, region, safe-search) trong từng yêu cầu, nhưng hiện đánh giá rằng điều này có thể làm giảm đáng kể tính ẩn danh
  • Trong phân tích ví dụ, người dùng gửi một thiết lập ngôn ngữ cụ thể là Lang 10 có thể tự động mất bảo đảm không liên kết sử dụng-sử dụng khi có khoảng 1.000 người dùng Privacy Pass
  • Kagi cho rằng ước tính này có thể quá thận trọng, nhưng hiện không bật mức cá nhân hóa mặc định cho người dùng xác thực bằng Privacy Pass
  • Một số cài đặt tìm kiếm thủ công có thể được áp dụng bằng cách thêm bangs vào truy vấn
    • Ví dụ, thêm !de trước truy vấn sẽ thực hiện tìm kiếm theo khu vực Đức
  • Nếu muốn trải nghiệm tìm kiếm được cá nhân hóa đầy đủ, cần dùng phương thức đăng nhập hiện có và vô hiệu hóa Privacy Pass

Các hạn chế như Safari và cửa sổ riêng tư

  • Privacy Pass không sử dụng blockchain
    • Nó sử dụng đường cong elliptic, hàm băm và cấu trúc hàm giả ngẫu nhiên lãng quên có thể xác minh
    • Token không được tạo, lưu trữ hay giao dịch trên blockchain
  • Việc tạo token không hoạt động trong cửa sổ riêng tư của Chrome và Firefox
    • Tạo token cần quyền truy cập cookie phiên
    • Trong cửa sổ riêng tư, tiện ích không thể truy cập cookie phiên
    • Trên Orion, tạo token vẫn hoạt động cả trong cửa sổ riêng tư
  • Dù bật Privacy Pass, do cách TCP/IP hoạt động, Kagi vẫn có thể thấy địa chỉ IP của yêu cầu tìm kiếm
    • Nếu lo ngại lộ địa chỉ IP, khuyến nghị dùng Tor hoặc VPN đáng tin cậy
  • Tất cả token sẽ hết hạn vào nửa đêm ngày đầu tiên của tháng X+2, tính theo tháng X khi token được tạo
    • Đây là cách để tránh việc ngày hết hạn tương tự nhau của các token được tạo cùng thời điểm bị dùng để nhận diện nhiều lượt tìm kiếm
  • Safari hiện chưa được hỗ trợ
    • Kagi hiểu rằng API tiện ích của Safari không hỗ trợ khả năng loại bỏ cookie khỏi yêu cầu
    • Nếu không thể loại bỏ cookie, việc xác thực vẫn tiếp tục bằng tài khoản đã đăng nhập
    • Nếu muốn trải nghiệm native tương tự dựa trên WebKit, có thể dùng Orion Browser đã tích hợp Privacy Pass như một lựa chọn thay thế

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-14
Ý kiến trên Hacker News

  • Việc Kagi giờ dùng Privacy Pass là tốt, và nhìn chung bản thân công ty cũng có vẻ ổn
    Tuy nhiên, Kagi về cơ bản đã lấy bản nháp IETF [1] và phần triển khai Rust [2] mà tôi đã làm trong một thời gian, tạo một lớp wrapper mỏng [3] phía trên rồi gọi đó là “phần triển khai Privacy Pass của Kagi”
    Tôi nghĩ lẽ ra họ nên ghi credit cho tôi ở một mức nào đó. Phần lớn công việc với IETF và phần mềm mã nguồn mở đều là tự nguyện, không lương, và thường được thực hiện ngoài giờ làm việc. Bị đối xử như vậy thì khó mà có động lực. Kagi có thể làm tốt hơn
    [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...

    • Thành thật mà nói, “phần triển khai Privacy Pass của Kagi” được nhắc trong bài có vẻ không chỉ bản thân phần triển khai RFC hay giao thức, mà là phần tích hợp chức năng đó vào máy chủ và client của Kagi. Bài viết cũng có ghi nhận RFC
    • Tôi tò mò liệu Kagi chỉ cần thêm “credit cho raphaelrobert”, hoặc đặt một bản sao giấy phép ở đâu đó trong mã, thì có được xem là tuân thủ không
      Mã nguồn mở của tôi chưa từng thực sự được dùng và thường được phát hành theo giấy phép MIT, nên tôi muốn biết các nhóm hay tổ chức khác trên thực tế tuân thủ giấy phép như thế nào
    • Khi chụp lại phần header của README vào khoảng 12:15 trưa giờ miền Đông, ngày 14 tháng 2 năm 2025, nó ghi như sau

      This repository contains the source code of the core library implementing the Privacy Pass API used by Kagi.
      Điều này chắc chắn tạo cảm giác không hay. Dù vậy, tôi nghĩ phía Kagi có lẽ sẽ sẵn sàng sửa cho chính xác hơn, chẳng hạn “thư viện lõi triển khai wrapper Crystal Lang cho raphaelrobert/privacypass”. Khả năng cao đây không phải là cố ý, mà là họ tập trung làm cho nó chạy được rồi không có ai đọc lại câu chữ

  • Tuyệt. Thật hiếm khi thấy một dịch vụ tôi dùng thực sự làm điều có lợi cho người dùng hơn là cho chính họ; điều này bất ngờ nhưng là một bất ngờ rất dễ chịu
    Tôi mong extension này có thể tự hiểu ngữ cảnh trình duyệt để tích hợp tốt hơn. Tức là ở chế độ thường thì dùng session của tôi, còn trong chế độ duyệt riêng tư (browser.extension.inIncognitoContext) thì tự xác thực bằng Privacy Pass mà tôi không phải làm thêm gì
    Tôi không dùng Orion vì không có bản GNU/Linux

    • Lý do những chuyện như vậy trở nên hiếm là vì hầu hết các công ty trong lĩnh vực này, thật ra là nhiều công ty công nghệ, đã dùng mô hình thị trường hai phía: cung cấp thứ gì đó cho một nhóm người dùng rồi bán kết quả cho một nhóm người dùng khác để kiếm tiền
      Vì bên tạo ra doanh thu thực sự là nhóm sau, về cơ bản lợi ích của nhóm trước và nhóm sau xung đột với nhau, và cấu trúc này dễ trở nên đối nghịch với nhóm trước
      Điều khiến Kagi hay các công ty công nghệ mới khác trở nên mới mẻ là họ đã bỏ mô hình này và quay lại mô hình “kiểu cũ”, trong đó nhóm mà họ phục vụ và nhóm họ kiếm doanh thu là một
    • Hôm qua đã bắt đầu làm Orion cho Linux
    • Nhược điểm của cách này là nếu bạn không ở trên một mạng lớn, chỉ riêng địa chỉ IP cũng có thể làm mất tính ẩn danh
      Kagi biết người dùng đã đăng nhập, và nếu người dùng tìm kiếm nhạy cảm trong cửa sổ riêng tư, họ có thể liên kết các tìm kiếm đó lại. Chuyển qua lại giữa các chế độ quá nhanh là điều không nên
    • Nếu bạn chưa biết, khoảng cuối năm 2024 họ đã thông báo trên podcast rằng đang lên kế hoạch cho phiên bản Orion cho Linux
    • Dùng Kagi rồi sẽ quen với việc họ đưa ra lựa chọn đúng đắn. Thật sự đáng ngạc nhiên là gần như họ chưa mắc lỗi đáng kể nào
      Ước gì áo thun Kagi của tôi cũng vậy. Sau lần giặt thứ hai, gấu áo bung ra, nên giờ nó thành áo ngủ kiêm áo mặc làm việc ngoài sân. Tôi có nhận được phiếu đổi áo miễn phí, nhưng áo vẫn chưa được gửi

  • Như bài viết cũng ngụ ý, sẽ hợp lý nếu có một cửa hàng nơi có thể mua Privacy Pass mà không cần tài khoản
    Cần hỗ trợ một loại tiền mã hóa nào đó, có lẽ là Monero, và cũng nên hỗ trợ những thứ như GNU Taler nếu một ngày nào đó công nghệ đó trở nên đủ dùng

    • Kagi nhận Bitcoin, nhưng nhà sáng lập Vlad đã nói trên diễn đàn rằng quá ít người dùng tùy chọn này nên việc đầu tư vào hỗ trợ Monero là không đáng
    • Tôi đồng ý rằng một cửa hàng bên thứ ba bán token mà không cần tài khoản là giải pháp lý tưởng, nhưng nếu không có tài khoản thì bạn sẽ mất các tính năng khiến Kagi đáng dùng, chẳng hạn loại bỏ một số domain khỏi kết quả hoặc tăng ưu tiên cho một số loại kết quả nhất định

  • Tôi thắc mắc liệu rốt cuộc đây có phải là quyền riêng tư dựa trên giả định rằng không ghi log hay không. Tôi không có ý gây sự, mà thật sự không hiểu phần này
    Giả sử người dùng A yêu cầu Kagi cấp token và Kagi nói “được, tôi sẽ cấp 500 token”. Nếu Kagi ghi lại 500 token vừa cấp cho người dùng A, thì sau này khi một trong số đó được dùng, chẳng phải họ có thể biết token đó đã được phân bổ cho người dùng A sao?
    Tất nhiên nếu Kagi không lưu dữ liệu này thì bản thân token chỉ được đánh dấu hợp lệ/không hợp lệ và không còn dưới dạng “token hợp lệ đã cấp cho người dùng A vào ngày Y”, nên sẽ ổn; nhưng có phải chỉ vậy thôi không? Tôi có đang hiểu nhầm gì không?

    • Không phải máy chủ tạo token, mà là client tạo token. Máy chủ phải có khả năng xác minh rằng token đó được tạo bởi một client đã được cấp quyền tạo, nhưng không được biết client nào đã tạo nó. Ít nhất là phải như vậy nếu không có thông tin kênh bên

      The main building block of our construction is a verifiable oblivious pseudorandom function (VOPRF)
      Tôi không rõ primitive này đã được kiểm chứng đến mức nào, nhưng ít nhất có vẻ nó có nhiều cấu trúc hơn hẳn so với việc máy chủ phát token cho client rồi giả vờ không biết đã phát cho ai
      Bài báo tham khảo: https://petsymposium.org/popets/2018/popets-2018-0026.pdf

    • Tài liệu Privacy Pass [0] có đề cập phần này, nhưng chủ yếu được giải thích sâu hơn trong bài báo. Theo tôi, điểm cốt lõi là token mà máy chủ trả về không thể liên kết với token đã được chỉnh sửa mà client gửi lại
      Máy chủ có thể biết mình đã trả về các token A, B, C cho một số người dùng nào đó và sau đó nhận được các token X, Y, Z. Nó cũng biết X, Y, Z là hợp lệ, nhưng không biết quan hệ tương ứng giữa chúng với các token mình đã phát hành. Việc này dùng mật mã đường cong elliptic
      [0] https://privacypass.github.io/
    • Ý tưởng là token không được liên kết với bất kỳ tài khoản nào. Đó là token ẩn danh
    • Có vẻ bạn chưa hiểu tiền đề của token Privacy Pass
      Điểm cốt lõi là máy chủ không biết token nào thuộc về client nào. Máy chủ không tạo token

  • Khiếm khuyết lớn nhất của Kagi mà tôi luôn thấy giờ đã được giải quyết. Cảm ơn vì đã lắng nghe và thực hiện để sản phẩm trở nên hấp dẫn với gần như tất cả mọi người

  • Một trong những phàn nàn lớn nhất của những người chưa dùng Kagi là lo ngại về quyền riêng tư do việc yêu cầu đăng nhập và thông tin thanh toán
    Tôi không thuộc nhóm lo về phần đó, nhưng tôi tò mò thay đổi này giảm bớt lo ngại đến mức nào đối với những người thật sự từng lo lắng

    • Tôi thuộc nhóm từng lo chuyện đó, và đến giờ vẫn thấy khó tin chuyện phải đăng nhập vào một công cụ tìm kiếm. Tất nhiên tôi biết hiện nay có bao nhiêu người làm như vậy
      Sau khi kiểm chứng sơ bộ hệ thống, khả năng tôi đăng ký giờ khá cao
    • Giả sử phần mật mã hoạt động đúng như Kagi nói, cách này tách hoàn toàn truy vấn tìm kiếm khỏi thông tin tài khoản. Tài khoản tạo ra nhiều token tìm kiếm, và mỗi truy vấn tìm kiếm tiêu thụ một token
      Token được tạo trên thiết bị và không rời khỏi thiết bị cho đến khi được sử dụng, nên về lý thuyết Kagi không có cách nào chỉ nhìn vào token mà biết tài khoản nào đã tạo ra nó. Việc này không giải quyết được theo dõi bằng dấu vân tay hay liên hệ qua IP, nhưng họ nói plugin cho Firefox và Chrome sẽ có các biện pháp nhằm giảm theo dõi bằng dấu vân tay. Điều này không tệ hơn cũng không tốt hơn so với việc dùng thẳng Google hay DuckDuckGo, và nếu thật sự muốn quyền riêng tư thì nó cũng hoạt động trên Tor
      Tôi không chắc họ chứng minh tính hợp lệ như thế nào mà không hề chia sẻ token, nhưng có lẽ có thứ gì đó kiểu ~~bằng chứng không tiết lộ tri thức~~ trong đó
      Sửa: có vẻ không phải bằng chứng không tiết lộ tri thức mà là chữ ký mù

  • Tôi không rõ điều gì ngăn ai đó phía Kagi thêm một cột mới vào bảng token để lưu người dùng đã tạo token và SessionCookie của họ
    Tôi không thấy lý do vì sao không thể liên kết rất dễ dàng với người tạo token ban đầu

    • Tôi là người triển khai. Trong giao thức “phát hành” của Privacy Pass, client tạo một “thông điệp” để server xử lý. Đầu ra của server được trả về cho client, rồi client tiếp tục chỉnh sửa đầu ra này để tạo token cuối cùng
      Vì các token này được ngẫu nhiên hóa ở bước chỉnh sửa cuối cùng phía client, server không thể xác định token đó thuộc quy trình phát hành nào
      Điểm thật sự hay là điều này vẫn đúng ngay cả khi server cố làm điều xấu ở bước của mình. Vì vậy người dùng chỉ cần tin tưởng phần mềm client, và chúng tôi đã công bố mã nguồn mở của nó: https://github.com/kagisearch/privacypass-extension
      Một số người nhắc đến chữ ký mù, và thực tế Privacy Pass có thể dùng nó như một thành phần. Tuy nhiên, nói chính xác thì tại Kagi chúng tôi đang dùng “Privately Verifiable Tokens” dựa trên “hàm giả ngẫu nhiên quên” (OPRF) (https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...), và cá nhân tôi thấy OPRF thú vị hơn chữ ký mù
    • Có vẻ như đây là nội dung được mô tả trong bài báo về giao thức token ẩn danh bằng mật mã học mà bạn trích dẫn [1]. Nó không phải là token văn bản thuần đơn giản
      https://petsymposium.org/popets/2018/popets-2018-0026.php (“Privacy Pass: Bypassing Internet Challenges Anonymously”)
      Có vẻ Cloudflare cũng đã triển khai cùng thứ này. Ít nhất các bình luận trên HN đều liên kết đến cùng bài báo đó
      https://news.ycombinator.com/item?id=19623110 (“Privacy Pass (cloudflare.com)”, 53 comments)
    • Token được “tạo” ở phía client, còn server chỉ cung cấp cho client lượng thông tin đủ để token được tạo cục bộ đó trở nên “hợp lệ”. Đồng thời, server vẫn không thể liên kết token đó với một lần xác minh cụ thể
    • Tôi cũng nghĩ đúng câu hỏi đó. Không thể dựa vào niềm tin ở phía server, nên tôi tự hỏi liệu mình có hiểu nhầm điều gì không
    • Nếu tôi hiểu đúng thì “Privacy Pass” dùng chữ ký mù, nên không thể liên hệ token nằm trong TokenResponse với token được cung cấp cho truy vấn tìm kiếm

  • Cái này thực sự hoạt động được không? Token chỉ dùng được một lần, nên trong thực tế client có lẽ sẽ chạy vòng lặp tạo và dùng token trong một phiên tìm kiếm cụ thể, khi đó việc ghép cặp chúng trở nên rất dễ. Bài viết cũng nói như vậy

    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 sẽ ngẫu nhiên hóa không gian, nhưng còn thời gian thì sao? Vì vậy tôi đã xem phần “xem bên dưới” nhưng không tìm thấy nội dung liên quan. Ý tưởng có phải là nếu có đủ lượng yêu cầu thì các client sẽ che khuất nhau theo thời gian không?
    Ngoài ra, Tor cũng có giới hạn trong việc ngẫu nhiên hóa không gian trừ khi cứ liên tục tạo phiên mới. Theo tôi biết, circuit được giữ cố định trong suốt phiên, và tạo lại phiên mất khoảng 10 giây. Vậy có thật sự có thể xem là ngẫu nhiên hóa không gian không?

    • Một yêu cầu token có thể tạo ra N token. Chúng tôi đặt N = 500, nên hầu hết người dùng sẽ chỉ cần yêu cầu token mới khá hiếm khi

  • Thật sự là một công việc rất hay và tuyệt vời
    Trước đây tôi từng tạo một cơ chế xác thực bằng chữ ký mù tương tự Privacy Pass, và tôi tò mò các bạn xử lý truy cập đa thiết bị như thế nào
    Tôi đoán việc trước tiên chỉ ra mắt cho người dùng tìm kiếm không giới hạn là để giảm nhẹ vấn đề mất quyền truy cập token trên các thiết bị khác. Tôi tò mò liệu các bạn có ý tưởng gì cho kế hoạch dài hạn không. Khi trước xây dựng những hệ thống kiểu này, tôi luôn phải gắn nó với đồng bộ hóa mã hóa đầu cuối. Điều này không chỉ phiền phức với người dùng cuối, mà còn tạo khả năng liên kết các cập nhật kho lưu trữ với các yêu cầu tìm kiếm mù
    Dù sao thì thật sự rất ấn tượng, và tôi càng hào hứng hơn vì giờ có thể xác minh rằng mình không chỉ đơn giản là tin tưởng Kagi nữa, mà là không cần phải tin tưởng

    • Đúng vậy, đa thiết bị chắc chắn không dễ. Chúng tôi đã thử nghiệm một vài ý tưởng, nhưng đây không phải là vấn đề có câu trả lời rõ ràng
      Hiện tại, chúng tôi cho phép dùng Privacy Pass trên nhiều thiết bị bằng cách để mỗi thiết bị tự tạo token độc lập thông qua giới hạn tốc độ. Chúng tôi sẽ xem mọi chuyện diễn ra ra sao, lắng nghe phản hồi của người dùng rồi quay lại bàn thiết kế

  • Đây có phải là cùng Privacy Pass mà Cloudflare từng dùng để cho phép client vượt CAPTCHA không? Nếu đúng thì đây là một ứng dụng thật sự gọn gàng của hệ thống đó. Tôi chưa từng nghĩ có thể dùng nó để xác thực ẩn danh với một dịch vụ trả phí

    • Mật mã học làm nền tảng cho Privacy Pass [1] thực ra xuất phát từ Ecash[2], nên rốt cuộc là đi một vòng rồi trở lại
      [1] https://www.petsymposium.org/2018/files/papers/issue3/popets...
      [2] https://en.m.wikipedia.org/wiki/Ecash
    • Đúng vậy. Tuy nhiên, theo tôi biết Cloudflare đã kết thúc chương trình thử nghiệm Privacy Pass
      Tôi nhớ Safari là trình duyệt duy nhất triển khai nó một cách native, nhưng có vẻ giờ Orion cũng hỗ trợ