From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBNn0-0005tn-T1 for guix-patches@gnu.org; Wed, 25 Apr 2018 13:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBNmw-0007nU-Tw for guix-patches@gnu.org; Wed, 25 Apr 2018 13:01:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:59844) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fBNmw-0007m8-EZ for guix-patches@gnu.org; Wed, 25 Apr 2018 13:01:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fBNmw-0002kK-3c for guix-patches@gnu.org; Wed, 25 Apr 2018 13:01:02 -0400 Subject: [bug#28004] Chromium 66 + status update Resent-Message-ID: Date: Wed, 25 Apr 2018 13:00:06 -0400 From: Leo Famulari Message-ID: <20180425170006.GA23453@jasmine.lan> References: <87y3qvb15k.fsf@fastmail.com> <87po32c47b.fsf@fastmail.com> <87po2own4s.fsf@dustycloud.org> <87woww8ojw.fsf@fastmail.com> <87tvs08ks0.fsf@fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <87tvs08ks0.fsf@fastmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Marius Bakke Cc: 28004@debbugs.gnu.org --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: 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. --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlrgtBIACgkQJkb6MLrK fwhz/xAAqBPjiWcv+I4QOxBK4jrcpSpz6iCdRZMZIMNYz+allgPivGafUV9VQGzT PDOfLEDlkbr3eujp7qfqev2FTG2nzwFrqdWqKwnkBqC+cR5nx00pJjnnwelMifHU LXFIh7Vai3jb2+AEqPZ3m5LvKwvKuKSkeBDyJd/45faQ/NQyUM30SEa6YLajYWCA BHNnl6bckKB/msmmOBT9vZS9zKcMLYfsBhnpimY06fBNe4FZ/Vh+7NSyNG9+oVg1 WwPgDNWCt9CkQbu6LKy2z8685iPrbl5dqWDXq24wmPpm7UkP173Nz8MjziMNHPIZ D+2Asir+x9lxdptFTBf2fvjm4L5Ry3hTA5fPV7zp5XaIb2cdzolu25HioQCXGUo0 ID1vitZdc15HHau3Mj9CN+WdQSck8/w8iN8x5vdqh1DanhanVHXZAQ8+aPmjkLvP 5TBuGwcUmsnFqdsIdcWiuTvw+w9C0wpRpp7Dvrk33MUPyziU82n3vUeMfJBsuo/L 80sCXDQms7A9FE37DbXFMVSYUEUqUzRdxphDPQ0bacsfx4ry5l4e52gFhdxzAkfR l1m/YDTywu4a56CKRf/AiszG7ptuTB6dAePu7oFDHQhlsEMl3YneAzgfrC5i4zSW IE6s37QR6oe6PolymjP7GMfACQW2Fs6poBHhkWy++0gZjMGV9B8= =nx9V -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--