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 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.
With regard to my examples, WEI provides full confidence and stability in identifying the browser.
Relying on detecting browsers by differentiating between their features and quirks involves on having a large suite of checks to run, some of which might become incorrect as browsers change over time. It’s a maintenance burden, to say the least.
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?
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.
And here’s a concern about the decentralized-but-still-centralized nature of attesters:
From my understanding, attesting is conceptually similar to how the SSL/TLS infrastructure currently works:
Each ultimately-trusted attester has their own key pair (e.g. root certificate) for signing.
Some non-profit group or corporation collects all the public keys of these attesters and bundles them together.
The requesting party (web browser for TLS, web server for WEI) checks the signature sent by the other party against public keys in the requesting party’s bundle. If it matches one of them, the other party is trusted. If it doesn’t, they are not not trusted.
This works for TLS because we have a ton of root certificates, intermediate certificates, and signing authorities. If CA Foo is prejudice against you or your domain name, you can always go to another of the hundreds of CAs.
For WEI, there isn’t such an infrastructure in place. It’s likely that we’ll have these attesters to start with:
But hey, maybe we’ll have some intermediate attesters as well:
Even with that list, though, it doesn’t bode well for FOSS software. Who’s going to attest to various browser forks, or for browsers running on different operating systems that aren’t backed by corporations?
Furthermore, if this is meant to verify the integrity of browser environments, what is that going to mean for devices that don’t support Secure Boot? Will they be considered unverified because the OS can’t ensure it wasn’t tampered with by the bootloader?
Adding another issue to the pile:
Even if it isn’t the intent of the spec, it’s dangerous to allow for websites to differentiate between unverified browsers, browsers attested to by party A, and browser attested to by party B. Providing a mechanism for cryptographic verification opens the door for specific browsers to be enforced for websites.
For a corporate example:
Suppose we have ExampleTechFirm, a huge investor in a private AI company, ShutAI. ExampleTechFirm happens to also make a web browser, Sledge. ExampleTechFirm could exert influence on ShutAI so that ShutAI adds rate limiting to all browsers that aren’t verified with ShutAI as the attester. Now, anyone who isn’t using Sledge is being given a degraded experience. Because attesting uses cryptographic signatures, you can’t bypass this user-hostile quality of service mechanism; you have to install Sledge.
For a political example:
Consider that I’m General Aladeen, the leader of the country Wadiya. I want to spy on my citizens and know what all of them are doing on their computers. I don’t want to start a revolt by making it illegal to own a computer without my spyware EyeOfAladeen, nor do I have the resources to do that.
Instead, I enact a law that makes it illegal for companies to operate in Wadiya unless their web services refuse access to Wadiyan citizens that aren’t using a browser attested to by the “free, non-profit” Wadiyan Web Agency. Next, I have my scientists create and release a renamed versions of Chromium and Firefox with EyeOfAladeen bundled in them. Those are the only two browsers that are attested by the Wadiyan Web Agency.
Now, all my citizens are being encouraged to unknowingly install spyware. Goal achieved!
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.
But the real questions is, can we change them?
Imagine this:
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.
Back when I was in school, we had typing classes. I’m not sure if that’s because I’m younger than you and they assumed we has basic computer literacy, or older than you and they assumed we couldn’t type at all. In either case, we used Macs.
It wasn’t until university that we even had an option to use Linux on school computers, and that’s only because they have a big CS program. They’re also heavily locked-down Ubuntu instances that re-image the drive on boot, so it’s not like we could tinker much or learn how to install anything.
Unfortunately—at least in North America—you really have to go out of your way to learn how to do things in Linux. That’s just something most people don’t have the time for, and there’s not much incentive driving people to switch.
A small side note: I’m pretty thankful for Valve and the Steam Deck. I feel like it’s been doing a pretty good job teaching people how to approach Linux.
By going for a polished console-like experience with game mode by default, people are shown that Linux isn’t a big, scary mish-mash of terminal windows and obscure FOSS programs without a consistent design language. And by also making it possible to enter a desktop environment and plug in a keyboard and mouse, people cam explore a more conventional Linux graphical environment if they’re comfortable trying that.
Had to give up at rule 20 because I was using a phone.
As much fun pain as that was, highlighting with a touch screen is nowhere near fast enough to put out the fire.
Would love to see a speedrun leaderboard for this, though.
Would absolutely love for Serif Labs to create a port for Affinity Photo and Designer. Of the programs I’ve tried, those two have the closest UX to Photoshop and Illustrator without the software-as-a-service model.
Hell, I’d even take it if all they did was support it working under WINE. While I would prefer a seamless UI that fits in with both GTK and Qt, it’s understandable that they might not consider it worth the effort.
“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.
You say that like it hasn’t been happening already for two decades.
https://www.cnet.com/news/privacy/fbi-taps-cell-phone-mic-as-eavesdropping-tool/
I can’t read French so I only have others’ translations and intepretations to rely on, but from what I understand, the differences here are that,
France lawmakers are being direct with their legislation, rather than relying on precedence or judges’ interpretations of anti-terrorism or national security bills; and
Privileged conversations (e.g. between client and attorney) can still be admissible when recorded surreptitiously this way.
Apparently it would still need to be pre-approved by a judge. That doesn’t inspire much confidence in it not being hand-wave allowed, though.
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.