typhoon

That is a good point. For privacy reason I don’t recommend anyone to share where they are located but yeah that is something to factor.

Ok, that is what I’m saying.

Same here, I’m surprised that some that ordered at the same day that I did are already with their devices. Have you ordered yours on May 8th as well?

Click on Linux: https://help.netflix.com/en/node/30081

You can check this in other sources as well: https://www.howtogeek.com/why-netflix-caps-chrome-at-1080p-without-telling-you/

https://en.wikipedia.org/wiki/Widevine

I doubt, one of the reasons they kept this on a leash was the incredible amount of third party markets devices that flooded the market pushing malware and trackers. I don’t foresee in a near future the Stream providers flexing more the rules. They will probably keep that close to the small amount of licensed companies and TV manufactures.

Unless there is a workaround that I’m not aware this would only limit to stream 720p in most browsers and 1080p in some browsers. We can’t stream for example Netflix at 4k with this method that you described without a license for the device.

I wish they would have licensed it to use with Stream providers. That would replace Nvidia Shield and/or Apple TV devices in a few homes.

Just to try to understand how bad this is, I reserved mine on May 8 at 18:48:30 +0000 (UTC) no email so far.

Did someone that reserved received an email? If yes, when did you reserve and when did you receive the email to order your controller?

TPM auto-unlock still relies on measured boot integrity (Secure Boot/PCRs), so it protects against offline theft and tampering when the machine is off or storage is removed.

But if an attacker has repeated physical access during boot, the protection depends on whether you’ve added extra factors like a TPM PIN or pre-boot passphrase. Login prompts don’t re-protect the disk once it’s decrypted.

In practice, for my use case (mostly shutdown or battery-dead scenarios), this is an acceptable trade-off for convenience. If your threat model includes targeted physical access during boot, then keeping a pre-boot secret is still the safer choice.

LUKS isn’t the alternative here, it’s the baseline. The question is how to unlock LUKS without manual passphrase entry at boot.

Using TPM2 + Secure Boot (e.g. via systemd-cryptenroll) binds the LUKS key to platform integrity, so it auto-unlocks when the system hasn’t been tampered with. You still keep a recovery passphrase, so you’re not locked out if hardware changes or fails.

TPM2 + Secure Boot via systemd-cryptenroll is the closest to the “just works” FileVault/Android experience. Keep a recovery passphrase in your password manager. You don’t lose your data if the motherboard dies, you just use the recovery key.

I use this on my daily drive laptop. Only real hiccup is that I still keep the dual boot because fwupd does not cover my laptop BIOS firmware updates but in a Linux tablet this a no issue.