Missing source in firefox-esr: EME module

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Missing source in firefox-esr: EME module

Nat Tuck

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

The firefox-esr package uses a mechanism apparently intended to work around the
requirement to include source code: it downloads the library at run time. This
implementation detail doesn't change the fact that this is built-in
functionality of the program, shown in the UI as an option like "enable
javascript" rather than as an addon or plug-in.

I'm surprised to find this issue in a package in the Debian "main" archive. Am I
misunderstanding debian policy or this situation?

Thanks,

– Nat

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Vincent Bernat-3
 ❦  4 juin 2019 15:23 -04, Nat Tuck <[hidden email]>:

> 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.

Encrypted Media Extensions are also needed to play free content.
Implementations of HLS and MPEG-DASH both need these extensions.
--
Use the fundamental control flow constructs.
            - The Elements of Programming Style (Kernighan & Plauger)

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Ian Jackson-2
In reply to this post by Nat Tuck
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 <[hidden email]>   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 | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Nat Tuck
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 <[hidden email]>   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 | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Ian Jackson-2
Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> 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.

You didn't answer my question:

 | [The bug] says that firefox-esr only downloads this proprietary
 | software after explicit user action.  Is that right ?

AIUI if I (and personally I am a user who do not want this) do not
ever give my browser permission to do this, it will never download it.

I think your complaint is that it is making it the default easy path.
Personally I would agree with such a complaint, as I said in my
earlier mail.

> Comparing this to the librejs question is unreasonable.

I appreciate that you are angry.  I'm sorry that the rest of my mail
seemed to push your buttons rather.  I did not intend to make an
equivalence between the librejs question and this DRM thing.

But the question of global control of suggestions to download
proprietary software inevitably involves consideration of various
different kinds of proprietary software.

> 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?

I don't know for sure.

I think there are probably other packages besides browsers with their
own add-on or plug-in repositories.  Those repositories sometimes have
a mix of free and non-free software.

The thing you are complaining about here is different, because that
particular feature only ever downloads non-free software.

Ian.

--
Ian Jackson <[hidden email]>   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 | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Nat Tuck
> You didn't answer my question:
>
>  | [The bug] says that firefox-esr only downloads this proprietary
>  | software after explicit user action.  Is that right ?

I'd say, no that's not right. User action is required, but that action doesn't explicitly request that additional software be downloaded. If the user opted in to downloading software this would still be questionable, but this functionality in firefox doesn't even clear that bar.

If the "Enable DRM" preference is ever enabled, the software is automatically downloaded and installed transparently in the background. There are two ways that preference can be enabled:

 - Checking "Enable DRM" in preferences.
 - Visiting a page with a DRMed video on it.

When you visit a page with DRMed video a yellow nag bar appears at the top of the page with the text "You must enable DRM to play some audio or video on this page", as well as a single "Enable DRM" button. Users click off these nag bars without reading them - so it's questionable that this is further user interaction than simply pressing "play" on a video. But even if you do read the text, in neither case are you requesting a software download.

DRM in Firefox isn't an addon, it's a preference. The implementation of enabling that preference is to download a proprietary component.

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Ian Jackson-2
Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> [Ian Jackson:]
> > You didn't answer my question:
> >  | [The bug] says that firefox-esr only downloads this proprietary
> >  | software after explicit user action.  Is that right ?
...
> If the "Enable DRM" preference is ever enabled, the software is automatically downloaded and installed transparently in the background. There are two ways that preference can be enabled:
>
>  - Checking "Enable DRM" in preferences.
>  - Visiting a page with a DRMed video on it.
>
> When you visit a page with DRMed video a yellow nag bar appears at the top of the page with the text "You must enable DRM to play some audio or video on this page", as well as a single "Enable DRM" button. Users click off these nag bars without reading them - so it's questionable that this is further user interaction than simply pressing "play" on a video. But even if you do read the text, in neither case are you requesting a software download.

OK so there are a number of problems here, which add

1. The message asking permission is far too inexplicit.  (TBH I
  remember deciding not to approve, when prompted by such messages,
  but because I hate DRM - and I didn't know that if I had approved,
  it would have downloaded proprietary software too.)

2. There is no way to prevent firefox from repeatedly asking
  permission.

3. Users who have not installed software from contrib find that their
  Debian firefox package will offer to download and run proprietary
  software.

Fixing problems 1 and 2 will not be controversial, I hope.  Would you
care to write a patch which changes the message, as a start ?

Presumably fixing problem 2 is not that hard either: at least,
providing something that could be set in about:config.

Problem 3 is awkward because in Debian we do not have a consensus
understanding of when it is appropriate for a package in main to
download and run proprietary software.  I think this will require a
General Resolution to fix, but necessary groundwork involves figuring
out what behavioural profiles users want, and trying to align those
behavioural profiles to our existing archive areas.

Ian.

--
Ian Jackson <[hidden email]>   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 | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Nat Tuck
I don't think it's appropriate to start by simply changing the messages since that doesn't solve the majority of the problem, but it would make the issue seem less urgent.

The Firefox package implements core functionality by downloading a component from a third party site. This would be a problem even if that component were freely licensed. The DRM component is not - as currently integrated into Firefox - an addon like what we see in Gnome or other Firefox functionality like ad blocking or userscripts.

There's a distinction between addons and what's going on here, and I think that distinction is important.

Firefox used to have an "enable javascript" checkbox in the preferences. If this button were unchecked by default, would it be appropriate for Debian to distribute a version of Firefox that didn't include the JavaScript engine and downloaded it from Mozilla when the box was checked? I don't think so. Debian packages are self contained. For a normal Debian package I'd expect the download mechanism to be disabled and replaced either by bundling the component in the firefox package or the addition of a firefox-js-engine package.

Having software be downloaded and installed from a hard-coded non-Debian URL is not a reasonable result from enabling a preference in a Debian package.

Your proposal of simply changing the text is effectively trying to convert DRM *into* an addon. That would then get us to your question of whether a package should propose downloading a proprietary addon. Doing that honestly would take some work - Firefox would need a new "proprietary addons" screen, the DRM preference would need to be moved there, and the nag bar would need to change to take you there rather than simply triggering the install. And even then, Debian probably shouldn't have a patch that *adds* a request to download a proprietary addon.

There are a bunch of other possible solutions. For example, a wildvine-drm-nonfree package that downloads the component, and a patch to Firefox that removes the downloading mechanism entirely and shows an error message if the DRM preference is enabled and wildvine-drm-nonfree is not installed. That would follow the spirit of the DFSG and allow the existing user signal of enabling repos to work as expected.

All that gets a bit off topic for why I started this thread on debian-legal. Currently, the Firefox package *logically* bundles this component in a way that's clearly intended to dishonestly circumvent the DFSG. Papering over the issue with UI changes just feels like doubling down on that dishonesty.

On Fri, Jun 28, 2019, at 08:38, Ian Jackson wrote:

> Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> > [Ian Jackson:]
> > > You didn't answer my question:
> > >  | [The bug] says that firefox-esr only downloads this proprietary
> > >  | software after explicit user action.  Is that right ?
> ...
> > If the "Enable DRM" preference is ever enabled, the software is automatically downloaded and installed transparently in the background. There are two ways that preference can be enabled:
> >
> >  - Checking "Enable DRM" in preferences.
> >  - Visiting a page with a DRMed video on it.
> >
> > When you visit a page with DRMed video a yellow nag bar appears at the top of the page with the text "You must enable DRM to play some audio or video on this page", as well as a single "Enable DRM" button. Users click off these nag bars without reading them - so it's questionable that this is further user interaction than simply pressing "play" on a video. But even if you do read the text, in neither case are you requesting a software download.
>
> OK so there are a number of problems here, which add
>
> 1. The message asking permission is far too inexplicit.  (TBH I
>   remember deciding not to approve, when prompted by such messages,
>   but because I hate DRM - and I didn't know that if I had approved,
>   it would have downloaded proprietary software too.)
>
> 2. There is no way to prevent firefox from repeatedly asking
>   permission.
>
> 3. Users who have not installed software from contrib find that their
>   Debian firefox package will offer to download and run proprietary
>   software.
>
> Fixing problems 1 and 2 will not be controversial, I hope.  Would you
> care to write a patch which changes the message, as a start ?
>
> Presumably fixing problem 2 is not that hard either: at least,
> providing something that could be set in about:config.
>
> Problem 3 is awkward because in Debian we do not have a consensus
> understanding of when it is appropriate for a package in main to
> download and run proprietary software.  I think this will require a
> General Resolution to fix, but necessary groundwork involves figuring
> out what behavioural profiles users want, and trying to align those
> behavioural profiles to our existing archive areas.
>
> Ian.
>
> --
> Ian Jackson <[hidden email]>   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 | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Ian Jackson-2
Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> All that gets a bit off topic for why I started this thread on debian-legal. Currently, the Firefox package *logically* bundles this component in a way that's clearly intended to dishonestly circumvent the DFSG. Papering over the issue with UI changes just feels like doubling down on that dishonesty.

I think you are missing something very important.

Namely, you have failed to appreciate that this is a *political*
problem.  It needs a political solution.  You will not get this
problem fixed by simply stating your opinion, and your reasons, on
this list (on in bug reports).

> Your proposal of simply changing the text is effectively trying to convert DRM *into* an addon.

I can definitely see that way of looking at it.  To my mind it would
make the problem less severe.

> I don't think it's appropriate to start by simply changing the messages since that doesn't solve the majority of the problem, but it would make the issue seem less urgent.

Well, that is a question of political tactics.  Personally I think it
is not a good look to refuse to help mitigate a problem because you
want the problem to be more obviously bad for tactical reasons.

I tried to help by suggesting possible starting strategies.  You don't
need to agree with me.  But in order to effect any change here you
will need to build a coalition of opinion sufficient to force a change
in Debian's approach.

I think the problem with proprietary addons offered by software in
Debian is a significant one, which we should address head-on.  If we
did that then users who are concerned with their own software freedom
will easily be able to avoid both this DRM code, and proprietary
addons.  Ie, solving the problem of addons would solve your firefox
problem.

That's why I wrote this:

> > Problem 3 is awkward because in Debian we do not have a consensus
> > understanding of when it is appropriate for a package in main to
> > download and run proprietary software.  I think this will require a
> > General Resolution to fix, but necessary groundwork involves figuring
> > out what behavioural profiles users want, and trying to align those
> > behavioural profiles to our existing archive areas.

Feel free not to take my advice.

But I am afraid that your current approach is doomed.  You seem to
have come to -legal to try to use it as a lever to fix #837091.  But
-legal has no authority.

Maybe you came here to drum up support.  That got you engagement with
one potential ally, namely me.  But you have responded by arguing with
me about semantics and details, rather than looking for common ground
and trying to develop a political strategy.  So I am not encouraged
:-(.

Regards,
Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Nat Tuck
My goals in posting were to drum up support, or at least to figure out what other people think about the issue.

My hope was that people who care about free licensing would be subscribed to debian-legal, and that at least some people would immediately be interested in / worried about the problem.

To me, what the firefox package is doing seems like a loophole that allows nearly arbitrary proprietary software to be packaged in "main", functionally indistinguishable from including the old flashplugin-nonfree in main and having Firefox depend on it. Another decent example would be if someone made a version of DOOM that shipped with free assets but had a "buy the official DOOM levels for $5" button.

My second goal has been accomplished: It looks like not everyone immediately sees it like that.

> Namely, you have failed to appreciate that this is a *political*
> problem.  It needs a political solution.  You will not get this
> problem fixed by simply stating your opinion, and your reasons, on
> this list (on in bug reports).

It doesn't look like we're at the fixing stage on this one. I haven't even managed to get one person to agree with me as to what the problem is.

I guess my most useful question as this point is this: There's not a lot of interest in this issue here on debian-legal. Is there another place where there would be more interest?
 

> > Your proposal of simply changing the text is effectively trying to convert DRM *into* an addon.
>
> I can definitely see that way of looking at it.  To my mind it would
> make the problem less severe.
>
> > I don't think it's appropriate to start by simply changing the messages since that doesn't solve the majority of the problem, but it would make the issue seem less urgent.
>
> Well, that is a question of political tactics.  Personally I think it
> is not a good look to refuse to help mitigate a problem because you
> want the problem to be more obviously bad for tactical reasons.
>
> I tried to help by suggesting possible starting strategies.  You don't
> need to agree with me.  But in order to effect any change here you
> will need to build a coalition of opinion sufficient to force a change
> in Debian's approach.
>
> I think the problem with proprietary addons offered by software in
> Debian is a significant one, which we should address head-on.  If we
> did that then users who are concerned with their own software freedom
> will easily be able to avoid both this DRM code, and proprietary
> addons.  Ie, solving the problem of addons would solve your firefox
> problem.

Addons seem like a separate, larger, less critical problem. But maybe you're right - maybe focusing on the more general problem makes more sense.

Firefox is definitely an example for non-free addons in general - for example, the extension "Evernote" is proprietary. Gnome extensions must be free software. To find other examples, I quickly find myself expanding from "addons" to package managers in general. "playonlinux" is a good example, but it's already in contrib. Some other package managers like npm or rubygems only install free software.

It'd probably be necessary to go through the packages in main and see if any other packages download and install proprietary software at all, or if this is just Firefox even in the more general case.
 

> That's why I wrote this:
>
> > > Problem 3 is awkward because in Debian we do not have a consensus
> > > understanding of when it is appropriate for a package in main to
> > > download and run proprietary software.  I think this will require a
> > > General Resolution to fix, but necessary groundwork involves figuring
> > > out what behavioural profiles users want, and trying to align those
> > > behavioural profiles to our existing archive areas.
>
> Feel free not to take my advice.
>
> But I am afraid that your current approach is doomed.  You seem to
> have come to -legal to try to use it as a lever to fix #837091.  But
> -legal has no authority.
>
> Maybe you came here to drum up support.  That got you engagement with
> one potential ally, namely me.  But you have responded by arguing with
> me about semantics and details, rather than looking for common ground
> and trying to develop a political strategy.  So I am not encouraged
> :-(.
>
> Regards,
> Ian.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Simon McVittie-7
On Tue, 02 Jul 2019 at 15:20:37 -0400, Nat Tuck wrote:
> It'd probably be necessary to go through the packages in main and see
> if any other packages download and install proprietary software at all,
> or if this is just Firefox even in the more general case.

I want to head this off right now, because continuing this train of
thought could lead to us removing all the email clients from Debian
(because they are willing to download this email[1], which I have not
placed under a Free license), and if that's the standard we are aiming
for then we might as well give up on producing a practically useful
Free Software distribution.

A program that *can* download and install proprietary software, but does
not depend on doing so, is definitely allowed in main: general-purpose
HTTP clients like Firefox and wget download whatever you tell them to,
proprietary or otherwise, and so will software package managers like
apt, Docker and pip. Even within the scope of installing executable
code through an interface specifically designed for executable code, the
extensions available from addons.mozilla.org and third-party sources are a
mixture of Free and non-Free, just like the dpkg packages available from
deb.debian.org and third-party apt sources, the Docker images available
from Dockerhub and third-party Docker registries, and the Python packages
available from PyPI and third-party pip-compatible repositories. Some
distribution points have a strict policy of Free Software only (Debian
main is one such distribution point, and I think PyPI aims for this?),
but any downloader that can't cope with multiple compatible distribution
points (federation) has an obvious missing feature, and any downloader
that *can* cope with multiple compatible distribution points can be
pointed to a distribution point that offers non-Free software.

Now, I do agree that Firefox's Widevine module is not the same as (for
example) the addons on addons.mozilla.org, because there is code in
Firefox to download and run this specific module (Widevine specifically,
not just the generic concept of an EME module), and the UI for that
feature does not make it immediately obvious that an additional module
will be downloaded and run when it is enabled. I think you might be
harming your chances of achieving your goal here by trying to make this
into a debate about DFSG-compliance (which I suspect is not one you are
likely to win), and by expanding its scope from Widevine to software
downloaders more generally.

If you approach this from the angle of "I had a reasonable expectation
of what this checkbox would do, but what it actually does is something
different, and I think this situation could be improved", then that
seems more likely to lead to changes, assuming you haven't already
antagonised the people you would have needed to persuade. It might not
lead to precisely the changes you hoped for, but sometimes compromise
is necessary.

More on the DFSG angle, because this *is* -legal:

Packages in main are not allowed to *depend on* proprietary software,
which we have generally interpreted as: imagine the proprietary software
was distributed via apt/dpkg (if it isn't already). If the strength of the
depending package's dependency on it is such that a Depends or Recommends
with no alternative would be appropriate, that isn't OK for main; but if
a Suggests or no explicit dependency at all would be more appropriate,
or if an appropriate dependency could have been an alternative-group like
"Depends: free-thing | non-free-thing"[2], then that's allowed.

So, imagine the proprietary Widevine module was included in the non-free
archive area or some third-party apt repository, so that firefox.deb
could have a Depends, Recommends or Suggests on it, rather than being
available via a non-apt mechanism. How strong would the correct dependency
be? I think the answer is probably Suggests: Policy says that means that
"the listed packages are related to this one and can perhaps enhance
its usefulness, but that installing this one without them is perfectly
reasonable", which seems about right. Installing Widevine enables an
additional feature (playing DRM-encumbered videos), but Firefox continues
to be useful for many other purposes without it.

Firefox frequently also downloads proprietary web pages, and proprietary
Javascript programs, but if anything the dependency relationship there is
the other way around: the web page and its associated Javascript programs
depend on a web browser. If (for example) Youtube was somehow packaged in
Debian[3], we'd be more likely to say
youtube Depends: firefox | chromium | www-browser than we would be
to say firefox Depends: youtube.

    smcv

[1] If you believe "software" means executable code and excludes
    non-executable data like the text of this email, please imagine that
    I had included a shell script under a "non-commercial use only" license
    in order to make my point
[2] Debian Policy §2.2.1, as resolved in #681419 and #587279
[3] April Fool's Day ITP, anyone?

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Mihai Moldovan
On July 3, 2019 1:55:04 AM GMT+02:00, Simon McVittie <[hidden email]> wrote:

>On Tue, 02 Jul 2019 at 15:20:37 -0400, Nat Tuck wrote:
>> It'd probably be necessary to go through the packages in main and see
>> if any other packages download and install proprietary software at
>all,
>> or if this is just Firefox even in the more general case.
>
>I want to head this off right now, because continuing this train of
>thought could lead to us removing all the email clients from Debian
>(because they are willing to download this email[1], which I have not
>placed under a Free license), and if that's the standard we are aiming
>for then we might as well give up on producing a practically useful
>Free Software distribution.
>
>A program that *can* download and install proprietary software, but
>does
>not depend on doing so, is definitely allowed in main: general-purpose
>HTTP clients like Firefox and wget download whatever you tell them to,
>proprietary or otherwise, and so will software package managers like
>apt, Docker and pip. Even within the scope of installing executable
>code through an interface specifically designed for executable code,
>the
>extensions available from addons.mozilla.org and third-party sources
>are a
>mixture of Free and non-Free, just like the dpkg packages available
>from
>deb.debian.org and third-party apt sources, the Docker images available
>from Dockerhub and third-party Docker registries, and the Python
>packages
>available from PyPI and third-party pip-compatible repositories. Some
>distribution points have a strict policy of Free Software only (Debian
>main is one such distribution point, and I think PyPI aims for this?),
>but any downloader that can't cope with multiple compatible
>distribution
>points (federation) has an obvious missing feature, and any downloader
>that *can* cope with multiple compatible distribution points can be
>pointed to a distribution point that offers non-Free software.
>
>Now, I do agree that Firefox's Widevine module is not the same as (for
>example) the addons on addons.mozilla.org, because there is code in
>Firefox to download and run this specific module (Widevine
>specifically,
>not just the generic concept of an EME module), and the UI for that
>feature does not make it immediately obvious that an additional module
>will be downloaded and run when it is enabled. I think you might be
>harming your chances of achieving your goal here by trying to make this
>into a debate about DFSG-compliance (which I suspect is not one you are
>likely to win), and by expanding its scope from Widevine to software
>downloaders more generally.

Very good points. By that same reasoning you could throw out wget since there is a risk of it downloading non-free software. Of course that argument is more a tongue-in-cheek one and there is a fundamental difference to what Firefox does: downloading proprietary software with wget is possible because wget allows any source to be fetched and has no control over the remote content, but Firefox hardcodes a very specific location and knows what it'll get. That's inline with the OP's assessment of bypassing non-free software requirements via a trick.

I wonder why no one brought it up yet, but here we go: IMHO, downloading pre-defined proprietary software should completely be disabled/removed in Firefox and the proprietary Widevine module be properly packaged as a package in non-free - with at most a Suggests dependency in the firefox(-esr) package. The nag bar might tell people to install this additional package.

This isn't just a (questionable) licensing question, but AFAICT even a potential security issue. I *hope* that Mozilla at least signs the module and checks the signature, but haven't checked. In theory, a malicious network could intercept and replace this module with arbitrary binaries when not using signatures. And even if Mozilla signs and checks this stuff, why should Debian trust their infrastructure? This module should be under trustworthy distro control, just like any other software package.



Mihai
--
Sent from mobile phone.

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Francesco Poli (wintermute)
On Wed, 03 Jul 2019 03:28:18 +0200 Mihai Moldovan wrote:

[...]
> IMHO, downloading pre-defined proprietary software should completely
> be disabled/removed in Firefox and the proprietary Widevine module be
> properly packaged as a package in non-free - with at most a Suggests
> dependency in the firefox(-esr) package. The nag bar might tell people
> to install this additional package.
[...]

For what is worth, I personally agree.

--
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Paul Wise via nm
In reply to this post by Mihai Moldovan
On Wed, Jul 3, 2019 at 9:38 AM Mihai Moldovan wrote:

> I wonder why no one brought it up yet, but here we go: IMHO, downloading pre-defined proprietary software should completely be disabled/removed in Firefox and the proprietary Widevine module be properly packaged as a package in non-free - with at most a Suggests dependency in the firefox(-esr) package. The nag bar might tell people to install this additional package.

The Widevine license does not allow redistribution.

https://sources.debian.org/src/firefox-esr/60.7.2esr-1/toolkit/content/gmp-sources/widevinecdm.json

        "Linux_x86_64-gcc3": {
          "fileUrl":
"https://redirector.gvt1.com/edgedl/widevine-cdm/4.10.1196.0-linux-x64.zip",

LICENSE.txt from the zip contains this:

"Google Inc. and its affiliates ("Google") own all legal right, title and
interest in and to the content decryption module software ("Software") and
related documentation, including any intellectual property rights in the
Software. You may not use, modify, sell, or otherwise distribute the Software
without a separate license agreement with Google.  The Software is not open
source software.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Francesco Poli (wintermute)
On Thu, 4 Jul 2019 13:13:26 +0800 Paul Wise wrote:

> On Wed, Jul 3, 2019 at 9:38 AM Mihai Moldovan wrote:
>
> > I wonder why no one brought it up yet, but here we go: IMHO,
> > downloading pre-defined proprietary software should completely
> > be disabled/removed in Firefox and the proprietary Widevine module
> > be properly packaged as a package in non-free - with at most a
> > Suggests dependency in the firefox(-esr) package. The nag bar might
> > tell people to install this additional package.
>
> The Widevine license does not allow redistribution.
[...]

Good point.

Then, the strategy could be similar to [flashplugin-nonfree]:
a package (in Debian contrib) that automatically downloads and install
the non-free module from the upstream distributor, and installs it...

[flashplugin-nonfree]: <https://packages.debian.org/sid/flashplugin-nonfree>


--
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Missing source in firefox-esr: EME module

Paul Wise via nm
On Sat, Jul 6, 2019 at 5:41 AM Francesco Poli wrote:

> Then, the strategy could be similar to [flashplugin-nonfree]:
> a package (in Debian contrib) that automatically downloads and install
> the non-free module from the upstream distributor, and installs it...

IIRC the Debian maintainers of Firefox are now Mozilla employees. I
speculate that Mozilla has a contract with Google about how they bring
Widevine to Firefox users. I speculate that a downloader package might
not comply with that contract. I speculate that Mozilla would not be
willing to deviate from that contract for Firefox upstream since
Firefox users worldwide would lose access to Widevine and to content
they expect to work. I speculate that, due to the contract, modifying
Firefox in Debian to use a downloader package for Widevine might not
be allowed under Firefox's trademark license. That said, it sounds
like a download package could divert the Firefox binaries to a script
that sets the MOZ_GMP_PATH environment variable to the location for
Widevine. That might conflict with the gcm-sources I mentioned in an
earlier mail though, depends on what order the environment variable
and the gcm-sources are loaded in.

https://wiki.mozilla.org/GeckoMediaPlugins

--
bye,
pabs

https://wiki.debian.org/PaulWise