From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBNov-0006ZS-UR for guix-patches@gnu.org; Wed, 25 Apr 2018 13:03:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBNos-0000OJ-2t for guix-patches@gnu.org; Wed, 25 Apr 2018 13:03:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:59849) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fBNor-0000O6-Ul for guix-patches@gnu.org; Wed, 25 Apr 2018 13:03:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fBNor-0002nI-Lg for guix-patches@gnu.org; Wed, 25 Apr 2018 13:03:01 -0400 Subject: [bug#28004] Chromium 66 + status update Resent-Message-ID: Date: Wed, 25 Apr 2018 13:02:29 -0400 From: Leo Famulari Message-ID: <20180425170229.GB23453@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="MfFXiAuoTsnnDAfZ" 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 --MfFXiAuoTsnnDAfZ 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'd also like to point out that we cannot and should not try to guarantee privacy. Privacy from whom? For whom? Of course we want to offer a system that is reasonably private, but if we use words like "guarantee", we are setting an impossible and undefined goal for ourselves. --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlrgtKUACgkQJkb6MLrK fwgWwQ//aVWUsdRGoCZQR2PWunOEPeb7CbMUQrBOyS/AKhjGFOZ93cetcusPR57S EOVmOci26oxIy48ZCrfSw/7nCtML2HSlfAdlR7l7TyFyubswT/IIf0PO1vkZoKvS aS2BiKZm+DAGPFoFvCL/EvGYfrOfY9/KLmBmhHP17OqunfGUJNHt0F1BPFAzDKRA PTdsbsA3NN2VxRpbshfooU1kFUzZpL+MIFXmNG1rQb8BiOFjPKof9YhhGm7Z5otV VBLeYehnjbWRi19VrDg3IQD+eJHzwU1m8C6s42VHRuMmgW6jVfFn+UuXB6ZuFiAQ 2i02jxXATrXus2xBvYZhmkhU3+6qCB5Z9+pL6IQw2Fax6+8u4/k91I7qb+AqDevr jaRf4PVRTGq6Zh+PPwbCTtvNIc3mRODPKDZuKRNL2f087XrwO+nYwnvUigTgvh4f 0SVluYCmejn6LII0x5v8TZcDez/aqas3kEPvh3qpl9kKL2mxf3f6ZPkp81+Smk4w B2IM5qi4sfzlQSDyUxfxO8ANfOEP3RP5a3EovmWJ+iEaq4CVafO5vsadzHjEEFaH mFRKAy8bzMNZx0dbW42yRT0XmzzeyiJV7lxdCM3LpvH8cTcp+7LFYMc0Z7sESBOe oc6Cly9b5BEFshuQGJM072Q2SDy5B0Nl5Q+WTAvFVUre6SRUdhI= =BrDC -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ--