On Wed, 2 Jan 2013 08:25:21 +0100 Mike Hommey wrote: [...] > On Tue, Jan 01, 2013 at 05:03:35PM +0100, Francesco Poli (wintermute) wrote: [...] > > It seems that Firefox sends a bunch of user data (including IP address, > > used browser version, browser usage times, number of users and list > > of enabled extensions) to a Mozilla-Foundation-controlled server. > > Daily! > > No list of extensions is sent.
Mike, first of all thanks a lot for your prompt response. That's really appreciated, indeed. The fact that no list of extensions is sent is a (partial) relief, thanks for clarifying. > > > It seems that this is used to disable extensions which are deemed to > > be "dangerous" by Mozilla. But I think that this poses at least two issues: > > > > * the user should not be silently induced to trust Mozilla on which > > extensions are OK and which are "dangerous" > > They should be instead lured into installing malware. Please don't take offense: I have no special reason to think that Mozilla Corporation is doing anything nasty with the few data which are silently sent to them. I am implying nothing of the kind. I apologize, if I was not clear enough on this. It's just that, being a bit paranoid, I am always suspicious about programs that phone home. And I think that Debian users should *not* be forced to trust Mozilla Corporation without even being informed about this "feature"... > > > * the data sent to Mozilla seem to be unnecessarily detailed and thus > > are a privacy issue (after all, the same purpose could be achieved > > by _downloading_ a list of "dangerous" extensions from Mozilla, > > without _sending_ any data to them!) > > That's actually what happens, a list of blocked addons is downloaded. This is less creepy than depicted, then. Thanks again for clarifying. > No list of extensions is sent to Mozilla. The only information sent is: > - APP_ID > - APP_VERSION > - PRODUCT > - BUILD_ID > - BUILD_TARGET > - OS_VERSION > - LOCALE > - CHANNEL > - DISTRIBUTION > - DISTRIBUTION_VERSION > - PING_COUNT > - TOTAL_PING_COUNT > - DAYS_SINCE_LAST_PING > > Only the first two are strictly required. Well, then I wonder why the other information is sent at all... [...] > I'm not very much concerned by this kind of data being sent by default, > first, because it doesn't expose much of anything, I am under the impression that some partial info about usage habits may be inferred by the three *PING* values. [...] > and second, because > the server-side code is also open-source. > > https://github.com/mozilla/zamboni/blob/master/lib/urls_base.py#L24 > https://github.com/mozilla/zamboni/blob/master/apps/blocklist/views.py That's true, but, once again, users must trust Mozilla Corporation that the publicly known server-side code is actually what is being run by the Mozilla-controlled server. I guess it actually is, I have no special reason to think that Mozilla Corporation is telling lies, but, nonetheless... believing this requires trusting Mozilla Corporation, something that not all Debian users are necessarily comfortable with... > > > Hence, I am convinced that this feature should be disabled by default > > in Debian's Iceweasel, unless the user explicitly re-enables it. > > Hence, I am not convinced this feature should be disabled by default, > especially since this is a useful malware protection (and yes, it's > pretty easy to encounter such malware, there have been some spreading > through facebook a few months ago, for instance). I personally try as much as possible to avoid installing extensions from within Iceweasel for my regular user: I strongly prefer to install packaged extensions for the entire system through aptitude. But I acknowledge that several users will sure install extensions from within Iceweasel. Hence, I am *not* saying that this may not be a useful malware protection. Indeed it may be. But users must trust Mozilla Corporation that it will not be abused for nasty purposes. That's why I think it should not be *silently* enabled by default and buried in some obscure about:config setting. I hope I clarified my opinion. Thanks for understanding. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpRfQrt_98uy.pgp
Description: PGP signature
