Request for Mozilla Position on an Emerging Web Specification Specification Title: Web Environment Integrity API Specification or proposal URL (if available): https://rupertbenwiser.github.io/Web-E...
Web dev here. 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.
That sounds a bit dry, but the implications are huge. It means:
ad blockers won’t work (the main reason for Google’s ploy)
many, if not most, other browser extensions won’t work (eg.: accessibility, theming, anti-malware)
people are going to start running into a lot of scam ads that ad blockers would otherwise prevent
malicious websites will be able to operate with impunity since you cannot run security extensions to prevent them
web developers are going to be crippled for lack of debugging ability
These are just a few things off the top of my head. There are endless and very dangerous implications to WEI. This is very, very bad for the web and antithesis of how it’s supposed to be.
TBL is probably experiencing a sudden disturbance in the force.
I think you’re missing the fact that if google doesn’t attest for your software choice, the website could prevent access. It is google trying to take ownership of what is and isn’t supported software when accessing the internet. This is far more serious that a few adverts, this could be the removal of liberty on the open web.
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.
Read between the lines, dude. Ad blockers work by observing and analyzing the DOM for elements presenting or containing ads and subsequently removing or obscuring those elements by manipulating the DOM. There’s no way for WEI to carry out its purported goals without forcibly preventing DOM manipulation.
There are absolutely no possible benefits for users. None.
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.
I didn’t read through the entire spec, but I read enough to sniff out their Trojan horseshit. I’m not regurgitating anything, I’m calling it as I see it.
This is of benefit to no one but for corporate overlords to do more overlording. It’s fixing a problem that doesn’t exist.
I don’t know why you’re trying to hard to defend one the biggest corporations on earth that decidedly not-not-evil, but if I ever need a top notch recipe for robust leather footwear, I’ll be sure to call you up.
So your suggestion is hopefully later, google will allow extensions even though their proposals are against it. This is the company that rolled out web manifest v3, a proposal to limit and remove extensions. Their past actions have demonstrated motives opposite to what you are implying could happen. It’s entirely wishful thinking.
Google may want to place themselves judge and jury of what software is allowed on a computer, but anyone of sane mind should not be considering allowing them.
HTTPS already prevents man in the middle attacks and changes to the website content to protect users. This is to protect companies from users. It’s horrific and an attack on the web freedoms that have so long been held.
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.
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 way1, 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.
Web dev here. 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.
That sounds a bit dry, but the implications are huge. It means:
These are just a few things off the top of my head. There are endless and very dangerous implications to WEI. This is very, very bad for the web and antithesis of how it’s supposed to be.
TBL is probably experiencing a sudden disturbance in the force.
I think you’re missing the fact that if google doesn’t attest for your software choice, the website could prevent access. It is google trying to take ownership of what is and isn’t supported software when accessing the internet. This is far more serious that a few adverts, this could be the removal of liberty on the open web.
That’s the “endless and very dangerous” part.
I appreciate that, I just thought it’s worth spelling out so people really get the gravity of this situation.
Any idea on what happens to DNS level blockers?
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:
Read between the lines, dude. Ad blockers work by observing and analyzing the DOM for elements presenting or containing ads and subsequently removing or obscuring those elements by manipulating the DOM. There’s no way for WEI to carry out its purported goals without forcibly preventing DOM manipulation.
There are absolutely no possible benefits for users. None.
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.
I didn’t read through the entire spec, but I read enough to sniff out their Trojan horseshit. I’m not regurgitating anything, I’m calling it as I see it.
This is of benefit to no one but for corporate overlords to do more overlording. It’s fixing a problem that doesn’t exist.
I don’t know why you’re trying to hard to defend one the biggest corporations on earth that decidedly not-not-evil, but if I ever need a top notch recipe for robust leather footwear, I’ll be sure to call you up.
So your suggestion is hopefully later, google will allow extensions even though their proposals are against it. This is the company that rolled out web manifest v3, a proposal to limit and remove extensions. Their past actions have demonstrated motives opposite to what you are implying could happen. It’s entirely wishful thinking.
Google may want to place themselves judge and jury of what software is allowed on a computer, but anyone of sane mind should not be considering allowing them.
HTTPS already prevents man in the middle attacks and changes to the website content to protect users. This is to protect companies from users. It’s horrific and an attack on the web freedoms that have so long been held.
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.
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 way1, 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.