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

This proposal is substantially similar to the Private State Token API (https://wicg.github.io/trust-token-api/, https://github.com/w3ctag/design-reviews/issues/780), but it seeks to address one of the key privacy concerns with that approach.

Private State Tokens allowed a site to write a bit¹ when it was in a top-level or same-site context and read that bit when it is embedded in a cross-site context. The major problem with that from a privacy perspective is that no one really got to know what the bit meant. So while the intent was that this was supposed to signal that the site considered the user to be trusted².

The change here is to move to a single bit again, but strictly limit what that bit can mean. In the same-site context, a site is able to sign the current time. That genuinely carries a single bit into the browser that the site cannot control. In the cross-site context, the site can then ask the browser for proof that the time it previously signed was before a time of its choice. The site then either receives that proof or not, providing it with a single bit. The site has some control, because they can choose how old the original signature was, but they don't get anything more than that.

For anti-abuse purposes, this is useful because it allows sites to call out to an anti-abuse provider and separate potential abusive visitors into two groups: those with a history longer than some predefined age, and those without. Those with a long history are unable to spoof that (with caveats), which allows the site to (at their discretion) focus their abuse protection mechanisms more closely on those without a long history.

This strikes a balance between the anti-abuse needs and privacy, for sure. Whether it strikes an appropriate balance depends on several factors, which we'd like to see more detail on:

1. One of the major drawbacks of Private State Tokens is the natural bias toward centralization. If you don't limit the number of entities that can supply tokens, the API is basically a fingerprint-creation API. This proposal is no different in that regard. In particular, this creates a tendency for sites to partner with anti-abuse vendors who have been around longer and those who have been exposed to more users. The proposal does not appear to (currently) have robust safeguards in place for that bias. We'd like to see some more analysis about what the options might be here. The explainer section on side channels is not really adequate to understand the full privacy implications of this.

2. The idea of issuer "fungibility" explored in the explainer seems impractical as described, but the general idea that the choice of issuer is not revealed through the proof is worth exploring as a potential mitigation for the natural centralization tendency in the API. We understand that this has a range of challenges -- it isn't clear what would incentivize the necessary cooperation, it requires new and potentially different cryptography, plus it might have other centralization biases -- but we want to encourage further investigation along these lines.

3. The underlying cryptography includes rate limiting measures, which allows sites to specify a maximum number of times that their signature can be used in a given time period. This exists to prevent a user from sharing the signature they receive with others. There is discussion in the explainer of putting these rate limiting parameters in a .well-known location on a site, but this seems to be subject to change, which might enable abuse. We'd like to see this more clearly specified, with clear guardrails on use so that they cannot be abused. This might require some analysis to support the choices made.

4. We'd like to see some consideration given to device portability of the underlying keying material that is used. Does your trustworthiness reset if you get a new phone? (This might be a desirable property because it means that there are more reasons that someone might appear too "new", more below.)

5. It's not clear that it is safe to expose enrollment in this system in a cross-site context without revealing additional fingerprinting bits.

6. Given the high computation cost involved in producing the bit, what safeguards can be put in place by user agents to ensure that this does not lead to a different form of abuse? Particularly on battery-powered devices that tend to have less computation resources.

7. Some work clearly needs to be done to safeguard against revealing side channels. Is it not possible to unconditionally perform the computation and return an invalid value if no token exists? This also applies to the hasToken() API, which leaks a fingerprinting bit.

8. The API involves a fetch for all invocations, which seems unnecessary. Though both generation of signatures and validation of proofs might need to occur on servers, imperative JavaScript APIs to manage the necessary interactions are sufficient.

9. Other similar APIs have included a non-trivial base rate of forced errors, even for users who have valid tokens. This is not so much to provide a measure of privacy, though it could provide a small measure of differential privacy, but more to ensure that sites do not become too dependent on the API being able to produce valid proofs. This forces sites to provide a reasonable user experience for people who cannot satisfy their challenge. After all, this API encodes a bias against new or younger users. What, if anything, do you plan to do to encourage sites to be responsible in that regard.

Hi, we are just looking at this in our W3C TAG breakout today. @arichiv @samuelschlesinger @philippp — do you have any thoughts on our feedback above?

Sorry for the delay, we appreciate the feedback given and are considering it as well as the positioning of the Private Proof API itself right now. We hope to revisit when ready, but this may take some time.

Hi @arichiv , many thanks for this spec. Can you please have a look at these?

1. I have a question regarding the design of the protocol: How does this spec resists against a fraudulent who want to impersonate an honest user? Consider this scenario:

• You are fraud or part of a fraud campaign that is small or medium sized, you use a malicious extension to record the message exchange (which is not an unreasonable assumption for fraud).
• As message is not bound to time or recorded nonce (to prevent tracking), you distribute it among dozen of other user agents. Each one will try to impersonate a user, relaying the same messages with the hope that one of them will pass the browser challenge (if the T* is predictable, which I think it is).
• the above scenario may work with large scale or targeted fraud attacks too.

2. Also, The diagram in the explainer is confusing (and misleading) in many ways: for instance (but not limited too), client private key k and then, response k? are they different? Does it mean the private key is sent to the server?

Many thanks again, Ehsan

Hi @toreini. The client's private key k is never sent to the server except as a blinded portion of the request for an issuance (by blinded, I mean the server cannot invert this to discover the value of k), and it is in fact the key thing which prevents the distribution attacks you mention. In particular, we send a proof that there exist authenticated k and i within 0..RATE_LIMIT such that F_k(i || epoch) = RateLimitingToken, and RateLimitingToken is what's actually sent back to the server. Because F_k is cryptographically pseudorandom and our proof is zero-knowledge, we are never revealing the client's identity to the server. Further, because RateLimitingToken is determistically constructed from k andi, any given credential issuance can only be used RATE_LIMIT times per token. This means that, while we aren't binding the token to the user's device (this was a key design choice to allow all device types to be supported), our token presentations are scarce.

Hi @SamuelSchlesinger,

many thanks for your response. yes, I can see that the proof of ownership is sent instead of the private k in the spec text, but please make your protocol diagram more accurate. However, here is my current concern.

If a malicious actor can get access to the RateLimitingToken and the proof, then I think it can relay/replay the token later if it is not bound to something. You are essentially relying on the epoch_length and epoch_limit in the verification algorithm to mitigate the distribution attacks but these two parameters are deterministic. I assume you are holding on economy of scale and say each token cannot be relayed/replayed more than x times, accepting the risk of some fraud actors here and there, but not a large-scale campaign.

Essentially, my question is this: Is the relaying/replaying attack possible if a malicious actor get access to a legit token and proof? If the verification relies on epoch_length and epoch_limit, and they are predictable (which I think they are), then my concern is that if a small/medium fraud campaign or a clever big campaign can successfully bypass the current protocol if they have a collection of valid "RateLimitingToken and the proof". Even in case of using ring signature for issuer fungibility, as described in honest token sharing, collusion can be possible.

Yes, indeed that is possible with the current design in the explainer. One mitigation we could apply is binding the proof to a nonce provided by the issuer at challenge time, the underlying cryptography supports this. Still, I should clarify, if you have a sink of valid tokens, then you can generate proofs and rate limiting tokens anyways, as we cannot bind the tokens to a device without seemingly violating some of our aims to allow cross-platform compatibility.

Currently, this API is on hold, but if we pursue it I will be sure to address the concerns you raised about replay attacks and the inaccurate diagram.