Thanks, I was familiar with encryption but not with bitlocker.
So this only affects a particular mode of bitlocker in which the drive is automatically decrypted on boot without the user providing any secret. Meaning the key is basically stored in plaintext on-device, albeit in a convoluted way.
To me it seems intuitive that such a mode isn't secure. It's a bit like protecting your door with an unpickable unbreakable lock, but then putting the key in a lockbox on the wall with a flimsy padlock that can be raked or cut off in seconds.
It seems roughly equivalent to not encrypting the drive at all so it doesn't seem surprising that there's a way to bypass it.
I gave three ways in which encrypting a disk using a TPM provides advantages over encrypting the disk using a secret password.
Encrypting the disk using a secret password provides advantages over encrypting the disk using a public password.
Encrypting the disk using a public password again provides advantages over not encrypting the disk (such as being able to securely "delete" data by removing the data encryption key).
I agree with your core point that attempting to use measured boot and secure boot to control whether the disk can be decrypted is full of holes. But if you want the computer to have an encrypted drive and to be able to boot up without a network or human intervention, what are your options really?
The point is that the lockbox is the TPM that, on paper, is supposed to be unbreakable. In practice, sometimes it can still be broken with physical attacks (like side channel analysis or fault injection, or even simply snooping the communication between the TPM and the rest of the system with a logic level analyzer), despite that it should be designed to be hard to break even with such attacks.
If the TPM is properly designed and manufactured, and the software relying on it is again properly designed and implemented, then it would be perfectly secure. The problem is more the difference between the theory and the real world; the flimsy lockbox analogy doesn't hold.
If I was releasing a laptop with Linux support as a key selling point, and the battery life was bad on Ubuntu 24.04 but good on the pre-release 26.04, then I'd advertise the good figures and write "tested on Ubuntu 26.04 beta, requires Linux 7.0 or later" in the footnotes.
I definitely /wouldn't/ rely on just Windows figures for a machine that's otherwise advertised as "Linux first". If the battery life was the same on both, I'd prominently mention that.
I'm a long-time Linux user who might actually be in the market for a just-works upgradeable laptop[1] that comes with Ubuntu.
I already know that combinations of hardware and software can be stretched and tweaked to do really interesting things in really excellent ways. I don't need them to tell me that computer systems are flexible. That's just noise.
And I don't want them to tell me how their (unreleased) hardware might work in the future with some unreleased/beta software. That tends to be interpreted as speculation, or as lies and deceit.
I'd prefer to see benchmarks of how it works if it shipped today.
If those benchmarks are unsavory (as they may presently be) and thus omitted, then that's not ideal but it's okay.
I definitely don't want to feel as if I'm being lied to, in place of an omission.
[1]: I just want a 15" version. I'm not a fan of little screens. My eyes aren't getting any better.
Low bandwidth is a bigger problem than high latency. If it takes half a second or even a second for your clicks to register it's not a big deal, you learn to work around it. But if the bandwidth is so low that it takes 5-10 seconds just to write the screen it really sucks.
I don’t know if this craft has it, but they’ve been announcing all over that we’ll get 4K over a 260mbps link from the moon, so that shouldn’t be a problem
Yup. 57kbps transatlantic modem connection to a remote desktop in some country with poor telephone connectivity was probably even worse. Never want to have to do that again!
Can’t believe HN has become so afraid of generic probably-unenforceable “plz don’t reverse engineer” EULAs. We deserve to know what these tools are doing.
I’ve seen poor results from plan mode recently too and this explains a lot.
Doesn't stop them going to your employer and that hint of you doing something iffy is enough to claim you're bringing the company into disrepute by drawing unwanted attention.
The other advantage of fibre is subtlety if you can't (or don't want to) run it through walls. 0.9mm diameter and light enough to attach it with occasional dots of glue instead of needing cable clips.
I can second this 0.9mm transparent stuff, I've run it successfully and it's very subtle.
Depending on the media converter pair you're using, you probably want UPC instead of APC. I also found that the cheapest generic bidi media converters tend to be SC, so I want with a 30m pre-terminated SC/UPC cable. Total cost (cable plus media converters) was about £30.
Anecdotally, everything works flawlessly on my work machine: Optiplex Micro, Intel iGPU, Fedora KDE 43, 4K 32" primary monitor at 125% scale, 1440p 27" secondary monitor at 100%. No issues with Wayland or with anything else.
Everything actually feels significantly more solid/stable/reliable than modern Windows does. I can install updates at my own pace and without worrying that they'll add an advert for Candy Crush to my start menu.
I also run Bazzite-deck on an old AMD APU minipc as a light gaming HTPC. Again, it's a much better experience than my past attempts to run Windows on an HTPC.
As with everything, the people having issues will naturally be heard louder than the people who just use it daily without issues.
So this only affects a particular mode of bitlocker in which the drive is automatically decrypted on boot without the user providing any secret. Meaning the key is basically stored in plaintext on-device, albeit in a convoluted way.
To me it seems intuitive that such a mode isn't secure. It's a bit like protecting your door with an unpickable unbreakable lock, but then putting the key in a lockbox on the wall with a flimsy padlock that can be raked or cut off in seconds.
It seems roughly equivalent to not encrypting the drive at all so it doesn't seem surprising that there's a way to bypass it.