Registering issuers with browser developers

[martinthomson]

I had somehow completely missed that there was some intent to have issuers register with browser vendors.

That's problem 1: the spec isn't clear about this at all. I had assumed that sites would pick (and maybe commit to) an issuer of their choice. After all, the issuer identity is part of the URL that is provided as an argument to fetch().

Problem 2 is the bigger one: is this a good idea? Apple does it for PAT too, but that doesn't make it good.

I think that it isn't good and anything that depends on registration needs really careful consideration of alternatives, because building the necessary safeguards (technical, procedural, and governance) is icky.

There are a ton of reasons why using a legally-enforceable contract or similar agreement makes it easier to deploy something like this, but it means that Google now becomes a gatekeeper for the operation of the system. Google has to deal with a bunch of interesting governance questions about how they approve issuers, what rules they apply, how those rules are enforced, and so on. See also CA/BF¹.

It means that other browsers need to stand up their own system as well. Then, if there are differences (there will be), sites will shoulder the cost of having to interoperate with browser-specific issuer sets. The anti-competitive effects that come from this seem like they might be tricky to navigate (the usual disclaimers apply). There might even be geopolitical consequences. I don't say this to be alarmist, but because these are potential consequences of building something like this.

Footnotes

1. I mention CA/BF because there are strong similarities. There we have different policies from different browsers, but because the system somehow manages to operate despite that. Browser policies there tend to be mostly compatible, but it is the CA/BF and the people that work there that produce that consistency that allows the system to function. CA/BF is also a special case and I have strong reservations about the viability of trying to make another system like it. ↩

[dvorak42]

The registration requirement is a result of a few considerations:

1. A technical need to have a system of preventing the issuer from presenting targeted keys to different users (the key consistency problem in privacypass), and to enforce key rotation limits globally to avoid frequent key rotations. Initially (see consideration 3) we expect that any issuer that can maintain the technical requirements of registration will be accepted, our current registration requirements (https://github.com/WICG/trust-token-api/blob/main/REGISTRATION.md) is purely technical and an acknowledgement of having to refresh their registration after a period of time. We're hoping to increasingly automate the registration process over time where once an issuer provides their information, automated systems will verify the endpoints/keys before adding it to the commitment fetcher. Long-term a more consistent key consistency story/service would be nice, perhaps some sort of key transparency system, however that would need buy-in from other UAs/ecosystem for spinning up such a service or other key consistency system.

2. As we expect this API to evolve and change somewhat as the protocol is further standardized and other changes are made as other UAs help standardize this API, this registration process is also intended to give a way for communication with active issuers to help with future updates.

3. Finally, while we hope that the technical limitations of the API will prevent bad actors/uses of the API, having this registration/re-registration requirement lets us re-evaluate the sorts of requirements/limitations on issuers if it becomes necessary to mitigate/prevent abuse of the API.

I'll add a spec-work tag to this issue to track adding a note to the spec to reference the UA-specified behavior on "registering" issuers before websites can use them.

[etrouton]

Hi @martinthomson, thanks for pointing out the technical, procedural, and governance hurdles with this idea.

After further discussion, we're going to update the registration for Private State Tokens to be in line with the developer enrollment plans for the rest of the Privacy Sandbox work. In particular, instead of policy enforcement through browsers as described in point 3 above (individually, or collectively as in CA/BF), we're developing an approach along the lines of https://developer.chrome.com/blog/announce-enrollment-privacy-sandbox/#attestations: ask developers to make some public attestations about their behavior as API users, and have browsers just ensure that those public statements are being made. There are well-established consequences in much of the world for a company misrepresenting what it does with people's data.

[martinthomson]

This attestations idea has some attack modes¹ that mean that - until I see details - I can't really comment on whether your plan is going to address the concern. Do you have a concrete design in mind?

Footnotes

1. Let's imagine that your attestation consists of a public statement that can be automatically verified by browsers. This doesn't work if the adversary is willing to make that statement conditionally based on who is asking. Then they get nearly covert access to the API as long as they don't target too many people. You can ensure that the browser maker saw the attestation by requiring that they sign it, but then we're back into the business of browser makers acting as gatekeepers. ↩

[thegreatfatzby]

Hey @etrouton what's the latest on the Attestation vs Registration status? As I've been trying to grok this API and it's intended usage, how to test it out, etc, it seems like the Registration requirement is still active. The Registration doc in the spec still indicates a repo to hit to ask for permission, the list there was updated recently, and there are registration requests being dealt with in the last few weeks.

[dvorak42]

The current version of the API will continue to require registration, though you can test the API without registering by manually providing key commitments as a command-line flag as described in https://www.chromium.org/updates/trust-token/.

[thegreatfatzby]

@dvorak42 @etrouton thanks for the update, understood for now and will play around using the link. I'm still curious to square the circle, short or long term, of the previous comment and if/when/how that will be integrated into PST.

[etrouton]

Hi @thegreatfatzby, we expect registration to continue for the foreseeable future, but are open to feedback on the process and may make some changes as to what we are asking issuers to acknowledge and disclose ( https://github.com/GoogleChrome/private-tokens/blob/main/PST-Registration.md#disclosure-and-acknowledgement). I'm not sure if this answers your question, but we are not requiring currently any broader attestations at the moment.