Hacker News

164 Comments:
1vuio0pswjnm7 said 8 days ago:

"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.

kwijibob said 9 days ago:

I hate the smartphone app trend of having embedded browsers.

Just launch me to my preferred real browser.

Stop trying to trap us in your ecosystem.

tinus_hn said 9 days ago:

Never mind carrying around 6 copies of Chrome on your phone

pitaj said 9 days ago:

What are you talking about? Embedded browsers use the system webview, provided by Chrome, Firefox, or whatever is configured.

whereistimbo said 9 days ago:

Recent version of Android reverts the default webview to Android System WebView again.

tinus_hn said 9 days ago:

Sure, Chrome on iOS is ‘only’ a 118 mb application! And much of that is also in Google Maps, the Google Docs apps etc.

marcan_42 said 9 days ago:

Chrome on iOS isn't even a real thing, it's just an app embedding Safari like every other app with a webview (because Apple's draconian policies forbid alternate browser engines). All the other Google apps also have to use Safari for any web stuff.

trickstra said 8 days ago:

I'm surprised such draconian policies still haven't been challenged in court like Microsoft or Google have.

jakelazaroff said 9 days ago:

Are embedded browsers not usually just the system webview?

MereInterest said 9 days ago:

They might hide the URL, so I can't see where the link led me. Or they might disable the usual browser menu, preventing me from bookmarking a page. Or they might have the "close tab" interaction be in a completely different location, breaking any muscle memory.

If I'm following an HTTP(S) link, it means that I want to view it in a browser. I don't want to have some in-app view that can only return me to gmail, or to discord, or to google handouts, just because that happened to be where I clicked the link from. I don't care in the slightest whether the rendering engine is the same as the default browser. I care whether the user interactions are the same.

canofbars said 9 days ago:

Yes but how would you even know as a user. Or how would you know that you are on the real google page.

swiftcoder said 8 days ago:

On iOS, yes, since Apple's rules forbid alternate browser engines. On Android, it's not unknown for apps to embed an alternate browser engine in it's entirely.

Kudos said 8 days ago:

It's extremely uncommon though, pretty sure nothing I've installed does it.

athenot said 9 days ago:

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).

vaccinator said 9 days ago:

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

Aldipower said 9 days ago:

This is a campaign against Lynx!

> 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 said 8 days ago:

My site still works in Lynx, nojs, and Netscape.

Google is leaving the web behind, doing its own thing.

That is fine.

Enginerrrd said 9 days ago:

Man, that's deeply aggravating.

gitweb said 9 days ago:

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.

kiwidrew said 9 days ago:

How can a prohibition on "text-based browsers" have anything to do with MitM attacks? The browser's chosen rendering method (text or GUI) is irrelevant.

trickstra said 8 days ago:

Google is actually misrepresenting the danger in their blogpost, because they write "One form of phishing, known as man-in-the-middle,..." - this statement is clearly false because MITM is not phishing. Not in any stretch of the definition. So who knows what is the real justification.

kilburn said 8 days ago:

I agree that the post is not very well written, but if you are a bit generous you can read them saying "phishing sites are doing MITM attacks that we have a very hard time distinguishing from CEF logins, so we are axing CEF logins altogether".

I'm appalled of the general direction Google is pushing the web to (an AD haven), but some of their points make sense.

wwwigham said 9 days ago:

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.

dleslie said 9 days ago:

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.

npsimons said 9 days ago:

> 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 . . .

MereInterest said 9 days ago:

Yeah, the browser itself is an automation feature. It automates the downloading of a file over HTTP, downloading of any dependent resources, managing of caches, and rendering of the result. That these are so frequently done that this automated pipeline is referred to as "a browser" doesn't mean that this isn't an extremely automated system.

delroth said 9 days ago:

> 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.)

dleslie said 9 days ago:

Passing oauth tokens into automation tools is a common use case in order to automate the retrieval of account-restricted content.

duskwuff said 9 days ago:

Which would still be fine. The only thing that'd be blocked is obtaining those OAuth tokens by passing your Google username/password to a browser automation tool.

dleslie said 9 days ago:

Which would break some common authentication options in ytdl:

https://github.com/ytdl-org/youtube-dl#authentication-option...

worik said 9 days ago:

It is not the whole world attacking ytdl - but Google, definitely.

Evil by default?

seniorivn said 9 days ago:

