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!
But the real questions is, can we change them?
Imagine this:
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 can* explore a more conventional Linux graphical environment if they’re comfortable trying that.
It’s possible that Google doesn’t, although that would be weird since the ability to push apps is probably standardized and baked into the stock Android OS source code.
Or maybe you just used MVNOs that don’t purposefully install anything that isn’t strictly necessary.
Android OS developers or software devs working for cell providers would probably know the answer, though.
Anecdotally, I can confirm otherwise. I bought an unlocked Galaxy phone directly from Samsung, and putting in a SIM card provisioned it for my cell provider and installed their apps.
Thankfully, I’m not on a provider that pushes adware.
Oh cool, there’s a 200mp camera. Something that only pro photographers care about lol.
Oh this is a fun one! Trained, professional photographers generally don’t care either, since more megapixels aren’t guaranteed to make better photos.
Consider two sensors that take up the same physical space and capture light with the same efficiency/ability, but are 10 vs 40 megapixels. (Note: Realistically, a higher density would mean design trade-offs and more generous manufacturing tolerances.)
From a physics perspective, the higher megapixel sensor will collect the same amount of light spread over a more dense area. This means that the resolution of the captured light will be higher, but each single pixel will get less overall light.
So imagine we have 40 photons of light:
More Pixels Less Pixels
----------- -----------
1 2 1 5
2 6 2 3 11 11
1 9 0 1 15 3
4 1 1 1
When you zoom in to the individual pixels, the higher-resolution sensor will appear more noisy. This can be mitigated by pixel binning, which groups (or “bins”) those physical pixels into larger, virtual ones—essentially mimicking the lower-resolution sensor. Software can get crafty and try to use some more tricks to de-noise it without ruining the sharpness, though. Or if you could sit completely still for a few seconds, you could significantly lower the ISO and get a better average for each pixel.
Strictly from a physics perspective (and assuming the sensors are the same overall quality), higher megapixel sensors are better simply because you can capture more detail and end up with similar quality when you scale the picture down to whatever you’re comparing it against. More detail never hurts.
… Except when it does. Unless you save your photos as RAW (which take a massice amount of space), they’re going to be compressed into a lossy image format like JPEG. And the lovely thing about JPEG, is that it takes advantage of human vision to strip away visual information that we generally wouldn’t perceive, like slight color changes and high frequency details (like noise!)
And you can probably see where this is going: the way that the photo is encoded and stored destroys data that would have otherwise ensured you could eventually create a comparable (or better) photo. Luckily, though, the image is pre-processed by the camera software before encoding it as a JPEG, applying some of those quality-improving tricks before the data is lost. That leaves you at the mercy of the manufacturer’s software, however.
In summary: more megapixels is better in theory. In practice, bad software and image compression negate the advantages that a higher resolution provides, and higher-density sensors likely mean lower-quality data. Also, don’t expect more megapixels to mean better zoom. You would need an actual lense for that.
It’s a “feature,” in fact…
Under What to expect on this support page, it says:
The phone branding, network configuration, carrier features, and system apps will be different based on the SIM card you insert or the carrier linked to the eSIM.
The new carrier’s settings menus will be applied.
The previous carrier’s apps will be disabled.
The correct approach from a UX perspective would have been to display an out-of-box experience wizard that gives the user an option to either use the recommended defaults, or customize what gets installed.
Unfortunately, many manufacturers don’t do that, and just install the apps unconditionally and with system-level permissions. And even if they did, it’s likely that many of the carrier apps will either have a manifest value that requires them to be installed, be unlabeled (e.g. com.example.carrier.msm.mdm.MDM), or misleadingly named to appear essential (e.g. “Mobile Services Manager”).
I bought an unlocked phone directly from the manufacturer and still didn’t get the choice.
Inserting a SIM card wiped the phone and provisioned it, installing all sorts of carrier-provided apps with system-level permissions.
As far as I’ve found, there’s a few possible solutions:
Unlock the bootloader and install a custom ROM that doesn’t automatically install carrier-provided apps. (Warning: This will blow the E-fuse on Samsung devices, disabling biometrics and other features provided by their proprietary HSM).
Manually disable the apps after they’re forcibly installed for you. Install adb on a computer and use pm disable-user --user 0 the.app.package on every app you don’t want. If your OEM ROM is particularly scummy, it might go out of its way to periodically re-enable some of them, though.
Find a SIM card for a carrier that doesn’t install any apps, then insert that into a fresh phone and hope that the phone doesn’t adopt the new carrier’s apps (or wipe the phone) when you insert your actual SIM.
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.
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.