Re: [GNU-linux-libre] youtube-dl might be running non-free software from

[Ivan Zaigralin]

I do speak for FSF here, though I am a member.

On Tuesday, July 18, 2017 11:06:18 Adonay Felipe Nogueira wrote:
> 1. Considering the current GNU FSDG: What free/libre system distributions
>    should do when they face the JavaScript trap in case some of the
>    packages they have depend on non-free JavaScript?

Of note is the fact that youtube-dl does not *depend* on any non-free 
javascript. Don't point it to any place wich serves nonfree javascript, and it 
won't run it. Just like konqueror or icecat or any other free browser/app 
which supports any kind of subset of javascript.

> 2. <snip>

> 3. As a suggestion for the Free Software Foundation's Licensing and
>    Compliance Lab: Could the GNU FSDG have a text clarifying what must
>    be done in questions #1 and #2?

No one knows, the best I can tell. It's called javascript "trap" for a reason, 
and the reason is we are in it, and we can't seem to get out. Please allow me 
to elaborate.

There is a wide class of apps, let's call them "drive-by interpreters". These 
are apps built on top of the internet/web stack, which are also capable of 
interpreting some kind of language. What these apps do is they load web pages 
(or net resources in general), extract code from them, and execute that code 
instantly. Some drive-by interpreters *force* users to use network 
resources which are *known* to serve non-free code. Let's agree for now these 
stinkers fail FSDG, even if free themselves. However, some of the most popular 
drive-by interpreters are pointedly agnostic, and will require the user to 
specify the network resource. Nothing in these apps will require the execution 
of nonfree code, unless the user will elect to visit and process a resource 
with nonfree code. These include most free web browsers, and, as much as 
I understand, also youtube-dl. I will talk about these agnostic, user-
controlled apps only.

Javascript trap is just a famous example of a more general trap where we find 
ourselves today. A user who is intent on NOT running nonfree software simply 
cannot afford to use a drive-by interpreter all by itself. By firing up a 
drive-by interpreter the user instantly assumes full responsibility for the 
resources passed on to it. The interpreter app, in particular, has exactly one 
practical way of deciding whether a given resource is free: it can check the 
crypto whitelist: for example, verify that the resource is signed by a party 
such as FSF, trusted to supply only free software. What LibreJS does, for 
example (checking for the presence of an attached license) is naive to the 
extreme. A resource can lie. The served code can be obfuscated. The code could 
be undocumented spaghetti code. The code could be generated on the fly, 
different every time, by a nonfree and secret server-side daemon. None of that 
would be free software even when a correct license is attached, and none of it 
would be detected by a boiler-plate checker such as LibreJS. As an icing on 
the cake, the code could be in fact free, yet *malicious*, because it has not 
been audited. And how can one even hope to audit code which comes as a part of 
a web page, and may change literally every second?

1. And hence the correct and practical way to escape the JS trap is to stop 
using JS, or at least stop using JS the way it is used. A user unwilling to 
run nonfree JS software must use a whitelist of resources she trusts, period. 
It is not the responsibility of a drive-by interpreter to supply that 
whitelist, since different users will want to trust different parties, and may 
even have different opinions on whether a given piece of software is free. The 
only responsibilities a drive-by interpreter has to the user is to work with 
*any* and *all* technically valid resources suggested by the user, and to 
avoid *forcing* the user to run code which is reasonably well known to be 
nonfree.

2. This situation could be mitigated somewhat, maybe, if we get legislation 
which forces all public-facing web content to be explicitly free. But even 
then, I would argue, we will still be sitting in the security portion of the 
trap.

3. The situation could be mitigated more fully if we get legislation which 
forces all public-facing web content to be *free* *markup*, and some of the 
interactivity and flexibility of a dynamic web page can be salvaged by 
creating a "local javascript": a free and secure API package installed 
locally, which will be called on by the markup. So like if you want to present 
a web form that does some syntax checking, you as a web developer fill out an 
even bigger form, which is then passed to the free API, which then generates 
on the fly the free code to display the user-facing form.

As you can see, the practical solutions are 1. non-starter 2. non-starter and 
3. yeah, right... non-starter, hence we call it the javascript trap.

Concerning youtube-dl, thanks to everyone who looked at the code, both 
youtube-dl and the code it pulls from the web. It looks to me like youtube-dl 
fits the agnostic drive-by interpreter category, sharing it with, say, icecat, 
which has much more robust capability of executing mystery javascript code. If 
youtube-dl in fact relies on nonfree code even for vewing free web resources, 
then we need to document this fact as soon as possible, as it would certainly 
be a deal-breaker with FSDG. But in the meanwhile, IMHO, there is absolutely 
no reason to suggest that youtube-dl cannot be included in free distributions.

signature.asc
Description: This is a digitally signed message part.