"The browser must not proxy or alter the network communication. Your browser must not do any of the following:
* Rewrite HTTP headers
The browser must have a reasonably complete implementation of web standards and browser features. You must confirm that your browser does not contain any of the following:
* Headless browsers
* Text-based browsers"
Sure, I see the "increased security" goal of protecting HTTP headers and allowing images and Javascript in the context of the "sign in" process that Google has implemented. However I also see the goal of not impeding Google's online ad services business which, at least in part, relies on images, Javascript and blocking automation after the user signs in.
I fail to see the benefits of these requirements outside of Google's sign-in process.
HN does not impose such restrictions. It is no less useful than Google, IMO. Imagine if HN required "a reasonably complete implementation of web standards and browser features" just to sign in.
I once read that Marissa Mayer, former Google VP, still uses Pine.
Bias disclosure: I am a text-only browser user; I prefer text-only software.
Even worse when the embedded web view is not properly detecting the user-agent and puts up a banner... prompting you to download the app (looking at you, NHL).
yeah and in the case of Fairemail on Android, the embedded browser is dumbed-down and lacking most features... and the option to disable this "feature" is kind of hard to find
This is regarding man-in-the-middle attacks. There is not attack on Lynx. Many sites do not functionin without JavaScript. Sad, but that's the way it is.
I feel like detecting these environments is directly at odds with user privacy and anti-tracking; but I guess google has never been anti-tracking, so that's not too surprising. Still, I'm incredibly disappointed that they'd essentially require clients be fingerprintable to auth. I feel like this is just codifying an arms race between strengthening requirements and JS environment checks, and hostile embedders ability to emulate a real runtime, and taking legitimate embedders with less incentive to participate in the race down as collateral damage.
This has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others; from the post:
> The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
Edit:
I feel like mentioning youtube-dl was a mistake. It's not just about youtube-dl.
This policy bars the use of all text-based browsers, headless browsers, browsers without javascript, and browsers with automation when accessing Google's services. It bans browsers that contain Node.js, even.
> The browser must identify itself clearly in the User-Agent.
I wonder what they'd think of my proxy which I have setup to (among other privacy respecting features) rewrite the User-Agent to "By allowing me access, you waive all rights and policies regarding my access." This is basically my form of EULA.
> The browser must not provide automation features.
LOL. This was obviously written by some tech illiterate law type, perhaps a first year law student? I fear to think what incompetent engineer working at google of all places would have come up with that verbiage . . .
> To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021.
(emphasis mine)
So I don't follow how this would have anything to do with banning youtube-dl, which doesn't require login? And as the blog post mentions, you can still bootstrap auth through a normal web browser, and pass the auth token to your command line / less secure browser / ... app.
(Disclaimer: I work at Google, not on anything related to this blog post or to your hypothetical scenario.)
Well I guess my unofficial YouTube chat bot won't work anymore. The YouTube API is awful compared to the Twitch one for bot creation so it is easier to get the functionality you want using Selenium.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
If a web developer knows what they are doing they are using the standard web APIs supplied by the browser in an efficient way, designed to be invisible to accessibility for accessibility test automation, and thus this control from Google is largely unenforceable. As such I believe this is just a block against incompetent forms of automation that probably shouldn't be there in the first place.
The whole premise is a mistake, not the mention of youtube-dl. This policy doesn't ban the the things you claim it does. It is not 'everything to do with banning wget'. It's just a strange and mistaken conclusion you arrived at, seemingly by very selective reading.
Once upon a time Google would've been applauded for forcing people to improve their security. Like when they made https a ranking factor for sites and overnight forced all the laggards to move off http.
Now, people just scream "monopoly" at everything google does, good or bad and boy is it getting tedious.
Most of these controls are a blessing. They are blocking gross incompetence from front-end developers who don't know ow to do their jobs. I say this as a front-end developer.
If browsers which does "server-side rendering" are blocked from accessing my Google Account, I lose my access to all Google services requiring sign-in like Gmail etc.
I don't have the privilege to own a desktop, laptop, or even smartphone. I am using a J2ME enabled feature phone with Opera Mini to access the internet. Most websites requiring "modern browsers" are out of reach from me. Thanks to all the people who maintain the websites that are functional without JS or upto ES5.1 (last JS version supported by Opera's server rendering powered by Presto) or less. Only Google Search and Gmail works in Opera Mini, other Google services don't.
Rent a vps and run WRP [0] on it. WRP is basically a proxy that use chromium and render the pages as imagemap html pages that compatible with older/simpler browsers. It should works on opera mini. Hopefully google won't block it outright.
It meshes nicely for Google, because they want to use feature detection to detect whether you're using a Google-approved browser and not a competitor's unapproved browser.
This is why they state that JavaScript must be enabled, because that's how they do feature detection:
> The browser must have a reasonably complete implementation of web standards and browser features. You must confirm that your browser does not contain any of the following:
The only reason chrome isn’t mandatory is that there are still a few hold out browsers they can’t force out of the market.
Also, the requirement that the browser not lie about its identity in the UA means that the existing UA tests that google properties deploy everywhere means that those “acceptable” browsers may still be “accidentally” blocked.
It would be nice if people would start to acknowledge that chrome is the new IE and Google is the new MS.
Actually arguably worse: in addition to using free services subsidized by their primary advertising business. Once that business is gone they start charging.
All the while they grossly destroy user privacy, and come up with new specs that just happen to accidentally make tracking users easier. Generally poorly thought out ones to help single teams at google without any thought of what the general problem is.
Welcome to Google's private World Wide Web. Please ensure that you use the one and only official Google WWW client (others exist, but they are just for show). Unauthorized alteration of its configured operation will result in user termination.
One might wonder how that can accompany all the talk about open standards, and multitude of devices implementing different subsets, and responsive/adaptive/semantic design, etc. Then you realize that you don't really need, say, user-agent sniffing if you are already in position to dictate what browsers will and will not do, so into the trash it goes. You don't need interoperability hacks if you've stopped having interoperability problems.
Not much. If you're not using app passwords and your client wants to authenticate using Google auth (e.g. Thunderbird), it has to open the user's browser and setup the oauth flows instead of embedding the browser directly in the app.
It was recently (Oct 8) announced that that Google would provide a 12-month heads-up for stopping less secure app access, so it's my understanding that IMAP is not affected at this point.
I fail to see how they can possibly do this in a way that isn't trivially worked around by just embedding the same code as the full browser.
I guess their best bets are detecting non-fullscreen screen sizes on mobile, requiring Widevine or requiring Chrome and adding some proprietary authentication code, but all these are problematic and can be worked around.
Also of course both Firefox and Chrome support automation via WebDriver and WebExtensions so not quite sure what they plan to do with "The browser must not provide automation features".
However, if just to login in some application, it would be awful UX if going to the login step in an application triggers an unwanted load of 3 desktops full of 20 browser windows and a few hundred tabs, and some minutes delay while they all start up.
So if I'm not already running the "full browser" required for auth, ideally for authentication I'm going to want it to launch an "alternate profile" instance of my full browser which doesn't include all the other tabs or normal user info.
I.e. the browser should somehow be able to load just one special window for this application, and remember that it hasn't actually loaded my regular profile and saved state yet.
Clicking on any links for info that is logically "outside the application", that's what should probably lead to a regular full browser being started.
In the end, this ideal browser behaviour in response to an application requesting Google auth is much the same as using an embedded web view - except running separately from the application for security purposes so that it's UI isn't subject to application interference.
Given that's just a web view with security properties, why not instead allow auth to launch a "security instance" version of an embedded web view, one that is subject to guarantees from the OS/GUI security systems that it is running independently from the application which triggered its launch?
On Android, there's a feature called Chrome Custom Tabs (despite the name, it works with other browsers as well) which basically opens the default browser window in a restricted UI without most of the chrome and tabs. It shares the state and extensions though and it's meant as a replacement for these exact banned flows (on Android, webview logins are banned for years now).
I wonder if such interface could be exposed for desktop browsers.
If you don't like that google does this: stop using their products. Make the effort to choose, use and promote a service you think is doing a better job. If you so deem it necessary, tell Google why you're switching.
If people actually did something instead of just complain, companies like this would think pretty hard about their actions since it would harm their bottom line.
Same here. It's like I made a sharp, long-term investment. As the months pass, I enjoy the payoff: watching Google get worse and worse without it touching my life.
Google is becoming increasingly user-hostile, which is the wrong business phase to be in while your competition is on the rise. Other email providers are (finally!) getting almost as good as Gmail. Bing is an okay substitute for Google Search. YouTube has been strangled by subservience to advertisers and people are moving to Twitch and other places.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
So... banning password managers? I’m not seeing how that’ll improve security.
Also, I wonder how they plan to enforce this. Presumably impacted browsers will just spoof the user agent, etc.
Haven't heard of any large scale phishing operations on CEF/Electron/whatever apps. Then again I'm not keeping up with infosec news. Are they a big problem?
I wonder what is the plan for MFP to email scanning. There's a potential of bricking hardware in this case (or not using Google Workspace, formerly knows as G Suite).
Disabling less secure apps has been postponed though because of covid.
So, uh, does this mean I won't be able to use IMAP with Gmail anymore...? It already complains at me about this for being less secure than webmail, but that doesn't seem to be covered in this announcement.
They need non-Chrome browsers to exist, to avoid accusations of a monopoly. Chromium is arguably a strategy around this, where you can have a bunch of browsers using the same (Google controlled) infrastructure.
Safari is an exception, since Apple won't accept giving that up in their products.
>Next step: The browser must not be anything but Chrome.
It seems like that'd be difficult without somehow dealing with Apple first, maybe by getting the government to force them to allow Chrome. Which could happen. Some of the "antitrust" stuff getting tossed around is already starting to get exploited by entities like advertisers, and not just big ones like Facebook, there were those EU ones recently. Like all power, Apple's focusing of its user's collective power can be used not just for bad stuff but for very good stuff as well. But that nuance doesn't seem to be present in a lot of the last year's discussions, and of course lobbyists will use the opportunity if they can.
Without that though or another big disruptive shift Apple misses, can even Google afford to give up on the entire iOS market? Even the Mac market perhaps, if Apple really wanted to push back against Google there they've certainly got the potential capability.
Restricting to just Chrome/Safari(Apple webkit) would still be really bad though. Even if they still allow Firefox, that would further formalize just 3 browsers with minimal further experimentation still possible. That'd be a real shame.
No way. (Theoretically on Android, but let's be real, they won't).
No way they are giving up marketshare on Safari or on corporate boxes with IE. They've paid so much to get onto iPhones, there's not a chance they'd risk any marketshare erosion.
This is pretty much the current step already, not the next step, with broad ban on anything that isn't a lot like Chrome and anything that they simply don't want to allow. In the last thread the narrative was hijacked with bullshit "security" justification, while in the blog post they ban much more broadly, any automation, text-based browsers, etc.
Somewhat unrelated, but Google already blocks me from my account all the time because they don't recognize my device because of privacy settings in my browser... they need a lesson about fingerprinting I guess.
I really dislike this notion of many internet companies of their own self-importance. To me the obvious example is a website that requires you to set up a very strong password and link a phone number. A user account is a two way street, the website should give you the tools for good protection, and you should use them if it matters. If it doesn't matter to me let me use a weak password. If it doesn't matter to me let someone hack my account, what do I care. And if the user doesn't care why does the website owner? Why should hackernews care more about my user account than myself for example? It could be argued this position of security maximalism is due to cutting costs on customer support, for account recovery, but as I understand it Google doesn't have customer support already.
Frankly, this is just wrong. Maybe for some circumstances, but in Google's case, they provide email.
When it comes to things like email, your account being compromised doesn't just affect you. Google let people send out emails from those accounts, so if a compromised account is used for spam, it hurts them reputationally as they are actively facilitating harm.
You might not care if that account is compromised, but they should.
1. Many uses are not computer experts and don’t realize they’re at risk. They won’t adopt extra security measures unless they need to.
2. No company wants to announce that a bunch of accounts were hacked. The excuse that “our users don’t care” would be widely criticized.
3. Well yes, of course companies want to reduce customer support costs, but guess who else benefits from not needing customer support? The customers. It’s better to avoid a problem in the first place than to have great mechanisms for resolving it.
Denvercoder9|5 years ago
1vuio0pswjnm7|5 years ago
HN does not impose such restrictions. It is no less useful than Google, IMO. Imagine if HN required "a reasonably complete implementation of web standards and browser features" just to sign in.
I once read that Marissa Mayer, former Google VP, still uses Pine.
Bias disclosure: I am a text-only browser user; I prefer text-only software.
kwijibob|5 years ago
Just launch me to my preferred real browser.
Stop trying to trap us in your ecosystem.
tinus_hn|5 years ago
jakelazaroff|5 years ago
athenot|5 years ago
vaccinator|5 years ago
Aldipower|5 years ago
> The browser must have JavaScript enabled.
> You must confirm that your browser does not contain any of the following: > * Text-based browsers
Once upon a time the internet was TCP with things like FTP, Email, Newsgroups, IRC and yes also HTTP (aka WWW).
Now, the internet seems to be Google, Apple, Facebook aaand SEO.
Hey, wait! There is a small shiny place!! Hackernews! :)
forgotmypw17|5 years ago
Google is leaving the web behind, doing its own thing.
That is fine.
Enginerrrd|5 years ago
gitweb|5 years ago
wwwigham|5 years ago
dleslie|5 years ago
> The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
Edit:
I feel like mentioning youtube-dl was a mistake. It's not just about youtube-dl.
This policy bars the use of all text-based browsers, headless browsers, browsers without javascript, and browsers with automation when accessing Google's services. It bans browsers that contain Node.js, even.
npsimons|5 years ago
I wonder what they'd think of my proxy which I have setup to (among other privacy respecting features) rewrite the User-Agent to "By allowing me access, you waive all rights and policies regarding my access." This is basically my form of EULA.
> The browser must not provide automation features.
LOL. This was obviously written by some tech illiterate law type, perhaps a first year law student? I fear to think what incompetent engineer working at google of all places would have come up with that verbiage . . .
delroth|5 years ago
(emphasis mine)
So I don't follow how this would have anything to do with banning youtube-dl, which doesn't require login? And as the blog post mentions, you can still bootstrap auth through a normal web browser, and pass the auth token to your command line / less secure browser / ... app.
(Disclaimer: I work at Google, not on anything related to this blog post or to your hypothetical scenario.)
userbinator|5 years ago
Google wants to take over the Internet. We should not let it use these "less secure" excuses to sway the public opinion.
throwaway09223|5 years ago
It would be interesting to see this examined in the context of accessibility requirements created by the ADA.
InfiniteRand|5 years ago
I mean Chrome doesn't clearly identify itself as Chrome, it still identifies itself as Apple Webkit
worldmerge|5 years ago
scrollaway|5 years ago
austincheney|5 years ago
If a web developer knows what they are doing they are using the standard web APIs supplied by the browser in an efficient way, designed to be invisible to accessibility for accessibility test automation, and thus this control from Google is largely unenforceable. As such I believe this is just a block against incompetent forms of automation that probably shouldn't be there in the first place.
DevKoala|5 years ago
kevindong|5 years ago
> ...Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021
It says nothing about non-login related actions.
pvg|5 years ago
u801e|5 years ago
Exactly. What's insecure about an application that can establish a secure connection using an accepted version of TLS and cipher?
mrjin|5 years ago
suifbwish|5 years ago
nojito|5 years ago
There is currently millions -> hundreds of millions being made by scraping Google content.
heavyset_go|5 years ago
dageshi|5 years ago
Now, people just scream "monopoly" at everything google does, good or bad and boy is it getting tedious.
austincheney|5 years ago
cm2187|5 years ago
smlckz|5 years ago
I don't have the privilege to own a desktop, laptop, or even smartphone. I am using a J2ME enabled feature phone with Opera Mini to access the internet. Most websites requiring "modern browsers" are out of reach from me. Thanks to all the people who maintain the websites that are functional without JS or upto ES5.1 (last JS version supported by Opera's server rendering powered by Presto) or less. Only Google Search and Gmail works in Opera Mini, other Google services don't.
So I am out of luck! Anyone out of luck like me?
neurostimulant|5 years ago
[0] https://github.com/tenox7/wrp
ashneo76|5 years ago
forgotmypw17|5 years ago
akersten|5 years ago
Ok, so no password managers that auto-fill your password (like the one built-in to Chrome)? This guidance is not well-thought-out.
etaioinshrdlu|5 years ago
heavyset_go|5 years ago
This is why they state that JavaScript must be enabled, because that's how they do feature detection:
> The browser must have JavaScript enabled.
mleonhard|5 years ago
Won't this exclude automated testing? How will app developers test their "Sign-In with Google" integrations?
> Your browser must not do any of the following: Server-side rendering
Won't this exclude Kindle users and folks in poor countries that have underpowered phones?
lxe|5 years ago
olliej|5 years ago
Also, the requirement that the browser not lie about its identity in the UA means that the existing UA tests that google properties deploy everywhere means that those “acceptable” browsers may still be “accidentally” blocked.
It would be nice if people would start to acknowledge that chrome is the new IE and Google is the new MS.
Actually arguably worse: in addition to using free services subsidized by their primary advertising business. Once that business is gone they start charging.
All the while they grossly destroy user privacy, and come up with new specs that just happen to accidentally make tracking users easier. Generally poorly thought out ones to help single teams at google without any thought of what the general problem is.
ogurechny|5 years ago
One might wonder how that can accompany all the talk about open standards, and multitude of devices implementing different subsets, and responsive/adaptive/semantic design, etc. Then you realize that you don't really need, say, user-agent sniffing if you are already in position to dictate what browsers will and will not do, so into the trash it goes. You don't need interoperability hacks if you've stopped having interoperability problems.
cookiengineer|5 years ago
We've been there before, haven't we?
ashneo76|5 years ago
jhasse|5 years ago
gtirloni|5 years ago
d99kris|5 years ago
https://workspaceupdates.googleblog.com/2020/03/less-secure-...
edoceo|5 years ago
There was some noise from the PHP group because the imap_* functions don't do XOAUTH2 (but Net_IMAP and Zend IMAP libs do the trick)
duskwuff|5 years ago
devit|5 years ago
I guess their best bets are detecting non-fullscreen screen sizes on mobile, requiring Widevine or requiring Chrome and adding some proprietary authentication code, but all these are problematic and can be worked around.
Also of course both Firefox and Chrome support automation via WebDriver and WebExtensions so not quite sure what they plan to do with "The browser must not provide automation features".
jlokier|5 years ago
However, if just to login in some application, it would be awful UX if going to the login step in an application triggers an unwanted load of 3 desktops full of 20 browser windows and a few hundred tabs, and some minutes delay while they all start up.
So if I'm not already running the "full browser" required for auth, ideally for authentication I'm going to want it to launch an "alternate profile" instance of my full browser which doesn't include all the other tabs or normal user info.
I.e. the browser should somehow be able to load just one special window for this application, and remember that it hasn't actually loaded my regular profile and saved state yet.
Clicking on any links for info that is logically "outside the application", that's what should probably lead to a regular full browser being started.
In the end, this ideal browser behaviour in response to an application requesting Google auth is much the same as using an embedded web view - except running separately from the application for security purposes so that it's UI isn't subject to application interference.
Given that's just a web view with security properties, why not instead allow auth to launch a "security instance" version of an embedded web view, one that is subject to guarantees from the OS/GUI security systems that it is running independently from the application which triggered its launch?
izacus|5 years ago
I wonder if such interface could be exposed for desktop browsers.
LockAndLol|5 years ago
If people actually did something instead of just complain, companies like this would think pretty hard about their actions since it would harm their bottom line.
swiley|5 years ago
uniqueid|5 years ago
phendrenad2|5 years ago
hedora|5 years ago
So... banning password managers? I’m not seeing how that’ll improve security.
Also, I wonder how they plan to enforce this. Presumably impacted browsers will just spoof the user agent, etc.
indymike|5 years ago
jka|5 years ago
And if so, can that be solved by the proposed approach of gradually narrowing the requirements for supported clients?
mekkkkkk|5 years ago
ratiolat|5 years ago
Disabling less secure apps has been postponed though because of covid.
Sniffnoy|5 years ago
0xy|5 years ago
Unless you're Google and you need to bolt on X-Client-Data headers in all requests made to DoubleClick, of course.
haunter|5 years ago
tinus_hn|5 years ago
hedora|5 years ago
Sadly, no.
I’d happily set my user agent string to Mozilla 1.0 if it stopped all that stuff from working.
forgotmypw17|5 years ago
unixsheikh|5 years ago
cannedslime|5 years ago
skee0083|5 years ago
[deleted]
ivanche|5 years ago
[deleted]
maest|5 years ago
Safari is an exception, since Apple won't accept giving that up in their products.
xoa|5 years ago
It seems like that'd be difficult without somehow dealing with Apple first, maybe by getting the government to force them to allow Chrome. Which could happen. Some of the "antitrust" stuff getting tossed around is already starting to get exploited by entities like advertisers, and not just big ones like Facebook, there were those EU ones recently. Like all power, Apple's focusing of its user's collective power can be used not just for bad stuff but for very good stuff as well. But that nuance doesn't seem to be present in a lot of the last year's discussions, and of course lobbyists will use the opportunity if they can.
Without that though or another big disruptive shift Apple misses, can even Google afford to give up on the entire iOS market? Even the Mac market perhaps, if Apple really wanted to push back against Google there they've certainly got the potential capability.
Restricting to just Chrome/Safari(Apple webkit) would still be really bad though. Even if they still allow Firefox, that would further formalize just 3 browsers with minimal further experimentation still possible. That'd be a real shame.
gtirloni|5 years ago
bpodgursky|5 years ago
No way they are giving up marketshare on Safari or on corporate boxes with IE. They've paid so much to get onto iPhones, there's not a chance they'd risk any marketshare erosion.
bxk1|5 years ago
ashneo76|5 years ago
IshKebab|5 years ago
ForHackernews|5 years ago
vaccinator|5 years ago
throwawayay02|5 years ago
Latty|5 years ago
When it comes to things like email, your account being compromised doesn't just affect you. Google let people send out emails from those accounts, so if a compromised account is used for spam, it hurts them reputationally as they are actively facilitating harm.
You might not care if that account is compromised, but they should.
brokencode|5 years ago
2. No company wants to announce that a bunch of accounts were hacked. The excuse that “our users don’t care” would be widely criticized.
3. Well yes, of course companies want to reduce customer support costs, but guess who else benefits from not needing customer support? The customers. It’s better to avoid a problem in the first place than to have great mechanisms for resolving it.
bobbyi_settv|5 years ago