I haven't reviewed the proposal enough to see how they implemented that, and if it was done in a cryptographic way that prevents changing to 100%, then that could work. But the fact remains that control of our browsing computing environment is diminishing under this proposal.
I think if it were changed to be 100% then it would be problematic. Also it seems the proposal writer would also agree that some form of opt out is required to make it viable so as to not forbid unknown clients.
I think its important to stay away from considering potential “what ifs” that completely defy the intent of the spec. For an example of why this isn’t effective discourse, we could have a potential addition to the spec to explicitly block users from certain countries. That’s not great but also its easy to understand why its not worth debating that point (even though it does sound scary).
Granted, I don't fully understand how they intend to holdback, but even if they cache the results of the attestation such that 10 calls in a row fails to attest, they can't cache it infinitely. Website can employ traditional fingerprinting techniques/cookies in combination with attestation to build pretty foolproof systems to not serve the user based on attestation results.
Google is a big dog and will not care about our yapping. If it's allowed to do as it will without consequence then it will do so, and there is nothing that individuals can do to stop it other than to cease using their products.
Google would need to make holdbacks persistent enough that you couldn't retry them and get a different result. Even if they do, there are other problems, but... I mean, randomly failing requests is definitely not enough to guarantee that attestation would be optional. And there are no details I see in the spec that suggest to me that Google is planning to do something different.
Part of the job of web specification development is to determine what potential bad actors could do in the future. If a spec was proposed that easily allowed blocking users from certain countries, I would want that listed in the potential risks. Mitigations and technical requirements are introduced into specs all the time that only exist to stop a potential future attack.
So, no, you couldn't continually request attestation from the one site. Instead, you could create 20 separate top-sites and load them all in tiny iframes. :)
Remember that Firefox has at least a 3% marketshare. Safari has somewhere in the neighborhood of 20%. If websites are willing to go Chrome-only in that environment, permanent holdbacks won't change anything for those websites.
Particularly not if the solution to those holdbacks is "reinstall your browser and the holdback will probably go away." Which... they'd need to be unless Chrome starts tracking users to figure out who should have what holdbacks :)
The only way that holdbacks matter is if they affect 100% of Chrome users -- ie every single one of your customers/readers will at some point not send you attestation at some point for your website. And even then... telling them to refresh the page becomes a problem.
But it it's only a subset of users, then just banning 5% of users (especially from ad-supported platforms) seems perfectly feasible for a company and would probably be a preferred solution for some of them.
----
User: "Hey, for some reason when I browse Reddit nothing loads."
Support: "Yeah, very rarely a new Chrome install will do that. If you create an account and sign in, and then you send us some verification documents like an ID so we know you're not a scammer, then you'll still be able to browse. Otherwise just reinstall Chrome."
User: "Is there anything else I can do?"
Support: "No, we have to protect our ad integrity. If reinstalling the browser doesn't help, contact Google about it."
----
> Instead, you could create 20 separate top-sites and load them all in tiny iframes. :)
This too :)