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