GNU bug report logs - #49029
ungoogled-chromium failed to disable malware extension The Great Suspender

Previous Next

Full log

View this message in rfc822 format

From: "Jorge P. de Morais Neto" <jorge+list <at> disroot.org>
To: 49029 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: bug#49029: ungoogled-chromium failed to disable malware extension The Great Suspender
Date: Tue, 15 Jun 2021 13:59:44 -0300

Hi.  I didn't receive your email (I did this reply from Emacs debbugs
package).  Please include my email address in further messages to
mitigate the risk that I miss them.  I continue below:

On 06/15/21 09:49 , Leo Famulari wrote:
> Chromium is a program that is meant to be "evergreen".  Version
> numbers are not highlighted to the user and the software is supposed
> to update itself, quickly and often.  It's like a "rolling release"
> just for that program.

> A variant of the package that blocks communication to Google and
> requires one of us to update it is, if you trust the Chromium team,
> categorically less up-to-date than a "normal Chromium" downloaded
> directly from chromium.org, and thus also less "secure", as you've seen.

> I don't know exactly how the "disable malware extensions" mechanism
> works, but it's likely that the "ungoogling" disables the possibility
> that it can happen quickly, outside of full program updates.
>
> It's a tradeoff we (have to?) make to offer a variant of Chromium that
> is judged acceptable by us under the Free System Distribution
> Guidelines, which Guix follows:

I can accept a reasonable trade-off, but I still believe this should be
actively communicated to users.  It is not obvious.  If had known that
before, I would certainly have been more careful with extensions.
Indeed, now that I know, I have not only deleted my old
(ungoogled-)Chromium profile, but also, on the new profile, I installed
only HTTPS Everywhere and Privacy Badger extensions.  I have also
changed an important password that I remember having used on the
malware-infected Chromium.

> By the way, the Debian testing branch is the last to receive security
> updates, and in general has no guarantee of fast security updates.  If
> you want to use a Debian with more up-to-date software than the stable
> branch and also are concerned about your security, you might consider
> using Debian sid.

Thank you for the advice.  I already knew that though, and I think the
security risk of Debian testing is mitigated by my care.  I have
installed and configured debsecan.  It emails be about Debian
vulnerabilities, and then, in aptitude, I manually pull important
security updates from Debian unstable (sid).

That is a bit time-consuming, but I fear that going full unstable would
be too unreliable (more breakages) and would remove the option of
settling in stable without reinstalling.  I mean, since my sources.list
refers to bullseye, then, when it becomes stable, I will have Debian
stable and will have a choice whether (and when) to upgrade to the new
testing (bookworm).

Regards!

-- 
- https://stallmansupport.org "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Previous Next

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