← Back to context

Comment by Wowfunhappy

8 hours ago

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

4 comments

Wowfunhappy

Reply
embedding-shape  7 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.

  • imnewton  17 minutes ago

    Restricting or sandboxing software is something I've been looking into recently. Would you mind sharing what you use and possibly an example as well? Perhaps an example for yt-dlp?

  • Wowfunhappy  6 hours ago

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