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

[Jean Louis]

That is very good analysis Ivan.

There is just one point for me to which I do not
agree:

According to:
http://www.gnu.org/distros/free-system-distribution-guidelines.en.html

QUOTING:

Please Teach Users about Free Software

To establish lasting freedom, just giving users
freedom isn't sufficient. It is necessary also to
teach them to understand what it means and to
demand it. Thus, we suggest and urge that free
distros announce prominently on the screen, before
login and on the default desktop after login, a
prominent statement about freedom, such as “This
system is freedom-respecting free/libre software”
or something comparable, and to present a link or
icon pointing at gnu.org or gnu.org/philosophy for
further information about the issue.


Of course that users get possibility to run
non-free software by using free software, as they
have the freedom, and all the programming
languages are there that are free software that
can run non-free software.

But if the program is exclusively made to run,
execute non-free software, for which is impossible
for user to know what it is really doing, such
program shall not be included in a free software
distribution, as it would be hypocritical to the
"teaching what it means and demanding it", as
quoted in the above guideline.

If I wish to teach somebody not to use non-free
software, I will not give him a program that
exclusively runs non-free software in order to
run.

However, if program is not "running" or
"executing" the non-free software, but just
parsing the URL, or circumventing it, that program
should be included in free software distribution.

I do not know what is the case with the youtube-dl
exactly. 

Jean Louis


On Tue, Jul 18, 2017 at 04:43:46PM -0700, Ivan Zaigralin wrote:
> 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.