Yt-dlp pronto requerirá un entorno de ejecución de JavaScript para las descargas de YouTube

yt-dlp pronto requerirá un entorno de ejecución de JavaScript para las descargas de YouTube

([Announcement] Upcoming new requirements for YouTube downloads · Issue #14404 · yt-dlp/yt-dlp · GitHub)

yt-dlp pronto requerirá un entorno de ejecución de JavaScript llamado Deno [1] para resolver los desafíos de JavaScript que YouTube genera para tratar de evitar que la gente descargue videos. El desarrollador que publicó el hilo de discusión sugirió que actualizar el intérprete integrado podría ser posible, pero mantener ese intérprete sería mucho más costoso (hasta el punto de ser impracticable) que en el pasado, porque los desafíos han aumentado mucho en complejidad. yt-dlp cambiará a un “enfoque basado en AST” en su lugar; no estoy seguro de si esto significa que el JavaScript se “ejecuta” realmente, pero tal vez alguien que entienda esto mejor pueda opinar.

El intérprete de JavaScript integrado existente ya era un poco controvertido [2], pero parece que la mayoría de la gente pensaba que estaba bien, ya que yt-dlp está incluido en Trisquel, Guix, Parabola y PureOS. Pensé que Hyperbola usaba hypervideo en su lugar, lo que eliminaba el intérprete integrado, pero ahora parece que no tienen ninguno de los dos paquetes.

Después de este cambio, parece que descargar videos de YouTube puede requerir descargar y ejecutar JavaScript privativo. No sé cómo interactúa esto con las reglas de Trisquel, ya que yt-dlp sigue siendo útil para descargar videos de otros sitios web, pero facilitará la ejecución de software privativo, incluso por accidente, dependiendo de cómo se implemente esto. Por otro lado, el caso de uso para el JavaScript no libre que se descarga y ejecuta es diferente al de la mayoría del software, así que tal vez no importe tanto que no sea libre.

A largo plazo, parece bueno alejarse de YouTube. Tal vez sería una buena idea pedir a las personas que hacen videos de YouTube que los publiquen bajo una licencia libre, para que alguien más pueda elegir alojar el canal en PeerTube o algo similar. Si no tenemos suficientes recursos para alojar muchos videos de esa manera, incluso un directorio de canales de video con contenido principalmente libre podría ser útil para el futuro. ¿Alguien sabe si existe algo así? (Supongo que los videos con licencia CC-BY-ND también funcionarían para este propósito específico).

¿Qué piensan sobre este próximo cambio en yt-dlp? ¿Deberíamos modificar yt-dlp para eliminar esta nueva función? Tal vez descargar desde Invidious sea una buena idea, pero ejecutar una instancia de Invidious probablemente también requeriría ejecutar software privativo en ese caso.

[1] https://deno.com/
[2] Re: Replace Youtube-DL with HyperVideo

Esta fue traducida por mi, pero el autor original en inglés es Jacob K (yt-dlp will soon require a JavaScript runtime for YouTube downloads | Trisquel GNU/Linux - ¡Va por libre!).

5 Me gusta

Ayer tuve problemas justamente con Statcher7 para bajar videos. Quizás ya están implementando esos cambios.

1 me gusta

Hay algunas cosas que decir al respecto.


Igual no se como puede interactuar un cambio con las políticas de Trisquel, pero cualquier entorno de ejecución, incluyendo los interpretes de los navegadores tienen el potencial de ejecutar software de cualquier tipo, incluyendo software con licencias no libres. Rechazar el paquete por la posibilidad de que pudiese llegar a ejecutar ese tipo de software no me parece la mejor de las ideas. Si ese fuese el caso, ¿los navegadores también deberían ser removidos? (Recordar que Deno y Node son una abstracción del motor V8 de Chromium, Bun lo es para JavaScriptCore de Safari, y las extensiones de bloqueo de contenido no son infalibles).


Lo que hacen tanto Invidious como yt-dlp es descargar el JS de YouTube, eso desde siempre. De ahí, dados los cambios tan agresivos que ha hecho Google a sus sistemas de cifrado, todos requieren ejecutar algo de código de YouTube. En el caso de Invidious usa Invidious Companion como servicio auxiliar para ese propósito, y adivina, tambien usa Deno como interprete de JS.

Históricamente solo se habían dedicado a usar montones de parsers y expresiones regulares para recuperar solo datos relevantes para el descifrado de las URLs y contenido del video, y después usar sus propias implementaciones equivalentes a las del JS con los datos recuperados, pero, como dicen los desarrolladores, ese enfoque se ha vuelto poco practico y en varios casos directamente inviable.


Respondiendo directamente a algunas preguntas

Lo hacen, ejecutan código JS de Youtube, en el caso de yt-dlp en tu equipo, y con Invidious en el servidor en el que se aloja.

Es necesario de acuerdo a los requerimientos técnicos del proyecto.

No es necesario modificarlo, simplemente no usar el interprete, opcion ya considerada por los desarrolladores. No usarlo simplemente te va a dejar con un software con funciones limitadas específicamente para YouTube.


Opinion aparte. Siempre me ha parecido medio hipócrita el uso de servicios proxy libres para el consumo de contenido de plataformas no libres, dada la directa dependencia de los primeros a los segundos. Usar un servicio proxy libre solo oculta el uso de software no libre, y peor, caen en un auto engaño, en el que se aferran a la falsa idea de que no estan usando ni alientan el uso de software no libre. Es solo una mascara, y tarde o temprano se va a caer.

1 me gusta

Buenas, muchas gracias por compartir este tema, no estaba al tanto.

Un saludo

Relación con el tema: si javascript es privativo, entonces:

¿Y si expando mi lenguaje de programación como intérprete de HTML5 (HTML, CSS, JS)?

Sería bajo la GNU public, como núcleo de navegadores 100% libres. Aunque al principio solo ejecutaría HTML rudimentario…

Aunque, con el tiempo desarrollaría mi propia versión de javascript!

Ahora que estoy aprendiendo introducción al álgebra lineal, podré desarrollar los algoritmos para tanto el intérprete como los gráficos (OpenGL, MESA3D).

Ahora actualizo mi blog #2.

En base a la queja de JS como privativo.

1 me gusta

JavaScript no es privativo. Como C, Python, o cualquier otro lenguaje de programacion, el asunto esta en la licencia del codigo que escriben con ese lenguaje. Los interpretes como V8, JavaScriptCore o SpiderMonkey son, cuando menos, abiertos, y ECMAScript, el estandar sobre el que se desarrolla JavaScript, también es abierto.

Aunque se supone que cualquiera puede ver JS desde el inspector de su navegador…

Es cierto que la naturaleza de la web hace que todo código que se ejecute en el navegador sea de fuente accesible. Por eso paginas como YouTube usan técnicas como la ofuscación en su código JS para dificultar su análisis.

Pinche youtube ■■■■, no tengo nada de ti. La verdad es que si es tremendo mierdon, yo estoy mas preocupado que esto empeore el rendimiento en dispositivos ya considerados obsoletos, joder… en fin, me encantaría que la gente normal utilizara peertube pero eso es casi imposible…

1 me gusta

Probaste con Tyoescript?

Colega, no es un problema con el lenguaje JavaScript, el problema son las obras creadas con JavaScript que han sido distribuidas como software privativo. No importa que lenguaje crees, ni que licencia le pongas a él ¿me entiendes?

Supuestamente, a mi no me importa el código del servidor, ya que se ejecuta en una máquina ajena a la mía. Mientras, cuando yo le mando una petición, supongamos, HTTP, recibo el código HTML5 (supongamos este nombre el conjunto html, css, js).

Por lo cuál, estaría recibiendo el código fuente qué ejecutará mi máquina, y que puedo leer.

El del servidor no va a ejecutarse en mi máquina, solo el front.

El JavaScript se ejecuta en tu computadora, por eso se almacena en el caché.

2 Me gusta

Que canales o instancias de peertube recomiendan? Yo lo suelo usar para ver videos de isf del chad y de algún otro creador.

2 Me gusta

Hardlimit es el que vi que se hizo mas o menos popular, pero igual, si solo quieres ver vídeos, cualquiera te sirve, para subir vídeos es otra historia

1 me gusta

El javascript se usa como complemento de HTML y se ejecuta en el navegador el javascript de ser ver seria con cosas como node, ya que este JavaScript del frontend reacciona a eventos en el HTML mandando de ser necesario peticiones a servidores y pueden llegar a hardcodearlo y estoy de acuerdo con @isf porque es así que puede llevar a ejecutar código que no sabes y a lo mejor ni puedes saber lo que hace en tu navegador

1 me gusta