6 ms·

The title is misleading. They've dropped the proposal as applied to Chrome, but are still pursuing it for the Android WebView API, which is basically a wrapper

The title is misleading. They've dropped the proposal as applied to Chrome, but are still pursuing it for the Android WebView API, which is basically a wrapper around Chrome.

andybak 3y ago
Webviews are particularly vulnerable though, being used for embedded logins for sometimes dubious 3rd party apps. Is there a reasonable angle to view this from? I personally don't think embedded webviews should be allowed general browsing capability unless they are part of a standalone browser. It's usually a trick to capture traffic that would otherwise go off to the open web.
- TremendousJudge 3y ago
  If that's the problem you're trying to solve, disallow embedded ~~logins~~ webviews and do it through a proper browser, same as on a regular computer. The other way seems overkill and smells like foul play to me.
  - andybak 3y ago
    I'm not sure how you disallow embedded login without disallowing embedded webviews. The line is very blurry.
    - TremendousJudge 3y ago
      I'm sorry, I wrote embedded logins but was thinking embedded webviews in general. The only legitimate use of that in my mind is "a web browser app that's a usability skin over Chrome". Everything else is just a way of keeping you in a walled garden, and would be better if it just sent you to your default browser.
      - andybak 3y ago
        Ok. So I think we are in agreement. I struggle to think of a use case that is in the user's best interests.
    - londons_explore 3y ago
      You have two types of webviews... "Webviews to the appmakers server", and "Webviews for the wider web". Webviews to the appmakers server need to be authorized by some manifest file on the server whitelisting the app identifier. Webviews for the wider web don't allow the app to know what's going on inside the webview, nor interact with it. So these are safe to type passwords into etc.
      - deleted 3y ago
        [deleted]
      - rezonant 3y ago
        So this would have no effect, because you can simply embed Chromium in your app instead of using the system-provided WebView. Because Android is very fragmented and there are still a significant amount of devices out there running less than Android M when the web view was made an upgradeable package, there is, at least for now, a very legitimate reason to ship your own browser implementation within an app that is primarily implemented using web tech: The Web View implementation shipped with M and earlier is not sufficient to run such an application.
  - claytongulick 3y ago
    > disallow embedded logins and do it through a proper browser How would you propose doing this from a technical standpoint? How is android supposed to know what an embedded login is on a web page? What happens when you're in an SSO or other secure environment and need to refresh credentials after a redirect?
  - Obscurity4340 3y ago
    Is Friendly Social Browser maybe a good solution to this problem?
- IshKebab 3y ago
  > being used for embedded logins for sometimes dubious 3rd party apps. That's a difficult problem to solve though. To do it properly you'd need something like Windows' secure key sequence (ctrl-alt-del) which apps can't intercept. Otherwise there's no way that a user can know that what they're seeing is the system rather than a malicious app. Consider that any app can embed any browser or UI that they want.
  - londons_explore 3y ago
    That exists on mobile though... They could easily have a "swipe down to login" gesture, where you would see some system UI saying "Appname wants your password to foo.com, do you want to allow the app to log in using your saved password?". foo.com could also cooperate and allow the message to say: "Appname wants to 'send pokes' on foo.com, do you want to allow this?" - allowing the app a scoped login to only specific actions.
    - IshKebab 3y ago
      Yeah an edge swipe could work. It would be difficult to introduce but Google doesn't seem to shy away from forcing app developers to make big changes so who knows. Of course a malicious app could still just show a webview and make you type the password in. The above solution would only work if everyone uses a password manager and showing a webview becomes way more suspicious than it is now.

The title is misleading. They've dropped the proposal as applied to Chrome, but are still pursuing it for the Android WebView API, which is basically a wrapper around Chrome.

andybak 3y ago

Webviews are particularly vulnerable though, being used for embedded logins for sometimes dubious 3rd party apps. Is there a reasonable angle to view this from? I personally don't think embedded webviews should be allowed general browsing capability unless they are part of a standalone browser. It's usually a trick to capture traffic that would otherwise go off to the open web.

TremendousJudge 3y ago
If that's the problem you're trying to solve, disallow embedded ~~logins~~ webviews and do it through a proper browser, same as on a regular computer. The other way seems overkill and smells like foul play to me.
- andybak 3y ago
  I'm not sure how you disallow embedded login without disallowing embedded webviews. The line is very blurry.
  - TremendousJudge 3y ago
    I'm sorry, I wrote embedded logins but was thinking embedded webviews in general. The only legitimate use of that in my mind is "a web browser app that's a usability skin over Chrome". Everything else is just a way of keeping you in a walled garden, and would be better if it just sent you to your default browser.
    - andybak 3y ago
      Ok. So I think we are in agreement. I struggle to think of a use case that is in the user's best interests.
  - londons_explore 3y ago
    You have two types of webviews... "Webviews to the appmakers server", and "Webviews for the wider web". Webviews to the appmakers server need to be authorized by some manifest file on the server whitelisting the app identifier. Webviews for the wider web don't allow the app to know what's going on inside the webview, nor interact with it. So these are safe to type passwords into etc.
    - deleted 3y ago
      [deleted]
    - rezonant 3y ago
      So this would have no effect, because you can simply embed Chromium in your app instead of using the system-provided WebView. Because Android is very fragmented and there are still a significant amount of devices out there running less than Android M when the web view was made an upgradeable package, there is, at least for now, a very legitimate reason to ship your own browser implementation within an app that is primarily implemented using web tech: The Web View implementation shipped with M and earlier is not sufficient to run such an application.
- claytongulick 3y ago
  > disallow embedded logins and do it through a proper browser How would you propose doing this from a technical standpoint? How is android supposed to know what an embedded login is on a web page? What happens when you're in an SSO or other secure environment and need to refresh credentials after a redirect?
- Obscurity4340 3y ago
  Is Friendly Social Browser maybe a good solution to this problem?
IshKebab 3y ago
> being used for embedded logins for sometimes dubious 3rd party apps. That's a difficult problem to solve though. To do it properly you'd need something like Windows' secure key sequence (ctrl-alt-del) which apps can't intercept. Otherwise there's no way that a user can know that what they're seeing is the system rather than a malicious app. Consider that any app can embed any browser or UI that they want.
- londons_explore 3y ago
  That exists on mobile though... They could easily have a "swipe down to login" gesture, where you would see some system UI saying "Appname wants your password to foo.com, do you want to allow the app to log in using your saved password?". foo.com could also cooperate and allow the message to say: "Appname wants to 'send pokes' on foo.com, do you want to allow this?" - allowing the app a scoped login to only specific actions.
  - IshKebab 3y ago
    Yeah an edge swipe could work. It would be difficult to introduce but Google doesn't seem to shy away from forcing app developers to make big changes so who knows. Of course a malicious app could still just show a webview and make you type the password in. The above solution would only work if everyone uses a password manager and showing a webview becomes way more suspicious than it is now.