Hacker News new | ask | show | jobs
by eivarv 1977 days ago
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."
2 comments

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?