Privacy Pass: The New Protocol for Private Authentication

Announcements Articles
1
13 Likes
3

This is a good article, but it has a fatal flaw. Cloudflare doesn’t actually respect their own Privacy Pass implementation or Apple’s.

3 Likes
4

Interesting, could you elaborate?

5

The privacy pass attestor endpoints in the official extension are just prototypes for testing. Not for production usage. And you’ll eg. still get captchas every time from Cloudflare.

You can also use the demo page on an iPhone with PAT enabled and see it not recognized: https://demo-pat.research.cloudflare.com/login

1 Like
6

Yeah, been a known issue with Cloudflare captchas for a long time. Very unfortunate :cry:

7

Good article on an important topic. Small request but is it possible to change the formatting of the Privacy Pass: The New Protocol for Private Authentication - Privacy Guides section so that it is more clear that CAPTCHA, Client State and Trusted Device are subsections? It is clear from the context and the Table of contents, but a bit visually disorienting when reading through.

A few initial thoughts open to anyone for reply or explanation:

  1. It’s unclear to me whether it would be better to modify the title such that the article is about ‘Private Authentication’ rather than Privacy Pass. It seems Privacy Pass is a web/webservice-specific protocol hence being bound to a browser. Private Authentication can broadly encompass Zero Knowledge Proofs and the mentioned Blind Signature Schemes which seem to be used in production in quite a few different places.
  2. Most minor nitpick. I don’t know whether it makes sense to tout Privacy Pass as a new thing, because it has been around for quite a few years now.
  3. Is it possible to organise the information so that it presents Private Access Tokens as an Apple-specific implementation of Privacy Pass for website access (CAPTCHA circumvention)? I don’t know if Apple use Private Access Tokens for anything else.
  4. Would it be worth adding private authentication schemes as a best-case criteria for all service-based recommendations on Privacy Guides?
1 Like
8

Really a great read, keep up the good work!

1 Like
9

Can I get some more info on the PrivacyGuides subscription that was referenced in the article? What’s the release date?? :upside_down_face:

1 Like
10

Sorry that was sort of a joke, that’s not real. Just had to come up with a fake subscription service as an example.

11
  1. Fair point, I wanted to focus on Privacy Pass since it’s an IETF standard. A lot of services like Apple’s Private Relay and Google’s VPN just say they use blind signatures without really going into whether they adhere to a specific standard. I wanted to highlight places where this type of thing is being done, and maybe I should’ve talked about how it should be standardized more. The IETF page for Privacy Pass describes an “ecosystem” of clients which I think would be cool to see, although I might be misinterpreting it. I’m imagining lots of different Issuers and Attesters all working together in an interoperable network of anonymous verification.
  2. That’s true, it’s evolved and changed so much from the original browser extension though. Cloudflare has a great blog post about the upgrades they’ve made that I should’ve linked in the article somewhere.
  3. It’s not really clear to me that Private Access Tokens were meant to be Apple only but they’re the only ones I’ve seen implement it. They only say they’re used for CAPTCHAs but I don’t know if there’s anything strictly preventing them from being used for other things as well.
  4. I like that idea, but it’s a bit too early I think for that. Kagi is the only service I can think of besides private relay and Google’s VPN using blind signatures to authenticate users. I’d love to see other VPNs like Proton and Mullvad using them.
4 Likes