Intent to Implement: Trust Token API

[Charles Harrison]

Contact emails

sva...@chromium.org, cshar...@chromium.org, kle...@google.com

Explainer

https://github.com/WICG/trust-token-api

Design doc/Spec

No spec yet. TAG review requested.

Summary

This is a new API for propagating a notion of user trust across sites, without using cross-site persistent identifiers like third party cookies.

Note that this is a very early stage design, and we’re explicitly not asking for permission to ship yet. We would like to get initial feedback on the idea and start prototyping.

Motivation

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.

Risks

Interoperability and Compatibility

As this is a new feature, the risk here is mostly interoperability, in the case some browsers do not ship the feature.

Firefox: No public signals

Edge: No public signals

Safari: Public support. General support for the idea during TPAC 2019 discussion.

Web developers: There is positive interest from Cloudflare, who are also in the process of standardizing their Privacy Pass protocol.

Ergonomics

N/A

Activation

Using this feature requires spinning up a (or partnering with an existing) trust token issuer that can issue and verify trust tokens, which is non-trivial. Additionally, verifying properties of the Signed Redemption Record or the client signature require some cryptography. It would be beneficial to have server-side libraries that developers can use to help make using this API easier.

Security

See the security considerations section of the explainer.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Link to entry on the feature dashboard

https://chromestatus.com/feature/5078049450098688

Requesting approval to ship?

No

[Michaela Merz]

Just to clarify: The token issuer (trust center) knows each and every web-site that request a trust token? And even the referrer? If so, I would strongly argue against this method ..

Michaela

[Charles Harrison]

Hey Michaela,

Each token issuer knows each site that requests/redeems their trust token, just like today e.g. Google Fonts knows every site that requests their fonts. Of course, this API should respect Referrer-Policy, so if a site wants to change the default behavior of 'Referer' they can.

What the trust issuer learns with this API should be similar to what other third parties on a page learn with no credentials. Let me know if that clears things up!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5b2b7f54-c866-41c2-b485-4a35cde1b0b8%40chromium.org.

[Tom Jones]

is it the intent that all relying parties (aka clients) would need to be registered with the issuer prior to requesting the validation of a token similar to Google/MSFT/FB today?

Do we have any feedback from the big existing issuers that they would be willing to delivery these tokens into the future?

I must admit that i am disappointed in the narrow scope of this proposal. Coming from BLINK i can understand that, but the the broader web community of native apps this feature may be important as well.

I posted on github that i am disappointed also in the lack of clear directives to user agents to assure a common user experience protocol.

[Steven Valdez]

Currently, I'd imagine that relying parties don't need to be registered with the issuer (at least in the general token use case), and the issuer should support arbitrary clients. There are likely going to need to be restrictions placed here to prevent malicious clients from (D)DoSing the issuer and similarly restrictions to prevent publishers from draining all of a particular issuer's tokens from the client.

Though there may also be use cases where different requirements might be needed, depending on the use case/user agent. In the case we end up going with the Allowed/Blocked Issuer List mitigation for malicious/abusive uses of the API, we could require that issuers who want inclusion to agree to policies about whether they are required to support arbitrary relying parties, how to classify malicious actors, etc and each user agent could have their own policy based on their use case.

Generally speaking, the current proposal is still in the early stages, and while it comes from mostly a web browser focused use case, we'd like to be able to support broader use cases and other parts of the web community. That said, we also need to be careful that the API is able to support legitimate use cases in building trust, while preventing malicious/abusive uses.

[Michaela Merz]

There are plenty of folks, us included, who are serving third party libraries from their own servers, because we believe that our users shouldn't be  exposed to third parties they don't even know. The trust token environment should also respect the privacy of the client. It should be implemented in a way that the the server is the mediator between the user and the trust center.

We should strive to improve overall privacy and confidentiality, even if it takes more effort to implement.

Michaela.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/X9sF2uLe9rA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxDYgmnkTSJ7XanE%2BRNONoj%2BM_XGmZ346jK6bYyzUw%3Dc%3DQ%40mail.gmail.com.

[Steven Valdez]

