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.

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.

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

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

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 :)

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

I glossed through some of the specifications, and it appears to be voluntary. In a way, it’s similar to signing git commits: you create an image and chose to give provenance to (sign) it. If someone else edits the image, they can choose to keep the record going by signing the change with their identity. Different images can also be combined, and that would be noted down and signed as well.

So, suppose I see some image that claims to be an advertisement for “the world’s cheapest car”, a literal rectangle of sheet metal and wooden wheels. I could then inspect the image to try and figure out if that’s a legitimate product by BestCars Ltd, or if someone was trolling/memeing. It turns out that the image was signed by LegitimateAdCompany, Inc and combined signed assets from BestCars, Ltd and StockPhotos, LLC. Seeing that all of those are legitimate businesses, the chain of provenance isn’t broken, and BestCars being known to work with LegitimateAdCompany, I can be fairly confident that it’s not a meme photo.

Now, with that being said…

It doesn’t preclude scummy camera or phone manufacturers from generating identities unique their customers and/or hardware and signing photos without the user’s consent. Thankfully, at least, it seems like you can just strip away all the provenance data by copy-pasting the raw pixel data into a new image using a program that doesn’t support it (Paint?).

All bets are off if you publish or upload the photo first, though—a perceptual hash lookup could just link the image back to original one that does contain provenance data.

Had to give up at rule 20 because I was using a phone.

Would love to see a speedrun leaderboard for this, though.

“Impede the replacement of” and “compatible battery” has a lot of room for interpretation. I hope they’re defined explicitly somewhere, or else we’re going to find implementations that effectively restrict non-OEM batteries while still adhering to the letter of the law.

For example, all batteries lacking a cryptographically-verified “certification” handshake could have safety restrictions such as:

• Limited maximum amperage draw, achieved by under-clocking the SoC and sleeping performance cores.

• Lower thermal limits while charging the device, meaning fast charging may be limited or preemptively disabled to ensure that the battery does not exceed an upper threshold of you-might-want-to-put-it-in-the-fridge degrees.

• Disabling wireless charging capabilities, just in case magnetic induction affects the uncertified battery full of unknown and officially-untested components.

• A pop-up warning the user every time the device is plugged into or unplugged from a charger.

All of that would technically meet the condition insofar that it’s neither impeding the physical replacement nor rendering the device inoperable, but it would still effectively make the phone useless unless you pay for a (possibly-overpriced) OEM part.

If they explicitly defined “Impede the replacement of” as “prevent replacement of or significantly alter user experience as a result of replacing,” and “compatible battery” as “electrically-compatible battery” all those cases would be covered.

Might be a bit of cynical take, but I don’t have too much faith in the spirit of the law being adhered to when profits are part of the equation.