Intent to Experiment: Trust Token API

[Steven Valdez]

Contact emails

sva...@chromium.org, privacy-s...@chromium.org

Design Doc

https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit

Summary

This is a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.

 

Initially this API will be available via an Origin Trial so that we can measure the usability and speed of this API.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/

Goals for experimentation

For an initial origin trial we hope to see that token-derived signals can be used by third parties, captcha providers, DoS protection, ad networks, CDNs, for fraud detection without 3P-cookie based schemes. Additionally we'll be checking third-party latency metrics and Chrome heartbeat metrics to ensure that this API is not blocking user visible load.

Experimental timeline

This experiment is intended to run through Chrome M84 to M87.

Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5078049450098688

[Dominic Farolino]

On Tue, May 5, 2020 at 10:31 AM Steven Valdez <sva...@chromium.org> wrote:

Contact emails

sva...@chromium.org, privacy-s...@chromium.org

Design Doc

https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit

Summary

This is a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.

 

Initially this API will be available via an Origin Trial so that we can measure the usability and speed of this API.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/

This link is broken for the public. You can use this instead: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X9sF2uLe9rA 

Goals for experimentation

For an initial origin trial we hope to see that token-derived signals can be used by third parties, captcha providers, DoS protection, ad networks, CDNs, for fraud detection without 3P-cookie based schemes. Additionally we'll be checking third-party latency metrics and Chrome heartbeat metrics to ensure that this API is not blocking user visible load.

Experimental timeline

This experiment is intended to run through Chrome M84 to M87.

Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5078049450098688

--
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/CANduzxAHqCKWRz9o8uJeAtcE2cMGeKmYoDG1wPsTeiSTA_MRJQ%40mail.gmail.com.

[Yoav Weiss]

Thanks for working on this. This seems like an important problem to solve!

On Tue, May 5, 2020 at 4:31 PM Steven Valdez <sva...@chromium.org> wrote:

Contact emails

sva...@chromium.org, privacy-s...@chromium.org

Design Doc

https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit

Would've been good to also add a link to the explainer.

Summary

This is a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.

 

Initially this API will be available via an Origin Trial so that we can measure the usability and speed of this API.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/

Goals for experimentation

For an initial origin trial we hope to see that token-derived signals can be used by third parties, captcha providers, DoS protection, ad networks, CDNs, for fraud detection without 3P-cookie based schemes. Additionally we'll be checking third-party latency metrics and Chrome heartbeat metrics to ensure that this API is not blocking user visible load.

Do you have partners lined up?

What would the experiment look like? Who would need to sign up for an OT? The issuer? The redeemer 1P? The redeemer 3P?

 

Experimental timeline

This experiment is intended to run through Chrome M84 to M87.

Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5078049450098688

--

[sligh...@chromium.org]

Would love to understand if there are specific questions y'all want to answer with this experiment. If you could perhaps just outline those here, that would be great.

With that nit, LGTM!

Regards

On Wednesday, May 6, 2020 at 11:22:16 PM UTC-7, Yoav Weiss wrote:

Thanks for working on this. This seems like an important problem to solve!

On Tue, May 5, 2020 at 4:31 PM Steven Valdez <sva...@chromium.org> wrote:

Contact emails

sva...@chromium.org, privacy-sandbox-dev@chromium.org

Design Doc

https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit

Would've been good to also add a link to the explainer.

Summary

This is a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.

 

Initially this API will be available via an Origin Trial so that we can measure the usability and speed of this API.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/

Goals for experimentation

For an initial origin trial we hope to see that token-derived signals can be used by third parties, captcha providers, DoS protection, ad networks, CDNs, for fraud detection without 3P-cookie based schemes. Additionally we'll be checking third-party latency metrics and Chrome heartbeat metrics to ensure that this API is not blocking user visible load.

Do you have partners lined up?

What would the experiment look like? Who would need to sign up for an OT? The issuer? The redeemer 1P? The redeemer 3P?

 

Experimental timeline

This experiment is intended to run through Chrome M84 to M87.

Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5078049450098688

--
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+unsubscribe@chromium.org.

[Steven Valdez]

At least initially, some of the questions we'd like to answer are:

- Whether there are any performance/latency issues with requesting/redeeming Trust Tokens as part of normal interactions.

- Whether the ergonomics of the APIs are usable in the wider web.

- Get feedback about additional use cases/modifications that can be made to the API to make it more useful for the wider ecosystem.

- Data on the number of redemptions we see sites perform between issuance (to help determine the scope of storage/issuance we should optimize the protocol towards supporting)

- Whether a Trust Token can provide equivalent/sufficient signal to be useful as a 3P-cookie replacement in existing systems.

- Ease of deployability of the infrastructure to support issuers/redemption logic in a web setting.

On Thu, May 7, 2020 at 3:27 PM <sligh...@chromium.org> wrote:

Would love to understand if there are specific questions y'all want to answer with this experiment. If you could perhaps just outline those here, that would be great.

With that nit, LGTM!

Regards

On Wednesday, May 6, 2020 at 11:22:16 PM UTC-7, Yoav Weiss wrote:

Thanks for working on this. This seems like an important problem to solve!

On Tue, May 5, 2020 at 4:31 PM Steven Valdez <sva...@chromium.org> wrote:

Contact emails

sva...@chromium.org, privacy-s...@chromium.org

Design Doc

https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit

Would've been good to also add a link to the explainer.

Summary

This is a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.

 

Initially this API will be available via an Origin Trial so that we can measure the usability and speed of this API.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/

Goals for experimentation

For an initial origin trial we hope to see that token-derived signals can be used by third parties, captcha providers, DoS protection, ad networks, CDNs, for fraud detection without 3P-cookie based schemes. Additionally we'll be checking third-party latency metrics and Chrome heartbeat metrics to ensure that this API is not blocking user visible load.

Do you have partners lined up?

What would the experiment look like? Who would need to sign up for an OT? The issuer? The redeemer 1P? The redeemer 3P?

 

Experimental timeline

This experiment is intended to run through Chrome M84 to M87.

Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5078049450098688

--
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.

[Steven Valdez]

On Thu, May 7, 2020 at 2:22 AM Yoav Weiss <yo...@yoav.ws> wrote:

Thanks for working on this. This seems like an important problem to solve!

On Tue, May 5, 2020 at 4:31 PM Steven Valdez <sva...@chromium.org> wrote:

Contact emails

sva...@chromium.org, privacy-s...@chromium.org

Design Doc

https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit

Would've been good to also add a link to the explainer.

Summary

This is a new API for propagating a notion of user authenticity across sites, without using cross-site persistent identifiers like third party cookies. Trust Token is built on Privacy Pass for anonymous tokens that can't be tracked between issuance and redemption.

 

Initially this API will be available via an Origin Trial so that we can measure the usability and speed of this API.

 

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/

Goals for experimentation

For an initial origin trial we hope to see that token-derived signals can be used by third parties, captcha providers, DoS protection, ad networks, CDNs, for fraud detection without 3P-cookie based schemes. Additionally we'll be checking third-party latency metrics and Chrome heartbeat metrics to ensure that this API is not blocking user visible load.

Do you have partners lined up?

What would the experiment look like? Who would need to sign up for an OT? The issuer? The redeemer 1P? The redeemer 3P?

There are some Google origins interested in issuing tokens and others for redeeming them in 3P contexts. I think that it is also valuable to eventually get feedback/more parties involved, both as issuers and redeemers, to see if the ecosystem is usable at scale. We have an initial protocol library in BoringSSL that others can use to write their own issuers/clients, and we'll try having some sample code for calling into the protocol on the client side further down the line.

Currently the issuing origin will need to sign up for an OT and provide configuration details to distribute to Chrome clients. Since redemption would likely happen via 3P contexts and it's infeasible to register most/every 1P that embeds a particular 3P, we'll be using something like third-party origin trials for the redemption side if it's available in time for this experiment.

[David Van Cleve]

Next week, we'll be making a configuration change that updates the Trust Token API origin trial to use a third-party origin trial instead of its current nonstandard origin trial configuration.

This involves two significant behavior changes:

1. Redemption and signing operations will require that they be executed in contexts bearing origin trial tokens. Third-party script that currently executes Trust Tokens redemption and signing will need to begin to serve origin trial tokens unless all of the scripts' embedding contexts already provide origin trial tokens. 

2. It will now be practical to request token issuance from third-party scripts. In the current state, a.com script embedded on sites s1.com, s2.com, and s3.com would need to ensure that each embedding site sj.com served an sj.com origin trial token in order to allow the script to use the feature. In third-party origin trial mode, instead, the a.com script can simply enable the feature itself by providing an a.com third-party origin trial token to each page on which it is embedded. This is the main motivation for the configuration change.

If you have any questions, please ask here or on Monorail. Thanks (and Happy New Year)!