when you delete "don't be evil" tagline, you become evil by default

tester756 said 9 days ago:

Let's dont act as if the whole world was trying to fight against ytdl.

dleslie said 9 days ago:

It's not just about ytdl; this policy will ban all headless browsers, text-based browsers, and browsers with automation tools.

trickstra said 8 days ago:

And it's also ineffective, because any full GUI browser can be automated with extensions or userscripts, so banning useragents or non-javascript browsers won't actually prevent automates sign-ins.

salawat said 9 days ago:

So they're breaking mountains of automated test and scripting tools? Nice to know.

>Headless browsers locked out (thanks for nreaking test automation) >Node.js (riiight) >Text-based browsers (Going aft Lynx? Of all things?) >JavaScript MUST be enabled

Totally not a power grab here folks. Totally not a company known to value reaping user data in any form possible up to any kind of user hostile behavior, or exercising undue influence over the character of the Net.

Nope, no siree, Bob. Moving riiiight along.

dmoy said 9 days ago:

What does that have to do with youtube-dl? (Sorry it's been like 5 years since I used it, I don't remember that being required)

dleslie said 9 days ago:

It allows one to download private videos that your account can access.

joshspankit said 9 days ago:

Such as:

- I have a script that downloads my liked videos (in case they get deleted, which I’ve found out happens a fair bit)

- I also have a script to download my watch later videos (for sync to devices without YouTube Premium/Red/whatever)

mattl said 9 days ago:

Would you share those scripts?

joshspankit said 8 days ago:

Sure:

```bash

# !/bin/sh

cd /media/youtube-dl

docker-compose run --rm youtube-dl -v --cookies /etc/youtube-dl.cookies.txt https://www.youtube.com/playlist?list=INSERTYOUROWNWATCHLATE... -o "watchlater/%(title)s-%(id)s.%(ext)s" --ignore-errors

```

That’s a bash script that runs via cron. One thing to note: this uses the cookies from a logged-in browser session because at some point YouTube blocked password log in from youtube-dl. This was is a bit of a pain to set up, and I wish it was not the case, but it mostly works.

dmoy said 9 days ago:

So the theory is this has nothing to do with security, but is only used to break private video downloading of youtube-dl?

dleslie said 9 days ago:

It blocks misrepresentation of agent, in general; automation is also blocked in general, but _especially_ for authentication.

dmoy said 9 days ago:

Sure but if the goal was to block youtube-dl usage, wouldn't they target the vastly more common usecase without authentication?

mulmen said 9 days ago:

There's an ocean between required and useful.

detaro said 9 days ago:

How does youtube-dl obtain the token today?

dleslie said 9 days ago:
detaro said 9 days ago:

And you claim that doing more to stop people from giving their google account password to "random apps" (I personally trust youtube-dl a lot too, but "random apps" is what it comes down to) and forcing those apps to use OAuth to obtain scoped tokens has "nothing to do with security"?

pjc50 said 9 days ago:

Security for whom? Locking the user out of the software they want to use is not improving security for them.

detaro said 9 days ago:

That's only true if you assume the user is perfectly capable of evaluating the trustworthiness and quality of the software they want to use. It's understandable that that's not the assumption Google designs their security under. Yes, that sometimes somewhat sucks for us power users.

kortilla said 9 days ago:

That’s a pretty fake excuse IMO as long as the browser keeps rendering web pages that look like Google’s sign-in page.

dleslie said 9 days ago:

If that were all that they were doing I might agree; but they are blocking browser identity misrepresentation and automation, as well; it also requires that all "browsers" have a complete implementation of web standards.

It explicitly blocks "headless" browsers.

> You must confirm that your browser does not contain any of the following:

> Headless browsers

> Node.js

> Text-based browsers

said 9 days ago:
[deleted]
9HZZRfNlpR said 9 days ago:

Definetly not on the right side of the history. With all the social changes and uprises we see one would expect you to do better.

userbinator said 9 days ago:

It has everything to do with security: securing Google's control.

Google wants to take over the Internet. We should not let it use these "less secure" excuses to sway the public opinion.

samuelroth said 9 days ago:

Google’s control...over the security of Google accounts?

If you are worried enough about Google’s dominance over the Internet to be upset by this particular practice, it is unlikely you have (or should maintain) a Google account.

I’m not a “Google stan” by any means, but to say that they want to take over the Internet is just not true.

