* Rewrite HTTP headers
* Headless browsers
* Text-based browsers"
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.
Just launch me to my preferred real browser.
Stop trying to trap us in your ecosystem.
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.
> 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! :)
Google is leaving the web behind, doing its own thing.
That is fine.
I'm appalled of the general direction Google is pushing the web to (an AD haven), but some of their points make sense.
> 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.
I feel like mentioning youtube-dl was a mistake. It's not just about youtube-dl.
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 . . .
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.)
Evil by default?
>Headless browsers locked out (thanks for nreaking test automation)
>Text-based browsers (Going aft Lynx? Of all things?)
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.
- 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)
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.
Username, Password, 2FA, etc.
It explicitly blocks "headless" browsers.
> You must confirm that your browser does not contain any of the following:
> Headless browsers
> Text-based browsers
Google wants to take over the Internet. We should not let it use these "less secure" excuses to sway the public opinion.
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.
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.
Can you imagine if Fox announced that only approved televisions could show their content?
I mean Chrome doesn't clearly identify itself as Chrome, it still identifies itself as Apple Webkit
... and many more
It would be interesting to see this examined in the context of accessibility requirements created by the ADA.
It blocks auth to prevent phishing, not actual access.
Good luck keeping your account!
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.
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)
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.
> ...Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021
It says nothing about non-login related actions.
Exactly. What's insecure about an application that can establish a secure connection using an accepted version of TLS and cipher?
There is currently millions -> hundreds of millions being made by scraping Google content.
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?
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.
Now, people just scream "monopoly" at everything google does, good or bad and boy is it getting tedious.
>And remember… don’t be evil, and if you see something that you think isn’t right – speak up!
>Last updated September 25, 2020
How times have changed.
Of course, if you just hand-wave away such criticism as being "tedious", I don't expect you to care, but other people do.
Ok, so no password managers that auto-fill your password (like the one built-in to Chrome)? This guidance is not well-thought-out.
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?
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.
- Headless browsers
- Text-based browsers
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.
We've been there before, haven't we?
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".
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)
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?
I wonder if such interface could be exposed for desktop browsers.
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.
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.
And if so, can that be solved by the proposed approach of gradually narrowing the requirements for supported clients?
Disabling less secure apps has been postponed though because of covid.
Unless you're Google and you need to bolt on X-Client-Data headers in all requests made to DoubleClick, of course.
I’d happily set my user agent string to Mozilla 1.0 if it stopped all that stuff from working.
Safari is an exception, since Apple won't accept giving that up in their products.
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.
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.
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.
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.
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.
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.