This is an example of Google sabotaging a techology it doesn't like. I'm not saying it is a conspiracy. But by thwarting TOTP like this, Google is benefiting.
I really like TOTP. It gives me more flexibility to control keys on my end. And you can still use a Yubikey to secure your private TOTP key. But you can also choose to copy your private key to multiple hardware tokens without needing anyone's permission. Properly used, you can get most of the benefit of FIDO2 with a lot more flexibility.
I actually recently deployed TOTP, and everyone was quite happy with it. But knowing that Google is syncing private keys around by default, I no longer think we can trust it.
> You, as the administrator of a computer, can install whatever X.509 roots of trust you want. Including a root of trust you own, which can issue certificates for whatever websites you approve of.
That is a completely unreasonable assumption. The barriers of entry have been greatly increased.
How many users have devices that they are really administrators of? Fewer and fewer.
What is the technical challenge of setting up your own HTTP server that can be browsed with an off the shelf browser on your local computer?
> How many users have devices that they are really administrators of? Fewer and fewer.
As long as nobody has forced you to join your computer to a domain and accept the installation of group-policy overrides, you're still fundamentally an administrator of that machine.
You might not ever feel the need to administrate it, because the OS vendor is often co-administering the machine (see: Windows or macOS when you use a local account rooted in their cloud SSO) but the OS vendor hasn't restricted you from doing your own administration in the way that a corporation or institution administering the domain your device belongs to would restrict you. You still have the ambient authority to administer your machine, whether you ever bother to elevate yourself or not.
You can still install your own X.509 roots of trust. Even on, say, iOS! (You must administer the iOS device using tools — e.g. https://github.com/ProfileCreator/ProfileCreator — that run outside of the device on a "real computer"; but that's just a fact of history, to do with how system administrators generally prefer to interact with computers, not a property of the target device's security. A config profile is just a file format; if someone ever wanted to make a profile editor that ran on iOS itself, they could.)
(And if we're talking about a machine that is corporate or institutionally controlled? Well, then it's the responsibility of the people who manage your device — your IT department — to decide whether a given cert should be given trust. Like it always was under X.509.)
> What is the technical challenge of setting up your own HTTP server that can be browsed with an off the shelf browser on your local computer?
The approach where you run a proxy that wraps untrusted connections into trusted ones is fully general, but yes, only really applicable to the most advanced users. But then, only the most advanced users really need and/or should want the full power of this approach. Only someone with a lot of experience in network security should consider themselves capable of vouchsafing a non-TLS HTTP connection as worth being trusted. You have to basically come up with a [continuously falsifiable!] "attestation heuristic" for the remote yourself — that it stays on the same IP, that its DNS records haven't changed owner, that the server is still sending the same Server response header, etc.
(In fact, if the point is just to look at old websites that were never updated to use TLS, it's probably better to let someone else solve this specific problem for you, through a full application-layer compatibility forward-proxy service like https://theoldnet.com/ .)
If your needs are slightly weaker — if you can assume that every remote is at least using self-signed TLS certs rather than not using TLS at all — then the problem is vastly simplified: you can directly trust any cert by putting that cert directly into your X.509 trust store (in effect making it a root-of-trust — though it doesn't have the X.509 property that enables other certs signed by the cert to be trusted transitively, so it's a leaf-node root-of-trust. A "stump of trust", if you will.) You don't need to run any local servers to do this. And, at least in some cases (e.g. macOS Safari) it's just a few clicks to get from "this cert is invalid" over to "add this cert as a root-of-trust" (i.e. https://i.imgur.com/IXpF4ld.png).
The only problem with this approach, is that there will be no continuity of identity if the X.509 cert of the remote gets to the end of its lifetime and must be renewed. You must act in the capacity of the CA, figuring out again, from scratch, whether the new remote cert should be trusted.
If your goal is to get together with a bunch of your buddies to escape the "X.509 CA cabal" by doing your own cert signing, you'd therefore be better off not using self-signed certs, but rather creating your own CA (probably an automated one using ACME!); importing that CA cert onto all your devices as a root-of-trust; and then having that CA sign certs for all your group members' sites. Then you'll get all the advantages of regular X.509, just in a sort of "overlay world" where your group's browsers can trust both regular sites and your private-world sites, while regular people who aren't part of your group will see a certificate error when visiting your group's sites (unless they also decide to import your CA as a root-of-trust.)
(TBH, this would be kind of a cool "member's only club" to join. In theory, with sufficiently-advanced ACME probes, you could also enforce whatever properties of each site you liked, at least at time of issuance. You could create an "overlay web" that acts like Gopher/Gemini or whatever else you like, just by doing this.)
Looking at it in terms of leverage and market-share is a huge mistake that Mozilla keeps making. Mozilla doesn't have a platform like Google does. What exactly is Mozilla even competing for? Popularity?
They should hunker down and make the best browser they can, implementing their best web. It worked 20 years ago, and in many ways the circumstances are the same. We have tech monopolies proposing ludicrous "content security" mechanisms. Where would Mozilla have been if they tried making some sort of half baked "less evil" form of Microsoft Janus DRM[1]?
People are going to get sick of how intrusive DRM is becoming, and there should be an alternative waiting for them.
Every person who has content they thought they purchased "expire" and be erased from their device, or who can no longer use their expensive projector after the latest mandatory update.
I evangelized heavily for Firefox in the 1.x days. People were sick of IE6, and were glad to have Firefox. I worked at a computer store and probably converted 100+ people.
Mozilla and Wikimedia both have a reputation for wasting money by trying to branch out beyond their main product. Wikimedia is totally overfunded so wasting money doesn't threaten their survival but they've also been criticized for begging for donations that they don't need. Personally I don't see a reason to combine them.
Wikimedia is much much less shady than Mozilla in a bunch of ways. Some people might take issue with the way they spend their money, or the tactics they use to raise money, but I don't think I would consider them shady.
Full disclosure: I was employed as a software release engineer at the Wikimedia Foundation from 2015 through 2022.
DRM should be inconvenient and expensive. There have always been ways to implement DRM security theater for the comfort of content providers in board rooms.
The media ecosystem is not going to be enhanced by making DRM more restrictive. Netflix could completely deactivate all DRM today, and it would change nothing.
Apple completely abandoned their "FairPlay" iTunes music DRM because it became evident that it was not needed.
Apple in no way abandoned FairPlay. Every file on Apple Music, and iTunes Match is protected with it. And those greatly outnumber transactional sales through the iTunes store, by an order of magnitude. The customer picked the DRMed version, every time.
So what if Netflix doesn't work?? That is the choice of Netflix. Big content will always want more control. Firefox will never be able to keep up. They will just do a mediocre job of working against their users.
Microsoft and Real Player pushed hard for an integrated ActiveX based DRM ecosystem over a decade ago. I'm so glad that Mozilla flatly refused to entertain such idiocy. I sure wish that Mozilla still existed.
Mozilla is now just a "pick me" [1] organization to big content. They should own being a browser that caters to users, not platforms. Because they will end up with nothing.
Good. DRM should be external to the browser, not integrated into it.
DRM is mostly security theater anyway. Until a few years ago, the Spotify client just left unencrypted mp3s cached locally. And they stopped DRMing music over a decade ago. People are willing to pay a reasonable price for first party content.
If a company insist on DRM, then they should be on their own.
If we make it too easy, then they will just use it everywhere.
Yes, but that is fairly recent! Did anyone even notice? For years, you could siphon every song you listened to and save it locally. But did it affect anything? I did it for a little while, but then found it wasn't worth the trouble.
There's a really good example that someone found in the wild, where Google would omit exact string matches, but could then be coaxed into producing them indirectly.
It is disturbing because I thought this was a problem we had solved 20 years ago. If I could remember a few details about something that was indexed by Google, I used to be able to just find it.
I really like TOTP. It gives me more flexibility to control keys on my end. And you can still use a Yubikey to secure your private TOTP key. But you can also choose to copy your private key to multiple hardware tokens without needing anyone's permission. Properly used, you can get most of the benefit of FIDO2 with a lot more flexibility.
I actually recently deployed TOTP, and everyone was quite happy with it. But knowing that Google is syncing private keys around by default, I no longer think we can trust it.