From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Firefox 52's end of life, packaging Chromium Date: Sun, 02 Sep 2018 12:21:42 +0200 Message-ID: <87va7oyzbd.fsf@elephly.net> References: <87ftyx35pw.fsf@lassieur.org> <87pny09rgo.fsf@elephly.net> <875zzozcnf.fsf@netris.org> <871sacz9si.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fwPWF-0005Dw-ST for guix-devel@gnu.org; Sun, 02 Sep 2018 06:22:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fwPWC-0001tm-Kr for guix-devel@gnu.org; Sun, 02 Sep 2018 06:22:11 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21131) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fwPWC-0001sn-B0 for guix-devel@gnu.org; Sun, 02 Sep 2018 06:22:08 -0400 In-reply-to: <871sacz9si.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org, =?utf-8?Q?Cl=C3=A9ment?= Lassieur Hi Mark, > Mark H Weaver writes: > >> Ricardo Wurmus writes: >> >>> The TODO list for convenience: >>> >>> * There is still some data transmitted when starting the browser for the >>> first time. It seems related to the "domain_reliability" component. >>> * Remove remaining "Web Store" links. Currently I've only found it in >>> settings, under "accessibility" and "fonts". >>> * Opening settings transmits a bunch of data, the next version will >>> include the 'disable-translation-lang-fetch' patch from Inox. >>> * PDFium is built, but does not seem to work (the 'install' phase >>> probably needs tweaking). Might just disable it instead. >>> >>> It would be *very* nice if the first and third items could be solved >>> before merging, but I don=E2=80=99t consider them blockers. >> >> The GNU FSDG says "The distro must contain no DRM, no back doors, and no >> spyware." Since GNU Guix has committed to follow the FSDG, that means >> that we must not include programs that include spyware. We have >> committed ourselves to "removing such programs if any are discovered." >> >> Guix _is_ committed to the GNU FSDG, right? Of course it is. >> Do you agree that #1 and #3 look like spyware? If so, wouldn't that >> make them blockers? #3 looks like it=E2=80=99s fetching translation information, which seems legitimate. #1 is unclear to me, honestly, as it seems to be a bug. AIUI the =E2=80=9Cdomain_reliability=E2=80=9D component is not enabled by d= efault. For context I read a little about this =E2=80=9Cdomain_reliability=E2=80=9D= thing and found this Google document (I don=E2=80=99t know if this is an official publication by the Chromium developers): https://docs.google.com/document/d/14U0YA4dlzNYciq2ke0StEMjomdBUN6ocSt1kN= 03HJ0s/pub#h.20j0auqi631o >From what I understand, the =E2=80=9CDomain Reliability Monitoring=E2=80=9D= feature in Chromium is sending connection successes / failures for resources on a participating domain to a collection point determined by the operators of that domain, i.e. not necessarily to Google. I certainly would not want this to be enabled by default (and my understanding is that it is not), but it would be okay to let users opt in by enabling it. (Just like the default for Epiphany is to use an ad-blocker by default, with a setting to disable it.) I personally don=E2=80=99t trust Chromium (because user privacy is against upstream=E2=80=99s interests) and will not use it myself nor will I recomme= nd its use. But I trust that Marius and others who have been working on this package for months and evaluated its behaviour periodically across upgrades act in good faith and have made considerable efforts to remove anti-features. >From what I know about these remaining TODO items, they don=E2=80=99t look = like spyware to me. I could be wrong, of course, and I=E2=80=99m happy that we = have a community of people who are very vigilant, including Marius and yourself. Thank you for also asking about EME support in Chromium[1], which is something I did not think of. [1]: http://issues.guix.info/issue/28004#263 > I admit that it's unclear whether or not those data transmissions could > reasonably be called 'spyware', but at the very least their existence > provides cover for spyware added later, by conditioning users to accept > data transmission to Google when it hasn't been requested (by either the > user or the website being visited). By =E2=80=9Cspyware added later=E2=80=9D do you mean with future updates to= the package? Future updates will remain difficult because we=E2=80=99re dealing with an upstream that is not aligned with our values. We take patches from other communities, though, that focus on removing anti-features from Chromium. Future updates will have to be evaluated in the future. > In addition, I'm under the impression that efforts to remove spyware > from Chromium are considered a work-in-progress, i.e. unfinished, but I > admit that I haven't looked recently. Perhaps that impression is stale. I=E2=80=99m afraid removing spyware from Chromium will never truly be finis= hed until Google stop developing the browser. Future upgrades will need to undergo careful checks (much like upgrades to Shogun to ensure that all non-free software is stripped off). -- Ricardo