Hacker News new | past | comments | ask | show | jobs | submit login

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



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.


Which would break some common authentication options in ytdl:

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


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

Evil by default?


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


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


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


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.

Nope, no siree, Bob. Moving riiiight along.


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)


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


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)


Would you share those scripts?


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.


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


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


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


There's an ocean between required and useful.


How does youtube-dl obtain the token today?



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


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


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.


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: