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

by 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.
  - danShumway 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? But... will this proposal stop that from happening? I think with every tradeoff between security and freedom, before we get into the philosophical questions we have to ask, "are we getting security from this tradeoff." Tbh, it is not clear to me how this improves security. The way I'll drain your bank account is by setting up a phishing site and proxying requests to your bank. That's how I would do it before this proposal, and it seems like post-proposal that would still work exactly the same way? I don't feel like I've seen enough information yet about how this is going to work to be able to confidently say that this is going to improve security.
  - mindslight 3y ago
    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.
    - c0pium 3y ago
      > 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.
  - keepamovin 3y ago
    Resorting to what appears as a moral high ground by labeling any dissenter with extreme negative attributes is, in essence, a shaming tactic intended to stifle opposition. This method is prevalent in political discourse, where extremists might brand those who disagree with them with the most severe moral condemnations available. The reliance on such shaming suggests that the accuser’s arguments might not withstand critical examination. Instead of yielding to this intimidation, intended to silence dissent, people should recognize these tactics as signs of argumentative weakness and a questionable moral stance. True morality, in contrast, supports the free exchange of ideas in a secure environment where all perspectives can be considered. Hostile tactics like these often betray an immoral position by those who employ them, despite their attempts to claim moral high ground. Their quickness to suppress dialogue through shaming undermines any claim to ethical superiority. Recognizing these tactics should prompt us to steer the conversation towards more constructive, open engagement, rather than engaging with any of the points raised in the moral intimidation directly, and question the robustness of the positions of those who resort to such methods.
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.

by ugh123 3y ago

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.
- danShumway 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? But... will this proposal stop that from happening? I think with every tradeoff between security and freedom, before we get into the philosophical questions we have to ask, "are we getting security from this tradeoff." Tbh, it is not clear to me how this improves security. The way I'll drain your bank account is by setting up a phishing site and proxying requests to your bank. That's how I would do it before this proposal, and it seems like post-proposal that would still work exactly the same way? I don't feel like I've seen enough information yet about how this is going to work to be able to confidently say that this is going to improve security.
- mindslight 3y ago
  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.
  - c0pium 3y ago
    > 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.
- keepamovin 3y ago
  Resorting to what appears as a moral high ground by labeling any dissenter with extreme negative attributes is, in essence, a shaming tactic intended to stifle opposition. This method is prevalent in political discourse, where extremists might brand those who disagree with them with the most severe moral condemnations available. The reliance on such shaming suggests that the accuser’s arguments might not withstand critical examination. Instead of yielding to this intimidation, intended to silence dissent, people should recognize these tactics as signs of argumentative weakness and a questionable moral stance. True morality, in contrast, supports the free exchange of ideas in a secure environment where all perspectives can be considered. Hostile tactics like these often betray an immoral position by those who employ them, despite their attempts to claim moral high ground. Their quickness to suppress dialogue through shaming undermines any claim to ethical superiority. Recognizing these tactics should prompt us to steer the conversation towards more constructive, open engagement, rather than engaging with any of the points raised in the moral intimidation directly, and question the robustness of the positions of those who resort to such methods.

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.