eth0p

I went to one of their concerts, and their lead singer, David Draiman, was one of the most wholesome and honest guys I've ever seen. Funny headline, but I hope he recovers quickly and without any long-term effects.

Unless something changed in the specification since I read it last, the attested environment payload only contains minimal information. The only information the browser is required to send about the environment is that: this browser is {{the browser ID}}, and it is not being used by a bot (e.g. headless Chrome) or automated process.

Depending on how pedantic people want to be about the definition of DRM, that makes it both DRM and not DRM. It's DRM in the sense that it's "technology to control access to copyrighted material" by blocking bots. But, it's not DRM in the sense that it "enables copyright holders and content creators to manage what users can do with their content."

It's the latter definition that people colloquially know DRM as being. When they're thinking about DRM and its user-hostility, they're thinking about things like Denuvo, HDCP, always-online requirements, and soforth. Technologies that restrict how a user interacts with content after they download/buy it.

Calling web environment integrity "DRM" is at best being pedantic to a definition that the average person doesn't use, and at worst, trying to alarm/incite/anger readers by describing it using an emotionally-charged term. As it stands right now, once someone is granted access to content gated behind web environment integrity, they're free to use it however they want. I can load a website that enforces WEI and run an adblocker to my heart's content, and it can't do anything to stop that once it serves me the page. It can't tell the browser to disable extensions, and it can't enforce integrity of the DOM.

That's not to say it's harmless or can't be turned into user-hostile DRM later, though. There's a number of privacy, usability, ethical, and walled-garden-ecosystem concerns with it right now. If it ever gets to widespread implementation and use, they could later amend it to require sending an extra field that says "user has an adblocker installed". With that knowledge, a website could refuse to serve me the page—and that would be restricing how I use the content in the sense that my options then become their way (with disabled extensions and/or an unmodified DOM) or the highway.

The whole concept of web environment integrity is still dubious and reeks of ulterior motives, but my belief is that calling it "DRM" undermines efforts to push back against it. If the whole point of its creation is to lead way to future DRM efforts (as the latter definition), having a crowd of people raising pitchforks over something they incorrectly claim it does it just gives proponents of WEI an excuse to say "the users don't know what they're talking about" and ignore our feedback as being mob mentality. Feedback pointing out current problems and properly articulating future concerns is a lot harder to sweep under the rug.

The problem with a common UA string is that you would know the request came from someone browsing Lemmy with Sync. Ideally, media requests to any third party should be indistinguishable from a regular web browser. As for empty strings: in my experience, some websites block requests with an empty or missing User-Agent header.

I still think the best approach would be to let the user pick a UA. Having a list of common browser/device pairs that update the version numbers automatically would probably be a good idea, though.

Thank you for making an informative and non-alarmist website around the topic of Web Environment Integrity.

I've seen (and being downvoted for arguing against) so many articles, posts, and comments taking a sensationalized approach to the discussion around it, and it's nice to finally see some genuine and wholly factual coverage of it.

I really can't understate how much I appreciate your efforts towards ethical reporting here. You guys don't use alarm words like "DRM," and you went through the effort of actually explaining both what WEI does and how it poses a risk for the open web. Nothing clickybaity, ragebaity, and you don't frame it dishonesty. Just a good, objective description of what it is in its current form and how that could be changed to everything people are worried about.

Is there anything that someone like me could help contribute with? It seems like our goals (informing users without inciting them, so they can create useful feedback without FUD and misinformation) align, and I'd love to help out any way I can. I read the (at the time incomplete) specs and explainer for WEI, and I could probably write a couple of paragraphs going over what they promised or omitted. If you check my post history, I also have a couple of my own example of how the WEI spec could be abused to harm users.

Ideally, yeah.

I'm not confident that instances would actually enable image proxying, though. The bandwidth for that costs money, and instances don't necessarily have a consistent revenue stream that would make it feasible to run a proxy in addition to hosting the instance itself.

With Sync Ultra being a subscription, I think it would be more viable for lj to maintain an image proxy for Ultra subscribers. And if Lemmy ever adds image proxying itself, the instance proxies could be used where available instead.

For spoofing the user agent, I still think that some level of obscurity could help. The IP address is the most important part, but when sharing an internet connection with multiple people, knowing which type/version of device would help disambiguate between people with that IP (for example, a house with an Android user and an iPhone user). I wouldn't say not having the feature is a deal breaker, but I feel like any step towards making it harder to serve targeted ads is a good step.

