7 ms·

> 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

> 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.

JohnFen 3y ago
It's not intended to benefit the user.
- deleted 3y ago
  [deleted]
- ugh123 3y ago
  The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. They don't give an example, but i'd imagine its something like: "bad app lets user's sign into their bank account through the app's webview, then webview scrapes/intercepts content to do as they wish".
  - ethbr1 3y ago
    Isn't that something that should be solved at the App Store and/or application fraud detection levels? I get bad actors exist. But they're not an excuse to strip everyone else of rights. >> The Android WebView API lets app developers display web pages which embed media, with increased control over the UI and advanced configuration options to allow a seamless integration in the app. This brings a lot of flexibility, but it can be used as a means for fraud and abuse, because it allows app developers to access web content, and intercept or modify user interactions with it. This proposal was always a stick of dynamite when a screwdriver was needed. Start with the assumption that a user client should be able to do whatever the user decides it should. And while keeping that in mind as an absolute, work backwards. If it creates false ad clicks... tough. Deal with it.
    - c0pium 3y ago
      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.
      - JohnFen 3y ago
        Perhaps the solution is to have two classes of machines, some "safe" for those who don't want to (or can't) be proactive and alert to security threats, and some "unsafe" for those who want total control over their machines and are willing to take on the security risks and responsibilities to do that.
        jasonjayr 3y ago
        I mean, yes. 1000% yes. But the reality is that the 'market' will push to only make content for the "safe" machines, and the total control folks will slowly get locked out. Banks have required auditors that will mandate only allowing access from 'safe' environments Media companies will do everything to make sure content is only played in 'safe' environments Government will allow allow you to interact with their technology from 'safe' environments, etc. And they will all believe 100% they are doing the right thing to protect the users. I am deeply afraid for open general purpose computing.
        ethbr1 3y ago
        It's economics. If "safe" means ceding control, and there's a business model by which I can make more money if the user cedes control (e.g. enforcing DRM), then I can subsidize the "safe" version and sell it for less than the total control version. I'll make it up on the backend.
      - ndriscoll 3y ago
        If they installed it through a commercial app store, hold the store owner liable as an accessory to fraud.
  - londons_explore 3y ago
    They could protect against that easily by simply adding a header to all outgoing requests saying "this request originated from com.appname". If a website didn't want to be embedded in that app, the webpage could refuse to let the user log in. The whole thing is a bit moot, because any app can just implement their own web renderer or just fake the login screen to Chase.com entirely to get the users creds.
  - josteink 3y ago
    > The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. You got it backwards. The user gets to trust nothing. The “trust” in this case is for the server to asses if it a trusted (not hacked/hackable) environment to deploy content to. DRM is the only use case.
    - c0pium 3y ago
      This is incorrect. If Chase uses attestation then only the Chase app can access their login site. It prevents DefinitelyChaseAndNotMalware from masquerading as Chase.
      - yjftsjthsd-h 3y ago
        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.
        c0pium 3y ago
        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.
        yjftsjthsd-h 3y ago
        > 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.
  - danShumway 3y ago
    > The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. How so? Phishing sites will still work. Okay, let's say I can't embed a bank's login form into an embedded webview. I can still embed a login form that looks to-the-pixel identical to the bank's login form. I can still proxy requests to other servers (even though Android natively). My guess would be that webviews are strictly easier than a normal browser to do a phishing attack in because they don't display the domain of the page they're visiting to the user. It's not immediately clear to me how attestation to the server would change that.
  - grishka 3y ago
    The "trust" in "trusted computing" is very much the reverse. In this threat model, the user is considered an adversary. The device and its software is built such that the corporate server could "trust" that the device isn't acting in user's interests, instead enforcing the corporation's business model.
- happytiger 3y ago
  DRM schemes, especially when they masquerade as public service, rarely are.
- jppittma 3y ago
  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.
  - JohnFen 3y ago
    I think there are some end-user benefits, but they're more side-effects than the reason the technology was invented.
    - jppittma 3y ago
      What is the basis for assuming that something like this was created in bad faith?
  - wildrhythms 3y ago
    >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.
    - jppittma 3y ago
      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.
ajross 3y ago
> 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!
- c0pium 3y ago
  You’re being downvoted at the moment, but this is absolutely true. Fake bank apps are a huge problem, which this addresses.
  - richij 3y ago
    It absolutely does not. The ability to craft a realistic phishing login page is unaffected by Google's proposed MI API.
    - c0pium 3y ago
      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.
