Hacker News Reader

> This is not DRM - WEI does not lock down content

Right, but there is a severe risk that you give the means to block non-mainstream clients, be it browsers, operating systems or devices, correct?

Yes, it's nice to know you may want to allow user agents to browse the web without WEI and I'm sure you have best intentions, but we are already in a world where banks and even stuff like Zoom just look at the user agent string and say "Ah, I don't know this browser, please install Chrome or Edge!". Why shouldn't they just similarly halt in the future if the WEI API does not exist? I (and the browser vendor) can spoof a user agent, but you can't spoof attestation, i.e. cannot fix it if websites don't allow my browser based on the (missing) WEI API. So, how will you prevent this?

How can you make sure that users of e.g. Asahi Linux will be able to use the web in the future? Who will attestate their browser based on what? How will e.g. Gentoo users use the web with their build-from-source browser and OS? Will e.g. Netflix continue to work reliably on a user agent without WEI (but with Widevine) - and will the holdback population (if holdback is implemented at all - no offense intended, but you didn't sound too confident about this on the blink-dev mailing list, tbh) be large and significant enough for them to not just say "eh, can't verify, use the app please or wait a bit"?

> 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.

I'm one of the blink API owners who would need to approve this feature if it were to ship in Chrome. I outlined some of my thoughts on this earlier here: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...

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.

> I will reopen them after the weekend

I suspect you didn’t just forget. It would look good to at least explain why you’re not following through on this, as it’s now Thursday in parts of the world.

In much the same vein as something clearly profoundly hurt you and you want to ruin the web out of spite, I root for global warming because it will destroy all the infrastructure on which you wish to take a giant dump.

> giving websites a way to maintain anti-abuse protections for their sites without resorting to invasive fingerprinting.

What prevents a website from using invasive fingerprinting _AND_ WEI together? I strongly suspect websites will end up using both WEI and invasive fingerprinting because:

1. Websites will want to use invasive fingerprinting on old browsers and it would work within browsers that deliberately don't implement WEI.

2. Websites will want to get as much invasive fingerprinting information as they can get their hands on.

3. It is another layer of fingerprinting in the likely event that WEI is ineffective due to TPM exploits[1], operating system/driver exploits, web browser exploits, determined actors using rooms of computer display recording devices and robotic arm mouse movers, etc. Invasive fingerprinting further increases the cost and complexity to actors the website is trying to block.

> This is not DRM - WEI does not lock down content

It is absolutely 100% DRM. Your proposal states that devices would need to attest their configuration to the website. The website can then block the user because it doesn't want to show the news article to a Linux device where the user can block annoying pop-up ad videos, copy and paste the text or save the web page. The website can instead only allow devices which are factory-configured to block copy+paste, block saving web pages, block screenshots, etc. It's still DRM even with the proposed holdback mechanism because in the best case, a user will still be blocked 9/10 times (or whatever the holdback mechanism is set to). The more likely scenario is a website owner will just refuse to serve content until the client has attested itself. "The requested page can not be provided due to an unexpected problem. Try again in a few minutes."

There are so many flaws with the scheme as currently proposed I feel I could write for days:

Will websites be expected to block and ban users of AMD-SP now that it is broken[1]? Or will whoever conducts ad fraud just buy all the AMD-SP devices they can get their hands on?

As another author replied, are Gentoo users that compile their web browsers and operating systems from scratch just ignored, and the proposal pretends it won't impact these users?

How does the proposal allow users with specialist accessibility software to browse the web without being blocked for being a minority group that is not economically worth website owner's time to support? What prevents abuse of said specialist accessibility software for other purposes?

How would a new start-up developing a competing browser or phone from scratch, and are very much unknown and in a minority position, be able to convince millions of website owners to unblock/allow their new browser or phone? Cloudflare's Friendly Bots program refuses to respond to open source projects, so why would Cloudflare as an implementer of WEI care about new start-ups or small open source software projects?

[1] https://arxiv.org/abs/2304.14717