dvfjsdhgfv said 9 days ago:

> to say that they want to take over the Internet is just not true.

I don't know if they "want", but they already do have control over various aspects of the Internet, especially of the web, but also DNS and email.

ForHackernews said 9 days ago:

Google wants to dictate what user-agent you can use to access their sites: that's pretty controlling!

Can you imagine if Fox announced that only approved televisions could show their content?

throwaway09223 said 9 days ago:

"The browser must not provide automation features."

It would be interesting to see this examined in the context of accessibility requirements created by the ADA.

InfiniteRand said 8 days ago:

This is kind-of funny requirement given the history of user-agent strings being incredibly convoluted.

I mean Chrome doesn't clearly identify itself as Chrome, it still identifies itself as Apple Webkit

worldmerge said 9 days ago:

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.

izacus said 9 days ago:

Why not? This restriction was added on Android years ago and it basically means that you retrieve the OAuth2 token with a normal browser and then send it to your automaton script/app.

It blocks auth to prevent phishing, not actual access.

scrollaway said 9 days ago:

If you'd bothered to read a little more before knee-jerking a reaction comment, you'd know this is only for the authentication flow.

pjc50 said 9 days ago:

And? What if I want to automate my login flow?

said 9 days ago:
[deleted]
izacus said 9 days ago:

You'll need to find another provider which doesn't care that much about preventing phishing attacks. Google accounts are a big target so it makes sense you move away from the masses.

pjc50 said 9 days ago:

In practice it just means faking the user-agent and other fingerprinting more enthusiastically. I'm not sure how google can win that without resorting to the same anti-cheat measures as games companies.

jlokier said 9 days ago:

You'll try, but the first time you won't know what fingerprinting tests they are going to do. After a few iterations you'll succeed, but it will be obvious to Google that the account you've just been testing it on belongs to someone trying to break their auth restrictions...

Good luck keeping your account!

dleslie said 9 days ago:

I did read that; did you know that passing oauth tokens into such automation tools is commonplace?

ath0 said 9 days ago:

OAuth tokens used in automation tools will continue to work. Entering in username & password through auth, to automate an OAuth flow (or any other traditionally manual flow) will stop working. Breaks some puppeteer scripts too - but those have been getting flaky for a while now.

dleslie said 9 days ago:

Thus making it even more cumbersome for users; now they simply login, in the future they'll have to know how to get the oauth token.

detaro said 9 days ago:

It's OAuth. The application can launch a normal browser for the OAuth flow and have the user complete it.

bxk1 said 9 days ago:

For plenty of applications the whole purpose is not to run "a normal browser" and possibly not even have it installed.

detaro said 9 days ago:

You can also use a browser on a different device if your thing can't run a browser itself. OAuth covers a large space of options.

Dylan16807 said 9 days ago:

They can spit out a url for you to copy into a normal browser, then.

joshspankit said 9 days ago:

And, OAuth tokens can be revoked meaning scripts will just suddenly fail.

scrollaway said 9 days ago:

What's your point? Passwords can change and sessions can get invalidated, which all has the same effect.

joshspankit said 8 days ago:

Yes I would agree with that, except that if you change a password you know the scripts will fail, but if an OAuth token gets invalidated by the system and not you, then it will fail without warning.

scrollaway said 8 days ago:

And if your password gets reset by the system and not you, same story.

What makes you say oauth tokens are any less robust? Aside from the fact they usually have an expiration attached to them, there's not much difference.

joshspankit said 8 days ago:

Also fair point.

What makes me say that? Experience.

However, I will say to counter my own point: it’s not all roses. Using password by necessity means that your password is now stored somewhere that is likely more easily compromised (In my case: secure passwords are stored in 1Password, but passwords for script usage are either stored in an ENV or in the script itself, neither of which are great from a security standpoint)

austincheney said 9 days ago:

> 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.

kevindong said 9 days ago:

The announcement specifically says this:

> ...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 said 9 days ago:

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.

u801e said 9 days ago:

> his has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others

Exactly. What's insecure about an application that can establish a secure connection using an accepted version of TLS and cipher?

mrjin said 9 days ago:

Google has went rouge for quite a while. AMP was another example of the same nature.

DevKoala said 9 days ago:

Pretty much. It also helps their ad business to combat fraud.

imglorp said 9 days ago:

