#1071: Private Proof API

Visit on Github.

Opened Mar 19, 2025

こんにちは TAG-さん!

I'm requesting an early TAG design review of Private Proof API.

This API uses Zero-Knowledge Proofs (ZKPs) to allow analysis of potentially identifiable signals while providing only a limited verdict output. For example, it empowers anti-fraud services to verify whether a user possesses an unmodified stored timestamp older than some provided timestamp without disclosing any additional user data. This approach strikes a balance between user privacy and anti-fraud capabilities by enabling websites to request a reputation signal (such as profile age) on which the user agent can enforce meaningful privacy constraints, while making the signal useful enough to remove the need for other burdensome or invasive checks, and allowing the user to clear said signal at will.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): Anti-Fraud CG
  • The group where standardization of this work is intended to be done ("unknown" if not known): Anti-Fraud CG
  • This work is being funded by: Google Chrome

Discussions

Log in to see TAG-private discussions.

Discussed Mar 1, 2025 (See Github)

Martin: Assuming familiarity with Private State Tokens: site decides you're trustworthy, and you can take those to another website, which can consume the tokens. This is basically the same, but the decision the website takes about trust isn't a decision. Instead, when it issues the original tokens, it saves the current time. Then when it comes back, the website can ask the browser if the saved time is prior to a specified time. Doesn't know where it created the signal or any other information other than the browser having been seen at least X minutes ago. If you're running an anti-fraud system, you rely on a long history of engagement. If you have a long history, you're more trustworthy. Can use this as a sorting function between likely-safe and unknown visitors.

Martin: This removes some of the problems from the Private State Token solution, because it passes arbitrary information. 1 bit could mean anything, like "lives in particular geography". Apple system said "person has bought an Apple device". Problem with PST is the user doesn't know what the signal is. In Private Proof, you know what the signal is. Has the other problems of PSTs: you have to limit the number of entities that can use the API, or else it becomes a great fingerprint. Needs to be a system of accountability, and that system isn't clear. Proponents suggest entropy limits == cap on number of sites that can use it in a context. Works, but encourages sites to use services with the oldest user accounts, which creates a centralizing incumbency advantage. Can't rely on a diversity of antifraud providers. They don't have a solution yet. Probably on balance it's ok if those problems can be worked through.

Jeffrey: Sounds like a set of questions for the proponents rather than a conclusion yet.

Martin to draft a comment with questions, and we'll run it by the rest of the TAG.

Lots of questions: https://github.com/w3ctag/design-reviews-private-brainstorming/issues/131#issuecomment-2770984939

Comment by @martinthomson Mar 27, 2025 (See Github)

See also #780 for something that is approximately the same shape.

Discussed Apr 1, 2025 (See Github)

Hadley: this is with me, and I need to look at it. Let's come back to it in a later meeting.