You should be as comfortable running the (proposed) attestator on your machine as you are running anti-virus software. In thinking about it relative to anti-virus, I came across an insight:

The Web Environment Integrity proposal isn't much different than requiring that, in order to receive an email, the sender both secures their machine with anti-virus and provides proof to you, the receiver, that the message in question is virus-free. Otherwise, without this proof, you won't accept the message.

Metal detectors and the requirement to pass through one to enter certain, defined spaces are probably the physical analogy that people are most familiar with.

I don't think this is a good analogy. The WEI proposal is different to anti-virus in many ways. The fundamental ones are:

1) WEI doesn't attest that your device isn't running malware, it attests that your device is running a particular set of software -- it is a positive filter, rather than a negative one. This means that you can't run your own software (if it's part of the WEI trust chain), even if you know it's not malware, without changing the attestation (and see the next point for why this isn't viable).

2) Because WEI doesn't have a way to prove that software is malicious or not, it instead requires you to trust the attestor (in a cryptographically secure way). In the usual case, this will mean trusting Google. This means that if I write my own attestor, there is no particular reason that people should trust what it says. On the other hand, there are plenty of reasons to trust what Google says, given that they wrote the software and certified the phone. The attestor model, because it relies on trust, is fundamentally biased towards organisations which you already are obliged to trust to some extent.

The same arguments apply to metal detectors. This isn't about detecting metal (negative filter), it's about detecting approved clothing.

1. Running a particular set of software _correctly_ i.e. the positive filter is positive insofar as the negative filter is negative. This logic applies to anti-virus if you predicate it's negative filtering on a positive filter that the problem itself hasn't been backdoored (which we arguably do as part of our intuitive trust model).

I disagree with your characterization of metal detectors defining success on approval. Consider the practical difficulty of defining a whitelist of every possible piece of "approved clothing" compared to a blacklist of known knowns (e.g. guns, knives, poison, etc.).

2. I think we're in agreement that who is permitted as a legitimate attestor is a core issue. I wouldn't ultimately conclude that it must be Google, although many web admins would be satisfied with that.

Your metal detector "that seems practically difficult" is exactly the issue: WEI does create a implicit whitelist (I believe the preferred term is allowlist). WEI will attest anything, but if you want it to be useful you have to already have some idea of what attestations you're going to trust.

Keeping a continuously-updated list of all attestations you're interested in trusting does indeed sound practically difficult. So it's quite likely that most sites will only trust attestations from Google about unmodified Google-supplied software (and perhaps some of the larger third parties).

I'm not sure how you're arriving at the implicit whitelist statement. Can you link to section in the proposal that supports this conclusion?

I'm still coming to the opposite conclusion: For example, as a web admin, it would be useful to me to block requests that forge the User Agent. In your mind, is this a white or black list?

""" Attester-level acceptable browser policy If the community thinks it's important for the attestation to include the platform identity of the application, and is more concerned about excluding certain browsers than excluding certain OS/attesters, we could standardize the set of signals that browsers will receive from attesters, and have one of those signals be whether the attester recommends the browser for sites to trust (based on a well-defined acceptance criteria). As new browsers are introduced, they would need to demonstrate to attesters (a relatively small group) that they pass the bar, but they wouldn't need to convince all the websites in the world. """

In other words, they realise it's infeasible for sites to keep up with new browsers and figure out whether to trust them. This is an implicit whitelist (I believe the preferred term is allowlist) because each site would have to keep a list of attested "platform identities" that they trust.

Instead, in the above paragraph, Google proposes that new browsers demonstrate to Google that they are worth attesting, and then Google will get the attester to say "Additionally, as the Google attester, I trust this browser". This is an explicit allowlist.

In other words, if you want to write a new browser, or fork an existing browser, or write or a site scraper, or whatever else, you either have to convince every site using WEI in the world to trust you, or you have to convince Google to trust you. Both methods involve an allowlist.

To use your example, as a Web admin, you wouldn't get information like "forges user agent". You would get a signal like "Genuine Chrome running on unrooted stock Android" (the attestation), plus "Google's attester recommends this browser for sites to trust" (the extra signal proposed by the paragraph I quoted above).

If you use the former signal, you have an explicit allowlist on your site. If you use the latter signal, you are relying on Google's allowlist.