On Thu, Nov 30, 2017 at 01:52:18PM +0000, Ian Jackson wrote: > 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. [...] > 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. > 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. 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.