With the current design, if you control the first-party site, you can specify which trust issuers you want to support (or none if you'd like to prevent any from being used on your site).

--

Steven Valdez |

Chrome Privacy Sandbox |

sva...@google.com |

210-692-4742

[Michaela Merz]

That's not good enough. Because it will most likely become something like oAuth today. You can choose between, big corp, bigger corp and huge corp. We must re-think this paradigm and create technologies with "privacy first" in mind.

Michaela

[Steven Valdez]

Having a wide ecosystem of both consumers and issuers of tokens is something we'd like to support, but there are some privacy challenges with allowing large numbers of issuers, since if multiple issuers are colluding, you could be leaking multiple bits of information for a user, which could be a privacy leak.

If sites A.example and B.example want to share data (for example a N bit user identifier), they could configure N issuers (that are colluding) that issue tokens based on whether the Mth bit of the user ID is 0 or 1. So a user with tokens for issuer0, issuer3, and issuer4 likely has a user ID of 10011.

As we refine the design of the API, we'll need to balance the privacy impact of abusive publishers/sites with ensuring a wide and growing ecosystem. We'll need to work on refining policy and technical measures to help mitigate these threats.

[Michaela Merz]

Steven: Ups. No. I didn't want to exclude blink-dev. Wrong button.

For the group: I suggested the following: User A is being verified as trusted by say Google. He get's a a number of anonymous tokens which can not be traced back to the particular user. If requested by site b, the browser passes a token to the site which then forwards it to Google (the token has a an issuer identifier). Google answers with an ACK or NACK and the user is verified (or not), without any loss of privacy.

Steven explained that this suggestion is a bit closer to the original PrivacyPass proposal, but might be too expensive for the site and that there would be vectors for abuse (servers caching the tokens and redeeming them later, building pools of tokens for each user to more easily leak state across the token issuance/redemption, etc)

As to your explainer (Steve) : Yes - it could be expensive for the site to verify every user. So it's up to them (us) to make it as streamlined as possible. In our case: We would verify the UA maybe once per session and use our own methods to keep the user validated. As to the abuse: It's easy for the UA to add some expiration bits before it is forwarded to the site. It use it (right away) or lose it. 

Sorry about the confusion as a result of not adding the group to my previous post.

Michaela

On Wed, Oct 16, 2019 at 9:52 AM Steven Valdez <sva...@chromium.org> wrote:

(did you intend to drop blink-dev from the thread)

This is a bit closer to the original PrivacyPass proposal. The original reason for the UA doing the token redemption and SRRs was that requiring a publisher to have to perform a request to the issuer on every user might be prohibitively expensive, and when multiple third parties on one first-party site need trust tokens it would allow less abuse to do a single redemption controlled by the UA and then pass along the SRRs to all the relying third-parties.

We could potentially support passing the raw trust token directly to the website, possibly by adding a param to send the trust token instead of the SRR to the site, though we'll need to be careful that the extension doesn't add additional abuse vectors (servers caching the tokens and redeeming them later, building pools of tokens for each user to more easily leak state across the token issuance/redemption, etc). It may also be harder to mitigate potential abuse from issuers who decide to block websites from redeeming tokens (blocking UAs from redeeming tokens is also an issue in the current design, but more easily detectable from the UA).

On Tue, Oct 15, 2019 at 6:45 PM Michaela Merz <misc...@googlemail.com> wrote:

Steven - I still don't think this is good enough. Here's my suggestion: User A is being verified as trusted by say Google. He get's a a number of anonymous tokens which can not be traced back to the particular user. If requested by site b, the browser passes a token to the site which then forwards it to Google (the token has a an issuer identifier). Google answers with an ACK or NACK and the user is verified (or not), without any loss of privacy.

Michaela

[Charles Harrison]

Michaela,

While I totally see the desire for this kind of protocol flow, there are a few issues we'd need to resolve:

1.  Sending raw tokens directly to third parties without consent from the token issuer brings up a difficult problem: token exhaustion attacks. In the current design, a token issuer can choose whether or not they want a token redeemed on a given site, to avoid bad sites intentionally redeeming tokens just to exhaust the token supply. While we could tell sites that they need to do a separate, server-to-server round trip to the issuer to actually verify the token, malicious sites could opt not to (there is no browser enforcement).

If we allowed third parties to request tokens without the issuer "in the loop" and we still wanted to prevent this attack, it might require token issuers to "tag" tokens with block/allow-lists of possible redeemers known a priori.

2. The current design relies on key consistency checks on the issuer at redemption time, to ensure that the issuer is not using unique keys for different users. This requires a separate fetch to the issuer in the context of the site that wants to redeem the token. Currently, this is the hook where issuers can refuse to redeem the token, by intentionally failing the check. However, it also serves a critical privacy purpose. If we were to send tokens directly to a third party without a key consistency check, this API could be used as a replacement for third party cookies.

One tentative idea that solves both of these issues is to just make key consistency and redemption optionally redirect through the publisher site (or have responses from the publisher include proof that the issuer is OK with it). This would allow publishers to act as sort of privacy proxies in front of token issuers. 

I think this is going a bit too deep for a mailing list thread though, so it might be best to file an issue on the Github to continue this design discussion. 

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7Y3xPvN_rnq6_y%3DJpek_nZhqO3P6hU7Mpfg-as1gFMfg%40mail.gmail.com.