1. 92
    1. 67

      Soon we’ll need Google-approved browsers to access Google’s version of the web. Well played.

      1. 34

        You already do! Try visiting a site using recaptcha from a non-approved browser sometime…

        1. 14

          One can only hope that the US DOJ’s lawsuit against google will result in any real penalties/changes for this, but I’m not holding out too much hope.

        2. 13

          The Chromium-based Edge seems immune to these. I get far fewer requirements to do some mechanical Turk work to classify images for Google’s self-driving cars on Edge on Windows than I do on Safari on Mac, Firefox anywhere, or pre-Chromium Edge on Windows. As @craftyguy says, this is exactly the kind of thing that I hope the DOJ will look at: Subtly making large amounts of the web worse for users unless they use a Google browser seems like the kind of thing that antitrust laws are supposed to prevent.

        3. 2

          Could the browser spoof the user agent to be something Google likes?

          1. 12

            yes totally, but of course this will end up in the usual cat and mouse game where Google will detect the circumvention technique and the circumventers will circumvent the circumvention technique circumvention.

          2. 5

            Isn’t Google trying to kill user agent?

            1. 5

              Yes It’s one of the many great ironies of Google - the Chrome team (along with other major browsers) are trying to kill the User Agent, but the rest of Google UA-sniffs. Exactly the kind of behavior they’re trying to kill the User Agent over.

            2. 2

              that and the address bar too

      2. 6

        Tried to log into my Google account from an OpenBSD laptop in Chrome today. Right creds, just got redirected to “we couldn’t verify that belongs to you”.

    2. 29

      Before jumping on the “don’t be evil eh” bandwagon, here’s what reading the post and the next two emails in the thread would have clarified:

      1. Any browser that meets a series of guidelines (like, not headless, supports JavaScript, not based on Node.js, …) is allowed
      2. There is a header to check in advance, and they did, and WebKit still works (https://lists.webkit.org/pipermail/webkit-dev/2020-November/031606.html)
      3. It looks like this might affect specifically OAuth flows

      This change makes perfect sense to me. I always cringe when an app pops open an embedded browser and asks me to login with Google because:

      1. I have to trust they did not fuck up certificate verification
      2. There is no address bar to check where the hell I’m typing my password into
      3. I am already logged in from my main browser why are you making this harder and less safe for me!

      Disclosure: I work for Google on completely different stuff.

      1. 8

        Yeah, the next message (by thread): [webkit-dev] Starting January 4, 2021, Google will block all sign-ins to Google accounts from embedded browser frameworks:

        Oh, I missed a very important point. There is a header we can use to 
        test: Google-Accounts-Check-OAuth-Login:true. I will try to figure out 
        how to hack up the libsoup backend to send that header with all 
        requests and see what happens....
    3. 21

      Personally, I think this is a good thing, though of course it’s so easily circumventable by apps.

      Whenever I’m in the position where I’m in an app using sign-in-with-some-other-service and it’s showing me an internal web view, I’m usually very anxious about who else is getting access to my password: The makers of the app? The analytics SDK of the makers of the App? The advertising SDK of the makers of the app?

      By forcing the sign-in to work through an external browser, I can be sure (to some extent) that the password will go only to the site itself (barring malware or bad extensions, of course)

      1. 3

        Microsoft has tried it and they failed. And I bet chrome in gmail will not be affected.

        1. 6

          And I bet chrome in gmail will not be affected.

          Oh - I’m sure it won’t. But google can trust their own gmail app.

          Or rather: If you don’t want to give your gmail password to the gmail app because you don’t trust your gmail app with your gmail password, then I don’t see how you could still be able to access gmail through the app.

          Or: If google wants access to your password, it can just take the password you submit through the embedded web view of their own app. It doesn’t need to exfiltrate it using JS injected into their own web view by their own app.

          1. 1

            I was thinking about logging into other google services using chrome embedded into gmail app. But it also makes little sens. Silly me!

    4. 15

      It’s sad that google holds such a monopoly on the web that it has the power to kill minority browsers like this.

      1. 4

        This doesn’t “kill minority browsers”, it limits logins to Google’s own services to browsers considered trustworthy. The attack vector this attempts to mitigate are applications which open an embedded browser window and sniff your credentials. Furthermore, browsers which meet certain guidelines are allowed.

        See FiloSottile’s comment.

        Disclosure: I also work at Google, not on auth, identity or Chrome.

    5. 24

      Brave of Google, to take action where the side-effect is to exclude competitor browsers at a time when they’re under scrutiny for anti-competitive practices

      1. 15

        Silicon Valley has a very friendly relationship with the incoming administration.

    6. 5

      I’m not privy to any of the decisions behind that move but given the tests documented in that thread maybe it’s really only about services using Google accounts doing oauth flows through an embedded browser engine where a native oauth flow should be used instead (and when you’re in the situation to embed a browser you should also be able to add oauth natively)? I guess it could be a measure to reduce the attack surface because native oauth has fewer moving parts than a whole browser engine.

      (Yeah, I work for Google but as said, no idea what this is about, so this is speculation just like everybody else’s)

      1. 4

        I remember someone (Gruber? Arment?) complaining that Apple were strongly suggesting that you should shell out to Safari for OAuth, etc., rather than using the embedded browser - “good for privacy, horrible for UX” - but annoyingly I can’t find it now.

        1. 8

          It is also mentioned in the OAuth specification for “Native Apps”: https://tools.ietf.org/html/rfc8252#section-8.12

          Update: and also part of the OAuth 2.1 draft RFC: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-9.20

          1. 2

            Good reference, thanks!

        2. 5

          Both complained about a similar change to Twitter 9 years ago with approximately that reason: https://marco.org/2011/05/19/twitter-dm-oauth-requirement with a link to Gruber in there.

          The situation was similar: while the clients had no need to store username and password, they had the ability to access them under the old scheme. The difference is that back then they still allowed embedded web views, but as time progresses so does experience and so standards become more strict over the years.

    7. 4

      Is this not anti-competitive behavior!?

    8. 3

      This is very hypocritical considering Google’s own browsers is one of the worst offenders of User-Agent impersonation. This is a User-Agent you might see from it: “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/74.0.3729.169 Chrome/74.0.3729.169 Safari/537.36”.

      This might have additional unintended effects on mail clients as they may open an embedded browser for the OAuth2 dialog.

    9. 3

      They’re really trying hard to lose this anti-trust investigation, aren’t they ?

      1. 2

        Lose. They’re playing fast and loose, unafraid to lose this investigation.

        1. 1

          I’m all for loosening up the relationship between google the search, the SaaS and chrome..

      2. -6

        They’ve won the election. And undoubtedly placed their finger on one of the scales.

        Now is time to reap the rewards.

        EDIT: Clarification. Their candidate won the election.

        1. 6

          Won the election? What are you talking about?

        2. 3

          Lol get that QAnon conspiracy outta here

          1. 2

            I don’t think anything about considering the Democratic party as “Big Tech”‘s choice is anything to do with Qanon, please don’t be part of a force that turns the word Qanon into something meaningless…

            1. 2

              Who in Big Tech has come out as explicitly stating the Democratic party is their choice (as a company, not private individual)? My point in making the statement is that the comment I replied to was just conjecture, conspiracy theory, etc…. Sure, tech/social media plays a big role in politics, but “placed their finger on one of the scales” sounds like they deliberately endorse/favor one side over the other.

              1. 1

                Sure, tech/social media plays a big role in politics, but “placed their finger on one of the scales” sounds like they deliberately endorse/favor one side over the other.

                It’s way simpler than that.

                1. hire moderators in a state where population votes in particular way
                2. when election comes, introduce more rules that encourage more active moderation
                3. observe how one of the sides gets moderated into oblivion

                All of this is an unintended consequence of pretty normal decisions. But boy are they convenient.