[delroth]

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

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

[duskwuff]

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]

Which would break some common authentication options in ytdl:

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

[worik]

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

Evil by default?

[seniorivn]

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

[tester756]

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

[dleslie]

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

[trickstra]

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]

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]

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]

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

[joshspankit]

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]

Would you share those scripts?

[joshspankit]

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]

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

[dleslie]

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

[dmoy]

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

[mulmen]

There's an ocean between required and useful.

[detaro]

How does youtube-dl obtain the token today?

[dleslie]

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

Username, Password, 2FA, etc.

[detaro]

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]

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

[detaro]

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.

[dleslie]

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

[9HZZRfNlpR]

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.