It's not intended to benefit the user.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Umm, yes? Google themselves even offer this as a product: Youtube Premium.