4 ms·

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 wh

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?

matheusmoreira 3y ago
Remote attestation happens in hardware now. Significantly harder to fake.
- danShumway 3y ago
  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.
  - matheusmoreira 3y ago
    It does. It's called SafetyNet and it wiped out the freedom Android used to have. https://www.xda-developers.com/safetynet-hardware-attestation-feature-here-to-stay/ https://www.xda-developers.com/safetynet-hardware-attestatio...
    - JohnFen 3y ago
      This sort of lockdown (along with others) is why I'm abandoning smartphones altogether.
kevincox 3y ago
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)
- danShumway 3y ago
  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.

matheusmoreira 3y ago

Remote attestation happens in hardware now. Significantly harder to fake.

danShumway 3y ago
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.
- matheusmoreira 3y ago
  It does. It's called SafetyNet and it wiped out the freedom Android used to have. https://www.xda-developers.com/safetynet-hardware-attestation-feature-here-to-stay/ https://www.xda-developers.com/safetynet-hardware-attestatio...
  - JohnFen 3y ago
    This sort of lockdown (along with others) is why I'm abandoning smartphones altogether.

kevincox 3y ago

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)

danShumway 3y ago
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.