3 ms·

> 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

> 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.
      - c0pium 3y ago
        You should reread more carefully, you clearly don’t understand the points you’re replying to.
    - xerox13ster 3y ago
      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.
      - c0pium 3y ago
        > 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.

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.
    - c0pium 3y ago
      You should reread more carefully, you clearly don’t understand the points you’re replying to.
  - xerox13ster 3y ago
    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.
    - c0pium 3y ago
      > 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.