I have a 7950X, a pile of RAM, and an unfairly expensive RTX 4000-series GPU. The cursor occasionally hitches for ~400ms whenever doing things like opening task manager or resuming from the lock screen, so that checks out unfortunately.
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.
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.
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:
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 hope you were being sarcastic, because, ideally, nobody implements this.
Good article. Not clickbait/ragebait, and it explains the specification simply and succinctly, while also demonstrating why it’s dangerous for the open web.
I’m not a lawyer, nor do I have the full context of the legislation you’re quoting, but my interpretation of that paragraph is that it only applies to aircrafts that are carrying passengers.
. . . in the air space in possession of another, by a person who is traveling in an aircraft, is privileged . . .
You’re the one who does this for a hobby, though. I’m sure that you know the laws more than I do :)
Fair and respectable points, but I don’t think we’re going to see eye to eye on this. It seems like we have different priorities when it comes to reporting on issues.
Honestly, I don’t disagree with you in thinking that the ulterior motive of the proposal is to undermine user freedom, user privacy, and/or ad blockers. Given Google’s history with Manifest V3 and using Chrome’s dominance to force vendors to adopt out-of-spec changes to web standards (passive scroll listeners come to mind), it would be burying my head in the sand to expect otherwise. My issue here is with portraying speculation and personal opinions as objective truths. Even if I agree that a locked down web is the most likely outcome, it’s just not a fact until someone working on that proposal outright says it was their intent, or it actually happens.
That doesn’t mean I think we should ignore the Doomsday device factory until it starts creating Doomsday devices, either, though. Google will never outright state that is their goal to cripple adblockers or control the web, and if it comes to happen, they’ll just rely on corporate weasel words to claim that they never promised they wouldn’t. And since we can’t trust corporations to be transparent and truthful, we shouldn’t be taking their promises or claims at face value. You’re absolutely right about that.
Going back to reporting about this kind of stuff, though: It’s not wrong for the original post to look past the surface-level claims, or for people to point out the corporate speak and lack of commitment. If there’s a factory labeled “Not Doomsday Devices” that pinkie promises they aren’t building Doomsday devices, I definitely would want someone to bring attention to it. I just don’t think the right way to do it is with a pitchfork-wielding mob of angry citizens who were told the factory is unquestionably building anthrax bioweapons, however.
We don’t gain much from readers being told things that will worry them and piss them off. I mean—sure—there’s now more awareness about the issue. But it’s not actually all that constructive if they aren’t critically engaging with the proposal. Google and web standards committees aren’t going to listen to a bunch of angry Lemmy users reiterating the same talking points over and over. They’re just going to treat it as a brigade and block further feedback until people forget about it (which they did).
If the topic was broached in a balanced and accurate way that refrained from making conclusions before providing readers with the facts, there would be less knee-jerk reactions. Maybe this is just me being naive, but I think it’s more likely that Google would be receptive to well-thought-out, respectful criticism as opposed to a significant quantity of hostile accusations.
With that being said, I will concede that I overcorrected for the original post too much. I should have written a response covering the issue in a way that I found more ideal, rather than trying to balance out the bias from the original post. My goal was to point out the ragebait title and add missing information so readers could come to their own informed conclusions, not defend Google.
Would my government? Aladeen, 100%.
If that doesn’t make sense, it’s a reference to a movie.
Did you read until the end, or was it more important to accuse me of either being stupid or a corporate shill? I have nothing against you, and I don’t see how it’s constructive to be hostile towards me.
I said that the proposal itself does not aim to be DRM or adblock repellent, and cited the text directly from the document. It’s possible that something got lost in communication, but that wasn’t me trying to suggest that we should just blindly trust that this proposal has the users’ best interests at heart, or that motivations behind creating it could never, ever be disingenuous.
Hell, I even made sure to edit my post to clarify how the proposal—if implemented—could be used to prevent ad blockers. The paragraphs right after the one you quoted say:
To elaborate on the consequences of the proposal…
Could it be used to prevent ad blocking? Yes. There are two hypothetical ways this could hurt adblock extensions:
- As part of the browser “environment” data, the browser could opt to send details about whether built-in ad-block is enabled, any ad-block extensions are enabled, or even if there are any extensions installed at all.
Knowing this data and trusting it’s not fake, a website could choose to refuse to serve contents to browsers that have extensions or ad blocking software.
- This could lead to a walled-garden web. Browsers that don’t support the standard, or minority usage browsers could be prevented from accessing content.
Websites could then require that users visit from a browser that doesn’t support adblock extensions.
Given Google’s history, the assertion made by the title isn’t wrong. That doesn’t mean that it’s objective and informative, however.
The title suggests that the intent is to create DRM for web pages and “make ad blockers near-impossible”. From an informational standpoint, it correctly captures the likely consequences that would occur should the proposal be implemented. What it (nor the post body) does not do is provide an explanation, information, or context to explain why the proposal demonstrates the claim that is being made.
The reader is not informed about Google’s history of trying to subvert ad blockers, nor are they shown how the proposal will lead to DRMed web pages and adblock prevention. The post is a reaction-inducing title followed by a link to a proposal and angry comments on GitHub. That’s not informative; that’s ragebait.
Suppose I give the post the benefit of the doubt, and consider the bar for being “informative” to be simply letting people know about something. It’s still not objective. I’m not saying the OP should support Google or downplay the severity of the proposal, but they could have got the same point across without including their own prejudices:
“Google engineers propose new web standard that would enable websites to prevent access from browsers running adblockers or website-altering extentions.”
For the record: I agree with what this post is trying to say. I just disagree with how it’s said. Lemmy isn’t hemorrhaging ad money, and it isn’t overwhelmingly noisy. We don’t need to bring over toxic engagement tactics to generate views.
Oh, for sure. When bullet point number one involves advertising, they don’t make it hard to see that the underlying motivation is to assist advertising platforms somehow.
I think this is an extremely slippery and dangerous slope to go down, and I’ve commented as such and explained how this sort of thing could end up harming users directly as well as providing ways to shut out users with adblocking software.
But, that doesn’t change my opinion that the original post is framed in a sensationalized manner and comes across as ragebaiting and misinforming. The proposal doesn’t directly endorse or enable DRMing of web pages and their contents, and the post text does not explain how the conclusion of adblockers being killed follows from the premise of the proposal being implemented. To understand how OP came to that conclusion, I had to read the full document, read the feedback on the GitHub issues, and put myself in the shoes of someone trying to abuse it. Unfortunately, not everyone will take the time to do that.
As an open community, we need to do better than incite anger and lead others into jumping to conclusions. Teach and explain. Help readers understand what this is all about, and then show them how these changes would negatively impact them.
Having thought about it for a bit, it’s possible for this proposal to be abused by authoritarian governments.
Suppose a government—say, Wadiya—mandated that all websites allowed on the Wadiyan Internet must ensure that visitors are using a list of verified browsers. This list is provided by the Wadiyan government, and includes: Wadiya On-Line, Wadiya Explorer, and WadiyaScape Navigator. All three of those browsers are developed in cooperation with the Wadiyan government.
Each of those browsers also happen to send a list of visited URLs to a Wadiyan government agency, and routinely scan the hard drive for material deemed “anti-social.”
Because the attestations are cryptographically verified, citizens would not be able to fake the browser environment. They couldn’t just download Firefox and install an extension to pretend to be Wadiya Explorer; they would actually have to install the spyware browser to be able to browse websites available on the Wadiyan Internet.
In my other comments, I did say that I don’t trust this proposal either. I even edited the comment you’re replying to to explain how the proposal could be used in a way to hurt adblockers.
My issue is strictly with how the original post is framed. It’s using a sensationalized title, doesn’t attempt to describe the proposal, and doesn’t explain how the conclusion of “Google […] [wants] to introduce DRM for web pages” follows the premise (the linked proposal).
I wouldn’t be here commenting if the post had used a better title such as “Google proposing web standard for web browser verification: a slippery slope that may hurt adblockers and the open web,” summarized the proposal, and explained the potential consequences of it being implemented.
Frankly, I don’t trust that the end result won’t hurt users. This kind of thing, allowing browser environments to be sent to websites, is ripe for abuse and is a slippery slope to a walled garden of “approved” browsers and devices.
That being said, the post title is misleading, and that was my whole reason to comment. It frames the proposal as a direct and intentional attack on users ability to locally modify the web pages served to them. I wouldn’t have said anything if the post body made a reasonable attempt to objectively describe the proposal and explain why it would likely hurt users who install adblockers.
I don’t disagree with you. If this gets implemented, the end result is going to be a walled garden web that only accepts “trusted” browsers. That’s the concern here for ad blocking: every website demanding a popular browser that just so happens to not support extensions.
My issue is with how the OP framed the post. The title is misleading and suggests that this is a direct attempt to DRM the web, when it’s not. I wouldn’t have said anything if the post was less sensationalized, laying out the details of the proposal and its long-term consequences in an objective and informative way.
This post title is misleading.
They aren’t proposing a way for browsers to DRM page contents and prevent modifications from extensions. This proposal is for an API that allows for details of the browser environment to be shared and cryptographically verified. Think of it like how Android apps have a framework to check that a device is not rooted, except it will also tell you more details like what flavor of OS is being used.
Is it a pointless proposal that will hurt the open web more than it will help? Yes.
Could it be used to enforce DRM? Also, yes. A server could refuse to provide protected content to unverified browsers or browsers running under an environment they don’t trust (e.g. Linux).
Does it aim to destroy extensions and adblockers? No.
Straight from the page itself:
Non-goals:
…
- Enforce or interfere with browser functionality, including plugins and extensions.
Edit: To elaborate on the consequences of the proposal…
Could it be used to prevent ad blocking? Yes. There are two hypothetical ways this could hurt adblock extensions:
Knowing this data and trusting it’s not fake, a website could choose to refuse to serve contents to browsers that have extensions or ad blocking software.
Websites could then require that users visit from a browser that doesn’t support adblock extensions.
I’m not saying the proposal is harmless and should be implemented. It has consequences that will hurt both users and adblockers, but it shouldn’t be sensationalized to “Google wants to add DRM to web pages”.
Edit 2: Most of the recent feedback on the GitHub issues seems to be lacking in feedback on the proposal itself, but here’s some good ones that bring up excellent concerns:
The proposal does not do an adequate job explaining how a browser may be attested to.. Would this require something like Secure Boot in order for a browser to be attested to? That would discriminate against users with outdated hardware lacking support for boot integrity, or users who don’t have it enabled for some reason or another.
I suspect to get downvotes into oblivion for this, but there’s nothing wrong with the concept of C2PA.
It’s basically just Git commit signing, but for images. An organization (user) signs image data (a commit) with their public key, and other users can check that the image provenance (chain of signed commits) exists and the signing key is known to be owned by the organization (the signer’s public key is trusted). It does signing of images created using multiple assets (merge commits), too.
All of this is opt-in, and you need a private key. No private key, no signing. You can also strip the provenance by just copying the raw pixels and saving it as a new image (copying the worktree and deleting .git).
A scummy manufacturer could automatically generate keys on a per-user basis and sign the images to “track” the creator, but C2PA doesn’t make it any easier than just throwing a field in the EXIF or automatically uploading photos to some government-owned server.
From what I can tell, that’s basically what this is trying to do. Some company can sign a source image, then other companies can sign the changes made to the image. You can see that the image was created by so-and-so and then manipulated by so-and-other-so, and if you trust them both, you can trust the authenticity of the image.
It’s basically git commit signing for images, but with the exclusionary characteristics of certificate signing (for their proposed trust model, at least. It could be used more like PGP, too).
If that were the case, wouldn’t the mouse jump when the latest frame is presented? For me, it’s more that it just stays still until after Windows stops having a fuss.