3 ms·

> Instead, the Android team aims to focus on the Android WebView Media Integrity API, which provides a similar form of attestation but only for WebViews embedde

> Instead, the Android team aims to focus on the Android WebView Media Integrity API, which provides a similar form of attestation but only for WebViews embedded in Android apps. I'm not as dismissive of this as the Register is; it's definitely less harmful than the original proposal, but it's still DRM, and now it's no longer going through a standards process so we just don't have a ton of details about how it will work. I honestly feel like this announcement should probably be getting more skepticism than I've seen from the news sites reporting it. I'm not saying it's just as bad, I'm just saying we should question how much this is going to help security for end users or whether this is just going to to turn into more DRM to let embedded webapps act like native apps.

magicalist 3y ago
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.
- danShumway 3y ago
  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.
lamontcg 3y ago
Yeah it reads like they got too much bad press and outright hostile pushback from Plan A so they're switching to Plan B and hoping to boil the proverbial frog slowly over time.
- danShumway 3y ago
  This is almost exactly my worry, especially since this will for all intents and purposes be a web API that only works on one browser. So if Google comes back and tries to standardize this again, do they now rush it through the standardization process and say, "look, servers are already using this API, we're not doing anything new, we're just adding it to more browsers." Embedded webview is a web browser. This allows them to launch an API for remote attestation as a working implementation in a web browser and ship it to developers and users -- and that's a big chunk of standardization right there. ---- I'm not thrilled with it for Android either, but if I could trust that it was only ever going to stay in Android webview then I'd feel at least a little better about it. But Google has no way to credibly commit to that, and they've given no details or retrospectives about WEI. We get like 2 paragraphs in an email thread and 2 sentences in a press release that just says, "yeah, we're not working on that anymore." It's very difficult to trust that.
jmorenoamor 3y ago
To me, it sounds like: We are going to develop and test it anyways, and we will try to standarize it again when the time comes.
deleted 3y ago
[deleted]
hashhar 3y ago
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_kGO22g/m/LMlRMkrxCAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_... This was mentioned earlier in the thread if someone wants to follow the source.

magicalist 3y ago

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.

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

lamontcg 3y ago

Yeah it reads like they got too much bad press and outright hostile pushback from Plan A so they're switching to Plan B and hoping to boil the proverbial frog slowly over time.

danShumway 3y ago
This is almost exactly my worry, especially since this will for all intents and purposes be a web API that only works on one browser. So if Google comes back and tries to standardize this again, do they now rush it through the standardization process and say, "look, servers are already using this API, we're not doing anything new, we're just adding it to more browsers." Embedded webview is a web browser. This allows them to launch an API for remote attestation as a working implementation in a web browser and ship it to developers and users -- and that's a big chunk of standardization right there. ---- I'm not thrilled with it for Android either, but if I could trust that it was only ever going to stay in Android webview then I'd feel at least a little better about it. But Google has no way to credibly commit to that, and they've given no details or retrospectives about WEI. We get like 2 paragraphs in an email thread and 2 sentences in a press release that just says, "yeah, we're not working on that anymore." It's very difficult to trust that.

jmorenoamor 3y ago

To me, it sounds like: We are going to develop and test it anyways, and we will try to standarize it again when the time comes.

deleted 3y ago

[deleted]

hashhar 3y ago

https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_kGO22g/m/LMlRMkrxCAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_... This was mentioned earlier in the thread if someone wants to follow the source.