GNU bug report logs - #28004
Chromium

Previous Next

Full log

Message #212 received at 28004 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 28004 <at> debbugs.gnu.org, Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: [bug#28004] Chromium 66 + status update
Date: Wed, 25 Apr 2018 13:00:06 -0400

[Message part 1 (text/plain, inline)]

On Tue, Apr 24, 2018 at 09:30:23PM +0200, Marius Bakke wrote:
> The reason I don't think it's a blocking issue, is because Chromium is
> a massive project and I cannot guarantee that it will never "call
> home".  So while I am intent on fixing the issue, especially since it's
> easy to test (chromium --user-data-dir=/tmp/foo), it's just one of many
> "call home" scenarios/antifeatures.  And if you enable extensions or log
> in all bets are off.  Even Inox, which goes great lengths to de-google
> it, admits that they can't guarantee privacy.

I agree with Marius here.

> Other scenarios include checking for IPv6 availability, testing for
> captive portal, etc.  And I think it even falls back to Google DNS if
> the system resolver is unresponsive.  :-(

I think that handling captive portals and falling back to Google DNS (or
any fallback DNS) are *great* features that address common problems that
most internet users can not work around on their own.

I don't believe these features are forbidden by the FSDG:

https://www.gnu.org/distros/free-system-distribution-guidelines.en.html

Finally, there are several packages that automatically send data out,
even in Guix. This is not a reason to exclude the software from Guix, in
my opinion.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.