zlacker

>>jakobd+(OP)
The Chrome team have used "the Open Web" as a euphemism for what is to all intents and purposes Google's great ad supported walled garden. That so few people see this for what it is is amazing, and then they get all surprised when Google act to preserve it and close the capability gap with native platforms.

>>fidotr+G8
When Microsoft did this with IE, they did it with proprietary and undocumented APIs. The fact that this is an open spec, discussed in an open forum, using well established and standard technologies is what ensures it can never be positioned against users in any meaningful way.

To me it looks like SGX for the web. Maybe it will introduce some neat and weird capabilities, but at the end of the day, it will be trivial to bypass at scale if it ever positions itself as being harmful to users.

>>px43+ts
Can you explain how you'd bypass it?

Let's say example.com decides to require attestation from the {MS, Apple, Google} providers, and that they attest to only Chrome without extensions. You can't forge the attestation because cryptography. You can't fail to provide it (because they'll just refuse to send the bits). You can't use a "malicious" attestor because example.com won't trust it.

What's the trivial bypass I'm missing? How does a freely accessible standard impact the ability to bypass things in any way?

>>AlotOf+cJ
TPMs can be emulated. Also basically every hardware platform can be placed into a hardware debug mode that allows live debugging of the underlying operating system. Keys can also be extracted from hardware. If even one supported platform leaks a key (and in this doomer fantasy world all platforms must be supported right?) then the attestations can be bypassed. It only needs to be bypassed once to be bypassed everywhere, basically forever.

>>px43+XG5
Key revocation is a thing and no, not all platforms must be supported (or are intended to be supported). Here's the relevant Google blog post:

https://android-developers.googleblog.com/2019/09/trust-but-...