> It’s also an explicit goal to ensure that user agents can browse the web without this proposal
How, in an information theory sense, can you stop website operators from using this attestation information to block subsets of users? The "holdback" mentioned in your reference link seems like an optional thing, as if we're concerned about good faith actors rather than the opposite.
It would be nice if the spec included examples of how a hypothetical bad actor couldn't abuse the spec to block non-attestors. i.e. How do we stop "this website only works in Chrome on Windows" but for attestation? Right now, it's trivial to "fix" because we can lie about our environment (it's likely just reading our User-Agent) and it's unlikely that the website will actually not work in other OS/browser contexts.
Some websites really do only work in certain contexts, but I think critics' concern is what happens when the website would work perfectly fine, but it refuses to. I think this is largely the same concerns people have with mobile app permissions, but those can be gatekeeped by mobile app stores who can enforce political goals such as "You can't ask for permissions you don't need and refuse to work when you don't get them", websites have no such constraints.
What's to stop websites from blocking random users now? Nothing, really. But we don't have to bypass any cryptographic attestations in order to try to work around those blocks. This spec seeks to stop that.
It's complex and nuanced, all about altering probabilities of various bad things and TBH work still needs to be done to prove a useful middle ground even exists.
But one thing I can say for sure is there's no way I'm approving Chrome adding a feature which makes it possible for websites to be viewed only in Chrome. Nobody wants that and it's listed as an explicit anti-goal of the feature. Chrome couldn't have existed in the first place without masquerading as Safari, who masqueraded as Netscape etc.., this is something we're all very aware of and committed to in Chrome as its core to the openness of the web.
How, in an information theory sense, can you stop website operators from using this attestation information to block subsets of users? The "holdback" mentioned in your reference link seems like an optional thing, as if we're concerned about good faith actors rather than the opposite.
It would be nice if the spec included examples of how a hypothetical bad actor couldn't abuse the spec to block non-attestors. i.e. How do we stop "this website only works in Chrome on Windows" but for attestation? Right now, it's trivial to "fix" because we can lie about our environment (it's likely just reading our User-Agent) and it's unlikely that the website will actually not work in other OS/browser contexts.
Some websites really do only work in certain contexts, but I think critics' concern is what happens when the website would work perfectly fine, but it refuses to. I think this is largely the same concerns people have with mobile app permissions, but those can be gatekeeped by mobile app stores who can enforce political goals such as "You can't ask for permissions you don't need and refuse to work when you don't get them", websites have no such constraints.
What's to stop websites from blocking random users now? Nothing, really. But we don't have to bypass any cryptographic attestations in order to try to work around those blocks. This spec seeks to stop that.