amalcon 3y ago
It seems pretty straightforward to prevent that anyway, through Play Integrity attestation. This just makes it easier to do with a webview-based app.

JohnFen 3y ago

It's not intended to benefit the user.

deleted 3y ago
[deleted]
ugh123 3y ago
The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. They don't give an example, but i'd imagine its something like: "bad app lets user's sign into their bank account through the app's webview, then webview scrapes/intercepts content to do as they wish".
- ethbr1 3y ago
  Isn't that something that should be solved at the App Store and/or application fraud detection levels? I get bad actors exist. But they're not an excuse to strip everyone else of rights. >> The Android WebView API lets app developers display web pages which embed media, with increased control over the UI and advanced configuration options to allow a seamless integration in the app. This brings a lot of flexibility, but it can be used as a means for fraud and abuse, because it allows app developers to access web content, and intercept or modify user interactions with it. This proposal was always a stick of dynamite when a screwdriver was needed. Start with the assumption that a user client should be able to do whatever the user decides it should. And while keeping that in mind as an absolute, work backwards. If it creates false ad clicks... tough. Deal with it.
  - c0pium 3y ago
    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.
    - JohnFen 3y ago
      Perhaps the solution is to have two classes of machines, some "safe" for those who don't want to (or can't) be proactive and alert to security threats, and some "unsafe" for those who want total control over their machines and are willing to take on the security risks and responsibilities to do that.
      - jasonjayr 3y ago
        I mean, yes. 1000% yes. But the reality is that the 'market' will push to only make content for the "safe" machines, and the total control folks will slowly get locked out. Banks have required auditors that will mandate only allowing access from 'safe' environments Media companies will do everything to make sure content is only played in 'safe' environments Government will allow allow you to interact with their technology from 'safe' environments, etc. And they will all believe 100% they are doing the right thing to protect the users. I am deeply afraid for open general purpose computing.
        ethbr1 3y ago
        It's economics. If "safe" means ceding control, and there's a business model by which I can make more money if the user cedes control (e.g. enforcing DRM), then I can subsidize the "safe" version and sell it for less than the total control version. I'll make it up on the backend.
    - ndriscoll 3y ago
      If they installed it through a commercial app store, hold the store owner liable as an accessory to fraud.
- londons_explore 3y ago
  They could protect against that easily by simply adding a header to all outgoing requests saying "this request originated from com.appname". If a website didn't want to be embedded in that app, the webpage could refuse to let the user log in. The whole thing is a bit moot, because any app can just implement their own web renderer or just fake the login screen to Chase.com entirely to get the users creds.
- josteink 3y ago
  > The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. You got it backwards. The user gets to trust nothing. The “trust” in this case is for the server to asses if it a trusted (not hacked/hackable) environment to deploy content to. DRM is the only use case.
  - c0pium 3y ago
    This is incorrect. If Chase uses attestation then only the Chase app can access their login site. It prevents DefinitelyChaseAndNotMalware from masquerading as Chase.
    - yjftsjthsd-h 3y ago
      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.
      - c0pium 3y ago
        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.
        yjftsjthsd-h 3y ago
        > 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.
- danShumway 3y ago
  > The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. How so? Phishing sites will still work. Okay, let's say I can't embed a bank's login form into an embedded webview. I can still embed a login form that looks to-the-pixel identical to the bank's login form. I can still proxy requests to other servers (even though Android natively). My guess would be that webviews are strictly easier than a normal browser to do a phishing attack in because they don't display the domain of the page they're visiting to the user. It's not immediately clear to me how attestation to the server would change that.
- grishka 3y ago
  The "trust" in "trusted computing" is very much the reverse. In this threat model, the user is considered an adversary. The device and its software is built such that the corporate server could "trust" that the device isn't acting in user's interests, instead enforcing the corporation's business model.
happytiger 3y ago
DRM schemes, especially when they masquerade as public service, rarely are.
jppittma 3y ago
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.
- JohnFen 3y ago
  I think there are some end-user benefits, but they're more side-effects than the reason the technology was invented.
  - jppittma 3y ago
    What is the basis for assuming that something like this was created in bad faith?
- wildrhythms 3y ago
  >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.
  - jppittma 3y ago
    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.

ajross 3y ago

> 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!

c0pium 3y ago
You’re being downvoted at the moment, but this is absolutely true. Fake bank apps are a huge problem, which this addresses.
- richij 3y ago
  It absolutely does not. The ability to craft a realistic phishing login page is unaffected by Google's proposed MI API.
  - c0pium 3y ago
    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.

amalcon 3y ago

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