WebViews can already be given access to literally anything you want to give them from your app you embedded them in, so I don't see any fundamental change? It's basically a new android DRM API, of which there are already several.
I wonder how hard it would have been before this to simulate the same API using the Play Integrity API and just exposing it to the webview. Is that something where the remote server would still have to trust the client to not lie about the API, or could they do an attestation check remotely in a way that would be difficult to fake?
The difference may be that any app could embed a "Google Verified" webview. (And presumably the OS would prevent the embedding app from modifying the webview in any "unapproved" way.
For example this could be used by Google to allow apps to embed a Google login page without them being able to access the users credentials or steal the full-access auth token (although this is still a bad idea for a variety of ways including click jacking, confusing overlays, conditioning the user to type their password into untrusted apps... but the raw capability is interesting and could potentially have "reasonable" use cases)
A couple of people have brought this up, and I'm certainly open to learning more about it, but I'll admit that I don't see the user benefit.
The problem with embedding Google login pages probably isn't user credential stealing as much as it's phishing? Webviews don't show the URL on Android, so what about this change prevents me from sending you to a "Google" log-in page that harvests your credentials using an old-fashioned phishing attack?
Okay, I can't steal the credential directly from the actual Google log-in, but is that how most malicious actors are stealing log-in information today? I wouldn't have guessed that, but :shrug: maybe I'm wrong. It seems like for all the problems you bring up, standardizing a feature to use user-controlled browsers for a subset of auth requests for native apps would be way better. Or (for all of my skepticism about them) using passkeys. Both would provide more opportunities to encourage developers/companies to do auth the "right" way -- via limited access tokens where credentials aren't shared between apps.
Don't get me wrong, embedded log-in forms in apps are dangerous for user security, but it seems like there are far better solutions to that problem that don't have any of the downsides of attestation?
----
Edit: Also, I'm realizing as I'm typing this that "non-approved apps shouldn't be able to load certain web pages" would be a far better candidate for a user-permission with sensible defaults rather than a server setting. Browsers have CORS requests today, the key point being that as a user, if I want to, I can override them. It changes the entire model from being "prove to the server that you're trustworthy" to "here is a recommendation to the client (in this case the Android OS) on how to keep the user safe, and if you want to ignore it, fine, but you probably shouldn't by default."
I still am not sure this would solve phishing and I'm not sure it would be a meaningful increase in security, but I'm realizing that if this wasn't attestation and Android was announcing that they were rolling out user-controlled permissions and routing tables for the system webview that would allow you to specify allowed domains on system/app level, I would only have praise for that announcement.
Could copy CORS for servers to set defaults; webview would do a preflight check for app IDs based on the system and refuse to load the webpage if the "CORS" request fails. I'd support that as a web standard, off the top of my head I don't think it would have almost any of the downsides of attestation since it would ultimately be up to the user-agent whether to respect the restriction, not the server.
Right -- again, assuming the best intentions around this change and only thinking about the security implications, I'm just wondering if trying to secure that process is counterproductive in itself.
I really like the engineering concept of encouraging developers to fall into a "pit of success" and I wonder if having an alternate auth flow that genuinely avoids most of these problems beyond the very narrow "developers can access the context of the current web page" problem would be better. We really shouldn't do embedded login forms at all, we should encourage developers to move away from them.
I'd support a web standard that made it easier to use the user-controlled actual browser to handle auth requests by apps. That would at least give the user visual access to the URL which would fend off some phishing attacks. And (assuming the FIDO Alliance shapes up and actually addressed current problems with spec) passkeys would be even better for this since cross-environment authentication that doesn't transfer credentials and is invulnerable to (most) phishing is passkey's entire deal.
I don't want to make a hard claim because I don't know the research, but I would not take it as a given that a change that as a side-effect encourages developers to embed login forms is a net benefit for user security.
For most purposes, you could probably have the phone have a TLS cert for an identity, have the identity provider sign that cert, then use mTLS. No phishing possible because you're not giving access to anything; just proving your identity to whichever server you talk to (and they can't forward that proof).
Honestly I'm not sure why oauth became such a thing and mutual SSL did not. Most "social login" use cases don't need a token that grants any access to anything from the idp. Just proof of id, which could be done in the background by your browser/OS service though some standardized cert renewal process.
Can you elaborate? I'm not sure I understand what you mean by "now".
What I'm asking is whether or not the Play Integrity API supports remote attestation on its own today (ie, before any of the webview changes ship). Or I guess, more specifically, is there a challenge-response API currently for the Play Integrity API that a remote server could use?
If yes, then sure, I buy that this is not really adding anything new. If no, then adding a webview API does seem to me like a meaningful expansion of Android's DRM capabilities.
