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

231–240 of 247 posts

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

#231

Post by rezonant »

Wowfunhappy wrote: post #141
nolist_policy wrote: post #137

Earlier quoted context omitted.

All this is about attesting authenticity to the server .

But only Android WebViews can attest their authenticity. Are servers going to block standalone web browsers? If they are, why even use a WebView? Just make it part of your app.

I've posted elsewhere about this as well, and I think it means the WebView Integrity solution will effectively do nothing. It just won't solve the problems Google is trying to solve. The bad actors they want to route out will work around it, so even if websites implement it, the fraud or other bad behaviors they describe will continue mostly unimpeded, because the websites literally cannot block unattested access (because all legitimate non-WebView browsers will be unattested)

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

#232

Post by rezonant »

londons_explore wrote: post #172
andybak wrote: post #69

Earlier quoted context omitted.

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

You have two types of webviews... "Webviews to the appmakers server", and "Webviews for the wider web". Webviews to the appmakers server need to be authorized by some manifest file on the server whitelisting the app identifier. Webviews for the wider web don't allow the app to know what's going on inside the webview, nor interact with it. So these are safe to type passwords into etc.

So this would have no effect, because you can simply embed Chromium in your app instead of using the system-provided WebView. Because Android is very fragmented and there are still a significant amount of devices out there running less than Android M when the web view was made an upgradeable package, there is, at least for now, a very legitimate reason to ship your own browser implementation within an app that is primarily implemented using web tech: The Web View implementation shipped with M and earlier is not sufficient to run such an application.

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

#233

Post by wildrhythms »

jppittma wrote: post #203
JohnFen wrote: post #38

Earlier quoted context omitted.

It's not intended to benefit the user.

Do you really believe that the ability for people to play YouTube without ads benefits the user? I mean, it sounds great on some level. Perhaps browsers should just ship with ad blocking by default. Everybody the world over can use the internet and have a better experience without anybody ever seeing any of those pesky paid ad things.

>Do you really believe that the ability for people to play YouTube without ads benefits the user

Umm, yes? Google themselves even offer this as a product: Youtube Premium.

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

#234

Post by v147 »

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…

Vivaldi (from the 3rd link) also posted an update today:

Hot off the press, we have learned that Google is not proceeding with its Web Integrity API.

This is massively positive for the neutrality of the open Web. Though of course, with Google being so heavily driven by their interests rather than the benefit of the Web in general, it remains to be seen (and we strongly suspect it won’t take long) what they choose to replace it with. Are they, for example, just preparing a seemingly less obnoxious spec that is actually just as harmful to users (as they did with FLOC and Topics)? It also seems highly suspicious that it coincides with their very recent announcement to move from pay-per-click to pay-per-impression for ads.

Generally, Google hasn’t shown itself to be a trustworthy custodian of the web and we can’t let this apparent victory lure us into resting on our laurels. As always, a strong diversity of browsers and browser engines is going to be crucial to counteract any future attempt by a single party to dictate the future of the web.

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

#235

Post by jppittma »

wildrhythms wrote: post #233
jppittma wrote: post #203

Earlier quoted context omitted.

Do you really believe that the ability for people to play YouTube without ads benefits the user? I mean, it sounds great on some level. Perhaps browsers should just ship with ad blocking by default. Everybody the world over can use the internet and have a better experience without anybody ever seeing any of those pesky paid ad things.

>Do you really believe that the ability for people to play YouTube without ads benefits the user Umm, yes? Google themselves even offer this as a product: Youtube Premium.

My impression is that it's not people paying for Youtube Premium who are complaining about Google targeting people with ad blockers. I suppose Netflix used to offer only paid, ad free video streaming, so it isn't really out of the question for somebody to wish that were youtube's model; however, I can't help but imagine that if YouTube said they were switching to that most people on this site would be even more upset.

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

#236

Post by cmrdporcupine »

Intralexical wrote: post #224
cmrdporcupine wrote: post #210

Earlier quoted context omitted.

Here in the rural parts of Ontario (well not in my rural part of Ontario, but further north), that pronoun is "youse" As a long boy visiting from Alberta I was astounded that this existed. It might be dying out tho

> I's the by that build the boat. > You's the by that sail 'er. — Wait, that's singular.... I think? Does it change again when you go further east? ....Or actually, is the second line also "I"?

My take is that "uneducated" people with "undisciplined" language spontaneously create their own plural second person pronouns wherever they go because, well, the language has needed them ever since they were lost from Anglo-Saxon ("ge", pronounced "ye").

I vote we just bring back this "ye" and make it official.

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

#237

Post by richij »

c0pium wrote: post #163
ajross wrote: post #74

Earlier quoted context omitted.

> 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 effect…

You’re being downvoted at the moment, but this is absolutely true. Fake bank apps are a huge problem, which this addresses.

It absolutely does not. The ability to craft a realistic phishing login page is unaffected by Google's proposed MI API.

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

#238

Post by Intralexical »

cmrdporcupine wrote: post #236
Intralexical wrote: post #224

Earlier quoted context omitted.

> I's the by that build the boat. > You's the by that sail 'er. — Wait, that's singular.... I think? Does it change again when you go further east? ....Or actually, is the second line also "I"?

My take is that "uneducated" people with "undisciplined" language spontaneously create their own plural second person pronouns wherever they go because, well, the language has needed them ever since they were lost from Anglo-Saxon ("ge", pronounced "ye"). I vote we just bring back this "ye" and make it official.

Ah, indeed. The plague of prescriptivism, as a gross exclusionary method of filtering social status, holding us back…

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

#239

Post by zarzavat »

jezzamon wrote: post #228
zarzavat wrote: post #70

Earlier quoted context omitted.

DRM for web browsing. A website would be able to request an attestation that your browser is “trusted”, i.e. it is secure and unmodified. Because some systems are by definition untrusted, e.g. Linux, or Firefox compiled from source, these users might be blocked from certain websites. At least that seemed like the intention, otherwise what’s the point of building such a feature?

If you want the "assuming good intent" explanation it was to be able to detect spam and bots which apparently are a significant problem now and are no longer stopped by captchas. One online community I'm part of literally turned off new sign ups because they couldn't stop the bot problem (ldjam.com). Users also find captchas annoying so it supposedly stop the need for that for many cases (except for when you're in th…

There’s still no way to tell the difference between a Linux user and a bot through such an attestation mechanism. So the effect on users is the same regardless of the intention.

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

#240

Post by c0pium »

richij wrote: post #237
c0pium wrote: post #163

Earlier quoted context omitted.

You’re being downvoted at the moment, but this is absolutely true. Fake bank apps are a huge problem, which this addresses.

It absolutely does not. The ability to craft a realistic phishing login page is unaffected by Google's proposed MI API.

Crafting a fake login page in your app is a totally different problem than transparently proxying the web interface. First, if you copy the login page those assets are in the apk. This is easily detectable by bouncer and allows those apps to be denied (this happens today). Second, stealing the assets opens the app up to dmca takedown, which also happens today. Third, and most importantly, if you reverse proxy the page then the app will appear to users to actually work. This is crucial for the bad actor as it keeps the app from having a low rating in the App Store for not working. When they just steal the login page, the app gets downvoted quickly for being “broken”.

All of this adds up to making the bad actors have to work much harder, which is the goal.

Post reply on HN