Comment by embedding-shape
6 hours ago
> What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code
Nothing specific, just tend to run tools in restricted VMs where things are whitelisted and it's pretty much as locked down as it can be. It can run whatever I want it to run, including JS, and as the logs in my previous comment shows, it is in fact running both Python and JS, and has access to YouTube, otherwise it wouldn't have worked :)
I tend to have the rule of "least possible privileges" so most stuff I run like that has to be "prepped" basically, especially things that does network requests sometimes (updating the solver in this case), just a matter of packaging it before I run it, so it's not the end of the world.
No weird OS or architecture here, just good ol' Linux.
> IMO it seems like it should safe to trust code being served by Google on the official Youtube domain
The JS script being downloaded is from the yt-dlp GitHub organization (https://github.com/yt-dlp/ejs/releases/download/0.3.1/yt.sol...), not from Google or any websites, FWIW.
> The JS script being downloaded is from the yt-dlp GitHub organization
I meant the challenge that is the reason they need the Javascript in the first place.
You can’t very well run yt-dlp without trusting yt-dlp code.
The original point was this:
> > IMO it seems like it should safe to trust code being served by Google on the official Youtube domain
Which came from a misunderstanding about where the downloadable solver script comes from, as it doesn't come from youtube.com, it comes from github.com (yt-dlp org), I was just correcting that misunderstanding.
> You can’t very well run yt-dlp without trusting yt-dlp code.
That makes a ton of sense and I agree! I'm not sure how that is related to anything though? I download yt-dlp from Arch repositories, so yes I'm trusting Arch maintainers and of course yt-dlp developers. Then I'm adding a manifest which controls what this application can actually access, which is basically a VM config, where I define that it can access youtube.com (and a bunch of other sites I mirror/archive). This is the part that shouldn't have github.com/* access.
Again as mentioned, not a big issue, plenty of workarounds, so not the end of the world.
> Which came from a misunderstanding about where the downloadable solver script comes from, as it doesn't come from youtube.com, it comes from github.com (yt-dlp org), I was just correcting that misunderstanding.
But that script is ultimately running a JS challenge from Youtube, right? That’s why we actually needed a JS runtime in the first place.
1 reply →
This is the way. Leaving so many packages with unfettered access to your system is only so secure.