[Proposal] Trust Token API

Here is an explainer detailing this new API idea.

Problem

The web ecosystem relies heavily on building trust signals to detect fraudulent or spammy actors. One common way this is done is via tracking an individual browser’s activity across the web, usually via associating stable identifiers across sites.

Preventing fraud is a legitimate use case that the web should support, but it shouldn’t require an API as powerful as a stable, global, per-user identifier. In third party contexts, merely segmenting users into trusted and untrusted sets seems like a useful primitive that also preserves privacy. This kind of fraud protection is important both for CDNs, as well as for the ad industry which receives a large amount of invalid, fraudulent traffic.

Solution

This API proposes a new per-origin storage area for “Privacy Pass” style cryptographic tokens, which are accessible in third party contexts. These tokens are non-personalized and cannot be used to track users, but are cryptographically signed so they cannot be forged.

When an origin is in a context where they trust the user, they can issue the browser a batch of tokens, which can be “spent” at a later time in a context where the user would otherwise be unknown or less trusted. Crucially, the tokens are indistinguishable from one another, preventing websites from tracking users through them.

// Fetch trust tokens on one site...
fetchTrustTokens('/request-tokens').then(...)

// Redeem trust tokens on another site!
getTrustAttestation('https://token-issuer.com', {refresh-policy: 'use-cached').then(...)

We further propose an extension mechanism for the browser to sign outgoing requests with keys bound to a particular token redemption.

Please take a look! We hope to gather feedback via Github issues on the explainer.

Is the term “Privacy Guarantee” at https://github.com/dvorak42/trust-token-api#privacy-considerations capable of being fulfilled and verified (e.g., see Revocation of "basic" web permissions (such as internet access) or some other way to "trust" a webpage with your sensitive files (e.g. image editor app)) for any signals or storage device (https://en.wikipedia.org/wiki/Cellebrite)?

Or is the term used at the Explainer to describe the fact that there is absolutely no expectation of privacy on the Web (i.e., see A Good American) or using any analog or digital signals or storage devices?

Hey! I don’t quite understand the question. We used “privacy guarantee” to describe a cryptographic property of the tokens: that issuance and redemption are not linkable. The issuer sees “blinded tokens” in one context (issuance), and “clear tokens” in another context (redemption).

For more information, I encourage you to take a look at the VOPRF primitive which Privacy Pass is based on: https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/?include_text=1

The question is why is the term “guarantee” used?

AFAICT There is no “guarantee” of “privacy” on any wire at any time. All signals can be intercepted, analyzed, stored by undisclosed third-parties.

Perhaps consider removing the term “guarantee” from the Explainer? Or, if the term is retained, can you kindly explain exactly how a “guarantee” of “privacy” is verified at any arbitrary point in time, where a given third-party has the capabilities to intercept, analyze (and store indefinitely) at least 20TB/second of data (“real-time”) as of last century?

By what means is a “guarantee” of “privacy” verified? From within the same system which guarantees privacy?

The question is why is the term “guarantee” used?

AFAICT There is no “guarantee” of “privacy” on any wire at any time. All signals can be intercepted, analyzed, stored by undisclosed third-parties.

“Guarantee” is not used to say the API itself guarantees privacy, but that “issuer blinding” is a privacy guarantee of the API based on the cryptographic properties. That is, the API guarantees that tokens are unlinkable between issuance and redemption.

It’s possible this isn’t clear enough in the explainer, I’m fine rewording to “cryptographic guarantee” if this is confusing.

Re the terms “privacy” and “security”, in brief consider the case of EMV technology

• https://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/
• [insert stakeholder (insurance firms; banks, etc.) negotiations on whom assumes what, resposibities for implementation; consumers may or not get notice of new compulsory use of EMV “chip” card policy of institution for “security”; purported recent purchase, etc. using non-EMV card]
• https://securetablepay.com/emv-chip-cards-good-bad-ugly/
• https://web.stanford.edu/class/cs101/security-8-emv.html
• https://www.cl.cam.ac.uk/research/security/banking/interceptor/
• https://pdfs.semanticscholar.org/a3ab/1f3d95ca45b027cac744d0fd2a67d9375ba5.pdf

“cryptographic guarantee”

Is clearer from perspective here. Though using the term “guarantee” is binding, correct? Why is that term necessary? Could not the cryptographic algorithm used by described without guarantying anything as to what may or may not occur in the future, or potentially has already occurred, that is, what the API intends to do in the given environment?

Though using the term “guarantee” is binding , correct? Why is that term necessary? Could not the cryptographic algorithm used by described without guarantying anything as to what may or may not occur in the future, or potentially has already occurred, that is, what the API intends to do in the given environment?

The point of the section is to elaborate on the consequences of the properties of the underlying algorithm. If “guarantee” is too strong a word, “property” suffices.

Notes from TPAC discussion: https://www.w3.org/2019/09/18-trusttokens-minutes.html.