Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An experimental Android WebView Media Integrity API early next year

android-developers.googleblog.com

Post reply on HN
Print view View original

91–100 of 247 posts

Re: An experimental Android WebView Media Integrity API early next year

#91

Post by cryptonector »

userbinator wrote: post #55
jorvi wrote: post #26

Earlier quoted context omitted.

Uhm… what? Your beef is with things like Pluton, Intel’s ME and AMD’s PSP. TPM at their base are nothing else than a more secure place to store cryptographic data.

TPM at their base are nothing else than a more secure place to store cryptographic data. One which you, as the owner, don't have the keys to.

What do you mean specifically?

You can:

  - set passwords on the key hierarchies
  - roll the seeds for the key hierarchies,
    thus invalidating *all* keys on the TPM
Now, Windows might stop working if you do that, and naturally, if you wanted to use a TPM for locking your filesystems then you'll need to do this _before_ you install your OS.

Also, once you change the seed for the Endorsement Key hierarchy you'll lose the ability to prove that the TPM is a legit TPM made by whatever legit TPM vendor.

So sure, this is only something you do if you know what you're doing, especially if the TPM is soldered onto the motherboard.

Re: An experimental Android WebView Media Integrity API early next year

#92

Post by [deleted] »

freedomben wrote: post #15

TFA is about more than just WEI, but it does address it directly: > We’ve heard your feedback, and the Web Environment Integrity proposal is no longer being considered by the Chrome team. In contrast, the Android WebView Media Integrity API is narrowly scoped, and only targets WebViews embedded in apps. It simply extends existing functionality on Android devices that have Google Mobile Services (GMS) and there are no…

[deleted]

Re: An experimental Android WebView Media Integrity API early next year

#93

Post by [deleted] »

wkat4242 wrote: post #90

Wow that surprises me. A lot. I'm sure they will cook up something else evil though. FLoC just came back under a different name. It is so surprising to me that the one company that had "don't be evil" in their motto has become the one most antagonous company to society (or at least in a digital services manner, I'm sure Palantir and Monsanto can take that crown in their own areas).

[deleted]

Re: An experimental Android WebView Media Integrity API early next year

#94

Post by cryptonector »

vlovich123 wrote: post #76
userbinator wrote: post #55

Earlier quoted context omitted.

TPM at their base are nothing else than a more secure place to store cryptographic data. One which you, as the owner, don't have the keys to.

If you use a mobile device maybe. My desktop machine has a TPM and AFAIK I do have access to load my own keys / replace the root keys. Of course, nothing says there isn't a backdoor within the TPM, but it's not this secret locked down thing.

It's unlikely that there is a backdoor on the TPM itself. The more likely scenario is that given a TPM serial number or EKpub the vendor could furnish a seed in response to a subpoena or warrant -- however, even this is unlikely, as it would make TPM vendors huge targets for hacking. Also TPM vendors make a big deal of how they don't keep TPMs' seeds, and I tend to believe them, because again if they did keep them then they'd be huge targets.

Re: An experimental Android WebView Media Integrity API early next year

#95

Post by amalcon »

londons_explore wrote: post #31

> Android WebView Media Integrity API is narrowly scoped I don't see any benefit to the user... Surely any app which wishes to embed a webview can simply add an api to said webview with native code to use existing android integrity API's? To me, this looks like a backdoor way to prevent people making "hacked" apps which, for example, play youtube but without ads. This API doesn't benefit the users.

It seems pretty straightforward to prevent that anyway, through Play Integrity attestation. This just makes it easier to do with a webview-based app.

Re: An experimental Android WebView Media Integrity API early next year

#96

Post by wkat4242 »

mlyle wrote: post #88
nonrandomstring wrote: post #78

Earlier quoted context omitted.

It'll be back, in another form. Pay no attention to specific projects and proposals that are offered and withdrawn. Look at the bigger picture over a longer time-frame and ask; what are the forces acting within and upon an entity? Meadows' leverage points taxonomy can be used analytically as well as instrumentally. What are the values behind misadventures like WEI ? Google want to own your browser and infiltrate as m…

Sometimes what you're describing is a valid approach-- once a pattern is clear. This is looking pretty reasonable for Google. But it seems like a bit of a toxic, pessimistic response in general. There's other times where a party just screws up. e.g. Apple's CSAM-- once the industry educated them, they took a very different tack. There was no fundamental structural or cultural issue pushing them towards the problemati…

> There's other times where a party just screws up. e.g. Apple's CSAM

Did Apple really screw up? Their proposal is pretty much what the EU and UK governments want now :(

I think they screwed up because to have my own phone spying on me is unthinkable and I would never have considered another Apple product again. But politics seem to like the idea.

Re: An experimental Android WebView Media Integrity API early next year

#97

Post by josephg »

marklar423 wrote: post #57
Arainach wrote: post #40

Earlier quoted context omitted.

I don't trust applications enough to have things like the encryption key for my hard drive outside a TPM.

I don't disagree, but how do you feel about you (the machine owner) also not having access to it? That's my major problem with it; it locks you out of messing with your own machine data, which you can see being instantly abused by third parties to prevent modifications.

TPM chips are pretty open. I had a look through the spec & API for tpm 2.0 a few years ago and there’s a lot of neat tricks you can do with them. TPM chips are an open standard with many implementations.

As far as I can tell, as a software developer you have full access to the chip. The only thing you can’t do with them (by design) is read the signing keys or generate secure boot attestations for machines which didn’t secure boot. I think you can even replace the signing keys entirely if you want to.

They aren’t a hard drive. They don’t store your data. And unfortunately I don’t think they’ll do much to prevent software bugs from causing problems. Particularly in the operating system, where software bugs can undermine the entire chain of trust model.

Don’t get me wrong; the idea of getting my computer to cryptographically prove it’s running in some locked down Xbox mode to be allowed to play Netflix or do online banking is quite the ask. The hackability of computers is one of their best features and I don’t want that genie to go back in the bottle.

But every time the conversation comes up there’s so much misinformation about them. People conflate tpm chips with intel’s management engine (which is secret and closed source), Apple’s secure enclosure (which I think can store some data?) and other stuff that works really differently.

Re: An experimental Android WebView Media Integrity API early next year

#98

Post by matheusmoreira »

JohnFen wrote: post #34
jorvi wrote: post #26

Earlier quoted context omitted.

Uhm… what? Your beef is with things like Pluton, Intel’s ME and AMD’s PSP. TPM at their base are nothing else than a more secure place to store cryptographic data.

It's a place that applications can store such data without my knowledge or control, and I don't trust applications enough to be comfortable with them having that ability. Don't get me wrong, it's not a major issue for me, it's just uncomfortable. It just means I prefer my machines to not have TPM hardware in them.

The problem isn't the cryptography, who's using it and for what. There's nothing wrong with it if we're using it to empower and secure ourselves. There's everything wrong with it if it's some corporation using it to protect themselves from us, the owners of the machines. The former is just normal user activity. The latter means our computers are not really ours, they come pwned straight off the factory.

Re: An experimental Android WebView Media Integrity API early next year

#99

Post by mcpackieh »

belval wrote: post #42
jjoonathan wrote: post #30

Earlier quoted context omitted.

Oof, that hyper-aggressive whitewashing of the DRM proposal from yoavweiss_ was a harsh lesson in realpolitik. Nerds were bringing good faith arguments to a bad faith optics war and getting slaughtered.

For people wondering which of the links to click: https://news.ycombinator.com/item?id=36857676 It's mostly just the classic "nono if you don't agree it's because you don't understand" and "please educate yourself" approach.

> "P.S. I'd love to discuss this with y'all like professional adults. Can we do that?"

You can tell somebody is a snake when they aren't from the South but use "y'all". It's become a sort of corporate snake shibboleth.

Re: An experimental Android WebView Media Integrity API early next year

#100

Post by rezonant »

JohnFen wrote: post #34
jorvi wrote: post #26

Earlier quoted context omitted.

Uhm… what? Your beef is with things like Pluton, Intel’s ME and AMD’s PSP. TPM at their base are nothing else than a more secure place to store cryptographic data.

It's a place that applications can store such data without my knowledge or control, and I don't trust applications enough to be comfortable with them having that ability. Don't get me wrong, it's not a major issue for me, it's just uncomfortable. It just means I prefer my machines to not have TPM hardware in them.

They can store that data, but they cannot retrieve that data. That's because the data it stores are cryptographic secrets (private keys). If they store a private key there and then delegate encryption/decryption to the TPM, you can also ask the TPM to perform said encryption/decryption using that key as the system owner.

The entire point of a TPM is ensuring that private keys intended for a specific device are never leakable off of that device.

Now that being said, there is an additional function of TPMs that is more controversial, and that's how it can be used by the CPU and firmware to refuse to execute code when a chain of attestation coming from a root key stored in the TPM is not satisfied. That controversy is very valid for TPMs or other "enclave" devices which do not allow the system owner to change those root keys. And of course there is the extended ability to leverage this attestation over a network, to allow a _server_ to be able to refuse service if the attestation is not valid.

When the user can change the root attestation keys, I think local attestation is a net positive for the security of the user. When they cannot, it means that only the "blessed" builds from the hardware manufacturer can run. This second case should be made illegal in my opinion.

Though there's nuance here, remote attestation however is a net negative for the user. Taken to it's logical conclusion where unattested access is 100% refused without exceptions, it means that the user effectively cannot run their own software on devices that they own, and that is not acceptable. It also ensures that the user can only use hardware devices that the service provider deems as allowed, which is the more practical and likely outcome at scale.

Remote attestation is what's at issue with WEI (and indeed things like Google Play Integrity and the equivalent feature of Apple's iOS stack), not the ability to ensure that private keys cannot be leaked.

Post reply on HN