Hacker News Reader

Hacker News

Comment by smaddock | Hacker News Reader

Parent Full thread

smaddock

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

[1] https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...

View on HN

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.

> 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.

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.

>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?

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.

Do you need it everywhere? Why can't you just cut off the sellers?

Because of the asymmetry of use. Signing up takes a small amount of human labor, and there's already several sellers of fake accounts who use cheap human labor to create them. If actually sending spam would require human labor too, spamming would not be as desirable.

(For the record: I vehemently disagree with the idea of dictating what browsers are allowed to use an online service.)

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

- Min https://github.com/minbrowser/min/issues/868

- Agregore https://github.com/AgregoreWeb/agregore-browser/issues/65

From what I can tell, it's really any browser not well known by Google.

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.

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.

Google isn't restricting other/embedded browsers from the rest of the internet, Google is restricting them from its own sign-in page.

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.

Even Firefox has experimented with UA spoofing on Android because Google offers a severely downgraded experience even though the browser would technically support the same site that Chrome gets. So in the limited set of a dozen or so extensions for Firefox mobile, there is one that adopts the Google UA... The list was manually selected by Mozilla so you know their opinion on this.

Worth noting that Google's browser, Chrome, spoofs Firefox and Safari.

Are they likely to whitelist Electron (and React Native and other major webapp-as-native-app frameworks)? Or will those apps be forced to boot you out to the browser, and then back to the app?

I think I've already seen one app that did that to me. It was clunky and broke the illusion that the app was native -- though I guess that's a pretty thin illusion anyway.

Does Google provide any non-Web APIs ?

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...

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

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.

Hmm, how it is different from OpenID that Google currently uses?

At least on my Android device, OIDC sign ins are handled by the default browser, not a purpose-built application.

"The intention"

Stated intention. Unless you can read minds.

Reply on news.ycombinator.com