Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yt-dlp: External JavaScript runtime now required for full YouTube support

github.com

Post reply on HN
Print view View original

491–500 of 646 posts

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#491

Post by franga2000 »

zahlman wrote: post #481
arbll wrote: post #102

Earlier quoted context omitted.

It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp users but please do not use deno sandboxing as a your main security measure to execute untrusted code . Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.

> Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this. ... Isn't the web browser's sandboxing runtime-level?

Yes, and it's only reasonably secure because of years of exploits being found and fixed by some of the best (and very well-funded) software security engineers out there.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#492

Post by Tabular-Iceberg »

fragmede wrote: post #444
Tabular-Iceberg wrote: post #217

Earlier quoted context omitted.

No, it's also iOS that's arbitrarily restricting it. I opened a bare .webm directly in Safari and got nothing on long press and nothing in any of the control widgets to save it.

Long pressing on https://www.learningcontainer.com/wp-content/uploads/2024/07... gets me https://imgur.com/a/bseFwX3 on iOS 18, and https://imgur.com/a/Ksbz3zW on iOS 26 Maybe you're holding it wrong?

I think you're holding it wrong, because that's a .webp image, not a .webm video.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#493

Post by jcalvinowens »

zelphirkalt wrote: post #489
jcalvinowens wrote: post #118

Earlier quoted context omitted.

The really shitty thing is that vulnerable devices get blacklisted en masse, so all legitimate users get stuck with 480p video content on streaming services. The Nexus 5 got this treatment, as I understand it, because it was too easy to extract the keys.

Not a Netflix user here: Are you saying that paying customers get cut off from higher video quality, that they are possibly paying for, and pressured into buying new devices? That shit should be illegal!

Yes, that's exactly what happens!

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#494

Post by mike-cardwell »

Wowfunhappy wrote: post #218
embedding-shape wrote: post #95

Seems its already in Arch's repositories, and seems to work, just add another flag to the invocation: yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX' It is downloading a solver at runtime, took maybe half a second in total, downloads are starting way faster than before it seems to me. [youtube] [js…

What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code If the concern is security, it sounds like the team went to great lengths to ensure the JS was sandboxed (as long as you’re using Deno). If you’re using some sort of weird OS or architecture that Deno/Node doesn’t support, you might consider QuickJS, which is written in pure C and should work on anything. (Although…

This works for me:

    FROM python:3-slim
    RUN python3 -m pip --no-cache-dir install 'yt-dlp[default]'
    RUN apt-get update \
     && DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -q -y ffmpeg curl unzip \
     && curl -fsSL https://deno.land/install.sh -o /tmp/deno.sh \
     && sh /tmp/deno.sh -y \
     && mv /root/.deno/bin/deno /usr/local/bin/ \
     && rm --force --recursive /var/lib/apt/lists/* /tmp/* /var/tmp/*
    ENTRYPOINT ["yt-dlp"]

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#495

Post by NoahZuniga »

blackhaj7 wrote: post #459
baobabKoodaa wrote: post #413

Earlier quoted context omitted.

> It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp yt-dlp supports a huge list of websites other than youtube

Is there a full list? I struggled to find one

There's a supportedsites.md file in the base directory of the git repo.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#496

Post by NoahZuniga »

franga2000 wrote: post #491
zahlman wrote: post #481

Earlier quoted context omitted.

> Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this. ... Isn't the web browser's sandboxing runtime-level?

Yes, and it's only reasonably secure because of years of exploits being found and fixed by some of the best (and very well-funded) software security engineers out there.

Great news! Deno uses the same runtime as chrome, so you benefit from all those found exploits.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#497

Post by arbll »

zahlman wrote: post #481
arbll wrote: post #102

Earlier quoted context omitted.

It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp users but please do not use deno sandboxing as a your main security measure to execute untrusted code . Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.

> Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this. ... Isn't the web browser's sandboxing runtime-level?

It used to be 100% runtime-level and it was the golden age of browser exploits. Each of your tabs are now a separate process that the OS sandboxes. They can only access a specific API over IPC for anything that goes beyond js/rendering (cookie management, etc...). An exploit in V8 today only gives access to this API. A second exploit is needed in this API to escape the sandbox and do anything meaningful on the target system.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#498

Post by ciberado »

therein wrote: post #486
jcalvinowens wrote: post #483

Earlier quoted context omitted.

YT works pretty flawlessly for me with firefox on debian. What's the issue you're seeing?

If you are blocking ads now, the videos will start in a very delayed fashion almost as if the server is waiting the length expected for the ad to take before streaming you any bytes.

Same here. Still, I prefer to wait instead of suffering those aggressive ads.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#499

Post by arbll »

franga2000 wrote: post #491
zahlman wrote: post #481

Earlier quoted context omitted.

> Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this. ... Isn't the web browser's sandboxing runtime-level?

Yes, and it's only reasonably secure because of years of exploits being found and fixed by some of the best (and very well-funded) software security engineers out there.

That's not true. It's secure because they are stacking OS-sandboxing on top, forcing attackers to find a chain of exploits instead of a single issue in V8
Post reply on HN