Actually it was a pyrrhic victory, as Microsoft went on to apply their ideas to XBox, Azure Sphere, and now the change is coming back as future Windows hardware requirements for secure workstations via Pluton integration.
https://www.microsoft.com/en-us/security/blog/2020/11/17/mee...
I bet mostly UNIX focused folks haven't noticed that their next PC might have a Pluton CPU on them.
https://www.thurrott.com/hardware/260917/here-come-the-first...
https://www.microsoft.com/en-us/security/blog/2022/01/21/cel...
Citation needed. I'm pretty sure all Chromebooks have a TPM and it's a firm requirement for making one. ChromeOS uses the TPM extensively and fully supports remote attestation:
https://www.chromium.org/developers/design-documents/tpm-usa...
TPMs have been a requirement on PCs since at least 2016 I think, and in reality most came with them before that too (but there's a v1 vs v2 difference).
> a 1.X version of the TPM. In theory it performs just as well as TPM 2.X but they will not be supported because, again, I will not be able to use my own keys.
This is all wrong. TPM 1.2 uses SHA1 for everything which is a broken hash function so there is a major difference in robustness between them. That's why TPM 1.2 is being phased out. It has nothing to do with "using your own keys" which is out of the domain of what TPMs do anyway, TPMs are always owned by the device user. You're thinking of firmware boot signing and other things that are separate to the TPM chip but even there, you can use your own signing keys.
It's not focused on censorship resistance but instead decentralisation.
https://www.gnu.org/philosophy/right-to-read.html
He wrote that 26 years ago. It's worth reading again just to see how much he got right.
All these elites always want to know what we plebs are running. The governments want Venmo to report anything that adds up to over $600 a year to the IRS. FATCA travel rule pushes all countries to do the same, for $1K but FINCEN has lobbied for as low as $250!
Meanwhile the Pentagon can’t account for trillions, and both parties give them more money than they even ask for. We have government officials in constant secret meetings, failing to avert disasters, then the plebs have to fight.
I say — we should have attestation that the server is running verified code, the one that was audited by third parties that I accept! That would be what I always wanted on the Web. Instead, they only do it the other way.
We the People have to rise up and demand that Google implements a standard that uses SGX extensions or whatever, to guarantee that the code managing the website matches the audited code. This is long overdue! It is also why we use smart contracts and Web3 for now.
All I really want, on the mobile Web, is a way to visit a URL that has a content hash, and it will load a static file matching a content hash, and save it so it’s always available locally. That’s it! So I can trust the code. Without having to install an extension. Instead Apple clears everything after 7 days, making it useless! And SRI only works for subresources. Which means the server can be hacked and serve malicious code to me anytime!
https://arstechnica.com/information-technology/2022/08/archi...
https://www.notebooksbilliger.de/acer+swift+1+sf114+34+p91a+...
They have physical stores.
https://www.politifact.com/factchecks/2012/jul/11/eric-holde...
https://www.aclu.org/documents/oppose-voter-id-legislation-f...
https://www.usccr.gov/files/pubs/2018/Minority_Voting_Access...
https://www.washingtonpost.com/politics/courts_law/getting-a...
https://www.vox.com/xpress/2014/11/4/7157037/us-voter-id-req...
https://www.npr.org/2018/09/07/644648955/for-older-voters-ge...
https://rewirenewsgroup.com/2014/10/16/well-actually-pretty-...
https://www.theregreview.org/2019/01/08/shapiro-moran-burden...
https://www.theatlantic.com/politics/archive/2014/10/heres-h...
https://scholars.org/contribution/high-cost-free-photo-voter...
https://now.tufts.edu/2018/01/23/proving-voter-id-laws-discr...
TLDR holdbacks might help with specifically the DRM component; but they can only go one of three ways:
- They can be effective at forcing sites not to rely on attestation, in which case there is no benefit to this proposal because everyone (including users of browsers like Chrome) will still be subjected to the same invasive backup strategies. You'll still be fingerprinted and tracked no matter what because even if you're using Chrome 1/20 times you send a request the website will just revert back to the original fingerprinting.
- Or if they aren't effective at forcing sites not to rely on attestation, well... then they haven't solved the DRM problem.
- Finally, attestation might be used to primarily decrease annoying behaviors, which will still in practice make browsing the web for anyone who doesn't use a browser with attestation so painful that they'll eventually switch. Think "you're not on Chrome, so you're going to see 9x the captchas you otherwise would see."
You can't simultaneously have "this allows us to trust the client" and "we can't rely on it." One of them has to give. At their best holdbacks would turn this into another tracking vector and would change nothing about the web for the better. More likely, holdbacks will allow sites that would previously be judicious about where they used captchas and blocks around the site to start spamming them everywhere -- because Chrome users will only see 5-10% of those annoyances. And at their worst, sites would just not implement the fallbacks because the attestation signal is still reliable enough.
Holdbacks call the entire motivation of this spec into question, since the whole point of holdbacks is to make it impossible for websites to get rid of the invasive "backup" walls and tracking and captchas that the spec claims to be trying to replace. Blocking ad fraud? Blocking automated requests? WEI only helps with that if websites can trust the signal and block browsers that aren't sending it; otherwise websites are right back to square one trying to prevent fraud. But if they can do better blocking based on that signal, then we're back in DRM territory.
----
Another point raised by another commenter: >>36884649
Implementing holdbacks in a way that actually prevents DRM is likely to be fairly challenging. In the most straightforward implementation, websites can simply retry the request until they get an attesation token or until they hit 10 iterations, at which point they'll ban you as normal.
Statistically profiling users and determining whether or not their browser supports attestation is likely to be fairly easy, unless Google has a much cleverer implementation of holdbacks than they've revealed so far in the spec.
This would be the worst case scenario -- holdbacks would be used as an excuse to push the changes through and sites would simply ignore them and block users based on aggregate stats: you haven't passed an attestation check in the past 30 minutes even though you made 20 different requests that should have had a token attached? Yeah, you're pretty likely on an "unsupported" browser.