A more precise wording might be "... Google also blocks anything that's implemented in an embedded framework (e.g. CEF, webviews) and does not use browser-based OAuth authentication."

The problem is a web browser is arguably something which has a webview in it. The difference Google considers between "a browser" and "an app embedding a webview" is whether that app is specifically Chrome, Firefox, Edge, Safari, or IE.

There is another, arguably legitimate differentiating feature:

How up to date the embedded web engine is (and how quickly you would be able to merge upstream changes, update the framework, wait for "browsers" implemented using the embedded framework to update their dependencies, etc.) That can be a pretty big deal when there's a fix for a high-impact vulnerability.

There's another security consideration here: whether you trust the webview not to peek at your https content.

With a known browser, you get reasonable guarantees that TLS is being handled properly. With an unknown browser, these guarantees are gone. Considering the average person has no idea what https/TLS is, banning all unknown browsers as a defense against phishing seems completely reasonable.

HTTPS isn't even the largest concern - it's the browser being some malicious app asking to 'sign in to Google to load your profile' and stealing either the password or auth token.

What's frustrating (and clearly anti-competitive) is that Google thinks this is a problem enough to justify this, but refuses to ban browser extensions that utilize permissions broad enough to allow them to do this in Chrome directly. Browser extensions can generally collect everything on web sites and that you enter into websites, and has access after all TLS decryption has occurred.

For the most part, if a browser's extension store isn't in order, everything else they claim to do to secure web traffic is kinda a joke.

That's not correct, as Konqueror and Falkon browsers are also blocked.

I'm just summarizing what the linked article actually says.

As for your examples, Konqueror and Falkon might be blocked because they use Qt WebEngine – which embeds Blink in the Qt framework [0].

[0]: https://en.wikipedia.org/wiki/Blink_(browser_engine)#Framewo...

Nice for Google to block the project that wrote the origins of their browser engine.

> Nice for Google to block the project that wrote the origins of their browser engine.

In this case it's blocking the embedded Blink, which is their browser engine, so at least they're consistent?

Yeah, Blink, which is a fork from Safaris WebKit, which is a fork of Konquerors KHTML. Google Chrome wouldn't exist today if it wasn't for Konqueror.

yes, that's what the "consistent" was referring to...

The Qt project didn't write the origins of Google's browser engine.

Blink forked from Webkit, which started as a fork of the KHTML and KJS libraries from KDE. Many KDE-projects are built upon Qt, but Qt is an independent project.

I think they are talking about Konqueror, not QT. Konqueror is what KHTML was developed for, iirc.

Ah, right. Thanks!

KDE-projects like Konqueror and Falkon, the subjects under specific discussion?

It's pretty warranted when this is the type of attack possible:

https://news.ycombinator.com/item?id=25717156

See the comments for a summary and why the submission was flagged.

It's also a glaring ADA violation.

"We're perfectly accessible as long as you switch web browsers to the one we make" is probably not going to cut it by ADA standards if someone pushes hard enough. Chrome isn't a 1:1 drop-in replacement, and it may not be available on some devices.

Sorry to go off-topic slightly, but can any INFOSEC people confirm that this idea below makes any sense? The conventional thinking, as far as I am aware, has always been that JavaScript increases your attack vector and diminishes your security coverage.

> Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

I think they're looking at two different notions of security: security of Google's services against bots (which is probably what Google is trying to check with Javascript), and security of users' browsers against malware (which is an attack surface that can be limited by turning off Javascript).

It might be like thinking about whether a "TSA lock" increases security. One might say that it increases security because it allows TSA to check the contents of people's belongings more easily, or that it decreases security because it can allow anyone with brief physical access to a bag to steal its contents.

Edit: the sibling comment also points out a likely use about recognizing your own devices. If you let Google spy on you more, it can more accurately determine what is usual or unusual for you, in order to distinguish you from an impersonator. You might also not want Google or others to have this information.

Dirty little secret: when software vendors speak, they will frequently blur the purpose of a given security measure and who, exactly, it protects.

This measure helps protect Google. And much like a politician stretching the definition of the national interest to include themselves, Google might say that they're protecting you by protecting themselves.

If Google can use this to rate limit sign-ins more effectively, then it does protect users, since the limiting factor on password security is time to crack.

I want the ability to change these types of settings for my account. They can be buried in an advanced menu somewhere.

I have a password manager. My Google password is a long, unique string of random characters that I don't use on any other service. If someone does break into my Google account, it will be because they broke into my password manager and/or successfully phished me (or hit me on the head with a $5 wrench). Number of retries will have nothing to do with it, unless they have a computer from the future.

I am much more concerned about Google locking me out of my account some day in an attempt to stop someone from breaking in, then I am about someone else actually breaking in.

Upvoted for the subtle xkcd reference :)

There's probably more here, but one thing I can think of is fingerprinting the client as part of the automated risk assessment, deciding whether and when to block attempts, trigger MFA, and recognize specific devices (and potentially tie them to specific users for whatever reason).

You are correct. This is just for Google's benefit, as you can imagine. They are Google, after all.

Phishing is accessible to anyone with basic web development skills, while JavaScript sandbox escapes for major browsers are the domain of pretty sophisticated actors.