That's a crypto architecture design choice, MS opted for the user-friendly key escrow option instead of the more secure strong local key - that requires a competent user setting a strong password and saving recovery codes, understanding the disastrous implication of a key loss etc.

Given the abilities of the median MS client, the better choice is not obvious at all, while "protecting from a nation-state adversary" was definitely not one of the goals.

The alternative is just not having FDE on by default, it really isn't "require utterly clueless non-technical users to go through complicated opt-in procedure for backups to avoid losing all their data when they forget their password".

And AFAICT, they do ask, even if the flow is clearly designed to get the user to back up their keys online.

Forcing implies there are zero ways to begin with a local only account (or other non-Microsoft Account). That's simply not true.

For something as widely adopted as Windows, the only sensible alternative is to not encrypt the disk by default.

The default behavior will never ever be to "encrypt the disk by a key and encrypt the key with the user's password." It just doesn't work in real life. You'll have thousands of users who lost access to their disks every week.

I thought this was what happened. Clearly not :( That’s the idea with services like 1Password (which I suppose is ultimately doing the same thing) - you need both the key held on the device and the password.

I suppose this all falls apart when the PC unlock password is your MS account password, the MS account can reset the local password. In Mac OS / Linux, you reset the login password, you loose the keychain.

At this point, end-to-end encryption is a solved problems when password managers exist. Not doing it means either Microsoft doesn't care enough, or is actually interested on keeping it this way

Assume good intent. If Microsoft didn't escrow the keys, the next HN post would be "mIcR0SofT Ate mY chILDhooD pHOTos!!"

I think legally the issue was adjudicated by analogy to a closed safe: while the exact contents of the safe is unknown beforehand, it is reasonable it will contain evidence, documents, money, weapons etc. that are relevant, so if a warrant can be issued in that case compelling a locksmith to open it, then by analogy it can be issued against an encrypted device.

Without doubt, this analogy surely breaks down as society changes to become more digital - what about a Google Glass type of device that records my entire life, or the glasses of all people detected around me? what about the device where I uploaded my conscience, can law enforcement simply probe around my mind and find direct evidence of my guilt? Any written constitution is just a snapshot of a social contract at a particular historical time and technological development point, so it cannot serve as the ultimate source of truth regarding individual rights - the contract is renegotiated constantly through political means.

My question was more general: how could we draft that new social contract to the current age, how could we maintain the balance where the encrypted device of a suspected child predator and murderer is left encrypted, despite the fact that some 3rd party has the key, because we agreed that is the correct way to balance freedoms and law enforcement? It just doesn't sound stable in a democracy, where the rules of that social contract can change, it would contradict the moral intuitions of the vast majority.

No, that’s binary thinking. The degree to which they will resist giving them away matters.

I’d much rather they require a warrant than just give it to any enforcement agency that sends them an email asking. The former is what I expect.

It’s really just A. Point B is pretty much just derived from there.

No, not "only". E2EE is now used as a dog whistle.

Who holds/controls the keys on both ends?

> Every bad day for microsoft is yet another glorious day for linux.

Nah. If that were the case, Linux would dominate personal computer statistics. The reality is that most mainstream users just don't care. But, of course, that won't stop us.

And MacOS, which I suspect may be the more obvious choice for many users.

One could almost say "Embrace the penguin"

You forgot to list Slackware :)

http://www.slackware.com/

http://slackware.osuosl.org/slackware64-current/ChangeLog.tx...

Please read this section of Apple's own document before you talk about their "advanced data protection".

The following information may be available from iCloud if a user has enabled Advanced Data Protection for iCloud:

https://www.apple.com/legal/privacy/law-enforcement-guidelin...

Do you think Tim Cook gave that gold bar to Trump for nothing?

Yeah, the problem is whether they already bent over for Trump admin or not yet.

The Apple that offers gold statues to authoritarian regimes would certainly behave differently.

People also forget how they kind of always played ball in similar governments.

This was a decade ago, before the big tech went to brown nose Trump on live TV. We live in different reality nowadays. Apple doesn't even market their encryption and safety anymore, like they did on massive billboards all over the world.

That's why full disk encryption was always a no-go for approximately all computer users, and recommending it to someone not highly versed in technology was borderline malicious.

"Tough luck, should have made a backup" is higher responsibility than securing anything in meatspace, including your passport or government ID. In the real world, there is always a recovery path. Security aficionados pushing non-recoverable traps on people are plain disconnected from reality.

Microsoft has the right approach here with Bitlocker defaults. It's not merely about UX - it's about not setting up traps and footguns that could easily cause harm to people.

Well, for a consumer notebook or mobile device, the threat model typically envisions a thief grabbing it from a coffeehouse or hotel room. So your key needs to be safeguarded from the opportunist who possesses your hardware illegally.

Linux can be fairly well-secured against state-level threat actors, but honestly, if your adversary is your own nation-state, then no amount of security is going to protect you!

For Microsoft and the other consumer-OS vendors, it is typically a bad user-experience for any user, particularly a paying subscriber, to lose access to their account and their cloud apps. There are many ways to try and cajole the naïve user into storing their recovery key somewhere safe, but the best way is to just do it for them.

A recovery key stored in the user's own cloud account is going to be secure from the typical threats that consumers will face. I, for one, am thankful that there is peace of mind both from the on-device encryption, as well as the straightforward disaster recovery methods.

That's a reductionist view. Apple, at least, based a big portion of their image on privacy and encryption. If a company does that and is then proven otherwise, it does a tremendous damage to the brand and stock value and is something shareholders would absolutely sue the board and CEO for. Things like these happened many times in the past.

This isn't that simple.

A Proton model makes this very simple: full cooperation and handover and virtually nothing to be extracted from the data. Size is somewhat of a metadata, ip connection points and maybe date of first use and when data changes occurred... I'm all for law enforcement, but that job has to be old-school Proof of Work bound and not using blanket data collection and automated speeding ticket mailer.

But I guess it's not done more because the free data can't be analyzed and sold.

It's most software. Cryptography is user-unfriendly. The mechanisms used to make it user friendly sacrifice security.

There's a saying that goes "not your keys not your crypto" but this really extends to everything. If you don't control the keys something else does behind the scenes. A six digit PIN you use to unlock your phone or messaging app doesn't have enough entropy to be secure, even to derive a key-encryption-key.

If you pass a KDF with a hardness of ~5 seconds a four digit PIN to derive a key, then you can brute force the whole 10,000 possible PINs in ~13 hours. After ~6.5 hours you would have a 50% chance of guessing correctly. Six digit PIN would take significantly longer, but most software uses a hardness nowhere near 5 seconds.

It isn't required.

The user can opt out of this if they want.