7 ms·

With measures like this, Google is actively preventing new, independent browsers from ever scaling on their own. Want to sign in to Google? Use one of the sele

With measures like this, Google is actively preventing new, independent browsers from ever scaling on their own. Want to sign in to Google? Use one of the selected browsers with a significant, existing market share. But first though, are you actually human? Let's see if your browser is compatible with our reCAPTCHA service. [0] Oh, you wanted to watch something on Netflix? I hope your browser is approved by Google for DRM playback. [1] [0] https://twitter.com/bcrypt/status/1320410639244746753 https://twitter.com/bcrypt/status/1320410639244746753 [1] https://blog.samuelmaddock.com/posts/the-end-of-indie-web-browsers/ https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...

varenc 6y ago
The intention here is that users don’t enter their password into an embedded web view where the host application can inject JS or otherwise sniff the password/session cookie. (or just phish them). That’s a good thing. A new standalone browser should be a separate case. Hopefully. In an ideal world the Android/iOS framework would enforce that an insecure embedded webview has a distinguishing User-Agent or some other tell that Google can check. A standalone browser wouldn’t have that and in theory wouldn’t be caught up by Google’s enforcement of this. That’s how it should work, but it unclear to me if that’ll actually happen.
- ashneo76 6y ago
  This is not a security feature. This is smoke and mirrors. If it was really about securing the web, Google would made IETF and W3C recommendations, instead of trying to kill competition. This is strictly market grabbing and anti competitive
  - deleted 6y ago
    [deleted]
- cma 6y ago
  "The intention" Stated intention. Unless you can read minds.
- coolreader18 6y ago
  > A new standalone browser should be a separate case. Right, but what are the chances google will allow people to sign up with their own user agent with their new browser engine? Or even if that was a feasible thing for them to do, why should _they_ be able to gatekeep that? The security argument is valid, but there should be some web standard or something to address that, not google deciding who gets to read their email depending on the browser they use.
  - thu2111 6y ago
    It's tricky. Although this is being justified with references to phishing (which may well be the case) it's also an issue for spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments. If you think about it, you'll quickly end up in a briar patch of confusion over what exactly the definition of a "browser" is. Google have attempted to provide a definition here which is better than most, but it's basically a subtractive definition. A browser is a thing that supports "modern web standards" whilst not supporting automation features. OK. What about extensions? The intent is to ensure that only people can sign in when they understand which site they're on. If anyone can define any program as a browser you can't enforce that and would have to allow unlimited automation of web sites. That is too hard to do, purely server side content analysis algorithms don't get you far enough, hence CAPTCHAs and now this JavaScript based enforcement.
    - Thorrez 6y ago
      >spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments. Wouldn't sign up be a better enforcement point than sign in?
      - thu2111 6y ago
        The same system is enforced on sign up too, but the spam market is split between account creators/sellers and account users. So you need it everywhere.
        6y ago
- smaddock 6y ago
  The issue also affects Electron-based browsers, something I wouldn't consider "embedded". These are a few browsers affected off the top of my head: - Beaker https://github.com/beakerbrowser/beaker/issues/1749 https://github.com/beakerbrowser/beaker/issues/1749 - Min https://github.com/minbrowser/min/issues/868 https://github.com/minbrowser/min/issues/868 - Agregore https://github.com/AgregoreWeb/agregore-browser/issues/65 https://github.com/AgregoreWeb/agregore-browser/issues/65 From what I can tell, it's really any browser not well known by Google.
  - disgruntledphd2 6y ago
    The actual problem seems to be the UA string requirement (from the OP, at least). If he removes the UA spoofing, all Google sites break because Google use this to determine if they run their services (which is incredibly weird to me). If he doesn't, then his browser is banned. Somewhat of a double bind. The most charitable explanation here is that Google is a megacorp now, and the right hand and left hand are on different continents and aren't aware of each others existence.
    - smaddock 6y ago
      You're right that the issue described in the OP is more specific. However, I believe its a symptom of the larger, underlying problem. Google shouldn't wield the power to decide which browsers are worthy enough to access the larger internet they have control over. It's antithetical to the open web.
      - AgentME 6y ago
        Google isn't restricting other/embedded browsers from the rest of the internet, Google is restricting them from its own sign-in page.
        rrobukef 6y ago
        Google literally has the keys to a kingdom. Should Google's box ever be opened, countries will burn. Let's face it, the definition of a monopoly is insufficient on a global scale. Merely restricting their own sign-in service impacts over 1.5 billion people. Of course, most are unaffected.
- jsiepkes 6y ago
  ChromeOS also lets you sign-in into Google via an embedded browser view when you login to the device. Though I guess Google will probably exempt themselves from this policy...