This is probably the only case that actually affects them. There's really no argument for security here.

suifbwish said 9 days ago:

Has anyone thought of just not using Google? By using them you give them power in your life

nojito said 9 days ago:

It's to stop scraping of Google Data.

There is currently millions -> hundreds of millions being made by scraping Google content.

ForHackernews said 9 days ago:

Kind of hypocritical given that Google's entire business is founded on scraping the rest of the internet.

heavyset_go said 9 days ago:

Anti-trust action can't come fast enough.

dageshi said 9 days ago:

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.

gostsamo said 9 days ago:

Once upon a time Google had "don't be evil" in their corporate mission and people trusted them to act in good faith. Good old times.

tester756 said 9 days ago:

They still do

>And remember… don’t be evil, and if you see something that you think isn’t right – speak up!

>Last updated September 25, 2020

src: https://abc.xyz/investor/other/google-code-of-conduct/

gostsamo said 9 days ago:

Before, it stated that the company must not be evil. Now, it is for the employees not to be evil somewhere in the end. In the meantime, if you are high up the management ladder, you can fuck the subordinates and get away with millions.

Ygg2 said 9 days ago:

Now it's "Do the right thing (for corporate)"™.

How times have changed.

heavyset_go said 9 days ago:

Leveraging their dominance in one market to limit competition in the browser market is something the millennium-era DOJ went after Microsoft for.

Of course, if you just hand-wave away such criticism as being "tedious", I don't expect you to care, but other people do.

Enginerrrd said 9 days ago:

Explain to me how being forced to turn on Javascript or not use a text-based browser results in me having "improved security."

heavyset_go said 9 days ago:

The reason Google is requiring you to have JavaScript enabled, potentially opening you up to running malicious code, is because they want to use feature detection to prevent people from using competitors' Google-unapproved browsers.

sieabahlpark said 9 days ago:

It's almost like people have rose tinted glasses and opinions can change when a company has repeatedly abused it's position more than a handful of times.

Wow, it's really a shocker people could be upset. There comes a point where using a blanket term "security" to define uncompetitive behavior is called covering. They want to ensure ads cannot be blocked with manifest v3, they want to ensure DNS cannot be blocked by ad blockers, they cannot let you use any browser that isn't pre-approved so they can force you to be unable to block their ads. They'll define new web standards to help themselves and break the web.

Google isn't doing this for security, they're doing it to keep their ad market dominance and force customers to be required to use only approved browsers. Also when did JS being enabled become a hard requirement for the web as a standard?

cannedslime said 9 days ago:

They are not improving security, just making it more difficult to scrape google, who ironically is 100% based around scraping and living off other peoples content and creations in general.

austincheney said 9 days ago:

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.

cm2187 said 9 days ago:

They just got some friends elected. Wouldn't count too much on the DOJ being impolite with big tech the next 4 years.

smlckz said 9 days ago:

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.

So I am out of luck! Anyone out of luck like me?

neurostimulant said 8 days ago:

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.

[0] https://github.com/tenox7/wrp

smlckz said 8 days ago:

If I could rent a VPS, I could buy a smartphone instead. sigh

My j2me phone's screen resolution is 320x240, and Opera's server does a respectable job in transforming webpages to fit into that small screen size. It also uses a binary file format named OPML to encode the transformed page. With my 2G internet connection, it'd take much more time to load a page and cost me more to load images.

ashneo76 said 8 days ago:

Is it possible to de Google?? Google provides no value other than a few email address

forgotmypw17 said 8 days ago:

Always welcome all browsers and configurations.

akersten said 9 days ago:

"The browser must not provide automation features." in authentication workflows.

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 said 9 days ago:

How does this mesh with their plans to deprecate User-Agent? https://9to5google.com/2020/01/14/google-deprecate-chrome-us...

heavyset_go said 9 days ago:

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 JavaScript enabled.

mleonhard said 8 days ago:

> You must confirm that your browser does not contain any of the following: Headless browsers

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 said 9 days ago:

> 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
  - Node.js
  - Text-based browsers
Yeah... This has nothing to do with "standards or security".
olliej said 9 days ago:

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.

ogurechny said 9 days ago:

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.

cookiengineer said 8 days ago:

"optimized for IE6 and Microsoft ActiveX"

We've been there before, haven't we?

ashneo76 said 8 days ago:

Precisely

