Hacker News Reader

Comment by izacus | Hacker News Reader

I don't know why this is here, because this requirement has been in place for years - e.g. I've hit it at least two years ago where Google OAuth didn't allow builtin old WebKit login anymore.

Instead, you need to call users' default browser (Firefox, Chrome, whatever they have) and it'll return back with the token. Just like OAuth on desktop.

It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.

The utter ignorance in comments here is really depressing, what happened with HN?

View on HN

The writer of this post is the developer of a Webkit-based browser for Linux. Not an email or chat client with an embedded log-in screen—a real, true browser that just so happens to not be named Chrome, Safari, or Firefox. It is the default browser in many Linux distributions.

Yes. And we are all well past the point now where antitrust legislation should be invoked to break Google up. This is another attempt to use one piece of Google to promote another piece of Google.

For context, the author of this mailing list posting is concerned because Epiphany (the default browser in GNOME) uses GtkWebkit, an embedded Webkit browser engine. Presumably, it would be treated like any other unsupported browser.

(Edit: Additional context: in follow-up replies, they seem to have tested it by sending a header to try the changes early, and as of now it doesn’t appear to break things. I have not read the entire thread; folks should check the replies though.)

I guess the easiest solution is to use Firefox User Agent. It's obsolete header after all, isn't it?

...until they introduce browser fingerprinting to prevent such shenanigans. I'm sure they already have the infrastructure/code in place, given that they also run recaptcha.

Funny thing about that. From the article:

> Google says: "The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox." We cannot comply with this because user agent spoofing is required for compatibility with various Google websites.

The author is concerned that Google will become increasingly aggressive about detecting alternate browsers, since it's clearly against the rules and they certainly have the capability.

I think a lot of people are forgetting that Google saying "the browser must not try to impersonate another browser" is a fairly funny part in itself.

Everyone remembers the User-Agent for Chrome starts with "Mozilla/5.0" right? It has always impersonated another browser for compatibility reasons. For so long that we take this for granted now.

Yes, this! Here's my favorite send-up of the history of the User-Agent header (hard to believe it was already 12 years ago(!) when it first made me laugh)

https://webaim.org/blog/user-agent-string-history/comment-pa...

Make sure every alternate browser has accessibility specific features. Then smack them down with the ADA.

Actually, when I was reading Google's blog post, this rule jumped out to me:

> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.

Automating keystrokes and/or clicks could absolutely be necessary for accessibility.

Doesn't Chrome itself provide automation features that are used by integration testing frameworks?

yes it does.

Sounds like they're worried about fake ad clicks.

What does logging into google have to do with fake adclicks?

The ad clickspam system uses the logged in user (or lack of) as a strong signal.

Thanks.

My default browser is one I built, and it hasn't worked with Google auth since they disallowed auth from CEF. Not warned, put captchas in front of, etc but disallowed. Yes the ignorance in HN comments can seem depressing, but I decided to respond to this one anyways.

Yours is very edge case though, and the grandparent is rightly pointing out that the headline is a little misleading and comments are generally negative for a positive aspect.

It's a very important edge case. Every new browser, by definition, starts out as a self-compiled project.

If this happened in the 90s, would we ever have had Mozilla? Would tabbed web browsers exist?

This.

If something can't be accessed by any standards-conforming client, then it isn't the web.

>Yours is very edge case though

Not using google chrome is itself an edge case. That's kinda part-and-parcel with monopolistic predatory behaviors.

One man's edge case is another man's line in the sand.

If you think impersonating another browser's user-agent string for compatabililty reasons as a full fledged "real" browser is an edge case ...

You should remind yourself what the Chrome user-agent string actually is.

Have you checked YOUR user agent? This is rediculous.

I'm interested in this browser code you speak of...as a fledgling browser builder.

https://cretz.github.io/doogie/ - I don't publish prebuilt releases anymore because I don't really work on it anymore, but I build it for myself with the latest CEF every update. There's a bug here and there, but it is by far more productive for me than other browsers.

But user beware, you can't login to any Google account using it since they disallowed it.

This entire post is about legitimate browsers being banned from Google logins. It's really depressing to see quite a few people sidestepping this point entirely and even accusing people of ignorance.

>It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.

Not really. On non-sandboxed platforms (eg. windows or mac) it does nothing because the program already has full access to the operating system. It could very keylog the password as it's being entered into the "real" browser. Regardless of whether it's sandboxed, it could also launch a phoney "real" browser (ie. custom build of firefox/chrome that has keylogging logic built into the browser itself), and keylog using that. I'm not sure how that can be detected.

"It's much, much safer, because the app can't see orhjack the process - it doesn't get access to the login form and can't phish you with it."

What if you are the author of the "app" and its sole user?

> whatever they have

That's what is being threatened, other browsers. Google is throwing its weight around to try and enforce browser standards that are bad for a lot of people. Just like with amp.

> It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.

Apps that try this shouldn't be running on your computer. This is not much safer, it's negligibly safer with a significant cost.

> The utter ignorance in comments here is really depressing, what happened with HN?

The irony.

> That's what is being threatened, other browsers.

Is it? Oauth regularly opens Safari on mobile and Firefox on OS X for me; it's not clear that this move itself is forcing users to chrome per se.

If they're blocking non-popular browsers, that's obviously a problem. But if they'll let users open Firefox or Safari, then it seems fairly obvious to me that this is a mistake more than a sinister plan to drive Chrome adoption forward. After all, if they were trying to drive Chrome forward why would they push me more towards Safari?

Reply on news.ycombinator.com