The binary-only wildvine component of Firefox, as incorporated in the package 
currently shipped by Debian, can not reasonably be understood as an "optional 
addon that is downloaded separately in response to an explicit user request". 
It is intended as integral functionality of the browser, and the technical 
mechanism of downloading that component separately exists only as an attempt to 
game standards such as the DFSG that prefer free software.

This can be clearly seen in the Mozilla bug where the initially included 
mechanism to (even) opt-out was intentionally removed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1234355

Comparing this to the librejs question is unreasonable. That's like asking if 
Debian should package Java Web Start because someone might run a proprietary 
app that way. That's certainly an interesting question, but not the right point 
of comparison for this case.

A better comparison is something like the old "flashplugin-nonfree" package. It 
contained no non-free software directly, but downloaded and installed a 
non-free component by default. It even had UI elements that made it harder to 
download that component by mistake - it popped up an EULA screen with a "no" 
button before downloading. Should that package have been in main? How about 
"winetricks", where the components *are* clearly optional and explicitly 
requested?

Having something like the "don't ask again" button should be an absolute 
minimum requirement here. Even then, I'd still be disappointed to see stock 
Firefox in Debian. There may be a way to practically solve this with UI, but 
the more reasonable standard would be to say that programs that include 
hardcoded paths to download specific binary components innately violate the 
spirit of the DFSG.

Are there other packages in Debian main that have hardcoded URLs to download to 
non-free components from third parties? How do they handle this?

Is this a security issue? If someone hijacks Mozilla's web infrastructure does 
that allow them arbitrary remote code execution on Debian systems?
 
On Fri, Jun 21, 2019, at 13:09, Ian Jackson wrote:
> Nat Tuck writes ("Missing source in firefox-esr: EME module"):
> > The firefox-esr package in Buster includes the encrypted media extension
> > functionality, which relies on library called "wildvine". Source for
> > this library is not included in the firefox-esr source package.
> > 
> > This has been an outstanding bug since 2016, but it hasn't been
> > considered as a serious issue with the package:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837091
> 
> That bug seems to contradict you.
> 
> Firstly, it says that firefox-esr only downloads this proprietary
> software after explicit user action.  Is that right ?
> 
> Secondly, it is indeed tagged as "serious", ie release critical.
> 
> I think the behaviour described at the end of that bug is quite
> undesirable.  I think user action to download non-free sofware should
> be more explicit, and not so easily invited.
> 
> Overall, in Debian, we do not have a good enough mechanism for user
> control over these kind of suggestions.  There should be a single
> place where a user can say, during installation, what their posture is
> for non-free software.
> 
> Options should probably include:
> 
> 0  Never suggest non-free software to me; simply don't mention it.
> 
> 1  Explicitly confirm for each piece of non-free software.
> 
> 2  Automatically download and run non-free software whenever
>   it is likely to be convenient.
> 
> We would have to have some kind of argument about JavaScript on web
> pages.  I don't think the FSF's "librejs" stuff is useful in practice
> but we should probably offer it as an option.  Something like a ublock
> configuration that turns off JS by default and can be fiddled with,
> would probably be appropriate for users who select 0 or 1.
> 
> Ian.
> 
> -- 
> Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 
>

Reply via email to