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

71–80 of 247 posts

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

#71

Post by mixmastamyk »

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…

> Is there a risk that this is one of those "shelve it for 6 months and we'll try again later" playbooks...?

Odd way to phrase a sure thing. The "war on general purpose computing" is real and fought continuously by the powers that be. I believe Doctorow has one of the important works on the subject.

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

#72

Post by acdha »

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.

That feels wrong in some ways but it’s also the only way you can trust used hardware, or anything which has been compromised. I do get considerable value out of the resale value for my stolen Apple devices being much lower, and that’s probably a higher risk for most people.

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

#74

Post by ajross »

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.

> To me, this looks like a backdoor way to prevent people making "hacked" apps which, for example, play youtube but without ads.

More like "impersonate your bank and steal your login credentials". MitM attacks using interposed clients are a genuine threat outside the Apple and Google walled gardens (and even a little bit within). WEI was an attempt at solving a real problem.

Now, maybe it had unacceptable side effects, maybe it was more harmful than useful. And now it's dead. But the underlying issues got completely lost in the hyperbole wars around here. People were wildly slinging accusations of secret agendas and general bad faith[1]. It wasn't our finest moment as a community.

[1] Most of them while typing said comments on an Apple device objectively even less friendly to nonstandard clients!

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

#75

Post by mixmastamyk »

jjoonathan wrote: post #30
lol768 wrote: post #10

WEI itself was previously discussed across a number of threads, which make interesting reading: (July 2023, 456 comments) https://news.ycombinator.com/item?id=36854114 - "Google's nightmare Web Integrity API wants a DRM gatekeeper for the web" (July 2023, 431 comments) https://news.ycombinator.com/item?id=36817305 - "Web Environment Integrity API Proposal" (July 2023, 434 comments) https://news.ycombinator.com/item?i…

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.

Looks like yoavweiss was slaughtered, not the good-faith nerds.

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

#76

Post by vlovich123 »

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.

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.

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

#77

Post by pzmarzly »

userbinator wrote: post #52
raverbashing wrote: post #37

Earlier quoted context omitted.

Yes and according to discussions at that time Palladium would be always on, on all PCs and it would banish Linux from all PCs making Windows the some possible OS.. Which is totally what happened, right? /s

and it would banish Linux from all PCs making Windows the some possible OS We're getting closer to that with things like "secure" boot. Fortunately that can still be disabled, but MS even required that on ARM platforms it can't. The bigger Linux distros have bent over and gotten MS to sign their bootloaders, essentially making them at the mercy of MS.

Back when EFI consortium wanted to make Secure Boot always on, it wasn't even clear if ARM is going to win in mobile market, let alone PC/server one.

Nowadays all non-mobile aarch64 devices I used, and even many mobile ones, let you boot your own unsigned kernel. Arm's SBBR only states that IF you implement Secure Boot and TPM support in your EFI firmware (you don't have to), it has to comply with certain rules. Nothing about preventing users from disabling it. (https://documentation-service.arm.com/static/5fb7e66fd77dd80...)

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

#78

Post by nonrandomstring »

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…

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 much of the client-side as they can.

What other technical avenues and regulations can they make politically expedient use of?

To fight this abuse don't attack proposals, projects, or even behaviours. Study and attack their core values. What are they really about?

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

#79

Post by claytongulick »

TremendousJudge wrote: post #59
andybak wrote: post #36

Earlier quoted context omitted.

Webviews are particularly vulnerable though, being used for embedded logins for sometimes dubious 3rd party apps. Is there a reasonable angle to view this from? I personally don't think embedded webviews should be allowed general browsing capability unless they are part of a standalone browser. It's usually a trick to capture traffic that would otherwise go off to the open web.

If that's the problem you're trying to solve, disallow embedded ~~logins~~ webviews and do it through a proper browser, same as on a regular computer. The other way seems overkill and smells like foul play to me.

> disallow embedded logins and do it through a proper browser

How would you propose doing this from a technical standpoint?

How is android supposed to know what an embedded login is on a web page?

What happens when you're in an SSO or other secure environment and need to refresh credentials after a redirect?

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

#80

Post by TremendousJudge »

andybak wrote: post #69
TremendousJudge wrote: post #59

Earlier quoted context omitted.

If that's the problem you're trying to solve, disallow embedded ~~logins~~ webviews and do it through a proper browser, same as on a regular computer. The other way seems overkill and smells like foul play to me.

I'm not sure how you disallow embedded login without disallowing embedded webviews. The line is very blurry.

I'm sorry, I wrote embedded logins but was thinking embedded webviews in general. The only legitimate use of that in my mind is "a web browser app that's a usability skin over Chrome". Everything else is just a way of keeping you in a walled garden, and would be better if it just sent you to your default browser.
Post reply on HN