Fair point on just using a regular VPN, but I'm hoping for something a bit more granular. It's not that all traffic would need to be proxied, though. If I use some specific Lemmy instance or click on an image/link, that was my choice to trust those websites. The concern here is that simply scrolling past an embedded image will make a request to some third-party website that I don't trust.

I believe there's a misunderstanding somewhere. I wasn't suggesting anything; I was explaining how Web Environment Integrity could be altered in the future to kill extensions.

The current form of WEI does not have the ability to enforce anything. It isn't itself DRM, and it can't prevent extensions from running on pages. What it can do and the only thing it does, is tell websites about the browser environment.

Right now, the only thing it tells websites is the name of the browser. A website having the browser name can't directly enforce page integrity. It's already possible to find out the browser name through the user agent or by fingerprinting it with JavaScript.

If WEI is approved and implemented, that opens up the possibility for future additions to the specification. Those changes could require that the browser sends more info to websites. I gave the example of a change that would require WEI tells the website that the browser has an extension which could modify the page contents.

A website having that information would turn WEI into DRM. It gives the website the choice to refuse service to any browser that is running an extension that could change what the user sees.

I hope that was more clear. I don't expect Google to make changes that immediately block extensions, and then be kind enough to allow some of them back. I suspect they would make changes that don't prevent extensions, and then revise them to prevent certain types of extensions.

In other posts, I've tried to point out how some of the articles and comments around WEI are more speculative than factual and received downvotes and accusations of boot-licking for it. Welcome to the club, I guess.

The speculation isn't baseless, but I'm concerned about the lack of accurate information about WEI in its current form. If the majority of people believe WEI is immediately capable of enforcing web page integrity, share that incorrect fact around, and incite others, it's going to create a very good excuse for dismissing all dissenting feedback of WEI as FUD. The first post linking to the GitHub repository brought in so many pissed off/uninformed people that the authors of the proposal actually locked the repo issues, preventing anyone else from voicing their concerns or providing examples of how implementing the specification could have unintended or negative consequences.

Furthermore, by highlighting the DRM and anti-adblock aspect of WEI, it's failing to give proper attention to many of the other valid concerns like:

• Discrimination against older hardware/software that doesn't support system-level environment integrity enforcement (i.e. Secure Boot)
• The ability for WEI to be used to discriminate between browsers and provide poor (or no) service to browsers not created by specific corporations.
• The possibility of WEI being used in a way to force usage of browsers provided by hostile vendors
• The ability for it to be used to lock out self-built browsers or forked browsers.
• The potential for a lack in diversity of attesters allowing for a cartel of attesters to refuse validation for browsers they dislike.

I very well could be wrong, but I think our (the public) opinions would have held more weight if they were presented in a rational, informed, and objective manner. Talking to software engineers as people generally goes down better than treating them like emotionless cogs in the corporate machine, you know?

I don't disagree, and I'm personally aware of the consequences. Adding the API would be the first step, and future proposals and changes could amend it to add other environment details to tell a website that there are browser extensions that can read or modify the page.

I don't really think summarizing WEI as though it already includes those really helps people understand what WEI currently is or does, though. Nobody reads the actual documentation before repeating what they were told, and that's going to lead to the spread of factually-incorrect information. It's not a bad thing for people to be aware of the long-term issue with having a WEI API, but users' lack of understanding of WEI in its current form is just going to be used by Google as proof to dismiss dissenting feedback as FUD.

To elaborate on why I'm saying a citation is needed: I read the entire proposal and specification myself, and I couldn't find evidence affirming the statement.

The Web Environment Integrity explainer document doesn't require, suggest, or mention script or DOM integrity status under what information is in the signed attestation. Neither does the draft specification, which is pretty devoid of details. The closest it comes to that kind of thing is only enabling the API within a secure context, which basically means "the page was served over HTTPS using a valid certificate".

That doesn't mean that WEI can't be used to enforce page integrity in an extremely roundabout way^1^, but lacking a citation showing that it directly does that, it needs to be explained to people who are out of the loop how it can do that.

^1^: One of the environment details sent to a website is a unique identifier for the browser. Blocking every browser except Android Chrome would limit the ability to use extensions to modify the website, since that browser doesn't support them.

I'm not saying you're wrong or that Web Environment Integrity is a good thing, but a primary source and citation is needed for this statement:

It enforces the original markup and code from a server to be the markup and code that the browser interprets and executes, preventing any post-loading modifications.

Firefox will probably survive if they bow and add WEI support.

I can't imagine Google, Microsoft, and Apple opening themselves up to further monopolization scrutiny by trying to keep attestation restricted to their own browsers on their own operating systems.

Self-built or community forks are probably screwed, though.