- l3s2d 6y ago
  In an ideal world we would have settled on an authentication protocol which everyone could support. Something like "oidc://idp-url" which the OS could have a built-in handler for.
  - BlueTemplar 6y ago
    Hmm, how it is different from OpenID that Google currently uses?
    - l3s2d 6y ago
      At least on my Android device, OIDC sign ins are handled by the default browser, not a purpose-built application.

varenc 6y ago

The intention here is that users don’t enter their password into an embedded web view where the host application can inject JS or otherwise sniff the password/session cookie. (or just phish them). That’s a good thing. A new standalone browser should be a separate case. Hopefully. In an ideal world the Android/iOS framework would enforce that an insecure embedded webview has a distinguishing User-Agent or some other tell that Google can check. A standalone browser wouldn’t have that and in theory wouldn’t be caught up by Google’s enforcement of this. That’s how it should work, but it unclear to me if that’ll actually happen.

ashneo76 6y ago
This is not a security feature. This is smoke and mirrors. If it was really about securing the web, Google would made IETF and W3C recommendations, instead of trying to kill competition. This is strictly market grabbing and anti competitive
- deleted 6y ago
  [deleted]
cma 6y ago
"The intention" Stated intention. Unless you can read minds.
coolreader18 6y ago
> A new standalone browser should be a separate case. Right, but what are the chances google will allow people to sign up with their own user agent with their new browser engine? Or even if that was a feasible thing for them to do, why should _they_ be able to gatekeep that? The security argument is valid, but there should be some web standard or something to address that, not google deciding who gets to read their email depending on the browser they use.
- thu2111 6y ago
  It's tricky. Although this is being justified with references to phishing (which may well be the case) it's also an issue for spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments. If you think about it, you'll quickly end up in a briar patch of confusion over what exactly the definition of a "browser" is. Google have attempted to provide a definition here which is better than most, but it's basically a subtractive definition. A browser is a thing that supports "modern web standards" whilst not supporting automation features. OK. What about extensions? The intent is to ensure that only people can sign in when they understand which site they're on. If anyone can define any program as a browser you can't enforce that and would have to allow unlimited automation of web sites. That is too hard to do, purely server side content analysis algorithms don't get you far enough, hence CAPTCHAs and now this JavaScript based enforcement.
  - Thorrez 6y ago
    >spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments. Wouldn't sign up be a better enforcement point than sign in?
    - thu2111 6y ago
      The same system is enforced on sign up too, but the spam market is split between account creators/sellers and account users. So you need it everywhere.
      - 6y ago
smaddock 6y ago
The issue also affects Electron-based browsers, something I wouldn't consider "embedded". These are a few browsers affected off the top of my head: - Beaker https://github.com/beakerbrowser/beaker/issues/1749 https://github.com/beakerbrowser/beaker/issues/1749 - Min https://github.com/minbrowser/min/issues/868 https://github.com/minbrowser/min/issues/868 - Agregore https://github.com/AgregoreWeb/agregore-browser/issues/65 https://github.com/AgregoreWeb/agregore-browser/issues/65 From what I can tell, it's really any browser not well known by Google.
- disgruntledphd2 6y ago
  The actual problem seems to be the UA string requirement (from the OP, at least). If he removes the UA spoofing, all Google sites break because Google use this to determine if they run their services (which is incredibly weird to me). If he doesn't, then his browser is banned. Somewhat of a double bind. The most charitable explanation here is that Google is a megacorp now, and the right hand and left hand are on different continents and aren't aware of each others existence.
  - smaddock 6y ago
    You're right that the issue described in the OP is more specific. However, I believe its a symptom of the larger, underlying problem. Google shouldn't wield the power to decide which browsers are worthy enough to access the larger internet they have control over. It's antithetical to the open web.
    - AgentME 6y ago
      Google isn't restricting other/embedded browsers from the rest of the internet, Google is restricting them from its own sign-in page.
      - rrobukef 6y ago
        Google literally has the keys to a kingdom. Should Google's box ever be opened, countries will burn. Let's face it, the definition of a monopoly is insufficient on a global scale. Merely restricting their own sign-in service impacts over 1.5 billion people. Of course, most are unaffected.
jsiepkes 6y ago
ChromeOS also lets you sign-in into Google via an embedded browser view when you login to the device. Though I guess Google will probably exempt themselves from this policy...
l3s2d 6y ago
In an ideal world we would have settled on an authentication protocol which everyone could support. Something like "oidc://idp-url" which the OS could have a built-in handler for.
- BlueTemplar 6y ago
  Hmm, how it is different from OpenID that Google currently uses?
  - l3s2d 6y ago
    At least on my Android device, OIDC sign ins are handled by the default browser, not a purpose-built application.