Comment by embedding-shape
5 hours ago
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.
Correct, the data needed to solve the challenge comes from YouTube.