Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private State Token API #262

Closed
hober opened this issue Jan 29, 2020 · 2 comments · Fixed by #265 or #958
Closed

Private State Token API #262

hober opened this issue Jan 29, 2020 · 2 comments · Fixed by #265 or #958

Comments

@hober
Copy link

hober commented Jan 29, 2020

Request for Mozilla Position on an Emerging Web Specification

Other information

JS API built on top of Privacy Pass, see #261.

@martinthomson
Copy link
Member

See #261 for our assessment of the underlying protocol. We are deferring assessment there and so will defer here also.

@martinthomson
Copy link
Member

Google deployed the Privacy Pass protocols on the Web under the name “Private State Tokens”, which has been discussed in the Anti-Fraud Community Group of the W3C. We see several serious flaws in this deployment that mean that we have to take a “negative” position.

There are several characteristics of Google’s implementation of Privacy Pass for the Web that deserve praise. In particular, the detailed specification for Web integration is appreciated. We also appreciate the effort to support the provision of tokens by arbitrary sites, which goes some way to address our concerns about equitable access for sites.

However, Google’s proposal and deployment do not place adequate controls on the semantics of tokens. Having a more open policy for participation by sites means that there is no obvious way to ensure that tokens carry acceptable semantics.

Google requires that sites make a public declaration (https://github.com/privacysandbox/attestation) that they will not use this API for tracking purposes, but we do not believe that this is an adequate measure. There are potential abusive uses of tokens that do not involve tracking.

The choice to use a joint attester/issuer deployment model means that the issuer and service can use timing to correlate issuance (where private information is revealed) and redemption (where that information should not be).

The controls that we list in the latter half of our response to Apple’s proposal apply equally to Google’s proposal. In summary, we are skeptical that it is possible to develop adequate controls on the actions of issuers for this system to work. Our analysis goes into further detail.

We understand that the intent is to iterate on the proposal with a goal of eventually addressing these concerns, but we have to judge based on what is documented, implemented, and deployed.

martinthomson added a commit to martinthomson/standards-positions that referenced this issue Jan 8, 2024
1. Remove the position on privacy pass as a whole
2. Update the Private State Token (formerly Trust Token; Google) position to reflect conclusions
3. Add a position on Private Access Tokens (Apple)

Closes mozilla#261.
Closes mozilla#262.
Closes mozilla#954.
@tantek tantek closed this as completed in 3ed3f7d Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants