Discussion:
Automatic downloading of non-free software by stuff in main
(too old to reply)
Ian Jackson
2017-11-30 13:52:18 UTC
Permalink
This mail is going to a lot of lists. I have set the followups to
d-policy because ultimately this is hopefully going to result in a
change to policy.


Over the years, d-legal has discussed a number of packages which
automatically download non-free software, under some circumstances.

The obvious example is web browsers with extension repositories
containing both free and non-free software.

We have also recently discussed a media downloader/player which, when
fed a particular kind of url, will offer to automatically download a
proprietary binary-only protocol module to access the specified
proprietary web service.

We have generally put software like this in main, because it asks the
user first, and can be used perfectly well without the proprietary
parts. But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,

I would like to establish a way to prevent this. (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this. We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)

I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.

We should have a conversation about:

* What user experience options should ideally be available
* How those options should be represented in configuration
* Bug severity for programs that do not respect the "only free
stuff" setting.

Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.

The minimum required changes to individual packages should be small.

NB that this is going to be a _user option_. I'm not trying to shut
down non-free extension repositories. (Indeed I sometimes use them.)
I want to give users more control.


Obviously excluded from this discussion are downloader packages, which
have the fetching and use of proprietary things as their primary
purpose, and which therefore live in contrib.


But there is another category I want to distinguish:

Applications for processing Turing-complete file formats. This
includes web browsers, because of Javascript; but it also includes
PostScript viewers; interactive fiction interpreters; and so on.

The distinction between this and the general plugins I mention above
is that these applications all restrict the capabilities of the code
being executed, by running it in some kind of sandbox or container.
The idea being that the code gets to control the user's interactions
_with the providers of that code_, but not anything else.

There are some people who object to executing any non-free code on
their computer and I don't mind providing a facility for people to
restrict that. But I don't know exactly how to design such a thing.

For web browsers, there is the FSF's libre-JS. Personally I think
that is rather quixotic (and doesn't really address the real user
freedom question anyway), but I have no objection if anyone wants to
do the work to integrate that into some kind of freeness control
system.

But with file formats, the situation is much harder. I don't feel we
can introduce a policy requirement requiring package maintainers to
support users who want this kind of restriction, until we can come up
with a scheme that will actually work and be useable (and indeed, will
be minimal effort for a package maintainer to opt into).

(The question is: how do we stop a Postscript file received by email
being rendered automatically when the user clicks on it, while
allowing the user to still open a Postscript file they generated
themselves ?)


Ian.
--
Ian Jackson <***@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.
Andrey Rahmatullin
2017-11-30 14:12:38 UTC
Permalink
Post by Ian Jackson
I would like to establish a way to prevent this.
Why would the project do that, though?
Post by Ian Jackson
(There are even whole Debian derivatives who have as one of their
primary goals, preventing this.
Good.
Post by Ian Jackson
We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)
Why?

I also hope that you already have people who will do the actual work after
the discussions will provide the architecture.
--
WBR, wRAR
Adam Borowski
2017-12-01 05:09:12 UTC
Permalink
Post by Ian Jackson
Over the years, d-legal has discussed a number of packages which
automatically download non-free software, under some circumstances.
The obvious example is web browsers with extension repositories
containing both free and non-free software.
We have also recently discussed a media downloader/player which, when
fed a particular kind of url, will offer to automatically download a
proprietary binary-only protocol module to access the specified
proprietary web service.
[...]
Post by Ian Jackson
I would like to establish a way to prevent this. (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this.
No, those derivatives are damage. While their hearts are in the right
place, they cause data loss and security holes by at least making people on
Intel and AMD machines use known-buggy microcode.

Yeah, opaque encrypted microcode can be used to sneak in new backdoors,
but that doesn't make past bugs (and "oh, those foul hackers found one of
our backdoors, it was a honest bug, really!") any better. At the very
least, you get new TLA-only backdoors while those fixed are usable by both
TLAs and any random punk.

Likewise, closed firmware for your wifi card is evil, but still strictly
better than the same code burned into ROM: you get some bug fixes, and can
go back to a past version. Sweeping non-free code under the carpet doesn't
help in any way -- if you have to use it, it's better kept where you can
see it.

The biggest reason for me to avoid non-free code is that neither me nor
anyone among us can fix problems. And those derivatives you're talking
about tend to reintroduce this problem for political reasons (GFDL with
invariants).

Even Debian is not without fault here: for example, the ftpmasters accept
such a blatantly non-free licence as AGPL[1] into main.
Post by Ian Jackson
I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.
* What user experience options should ideally be available
* How those options should be represented in configuration
* Bug severity for programs that do not respect the "only free
stuff" setting.
I don't think any such extra infrastructure is needed: what we have already
works well, at most it could take some clarification in the Policy. I
believe the model that's in place for apt is worth adopting for browsers,
media players and such.

That is:
* no new non-free code is ever installed without the user's consent
("new" defined at package granulation, allowing splits/etc)
* it's not even proposed unless the software detects that such non-free
parts are actually needed
* once a piece of non-free code is installed, it should receive updates
unless explicitly configured otherwise

The last part matters because of recent Chromium issues. Of course, checks
for updates should be done in a way that minimizes privacy issues (which
Chromium's upstream loves to maximize), but defaulting to no updates at all
is irresponsible.


Meow!

[1]. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
AGPLed project in anything networked that has no, or cumbersome, ways to
pass advertising statements to the user (such as, eg, an IMAP server).
It also fails the Dissident Test: take a blogging software with
steganographic features, that you provide hosting for, for two classes of
users: fellow dissidents, and public at large. The former receive the code
(both binaries and source), the latter do not. Even revealing the existence
of your changes is a serious risk for the life of you and your friends.
Regular GPL has no such problems.

You might read my words as a sort of FSF bashing, as both bad licenses are
provided by them (GFDL and AGPL3), but regular GPL is generally much better
than BSD/MIT: it emulates a world without copyright much better, as in such
a world we'd have decompilers, etc.
--
< darkling> When all you have is a hammock, every problem looks like a nap.
Continue reading on narkive:
Loading...