jhasse said 9 days ago:

What does this mean for IMAP?

gtirloni said 9 days ago:

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.

d99kris said 9 days ago:

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.

https://workspaceupdates.googleblog.com/2020/03/less-secure-...

edoceo said 9 days ago:

If you have "less secure apps" you can still use password. Going forward G is pushing use of XOAUTH2 for IMAP auth.

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 said 9 days ago:

Nothing. IMAP doesn't use the web signin form that these changes apply to.

devit said 9 days ago:

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".

jlokier said 9 days ago:

Make sense for security.

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 said 9 days ago:

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.

LockAndLol said 9 days ago:

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.

swiley said 9 days ago:

Dear god I'm glad I got my crap off of google.

uniqueid said 9 days ago:

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.

phendrenad2 said 9 days ago:

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.

hedora said 8 days ago:

> 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.

indymike said 9 days ago:

This reads like Google is trying to eliminate browsers that don't have a user attached to them. Good luck with that.

jka said 9 days ago:

Is all of this an arms race around the question "is that a human at the other end of the connection?"

And if so, can that be solved by the proposed approach of gradually narrowing the requirements for supported clients?

mekkkkkk said 9 days ago:

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?

ratiolat said 9 days ago:

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.

Sniffnoy said 9 days ago:

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.

0xy said 8 days ago:

>Rewrite HTTP headers

Unless you're Google and you need to bolt on X-Client-Data headers in all requests made to DoubleClick, of course.

haunter said 9 days ago:

Hope that doesn't kill ungoogled-chromium

tinus_hn said 9 days ago:

Having a separate app for these insecure devices would be an improvement.

hedora said 9 days ago:

I briefly hoped this would apply to search and ad serving as well.

Sadly, no.

I’d happily set my user agent string to Mozilla 1.0 if it stopped all that stuff from working.

forgotmypw17 said 8 days ago:

This only concerns auth?

unixsheikh said 9 days ago:

I'm glad I neither use Google nor YouTube! Security.. riiight!

cannedslime said 9 days ago:

"less secure" more like you are not allowed to scrape the almighty scraper. What pathetic double standards.

skee0083 said 9 days ago:

Will iOS mail app still work?

ivanche said 9 days ago:

Next step: The browser must not be anything but Chrome.

maest said 9 days ago:

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.

canofbars said 9 days ago:

They don't need anything other than firefox or safari. All new browsers could be blocked as they are unknown/untrusted.

edoceo said 9 days ago:

And if you want to build a new one - you cannot test against a very common use case.

xoa said 9 days ago:

>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.

AnthonyMouse said 9 days 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.

But that would also imply they'd have to allow Firefox, and Brave, and Tor Browser. Which would certainly be worth the "cost" of allowing Chrome.

> 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.

All political coalitions work like this. If you're against DMCA 1201 then commercial pirates will be on your side. That doesn't mean they're your friends. They're not, and in fact are costing your side goodwill, even if your side is right in the end.

> 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

Because it's true of anything. Dictatorships are a wonderful thing if you're the dictator's friends, but that's hardly making a strong case for dictatorship.

gtirloni said 9 days ago:

Please stop spreading FUD on HN.

userbinator said 8 days ago:

FUD? You still do not see the frog boiling after years of pushing Chrome and mindwashing developers into creating sites that only work in Chrome?

Google is the one "spreading FUD". Just look at the downvoting going on in the discussion and you'll see some pretty obvious attempts to silence anti-Google criticism.

bpodgursky said 9 days ago:

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.

bxk1 said 9 days ago:

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.

ashneo76 said 8 days ago:

Basically, fuck you too Google. For sucking the open source community

IshKebab said 9 days ago:

This presumably means they are banning Chrome Lite?

ForHackernews said 9 days ago:

This link breaks the back button in Firefox. Is that also supposed to improve security?

vaccinator said 9 days ago:

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.

throwawayay02 said 9 days ago:

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.

Latty said 9 days ago:

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.

brokencode said 9 days ago:

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.

swiley said 9 days ago:

The problem is that you have to have an account on google to participate in a number of communities. Because of this they have social scaling problems that might be fundamentally unsolvable and in their attempt to find a solution they've done things like this.

bobbyi_settv said 9 days ago:

Even if you don't care if someone hacks your Google account, the rest of care when we start getting deluged with spam from that Gmail address.