Re: (was Re: Adding a description text property for a track) non-free javascript and ytdl

[Alexandre Garreau]

Le merkredo, 23-a de marto 2022 13-a horo kaj 13:09 CET, vous avez écrit :

> On Sat 2022-03-19 00:56:51 +0100, Alexandre Garreau wrote:

> > Le vendredo, 18-a de marto 2022, 21-a horo kaj 23:04 CET Yoni Rabkin a écrit :

> >> Yoni Rabkin <yoni@rabkins.net> writes:

> > yes, but i think the decision to make is more tricky as it may appear

> > as: the _javascript_ interpreter youtube-dl claims to use disable most

> > of its API, essentially interpreting turing-complete IO-less program

> > that’s actually not redacted by humans but generated randomly by a

> > script so that to act as an obscure key for some kind of weird kindof

> > symetrical encryption

> So afaik there are two js interpreters used by youtube-dl (I haven't

> checked yt-dlp).  One is the self-contained jsinterp (used by the

> youtube extractor), the other phantomjs (used by openload and *checks

> notes* pornhub extractors).

oh ok i didn’t know, i guessed they had abandoned phantomjs…

> Try put some print statements in the call_function js interpreter, see

> whether ytdl runs it.  Chances are it won't.

ofc if the *interface* doesn’t allow it: what would be interesting to try, however, would be to query or send data over network with that js.  if it works, then it’s unacceptable, a security threat, and implementing its own protocol that shall be freed.

> > and the whole usage of youtube (its standard interface is

> > proprietary and there so way to use it as a creator/writer without

> > using proprietary software) is problematic. Yet the sharing and

> > archiving of its videos is imho appropriate resistance.

>

> Right, GET-only usage without running nonfree js is fine and does not

> take away your freedom.  But POST is problematic because it requires

> nonfree js that is needed for signing up a google account etc.

I don’t see how GET/POST is related: you can use POST without any _javascript_ (both POST and PUT existed before _javascript_), while for youtube, even any GET statement provides nothing but a blank page, and you need to execute _javascript_ to get anything.

This is due to YouTube, Google, etc.’s trend of using «framework» to build websites, in this particular case AngularJS, made by Google, which is known to be unable to display anything without running _javascript_.

The fact I was talking about is you can use youtube without _javascript_ if only for watching videos, as you can use either of a downloader like youtube-dl or a foreign free-software proxy frontend such as Invidious.  However these don’t provide the possibility to upload videos, because they only reverse-engineered the watching interface.  This is not related to accounts as youtube-dl *does* support google accounts, signing in them and using them for various purposes (marking as watched, personalized suggestions, access to private and age-limited videos, etc.)

> > However I’m unsure it still needs it for youtube, afaik, they mostly

> > used it for openload and a very few other backends.  Actually it

> > doesn’t hurt really much to remove them, and could mostly lead users

> > to instead prefer other streaming platform to download (and then

> > share) movie, series, etc.

>

> I agree that a youtube-dl / yt-dlp without using any js interpreter

> would be better, and ideally they should be running some sort of LibreJS

> to block nonfree nontrivial scripts before executing any remaining free

> / trivial ones.  I'm gonna strip my copy of ytdl of code running js

> interpreters.

no, because usually whenever something is free-software, there is either a tailor-made API, or one can easily be devised using its documentation and/or source (at worse), so you don’t need to go to such extremes.

a good example is PeerTube, which also is built using AngularJS, but provides a simple API (1-to-1 mapping to direct links) to download videos directly (however it doesn’t support following the WebTorrent’s implementation, that way, tho, so you increase the load on the server whenever you try to save (hence re-download…) the video instead of watching the streamed blob…)

something you notice relevantly is actually there are now two active version of youtube-dl: yt-dlp (somewhat more active (and complete, as for extractors (also more up to date, say for tiktok, while youtube-dl’s one is broken for me)) but also more broken (as for metadata at least)), and the original youtube-dl (which has less extractors, some of which are now broken, but is more stable): then arise the question: on which is based hypervideo?

These are actually reverse-engineering webscraping projects, playing cat-and-mouse with bigger yet less numerous companies… hence bound to require frequent updates, lot of works, and to maximally optimized the efforts provided by the community in order to keep up with «the enemy» (the companies that want to seclude users to their proprietary interface): ideally, we shouldn’t ever fork or scatter force, but make the software more configurable and configure it so as to disable what we dislike…

Afaik that’s what hypervideo does, as I knew it not as a real, maintained, fork of youtube-dl, but the patched version specific to parabola.  to me this is right: free-software distributions (also, ideally, the upstream, but they apparently disagree) should distribute that software configured (or patched, in the most stable and future-proof possible way) not to depend on proprietary software.

but, again: I/O-less automatically-generated js scripts are not real programs to me, more like mere obfuscation, deobfuscatable via an open standard known as «interpreting basic (expressed as _javascript_, possibly recursive) arithmetic».  there wouldn’t be an interest to make them «free».