|
| From: | Sam Geeraerts |
| Subject: | Re: [GNU-linux-libre] Browser plugins |
| Date: | Thu, 26 May 2011 22:36:08 +0200 |
| User-agent: | Thunderbird 2.0.0.24 (X11/20101029) |
Leo wrote:
There are several ways we can deal with this:a) We do nothing. It's the website author who steers the user to non-free software, not the software. The author is free to suggest non-free software. We treat it like a "best viewed with Internet Explorer" message on the website. Strictly technically speaking the software is FSDG compliant.I kind of agree with this one.b) We cut out the browser code that suggests plugins. From the user's perspective, the message comes from the browser, not from the website. This would also block any steering to free plugins, but I have yet to see a website that does that. This is the easiest/quickest fix and already implemented in IceCat if I'm not mistaken.I think that in a way we'd be doing freedom through obscurity.
The same has been said about keeping references to non-free software out of our documentation.
The user can't play whatever flash is needed for and is left with the uncertainty of how to fix that. The popup suggests a solution, which in our eyes is not a solution at all, but at least the user can follow instructions on what to do. Suggesting nonfree is wrong, but I don't agree that not suggesting anything is the right way to solve that.
I agree that it isn't the right way. I suggested it as a lesser evil to quickly implement while a better way is being hacked on.
The way I see it, there are 4 possible scenarios after trying to see a site and not getting any notification:0) I'm new to computers, I ask around or search in a search engine and find out about the de facto choice because it's the most obvious and popular one and I end up installing nonfree flash anyway.
Ideally, the user would read documentation or ask the distribution's community. Realistically, you're right.
1) I'm new to GNU/Linux but have used computers before; I'd probably install nonfree Flash anyway since that's what I'd have previous knowledge of.
Ideally, the user would find a package manager by glancing over the menus or skimming some documentation. But you're right again.
2) I'm not new to GNU/Linux but I'm an opensource kind of person and I install nonfree flash because that's what it works and I don't want to have to deal with Gnash incompatibilities with some sites.
This person would find a reason to install non-free Flash anyway, even if a pretty well working Gnash were preinstalled. Preinstalling or an advocating message from the browser might nudge him a little bit (more) to see the importance of software freedom, but it might well have the opposite effect, emphasizing some prejudice against it (or its advocates). In any case, it's unlikely that he would consciously choose a libre distribution, so I consider this not our target audience and not a battle I'm willing to pick now.
3) I'm a freetard and subscribed to the GNU-linux-libre mailing list and I already know about this problem and I wouldn't get anywhere near nonfree software.
I think that most free distro users know about software freedom, care about it a great deal and are technically savvy. But gNewSense aims to be accessible by a broad group of people, so we shouldn't assume that's the typical user.
c) We keep a blacklist of known non-free URLs and replace them with links to free alternatives in the dialog box. While there are probably not many different URLs used in the wild, we're never sure to catch them all. We'd also have to keep track of the freedom status of the alternatives upstream besides all the packages in the distro. There may not even be something FSDG compliant to point to (which is preferably also easily installable by the user).This one I kind of agree with, but maybe with a message that says "The site you're visiting suggested installing nonfree software to have access to additional things. We suggest installing this instead: $INSERT_LINK_TO_FREE_FLASH_ALTERNATIVE_HERE".
My initial thought was to point to the alternative's project website, but it could also be an apturl, a distro wiki page or a distro package page. Pointing to upstream has the highest chance of getting accepted upstream as-is, but maybe they can be convinced to provide a hook for the latter options.
d) We use the dialog box (or e.g. integration with Software Center) to suggest a package from the distro to install for each media type.This one seems a bit difficult, considering that packages are named different and that package managers work in different ways. If we suggest a generic name, then that would probably be right. "The site you're visiting suggested installing nonfree software to have access to additional things. We suggest that you look for Gnash/swfdec/Lightspark in your repos instead."
I assumed distro-specific patching. If we can find a solution that upstream agrees with, all the better.
I think (a) is just a poor excuse. (c) seems high cost, low gain to me. A "first (b), then (d) if possible" implementation looks like the best solution to me.I think (a) is an option if a message was added to the popup; something like "The site suggested this plugin, which could be nonfree". I agree that (c) is high cost, but I don't think it has low gain.
I meant "low gain" as in: if we point the user to the upstream website, it might offer just a source archive, which wouldn't be very helpful to most users.
(b) I don't like much. (d) also sounds high cost, but if it's done how I suggested it, then it wouldn't be hard.I like (a) and not (b) because I see (b) a bit like censoring.
Which is why I'm not a big fan of (b) either (and even less so, now that I've considered your comments).
If a user doesn't want to install flash they can always dismiss the popup and never see it again. If we want to alert the user that the plugin is probably nonfree, then we can do that by putting a nice message warning the user right before the site's suggestion.
The catch here is that the user trusts the distro to not suggest non-free software. A warning that something /could be/ non-free is better than nothing, but not very helpful. I wouldn't be happy if a device I bought said "This probably won't explode if you plug it into 230 V. Contact your local electricien to be sure.".
(Actually, with The JavaScript Trap in mind, we should also warn about the lack of software freedom in Flash objects while we're at it. But that's another issue.)
It's a bit like the DEBLOBED messages in Linux-libre; I'm not exactly in agreement with that (although I don't strongly disagree with it, since I only use 100% free software and it doesn't bother me personally). I don't know if making it harder for the user to find the nonfree stuff actually benefits free software. If the user wants to install only free software, then a message of "This is nonfree software and we recommend you not to install it." should be enough instead of obfuscating things.
I see why you'd compare it to that, but the difference is that the browser is only relaying information from the web page, while Linux has more information about the firmware it's requesting (although the browser can be made more intelligent with (c) or (d)). Suppose you have an obese friend who's desperately trying to loose weight. Do you point to candy every time you see it, saying "I recommend you not eat that" or do you steer him away from the candy and encourage him to stay on a well balanced diet?
Also, if flash is needed as a crucial thing to view the site then I probably wouldn't be visiting it again anyway, even if it works perfectly with Gnash. Knowing that the site also recommends nonfree software might motivate me to send an email to the webmaster of the site to solve both problems. If I don't know they are making popups show up, then I never get to know that they are recommending nonfree software and I can't do anything about it. I feel that hiding this information is patching the problem instead of solving it (the problem being that sites promote nonfree software); webmasters might not even be aware that there's an alternative to flash or that nonfree software is a social problem.
Very true, which is why (b) should be a temporary solution at most, if it's chosen at all.
- What do we expect from upstream, i.e. the browser developers?When I posted about this in identi.ca one of the KDE devs (@afiestas) offered to help fix this, but then we discovered that Konqueror wasn't suggesting Adobe Flash directly. Since KDE 4 came out, the KDE people tend to lean more on the free software side than on the open source side. If this bug gets solved with a warning for the user, then we'll probably have a better chance upstream.
So far I haven't even been able to implement (b) on deltah. I'm still figuring how it was packaged. :/ Perhaps I should just try to show a warning first.
By the way, I just noticed that this is a potential security risk: I could put whatever link I want for the pluginspage variable and send a user to a site that appears to be Adobe's but isn't. Someone could be doing some serious phishing with this. Upstream might be interested in putting a warning about this, if not for the problem of nonfree.
That would be handy. Though it would surprise me if nobody has ever considered this issue.
| [Prev in Thread] | Current Thread | [Next in Thread] |