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

241–247 of 247 posts

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

#241

Post by c0pium »

yjftsjthsd-h wrote: post #179
c0pium wrote: post #162

Earlier quoted context omitted.

This is incorrect. If Chase uses attestation then only the Chase app can access their login site. It prevents DefinitelyChaseAndNotMalware from masquerading as Chase.

Well, no, at best it prevents DefinitelyChaseAndNotMalware from directly proxying Chase; it doesn't do anything to prevent someone... for the sake of argument, screenshotting the real Chase site and login flow, and serving that up to the user. It trades completely undermining user freedom and control for a minor increase in friction for bad actors.

It forces them to do the much harder to do and easier to notice work of making a fake login page. This is easier to detect with static analysis (bouncer) and allows the easier path of taking down fraudulent apps via DMCA request. It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app.

This is anti-fraud 101, forcing the bad actor to do more work makes the vector less viable. All anti-fraud tactics are about making an adversary do extra work.

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

#242

Post by yjftsjthsd-h »

c0pium wrote: post #241
yjftsjthsd-h wrote: post #179

Earlier quoted context omitted.

Well, no, at best it prevents DefinitelyChaseAndNotMalware from directly proxying Chase; it doesn't do anything to prevent someone... for the sake of argument, screenshotting the real Chase site and login flow, and serving that up to the user. It trades completely undermining user freedom and control for a minor increase in friction for bad actors.

It forces them to do the much harder to do and easier to notice work of making a fake login page. This is easier to detect with static analysis (bouncer) and allows the easier path of taking down fraudulent apps via DMCA request. It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app. This is anti-fraud 101, for…

> It forces them to do the much harder to do and easier to notice work of making a fake login page.

Are you sure it's more work to take a screenshot and stick it in the app vs building a wrapper that pulls data out of a site? It seems easier to me, though I grant it's marginally easier for the user to notice.

> This is easier to detect with static analysis (bouncer)

Unfortunately in this world your automated scanner is trivially blocked by the server because WEI forces your scanner software to tell every single site exactly what it is.

> and allows the easier path of taking down fraudulent apps via DMCA request.

If the authors get tired of playing whack-a-mole, they can just put the content in the app itself.

> It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app.

Yes, that's true; the optimal flow would be to fake the login to capture credentials, throw a nonsense error, and then redirect to the clean/unaltered page for real login (which the user sees as "log in, get weird error, try again as prompted, it works, move on with day"). And that is more friction and easier to catch, but not that much.

> This is anti-fraud 101, forcing the bad actor to do more work makes the vector less viable. All anti-fraud tactics are about making an adversary do extra work.

Sure, but tactics that destroy user freedom for a tiny benefit deserve to be thrown out.

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

#243

Post by c0pium »

yjftsjthsd-h wrote: post #242
c0pium wrote: post #241

Earlier quoted context omitted.

It forces them to do the much harder to do and easier to notice work of making a fake login page. This is easier to detect with static analysis (bouncer) and allows the easier path of taking down fraudulent apps via DMCA request. It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app. This is anti-fraud 101, for…

> It forces them to do the much harder to do and easier to notice work of making a fake login page. Are you sure it's more work to take a screenshot and stick it in the app vs building a wrapper that pulls data out of a site? It seems easier to me, though I grant it's marginally easier for the user to notice. > This is easier to detect with static analysis (bouncer) Unfortunately in this world your automated scanner…

You should reread more carefully, you clearly don’t understand the points you’re replying to.

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

#244

Post by xerox13ster »

c0pium wrote: post #241
yjftsjthsd-h wrote: post #179

Earlier quoted context omitted.

Well, no, at best it prevents DefinitelyChaseAndNotMalware from directly proxying Chase; it doesn't do anything to prevent someone... for the sake of argument, screenshotting the real Chase site and login flow, and serving that up to the user. It trades completely undermining user freedom and control for a minor increase in friction for bad actors.

It forces them to do the much harder to do and easier to notice work of making a fake login page. This is easier to detect with static analysis (bouncer) and allows the easier path of taking down fraudulent apps via DMCA request. It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app. This is anti-fraud 101, for…

So then this is just an end run by Google around their own shitty vetting for their appstore... If the central tenet here is that people will be downloading fake apps to try to get people's login information at the bank, it its Google's responsibility to make sure those apps never make it into the app store.

Chase also could require an authentication code from any Big3 Auth app or roll their own auth app that should be installed alongside the banking app, which will call down to it upon login.

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

#245

Post by c0pium »

xerox13ster wrote: post #244
c0pium wrote: post #241

Earlier quoted context omitted.

It forces them to do the much harder to do and easier to notice work of making a fake login page. This is easier to detect with static analysis (bouncer) and allows the easier path of taking down fraudulent apps via DMCA request. It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app. This is anti-fraud 101, for…

So then this is just an end run by Google around their own shitty vetting for their appstore... If the central tenet here is that people will be downloading fake apps to try to get people's login information at the bank, it its Google's responsibility to make sure those apps never make it into the app store. Chase also could require an authentication code from any Big3 Auth app or roll their own auth app that should…

> its Google's responsibility to make sure those apps never make it into the app store

Good, we agree, they should take this action which helps them keep fraudulent apps out of their App Store.

> Chase also could require an authentication code

Chase does require that. It doesn’t help here, because you can obviously phish codes just as easily as passwords. The solution here is attestation, anything else is a hack that makes bad behavior much too easy.

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

#246

Post by c0pium »

mindslight wrote: post #213
c0pium wrote: post #157

Earlier quoted context omitted.

And if it drains people’s bank accounts because they aren’t savvy enough to know that their bank’s app is realbank not realbankofficial? Deal with it? The stance that other people should have their savings stolen, when we could have easily stopped it, because of nebulous freedom reasons is pretty ghoulish.

This is not how bank accounts work at all. "Regulation E". Bank accounts are not bearer bonds, and the system is not meant to be impervious to unauthorized transactions. Your vulnerability/responsibility essentially ends at checking your statements for unauthorized transactions.

> This is not how bank accounts work at all.

Of course it is.

It is allegedly the case that you are correct. It is actually the case that using the system is incredibly painful, and hard to understand, and lots of people end up in a terrible situation because of it.

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

#247

Post by KETHERCORTEX »

c0pium wrote: post #240
richij wrote: post #237

Earlier quoted context omitted.

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

> First, if you copy the login page those assets are in the apk.

You don't need to store the assets in the APK if you can load a webpage.

> 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

You don't need to show the working bank app if it isn't advertised as one. Name it "Government assistance program" with "application process" requiring logging in with bank credentials (to confirm identity, because bank knows who you are). Then you can make it more convincing by adding some bs forms and stuff like "your application will be processed in two weeks".

I saw this stuff already implemented and used. They can add as many integrity protection layers as they want, but it won't trigger one. So it looks like a measure to say "bank apps are safe now we are great guys" without real effect.

I'd say that it may increase login thefts because users may get a false impression that anything they will install is safe now.

Post reply on HN