(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.)
> 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.
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.
https://webaim.org/blog/user-agent-string-history/comment-pa...
> 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.
But user beware, you can't login to any Google account using it since they disallowed it.
If this happened in the 90s, would we ever have had Mozilla? Would tabbed web browsers exist?
If something can't be accessed by any standards-conforming client, then it isn't the web.
You should remind yourself what the Chrome user-agent string actually is.
Not using google chrome is itself an edge case. That's kinda part-and-parcel with monopolistic predatory behaviors.
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.
macOS might be a little more secure post-Catalina; the user would have to grant additional permissions to the malicious app. Of course, a lot of apps legitimately need those permissions, so it wouldn't be so odd to request them.
What if you are the author of the "app" and its sole user?
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.
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?
It makes sense really - an operator can maybe write 60 posts an hour, which means it only costs a few hundred bucks a day to have 10% mindshare on all of HN.
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?