Firefox 52's end of life, packaging Chromium

Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Hi,

Firefox 52 isn't supported anymore upstream[1] and we don't have a
package for Firefox 60.  Currently the only alternative is Epiphany but
it's close to unusable (it crashes every 5 minutes, and sometimes
freezes my computer).

So the question is: can we push the Chromium package?  I've read it's
almost ready[2].  It's probably far better than everything we have,
despite not being totally 'finished'.  Maybe we can add what's left to
do as a TODO and fix the package later?

What do you think?

Clément

[1]: https://blog.mozilla.org/futurereleases/2018/01/11/announcing-esr60-policy-engine/
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28004#233

Re: Firefox 52's end of life, packaging Chromium

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

Shameless plug: I'm about half-way into getting Next browser packaged for Guix.

Next is a hackable browser written in Common Lisp, so I figured many Guixers
might like it :)

http://next.atlas.engineer/

My progress is on the wip-next-browser branch.  Any help with Common Lisp
packaging is more than welcome, there are a few challenges there at the moment
(among others, packaging SWANK and CFFI libraries).

It's still in an early phase of development, but it looks most promising!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Christopher Lemmer Webber]

Clément Lassieur writes:

> Hi,
>
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).
>
> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].  It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?

+1 on this.  Considering how well attacked browsers are, not providing a
generally usable recent browser is putting our users at risk.

Re: Firefox 52's end of life, packaging Chromium

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Wed, Aug 29, 2018 at 11:03:07AM +0200, Clément Lassieur wrote:
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).

Please report these crashes to <bug-guix@gnu.org> :)

> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].  It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?

+1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Amirouche Boubekki]

Hello all :]

I will confess that if I use Ubuntu today, long story short, it's
because of the web browser.
I could not find my way around patchelf so I gave up and installed Ubuntu.

The matter relates to me a lot!

Le mer. 29 août 2018 à 11:03, Clément Lassieur <clement@lassieur.org> a écrit :
>
> Hi,
>
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.
>   Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).

Here the list of known issues:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;include=subject:epiphany

>
>
> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].

>   It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?
>
> What do you think?
>
> Clément
>
> [1]: https://blog.mozilla.org/futurereleases/2018/01/11/announcing-esr60-policy-engine/
> [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28004#233


Not having access to a recent web browser can be a pain. That said
they are alternatives.
Many that don't involve more guix energy to be sucked into supporting
chromium or firefox
which I predict to be really painful in the future. Web browsers are
not just about getting the
initial package inside the main repository. It's a lot of pain.

What I think is that we choose our battle wisely. If this discussion
did not pop on the mailling list
I would be doing something else. Nevermind.

Let's choose our battle wisely. I want to remind that the core of the guix users
are GNU followers and are also anything but pro web or pro web browser or a
variation of that. I don't say every GNU follower is against the www.
It's not the
core of potential guix users

I won't help to bring firefox or chromium because I think even if done
ethically will
be a worthless time sink.

Let's be rational, and try to answer the following questions:

1) What firefox or chromium are useful for compared to other graphical
web browsers?

2) What will chromium bring to guix and guix developers that they
can't do otherwise?

3) What are the minimal features for a graphical web browser to be
useful for a guix developer?


I was going to say, let's find or build a minimal browser that use
qtwebkit but even that is
worthless because several people reported performance build issues
about it on IRC.

Sorry, it seems like a worthless timesink to me. The only thing
worthwhile is to build a
web browser using Guile but that will take several years before one
can use it instead
of Chromium... I still don't know why people would want to use that
except for SaaSS
stuff.

They are workarounds.

---

> The Internet was done so well that most people think of it as a
> natural resource like the Pacific Ocean, rather than something that
> was man-made. When was the last time a technology with a scale like
> that was so error-free? The Web, in comparison, is a joke. The Web was
> done by amateurs.

Alan Kay.

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Hi Amirouche,

Thanks for your answer.

Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:

> Let's choose our battle wisely. I want to remind that the core of the
> guix users are GNU followers and are also anything but pro web or pro
> web browser or a variation of that. I don't say every GNU follower is
> against the www.  It's not the core of potential guix users

Guix does not target GNU followers.  It targets all users.  GNU
followers are a very small part of them and they are not a problem
because they usually find their way around.  The problem is all users
that are not GNU followers (and some GNU followers like me) who need a
modern browser.  We definitely don't want to frighten them with our
nostalgic ideas about how the web should be and how a browser should be.
They just want a browser that works.  As long as it's free software,
let's not complicate things for them.  Otherwise we'll never grow.

> 1) What firefox or chromium are useful for compared to other graphical
> web browsers?
>
> 2) What will chromium bring to guix and guix developers that they
> can't do otherwise?
>
> 3) What are the minimal features for a graphical web browser to be
> useful for a guix developer?

Today I needed to browse some sites, at work, and I couldn't do it with
anything else than Firefox and Chromium.  I'm not alone.  Lots of people
need to browse complicated sites that they don't know in advance.  We
don't want them to wonder, every time: is it going to work with the
browser shipped with Guix?

> I still don't know why people would want to use that except for SaaSS
> stuff.

My Epiphany issues happened while reading newspapers.

Clément

Re: Firefox 52's end of life, packaging Chromium

[Amirouche Boubekki]

Le jeu. 30 août 2018 à 00:35, Clément Lassieur <clement@lassieur.org> a écrit :
>
> Hi Amirouche,
>
> Thanks for your answer.
>
> Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:
>
> > Let's choose our battle wisely. I want to remind that the core of the
> > guix users are GNU followers and are also anything but pro web or pro
> > web browser or a variation of that. I don't say every GNU follower is
> > against the www.  It's not the core of potential guix users
>
> Guix does not target GNU followers.

Good news.

> It targets all users.  GNU
> followers are a very small part of them and they are not a problem
> because they usually find their way around.

Yes.

> The problem is all users
> that are not GNU followers (and some GNU followers like me) who need a
> modern browser.

Out of curiosity, please let us know what you need from the "modern browser"?

On my side, I need a debugger for doing web frontends.

> We definitely don't want to frighten them with our
> nostalgic ideas about how the web should be and how a browser should be.

I don't want to be rude at all, especially with who has been nice to me.
But following that kind of logic cannot always be a good way forward.

> They just want a browser that works.  As long as it's free software,
> let's not complicate things for them.

I agree. I am wondering what that browser make it the browser they want.

> Otherwise we'll never grow.

Sorry again to disagree. I don't think the future of guix is in the desktop.
It has been said that GNU/Linux will kill windows on the desktop for a decade.
It did not happen. Nowadays, people use their computer only to run a browser
whatever the OS... Given that, It seems to defy the de facto
definition of a modern
OS not to provide a "good enough" web experience.

Snap!

>
> > 1) What firefox or chromium are useful for comparing to other graphical
> > web browsers?
> >
> > 2) What will chromium bring to guix and guix developers that they
> > can't do otherwise?
> >
> > 3) What are the minimal features for a graphical web browser to be
> > useful for a guix developer?
>
> Today I needed to browse some sites, at work, and I couldn't do it with
> anything else than Firefox and Chromium.  I'm not alone.  Lots of people
> need to browse complicated sites that they don't know in advance.

> We don't want them to wonder, every time: is it going to work with the browser shipped with Guix?

Agreed.

Ok. I will try to help  with

a) chromium
b) investigate what people are expecting from a modern web browser
c) See whether qtwebkit is follows upstream security updates and test
it to see if it's stable
d) do the same with webkit-gtk

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Amirouche Boubekki <amirouche.boubekki@gmail.com> writes:

>> The problem is all users
>> that are not GNU followers (and some GNU followers like me) who need a
>> modern browser.
>
> Out of curiosity, please let us know what you need from the "modern
> browser"?
>
> On my side, I need a debugger for doing web frontends.

I need to browse all javascript bloated newspapers.

>> We definitely don't want to frighten them with our
>> nostalgic ideas about how the web should be and how a browser should be.
>
> I don't want to be rude at all, especially with who has been nice to me.
> But following that kind of logic cannot always be a good way forward.

:-)  If I sounded rude, I sincerely apologize.  I used the word
'nostalgic' because I do feel nostalgic: I miss the time when the web
wasn't that complicated.  And I really think some users might refuse to
install GuixSD just because it lacks Firefox or Chromium, which would be
sad.

>> They just want a browser that works.  As long as it's free software,
>> let's not complicate things for them.
>
> I agree. I am wondering what that browser make it the browser they
> want.

'They' possibly want anything that the main browsers (Firefox, Chromium,
Edge, IE, Safari) provide because a lot of sites are built based on
these 'modern' features.

>> Otherwise we'll never grow.
>
> Sorry again to disagree. I don't think the future of guix is in the
> desktop.  It has been said that GNU/Linux will kill windows on the
> desktop for a decade.  It did not happen. Nowadays, people use their
> computer only to run a browser whatever the OS... Given that, It seems
> to defy the de facto definition of a modern OS not to provide a "good
> enough" web experience.

There are people who need GuixSD features *and* a 'modern' browser.  I
don't think the choice should be either the OS or the browser.  I
personally need both.  (But maybe I misunderstood your point?)

> Ok. I will try to help  with
>
> a) chromium

About that, my point was that the actual state is good enough to be
pushed.  I've seen in another email that you succeeded in building it.
Of course any work on the TODO list is very welcome :-)  But I think we
should push it before those improvements are done, given the urgency.

> b) investigate what people are expecting from a modern web browser

Again, I believe that we should package every feature that are provided
by Firefox and Chromium, as long as they are ethical, because I think at
some point some Guix users will need them.

> c) See whether qtwebkit is follows upstream security updates and test
> it to see if it's stable
> d) do the same with webkit-gtk

Thank you!

Clément

Re: Firefox 52's end of life, packaging Chromium

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote:
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).

This is a big problem.  Thanks for keeping up with the status.

I'll get into contact with the necessary people on behalf of GNU to
figure out the current status of IceCat.

But as was stated in another thread, once we _do_ have an updated IceCat
source distribution, we need it packaged for Guix, and that is quite the
undertaking.  Has anyone pursued packaging modern versions of vanilla FF
in recent months?

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Hi Mike,

Mike Gerwitz <mtg@gnu.org> writes:

> On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote:
>> Firefox 52 isn't supported anymore upstream[1] and we don't have a
>> package for Firefox 60.  Currently the only alternative is Epiphany but
>> it's close to unusable (it crashes every 5 minutes, and sometimes
>> freezes my computer).
>
> This is a big problem.  Thanks for keeping up with the status.
>
> I'll get into contact with the necessary people on behalf of GNU to
> figure out the current status of IceCat.

Thank you!

> But as was stated in another thread, once we _do_ have an updated IceCat
> source distribution, we need it packaged for Guix, and that is quite the
> undertaking.  Has anyone pursued packaging modern versions of vanilla FF
> in recent months?

The problem is a technical problem.  We would have with Icecat 60 the
same packaging difficulties we have with Firefox 60.  Whether we choose
Icecat or Firefox is unrelated.

Clément

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hi,

Clément Lassieur <clement@lassieur.org> skribis:

> The problem is a technical problem.  We would have with Icecat 60 the
> same packaging difficulties we have with Firefox 60.  Whether we choose
> Icecat or Firefox is unrelated.

That means pulling a number of Rust dependencies, is that right?

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Ludovic Courtès transcribed 331 bytes:
> Hi,
> 
> Clément Lassieur <clement@lassieur.org> skribis:
> 
> > The problem is a technical problem.  We would have with Icecat 60 the
> > same packaging difficulties we have with Firefox 60.  Whether we choose
> > Icecat or Firefox is unrelated.
> 
> That means pulling a number of Rust dependencies, is that right?

No, they are bundled. Now rust itself is a problem on our side, so I
haven't even attempted to unbundle them.

> Thanks,
> Ludo’.
> 

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Nils Gillmann <ng0@n0.is> writes:

> Ludovic Courtès transcribed 331 bytes:
>> Hi,
>> 
>> Clément Lassieur <clement@lassieur.org> skribis:
>> 
>> > The problem is a technical problem.  We would have with Icecat 60 the
>> > same packaging difficulties we have with Firefox 60.  Whether we choose
>> > Icecat or Firefox is unrelated.
>> 
>> That means pulling a number of Rust dependencies, is that right?
>
> No, they are bundled. Now rust itself is a problem on our side, so I
> haven't even attempted to unbundle them.

Oh right, ok.

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Nils Gillmann <ng0@n0.is> skribis:

> Ludovic Courtès transcribed 331 bytes:
>> Hi,
>> 
>> Clément Lassieur <clement@lassieur.org> skribis:
>> 
>> > The problem is a technical problem.  We would have with Icecat 60 the
>> > same packaging difficulties we have with Firefox 60.  Whether we choose
>> > Icecat or Firefox is unrelated.
>> 
>> That means pulling a number of Rust dependencies, is that right?
>
> No, they are bundled.

OK.  Ideally we’d unbundle them but the point is moot since we probably
don’t have package for these currently.  IOW, I think we could keep
those bundled dependencies initially, and then incrementally unbundle
them as we add more Rust packages to our package collection.

> Now rust itself is a problem on our side, so I haven't even attempted
> to unbundle them.

Our Rust package is supposed to work fine thanks to the work of Nikolai,
Danny, and others, so I’m (naively?) confident.  :-)

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Ludovic Courtès transcribed 990 bytes:
> Nils Gillmann <ng0@n0.is> skribis:
> 
> > Ludovic Courtès transcribed 331 bytes:
> >> Hi,
> >> 
> >> Clément Lassieur <clement@lassieur.org> skribis:
> >> 
> >> > The problem is a technical problem.  We would have with Icecat 60 the
> >> > same packaging difficulties we have with Firefox 60.  Whether we choose
> >> > Icecat or Firefox is unrelated.
> >> 
> >> That means pulling a number of Rust dependencies, is that right?
> >
> > No, they are bundled.
> 
> OK.  Ideally we’d unbundle them but the point is moot since we probably
> don’t have package for these currently.  IOW, I think we could keep
> those bundled dependencies initially, and then incrementally unbundle
> them as we add more Rust packages to our package collection.
> 
> > Now rust itself is a problem on our side, so I haven't even attempted
> > to unbundle them.
> 
> Our Rust package is supposed to work fine thanks to the work of Nikolai,
> Danny, and others, so I’m (naively?) confident.  :-)

Rust alone yes, but rust crates beyond single package dependencies:
no.  At least I haven't seen a confirmation that all of the defects of
the build-system have been adressed in the last months (year).

> Thanks,
> Ludo’.
> 

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Clément Lassieur <clement@lassieur.org> skribis:
>
>> The problem is a technical problem.  We would have with Icecat 60 the
>> same packaging difficulties we have with Firefox 60.  Whether we choose
>> Icecat or Firefox is unrelated.
>
> That means pulling a number of Rust dependencies, is that right?

Yes, if my understanding is correct.

Re: Firefox 52's end of life, packaging Chromium

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Thu, Aug 30, 2018 at 07:14:37 +0200, Clément Lassieur wrote:
> The problem is a technical problem.  We would have with Icecat 60 the
> same packaging difficulties we have with Firefox 60.  Whether we choose
> Icecat or Firefox is unrelated.

Right, which is why I was curious if there were recent efforts with
vanilla Firefox, since those efforts would directly apply to IceCat.

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Mike Gerwitz transcribed 1.8K bytes:
> On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote:
> > Firefox 52 isn't supported anymore upstream[1] and we don't have a
> > package for Firefox 60.  Currently the only alternative is Epiphany but
> > it's close to unusable (it crashes every 5 minutes, and sometimes
> > freezes my computer).
> 
> This is a big problem.  Thanks for keeping up with the status.
> 
> I'll get into contact with the necessary people on behalf of GNU to
> figure out the current status of IceCat.
> 
> But as was stated in another thread, once we _do_ have an updated IceCat
> source distribution, we need it packaged for Guix, and that is quite the
> undertaking.  Has anyone pursued packaging modern versions of vanilla FF
> in recent months?

Yes, I have. The outcome was not so much progress because Firefox
starting at a certain version does no longer allow disabling the build
of the rust crates. You then need a way to deal with the "breakage" in
the directory 'thirdparty/rust/' and its subdirectories.
Progress could be achieved with a phase which either records our changes
to the checksum related files or reverts our changes.

> -- 
> Mike Gerwitz
> Free Software Hacker+Activist | GNU Maintainer & Volunteer
> GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
> https://mikegerwitz.com

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Nils Gillmann transcribed 1.3K bytes:
> Mike Gerwitz transcribed 1.8K bytes:
> > On Wed, Aug 29, 2018 at 11:03:07 +0200, Clément Lassieur wrote:
> > > Firefox 52 isn't supported anymore upstream[1] and we don't have a
> > > package for Firefox 60.  Currently the only alternative is Epiphany but
> > > it's close to unusable (it crashes every 5 minutes, and sometimes
> > > freezes my computer).
> > 
> > This is a big problem.  Thanks for keeping up with the status.
> > 
> > I'll get into contact with the necessary people on behalf of GNU to
> > figure out the current status of IceCat.
> > 
> > But as was stated in another thread, once we _do_ have an updated IceCat
> > source distribution, we need it packaged for Guix, and that is quite the
> > undertaking.  Has anyone pursued packaging modern versions of vanilla FF
> > in recent months?
> 
> Yes, I have. The outcome was not so much progress because Firefox
> starting at a certain version does no longer allow disabling the build
> of the rust crates. You then need a way to deal with the "breakage" in
> the directory 'thirdparty/rust/' and its subdirectories.
> Progress could be achieved with a phase which either records our changes
> to the checksum related files or reverts our changes.

Addition: Aurora 52.7.2 is the last version I have packaged without
the mandatory rust.

> > -- 
> > Mike Gerwitz
> > Free Software Hacker+Activist | GNU Maintainer & Volunteer
> > GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
> > https://mikegerwitz.com
> 
> 
> 

Re: Firefox 52's end of life, packaging Chromium

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Thu, Aug 30, 2018 at 09:07:39 +0000, Nils Gillmann wrote:
> Mike Gerwitz transcribed 1.8K bytes:
>> But as was stated in another thread, once we _do_ have an updated IceCat
>> source distribution, we need it packaged for Guix, and that is quite the
>> undertaking.  Has anyone pursued packaging modern versions of vanilla FF
>> in recent months?
>
> Yes, I have. The outcome was not so much progress because Firefox
> starting at a certain version does no longer allow disabling the build
> of the rust crates. You then need a way to deal with the "breakage" in
> the directory 'thirdparty/rust/' and its subdirectories.
> Progress could be achieved with a phase which either records our changes
> to the checksum related files or reverts our changes.

Thank you for your efforts!

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Ricardo Wurmus]

Hi Clément,

> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).

I’m surprised to hear that you’ve had problems with Epiphany.  I’m using
it daily for dozens of tabs and I recommend it to people who cannot use
Icecat.  It’s difficult to send good bug reports when the browser
freezes the computer, of course, but it would be helpful to get more
information about these crashes, if you can reproduce them.

> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].

The TODO list for convenience:

--8<---------------cut here---------------start------------->8---
* 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.
--8<---------------cut here---------------end--------------->8---

It would be *very* nice if the first and third items could be solved
before merging, but I don’t consider them blockers.  Would someone like
to investigate one of these problems?

As has been stated multiple times in the discussion of this evolving
patch set, we cannot guarantee privacy, but we can make attempts to
remove problems as they become known.  This will remain an uphill battle
and in future iterations of this package we should try to integrate more
patches provided by other groups working on removing anti-features from
Chromium.

Thanks to Marius for driving the evolution of this patch set through
multiple upgrades and bringing it to a usable state!

My personal recommendation is to use Epiphany if possible (and Icecat
once version 60 is ready) and to be careful with Chromium.

--
Ricardo

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Hi Ricardo,

Thank you for your reply.

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Clément,
>
>> Firefox 52 isn't supported anymore upstream[1] and we don't have a
>> package for Firefox 60.  Currently the only alternative is Epiphany but
>> it's close to unusable (it crashes every 5 minutes, and sometimes
>> freezes my computer).
>
> I’m surprised to hear that you’ve had problems with Epiphany.  I’m using
> it daily for dozens of tabs and I recommend it to people who cannot use
> Icecat.  It’s difficult to send good bug reports when the browser
> freezes the computer, of course, but it would be helpful to get more
> information about these crashes, if you can reproduce them.

Sure, I'll report them when I find the time.

>> So the question is: can we push the Chromium package?  I've read it's
>> almost ready[2].
>
> The TODO list for convenience:
>
> --8<---------------cut here---------------start------------->8---
> * 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.
> --8<---------------cut here---------------end--------------->8---
>
> It would be *very* nice if the first and third items could be solved
> before merging, but I don’t consider them blockers.

It's not clear to me :-)  Does it mean we can merge?

> As has been stated multiple times in the discussion of this evolving
> patch set, we cannot guarantee privacy, but we can make attempts to
> remove problems as they become known.  This will remain an uphill battle
> and in future iterations of this package we should try to integrate more
> patches provided by other groups working on removing anti-features from
> Chromium.
>
> Thanks to Marius for driving the evolution of this patch set through
> multiple upgrades and bringing it to a usable state!
>
> My personal recommendation is to use Epiphany if possible (and Icecat
> once version 60 is ready) and to be careful with Chromium.

Thank you for this important information.

Clément

Re: Firefox 52's end of life, packaging Chromium

[Ricardo Wurmus]

Hi Clément,

>>> So the question is: can we push the Chromium package?  I've read it's
>>> almost ready[2].
>>
>> The TODO list for convenience:
>>
>> --8<---------------cut here---------------start------------->8---
>> * 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.
>> --8<---------------cut here---------------end--------------->8---
>>
>> It would be *very* nice if the first and third items could be solved
>> before merging, but I don’t consider them blockers.
>
> It's not clear to me :-)  Does it mean we can merge?

I’ll leave that up to Marius, because he is much more familiar with the
patch than I am.

I would not object to merging it, but I’d like to see these TODOs as
separate bug reports, with the first and third items at a higher
severity than “normal”.

--
Ricardo

Re: Firefox 52's end of life, packaging Chromium

[Amin Bandali]

Ricardo Wurmus <rekado@elephly.net> writes:

>> So the question is: can we push the Chromium package?  I've read it's
>> almost ready[2].
>
> The TODO list for convenience:
>
> --8<---------------cut here---------------start------------->8---
> * 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.
> --8<---------------cut here---------------end--------------->8---
>
> It would be *very* nice if the first and third items could be solved
> before merging, but I don’t consider them blockers.  Would someone like
> to investigate one of these problems?
>
> As has been stated multiple times in the discussion of this evolving
> patch set, we cannot guarantee privacy, but we can make attempts to
> remove problems as they become known.  This will remain an uphill battle
> and in future iterations of this package we should try to integrate more
> patches provided by other groups working on removing anti-features from
> Chromium.

I highly recommend looking into ungoogled-chromium [0], which
"modifies Google Chromium to remove Google integration and
enhance privacy, control, and transparency".  It's not exactly a
fork, but rather a series of patches and modifications they apply
to each Chromium release.

In terms of documentation, they have a high-level description of
the various components and patches [1], and build instructions
for a few platforms and distros [2].  There was also an attempt
to make a nix package a while ago [3], which may be helpful to
look at.

[0]: https://github.com/Eloston/ungoogled-chromium
[1]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md
[2]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md
[3]: https://github.com/NixOS/nixpkgs/pull/30916

-- 
Amin Bandali      |  GNU webmaster  | Grad student, UWaterloo
https://aminb.org | https://gnu.org |    https://aminb.org/uw
GnuPG Key: CDDE 75F9 0353 8E71 813C  DA27 D1FB A366 27D6 5876

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hi,

Amin Bandali <amin@gnu.org> skribis:

> I highly recommend looking into ungoogled-chromium [0], which
> "modifies Google Chromium to remove Google integration and
> enhance privacy, control, and transparency".  It's not exactly a
> fork, but rather a series of patches and modifications they apply
> to each Chromium release.

Looks interesting!  Perhaps eventually we should package this instead of
Chromium; I expect the package definition to be essentially the same,
right?

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Ludovic Courtès transcribed 507 bytes:
> Hi,
> 
> Amin Bandali <amin@gnu.org> skribis:
> 
> > I highly recommend looking into ungoogled-chromium [0], which
> > "modifies Google Chromium to remove Google integration and
> > enhance privacy, control, and transparency".  It's not exactly a
> > fork, but rather a series of patches and modifications they apply
> > to each Chromium release.
> 
> Looks interesting!  Perhaps eventually we should package this instead of
> Chromium; I expect the package definition to be essentially the same,
> right?

Please read into the chromium thread or search locally through it -
Marius already had some comments on ungoogled-chromium. Our chromium
browser is not just chromium taken from upstream. Many (maintained)
patches are taken and applied.

> Thanks,
> Ludo’.
> 

Re: Firefox 52's end of life, packaging Chromium

[Amin Bandali]

Nils Gillmann <ng0@n0.is> writes:

> Please read into the chromium thread or search locally through it -
> Marius already had some comments on ungoogled-chromium. Our chromium
> browser is not just chromium taken from upstream. Many (maintained)
> patches are taken and applied.

Thanks for mentioning this.  You seem to be referring to the [0]
message and the [1] package from last year, which I hadn't seen
before.

To quote Marius,

,----[ Marius Bakke <mbakke@fastmail.com> ]
| I actually picked most of the patches from ungoogled-chromium (which
| includes inox and iridium), but skipped "high maintenance" ones. This
| started as an attempt to package that very project, but they were
| lagging too far behind upstream IMO.
| 
| FSDG problems is the reason I haven't advertised it. At the very least,
| the Google integrations should be disabled and analytics removed (but
| Chromium can't currently build without either). I think if most of the
| "FIXMEs" are resolved upstream, it might be eligible for a free distro.
| 
| Now that the cat is out of the box, feel free to send patches somewhere
| and I'll incorporate them in the branch :-)
`----

With regards to FSDG problems, I wonder what the status is today,
considering that ungoogled-chromium's patch sets seem to have
grown a fair bit in number [2], and might be already addressing
some of the issues.

As for the "lagging too far behind upstream" issue, that doesn't
seem to be the case anymore: looking at releases on [3] and [4]
it looks like ungoogled-chromium's latest shipped release matches
the latest released chromium version.  Granted, I have noticed in
the past for ungoogled-chromium to lag behind the latest release
by a week or two, that'd still be better compared to the current
situation with respect to the current Firefox/IceWeasel release.

  -amin

[0]: https://lists.gnu.org/r/guix-devel/2017-01/msg00928.html
[1]: https://github.com/guix-users/guix-nonfree/blob/master/gnu/packages/chromium.scm
[2]: https://github.com/Eloston/ungoogled-chromium/tree/master/patches/ungoogled-chromium
[3]: https://ungoogled-software.github.io/ungoogled-chromium-binaries/
[4]: https://github.com/Eloston/ungoogled-chromium/releases/tag/68.0.3440.106-2

Re: Firefox 52's end of life, packaging Chromium

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

Amin Bandali <amin@gnu.org> writes:

> Nils Gillmann <ng0@n0.is> writes:
>
>> Please read into the chromium thread or search locally through it -
>> Marius already had some comments on ungoogled-chromium. Our chromium
>> browser is not just chromium taken from upstream. Many (maintained)
>> patches are taken and applied.
>
> Thanks for mentioning this.  You seem to be referring to the [0]
> message and the [1] package from last year, which I hadn't seen
> before.
>
> To quote Marius,
>
> ,----[ Marius Bakke <mbakke@fastmail.com> ]
> | I actually picked most of the patches from ungoogled-chromium (which
> | includes inox and iridium), but skipped "high maintenance" ones. This
> | started as an attempt to package that very project, but they were
> | lagging too far behind upstream IMO.
> | 
> | FSDG problems is the reason I haven't advertised it. At the very least,
> | the Google integrations should be disabled and analytics removed (but
> | Chromium can't currently build without either). I think if most of the
> | "FIXMEs" are resolved upstream, it might be eligible for a free distro.
> | 
> | Now that the cat is out of the box, feel free to send patches somewhere
> | and I'll incorporate them in the branch :-)
> `----
>
> With regards to FSDG problems, I wonder what the status is today,
> considering that ungoogled-chromium's patch sets seem to have
> grown a fair bit in number [2], and might be already addressing
> some of the issues.
>
> As for the "lagging too far behind upstream" issue, that doesn't
> seem to be the case anymore: looking at releases on [3] and [4]
> it looks like ungoogled-chromium's latest shipped release matches
> the latest released chromium version.  Granted, I have noticed in
> the past for ungoogled-chromium to lag behind the latest release
> by a week or two, that'd still be better compared to the current
> situation with respect to the current Firefox/IceWeasel release.

Indeed, Ungoogled have catched up pretty well and is a viable choice
nowadays.  If it helps get Chromium into Guix I'm all for it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Mark H Weaver]

Marius Bakke <mbakke@fastmail.com> writes:

> Amin Bandali <amin@gnu.org> writes:
>
>> As for the "lagging too far behind upstream" issue, that doesn't
>> seem to be the case anymore: looking at releases on [3] and [4]
>> it looks like ungoogled-chromium's latest shipped release matches
>> the latest released chromium version.  Granted, I have noticed in
>> the past for ungoogled-chromium to lag behind the latest release
>> by a week or two, that'd still be better compared to the current
>> situation with respect to the current Firefox/IceWeasel release.
>
> Indeed, Ungoogled have catched up pretty well and is a viable choice
> nowadays.  If it helps get Chromium into Guix I'm all for it.

I think it would be much better to explicitly use an upstream project
that is specifically focused on ongoing removal of spyware, than to rely
on Guix developers to do this ongoing work and to update our list of
cherry-picked patches with every update.

There is likely to come a time when our attention is elsewhere, and it
will sometimes be tempting to update our Chromium package without
properly researching whether additional spyware-removal patches should
be added.

What do you think?

Thanks for all of your hard work on this, Marius.

      Mark

Re: Firefox 52's end of life, packaging Chromium

[Joshua Branson]

Amin Bandali <amin@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>> So the question is: can we push the Chromium package?  I've read it's
>>> almost ready[2].
>>
>> The TODO list for convenience:
>>
>> --8<---------------cut here---------------start------------->8---
>> * 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.
>> --8<---------------cut here---------------end--------------->8---
>>
>> It would be *very* nice if the first and third items could be solved
>> before merging, but I don’t consider them blockers.  Would someone like
>> to investigate one of these problems?
>>
>> As has been stated multiple times in the discussion of this evolving
>> patch set, we cannot guarantee privacy, but we can make attempts to
>> remove problems as they become known.  This will remain an uphill battle
>> and in future iterations of this package we should try to integrate more
>> patches provided by other groups working on removing anti-features from
>> Chromium.
>
> I highly recommend looking into ungoogled-chromium [0], which
> "modifies Google Chromium to remove Google integration and
> enhance privacy, control, and transparency".  It's not exactly a
> fork, but rather a series of patches and modifications they apply
> to each Chromium release.

There is also the Brave browser

https://brave.com/

>
> In terms of documentation, they have a high-level description of
> the various components and patches [1], and build instructions
> for a few platforms and distros [2].  There was also an attempt
> to make a nix package a while ago [3], which may be helpful to
> look at.
>
> [0]: https://github.com/Eloston/ungoogled-chromium
> [1]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md
> [2]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md
> [3]: https://github.com/NixOS/nixpkgs/pull/30916

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Joshua Branson transcribed 2.3K bytes:
> Amin Bandali <amin@gnu.org> writes:
> 
> > Ricardo Wurmus <rekado@elephly.net> writes:
> >
> >>> So the question is: can we push the Chromium package?  I've read it's
> >>> almost ready[2].
> >>
> >> The TODO list for convenience:
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> * 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.
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> It would be *very* nice if the first and third items could be solved
> >> before merging, but I don’t consider them blockers.  Would someone like
> >> to investigate one of these problems?
> >>
> >> As has been stated multiple times in the discussion of this evolving
> >> patch set, we cannot guarantee privacy, but we can make attempts to
> >> remove problems as they become known.  This will remain an uphill battle
> >> and in future iterations of this package we should try to integrate more
> >> patches provided by other groups working on removing anti-features from
> >> Chromium.
> >
> > I highly recommend looking into ungoogled-chromium [0], which
> > "modifies Google Chromium to remove Google integration and
> > enhance privacy, control, and transparency".  It's not exactly a
> > fork, but rather a series of patches and modifications they apply
> > to each Chromium release.
> 
> There is also the Brave browser
> 
> https://brave.com/

It would very likely not be accepted in Guix. At least by my
interpretation of what we have included and cared for so far. Brave is
basically replacing Ads with other Ads and all the requests you make
in the browser are send through their proprietary servers.
Could be that we already discussed Brave a while back on irc or on
this list. Even when rejected, no onw forbids anyone to provide it
outside of core.

> >
> > In terms of documentation, they have a high-level description of
> > the various components and patches [1], and build instructions
> > for a few platforms and distros [2].  There was also an attempt
> > to make a nix package a while ago [3], which may be helpful to
> > look at.
> >
> > [0]: https://github.com/Eloston/ungoogled-chromium
> > [1]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md
> > [2]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md
> > [3]: https://github.com/NixOS/nixpkgs/pull/30916
> 

Re: Firefox 52's end of life, packaging Chromium

[Joshua Branson]

Nils Gillmann <ng0@n0.is> writes:

> Joshua Branson transcribed 2.3K bytes:
>> Amin Bandali <amin@gnu.org> writes:
>> 
>> > Ricardo Wurmus <rekado@elephly.net> writes:
>> >
>> 
>> There is also the Brave browser
>> 
>> https://brave.com/
>
> It would very likely not be accepted in Guix. At least by my
> interpretation of what we have included and cared for so far. Brave is
> basically replacing Ads with other Ads and all the requests you make
> in the browser are send through their proprietary servers.
> Could be that we already discussed Brave a while back on irc or on
> this list. Even when rejected, no onw forbids anyone to provide it
> outside of core.

Oh really?  I had no idea that they send stuff through their proprietary
servers.  That doesn't really make it free software.  :(  Bummer.

>
>> >
>> > In terms of documentation, they have a high-level description of
>> > the various components and patches [1], and build instructions
>> > for a few platforms and distros [2].  There was also an attempt
>> > to make a nix package a while ago [3], which may be helpful to
>> > look at.
>> >
>> > [0]: https://github.com/Eloston/ungoogled-chromium
>> > [1]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md
>> > [2]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md
>> > [3]: https://github.com/NixOS/nixpkgs/pull/30916
>> 

Re: Firefox 52's end of life, packaging Chromium

[Nils Gillmann]

Joshua Branson transcribed 1.4K bytes:
> Nils Gillmann <ng0@n0.is> writes:
> 
> > Joshua Branson transcribed 2.3K bytes:
> >> Amin Bandali <amin@gnu.org> writes:
> >> 
> >> > Ricardo Wurmus <rekado@elephly.net> writes:
> >> >
> >> 
> >> There is also the Brave browser
> >> 
> >> https://brave.com/
> >
> > It would very likely not be accepted in Guix. At least by my
> > interpretation of what we have included and cared for so far. Brave is
> > basically replacing Ads with other Ads and all the requests you make
> > in the browser are send through their proprietary servers.
> > Could be that we already discussed Brave a while back on irc or on
> > this list. Even when rejected, no onw forbids anyone to provide it
> > outside of core.
> 
> Oh really?  I had no idea that they send stuff through their proprietary
> servers.  That doesn't really make it free software.  :(  Bummer.

I've read into it again. Technically their source code is open.
But. There's only a minimal gain and possible even inside Guix
work to modify Brave to fit into our model, as they use Chromium.
It still looks like their server side is proprietary. Understandable,
but I'm waiting on how much information they publish with the 1.0
release as they hint to do so in their FAQ (https://brave.com/faq/).

I'm interested but very sceptic about it.

Read more (but no technical details) at https://brave.com/about-ad-replacement/

Debian has not processed the RFP for it so far:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864795

> >
> >> >
> >> > In terms of documentation, they have a high-level description of
> >> > the various components and patches [1], and build instructions
> >> > for a few platforms and distros [2].  There was also an attempt
> >> > to make a nix package a while ago [3], which may be helpful to
> >> > look at.
> >> >
> >> > [0]: https://github.com/Eloston/ungoogled-chromium
> >> > [1]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/design.md
> >> > [2]: https://github.com/Eloston/ungoogled-chromium/blob/master/docs/building.md
> >> > [3]: https://github.com/NixOS/nixpkgs/pull/30916
> >> 
> 

Re: Firefox 52's end of life, packaging Chromium

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> 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’t 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?

Do you agree that #1 and #3 look like spyware?  If so, wouldn't that
make them blockers?

       Mark

Re: Firefox 52's end of life, packaging Chromium

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Ricardo Wurmus <rekado@elephly.net> 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’t 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?
>
> Do you agree that #1 and #3 look like spyware?  If so, wouldn't that
> make them blockers?

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).

Someone may have analyzed the data transmitted at some time in the past
and concluded that it was most likely benign and with minimal impact to
one's privacy, but even if we accept that analysis, it cannot be assumed
to hold true for current or future versions of Chromium.

If we accept the existence of such traffic, we effectively eliminate our
ability to detect the inclusion of new spyware added to Chromium 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.

The reason I am so sensitive to this issue is that Debian included
nonfree software in their kernels for many years, despite it being a
widely known violation of the Debian Free Software Guidelines.
Apparently it was deemed sufficient to make a "best effort" to comply
with their own promises.  I hope that Guix would never take a similar
position.

If I have overreacted, and the situation is better than I fear, then I
apologize for the trouble.

I've asked Marius whether any spyware remains.

     Thanks,
       Mark

Re: Firefox 52's end of life, packaging Chromium

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:
> The reason I am so sensitive to this issue is that Debian included
> nonfree software in their kernels for many years, despite it being a
> widely known violation of the Debian Free Software Guidelines.
> Apparently it was deemed sufficient to make a "best effort" to comply
> with their own promises.

Sorry, I sent this draft message out prematurely.  This entire paragraph
should have been removed.  The reason for my sensitivity is not relevant
anyway.

Of course, we cannot hope to do more than to make our best effort, and
moreover, volunteers are not obligated to expend any effort at all.

       Mark

Re: Firefox 52's end of life, packaging Chromium

[Ricardo Wurmus]

Hi Mark,

> Mark H Weaver <mhw@netris.org> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> 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’t 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’s fetching translation information, which seems
legitimate.  #1 is unclear to me, honestly, as it seems to be a bug.
AIUI the “domain_reliability” component is not enabled by default.

For context I read a little about this “domain_reliability” thing and
found this Google document (I don’t know if this is an official
publication by the Chromium developers):

  https://docs.google.com/document/d/14U0YA4dlzNYciq2ke0StEMjomdBUN6ocSt1kN03HJ0s/pub#h.20j0auqi631o

From what I understand, the “Domain Reliability Monitoring” 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’t trust Chromium (because user privacy is against
upstream’s interests) and will not use it myself nor will I recommend
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’t look like
spyware to me.  I could be wrong, of course, and I’m 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 “spyware added later” do you mean with future updates to the package?

Future updates will remain difficult because we’re 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’m afraid removing spyware from Chromium will never truly be finished
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

Re: Firefox 52's end of life, packaging Chromium

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Mark,
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> Ricardo Wurmus <rekado@elephly.net> 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’t 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’s fetching translation information, which seems
> legitimate.  #1 is unclear to me, honestly, as it seems to be a bug.
> AIUI the “domain_reliability” component is not enabled by default.
>
> For context I read a little about this “domain_reliability” thing and
> found this Google document (I don’t know if this is an official
> publication by the Chromium developers):
>
>   https://docs.google.com/document/d/14U0YA4dlzNYciq2ke0StEMjomdBUN6ocSt1kN03HJ0s/pub#h.20j0auqi631o
>
> From what I understand, the “Domain Reliability Monitoring” 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.

Woah, good find!  Apparently this is being submitted as a W3C standard:
<https://w3c.github.io/network-error-logging/>.

I'll try to find a toggle.  If this package gets into Guix, I think we
should add system tests (or similar) to catch regressions in the
unsolicited network traffic area.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Ricardo Wurmus]

Marius Bakke <mbakke@fastmail.com> writes:

> If this package gets into Guix, I think we
> should add system tests (or similar) to catch regressions in the
> unsolicited network traffic area.

That’s an excellent idea, though it may be difficult to accomplish.  I
wouldn’t know how to do this reliably as the behaviour of Chromium would
likely differ dependent on whether it’s running in an environment
without networking.  It’s worth exploring, though.

--
Ricardo

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> 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).

Speaking of spyware, someone shared these links recently on IRC, which I
found insightful:

  https://spyware.neocities.org/articles/icecat.html
  https://spyware.neocities.org/articles/firefox.html
  https://spyware.neocities.org/articles/chrome.html

For instance, Firefox’ portal detection mechanism (which I find handy)
raises privacy issues, even if that’s not intended.  (I suppose we could
replace it with example.org and it would work just as well.)

Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

On Sun, Sep 02, 2018 at 01:33:40AM -0400, Mark H Weaver wrote:
> Ricardo Wurmus <rekado@elephly.net> writes:
> > 1 There is still some data transmitted when starting the browser for the
> >   first time.  It seems related to the "domain_reliability" component.
> > 3 Opening settings transmits a bunch of data, the next version will
> >   include the 'disable-translation-lang-fetch' patch from Inox.
> 
> Guix _is_ committed to the GNU FSDG, right?

That's my assumption (I know you didn't ask me directly).

> Do you agree that #1 and #3 look like spyware?  If so, wouldn't that
> make them blockers?

Maybe they are spyware, maybe they are not. I think there are legitimate
reasons for a program to be "chatty". It depends on the user's
expectations, what data is sent, and who it is sent to. We should keep
looking into issues #1 and #3.

Also, I think the Chromium package is being held to a very high standard
compared to other packages, which is good, since web browsers are so
important now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hello,

Clément Lassieur <clement@lassieur.org> skribis:

> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].  It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?

As long as the freedom issues and phone-home issues are addressed, which
appears to be the case, I’m all for it.

Marius?

Thanks,
Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Hello :-)

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Clément Lassieur <clement@lassieur.org> skribis:
>
>> So the question is: can we push the Chromium package?  I've read it's
>> almost ready[2].  It's probably far better than everything we have,
>> despite not being totally 'finished'.  Maybe we can add what's left to
>> do as a TODO and fix the package later?
>
> As long as the freedom issues and phone-home issues are addressed, which
> appears to be the case, I’m all for it.
>
> Marius?

Marius, what is the status, can we merge it?

Clément

Re: Firefox 52's end of life, packaging Chromium

[Clément Lassieur]

Clément Lassieur <clement@lassieur.org> writes:

> Hello :-)
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> Clément Lassieur <clement@lassieur.org> skribis:
>>
>>> So the question is: can we push the Chromium package?  I've read it's
>>> almost ready[2].  It's probably far better than everything we have,
>>> despite not being totally 'finished'.  Maybe we can add what's left to
>>> do as a TODO and fix the package later?
>>
>> As long as the freedom issues and phone-home issues are addressed, which
>> appears to be the case, I’m all for it.
>>
>> Marius?
>
> Marius, what is the status, can we merge it?

Ping
>
> Clément

Chromium channel

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Clément Lassieur <clement@lassieur.org> writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>> Hello :-)
>>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello,
>>>
>>> Clément Lassieur <clement@lassieur.org> skribis:
>>>
>>>> So the question is: can we push the Chromium package?  I've read it's
>>>> almost ready[2].  It's probably far better than everything we have,
>>>> despite not being totally 'finished'.  Maybe we can add what's left to
>>>> do as a TODO and fix the package later?
>>>
>>> As long as the freedom issues and phone-home issues are addressed, which
>>> appears to be the case, I’m all for it.
>>>
>>> Marius?
>>
>> Marius, what is the status, can we merge it?
>
> Ping

Hello, sorry for the delay.

I've set up a channel for Chromium here:

https://gitlab.com/mbakke/guix-chromium

Chromium has been updated for version 69 as well.

I don't think we can merge as-is due to the tight Web Store integration
(even if it's disabled), but I will start work on packaging the full
"Ungoogled-Chromium" next:

https://github.com/Eloston/ungoogled-chromium

I'll bump this thread once it is ready for testing.  Developments will
happen in the Gitlab repository.  Pull requests welcome!  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Chromium channel

[Clément Lassieur]

Marius Bakke <mbakke@fastmail.com> writes:

> Clément Lassieur <clement@lassieur.org> writes:
>
>> Clément Lassieur <clement@lassieur.org> writes:
>>
>>> Hello :-)
>>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Hello,
>>>>
>>>> Clément Lassieur <clement@lassieur.org> skribis:
>>>>
>>>>> So the question is: can we push the Chromium package?  I've read it's
>>>>> almost ready[2].  It's probably far better than everything we have,
>>>>> despite not being totally 'finished'.  Maybe we can add what's left to
>>>>> do as a TODO and fix the package later?
>>>>
>>>> As long as the freedom issues and phone-home issues are addressed, which
>>>> appears to be the case, I’m all for it.
>>>>
>>>> Marius?
>>>
>>> Marius, what is the status, can we merge it?
>>
>> Ping
>
> Hello, sorry for the delay.
>
> I've set up a channel for Chromium here:
>
> https://gitlab.com/mbakke/guix-chromium
>
> Chromium has been updated for version 69 as well.
>
> I don't think we can merge as-is due to the tight Web Store integration
> (even if it's disabled), but I will start work on packaging the full
> "Ungoogled-Chromium" next:
>
> https://github.com/Eloston/ungoogled-chromium
>
> I'll bump this thread once it is ready for testing.  Developments will
> happen in the Gitlab repository.  Pull requests welcome!  :-)

Great!

Thank you very much Marius, and sorry for insisting.  The 'channels'
solution seems to fit very well!

Clément

Re: Chromium channel

[Nils Gillmann]

Clément Lassieur transcribed 1.4K bytes:
> Marius Bakke <mbakke@fastmail.com> writes:
> 
> > Clément Lassieur <clement@lassieur.org> writes:
> >
> >> Clément Lassieur <clement@lassieur.org> writes:
> >>
> >>> Hello :-)
> >>>
> >>> Ludovic Courtès <ludo@gnu.org> writes:
> >>>
> >>>> Hello,
> >>>>
> >>>> Clément Lassieur <clement@lassieur.org> skribis:
> >>>>
> >>>>> So the question is: can we push the Chromium package?  I've read it's
> >>>>> almost ready[2].  It's probably far better than everything we have,
> >>>>> despite not being totally 'finished'.  Maybe we can add what's left to
> >>>>> do as a TODO and fix the package later?
> >>>>
> >>>> As long as the freedom issues and phone-home issues are addressed, which
> >>>> appears to be the case, I’m all for it.
> >>>>
> >>>> Marius?
> >>>
> >>> Marius, what is the status, can we merge it?
> >>
> >> Ping
> >
> > Hello, sorry for the delay.
> >
> > I've set up a channel for Chromium here:
> >
> > https://gitlab.com/mbakke/guix-chromium
> >
> > Chromium has been updated for version 69 as well.

Huh! Did the requirement for building go up by 100% with version 69?

I will test if my 8GB RAM buildmachine can still build it like it
used to up to version 68.x.

> > I don't think we can merge as-is due to the tight Web Store integration
> > (even if it's disabled), but I will start work on packaging the full
> > "Ungoogled-Chromium" next:
> >
> > https://github.com/Eloston/ungoogled-chromium
> >
> > I'll bump this thread once it is ready for testing.  Developments will
> > happen in the Gitlab repository.  Pull requests welcome!  :-)
> 
> Great!
> 
> Thank you very much Marius, and sorry for insisting.  The 'channels'
> solution seems to fit very well!
> 
> Clément
> 

Re: Chromium channel

[Pjotr Prins]

On Mon, Sep 17, 2018 at 03:28:23PM +0200, Marius Bakke wrote:
 
> I've set up a channel for Chromium here:
> 
> https://gitlab.com/mbakke/guix-chromium

Too much coolness. I am fainting!

Pj.

Re: Chromium channel

[Ludovic Courtès]

Hello Marius,

Marius Bakke <mbakke@fastmail.com> skribis:

> I've set up a channel for Chromium here:
>
> https://gitlab.com/mbakke/guix-chromium

Nice!  Great to see channels put to good use.  :-)

Though… let’s make sure this channel doesn’t derail “us” from the goal
of having an FSDG-compliant Chromium in Guix proper!

Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Benjamin Slade]

Speaking from a user-perspective, I would be very much in favour of
having modern Firefox and Chromium (appropriately de-Googled as much as
possible, of course) as actual Guix offerings.

And while there are lots of objectionable things about the www in 2018,
I don't think being a GNU follower is likely to strongly correlate with
being anti-web (I suspect the opposite, if anything).

On most of my machines I find what I really need are Emacs, LaTeX, a
terminal, and the latest versions of Firefox and Chromium, as there are
things which simply don't work otherwise (and having used IceCat 52 for
a few weeks now on Guix, I'm also reminded of how horribly slow Firefox
used to be).

I've managed to jury-rig a mostly-working actual Firefox on my GuixSD
machine, but only by installing Docker via Nix and figuring out how to
build and run Firefox in a Docker container (non-trivial task, having
never touched Docker before, and one that still doesn't work
100%). While this has been somewhat educational, I'd have rather spent
the time further exploring Guix (trying to build new Guix packages &c.).

Just my two bits as a user,
  —Ben

--
Dr Benjamin Slade - Uni of Utah - Linguistics [linguistics.utah.edu]
 ( https://slade.jnanam.net . https://babbagefiles.xyz )
  `(pgp_fp: ,(21BA 2AE1 28F6 DF36 110A 0E9C A320 BBE8 2B52 EE19))
    '(sent by mu4e on Emacs running under GNU/Linux . https://gnu.org )
       `(Choose Linux ,(Choose Freedom) . https://linux.com )

Re: Firefox 52's end of life, packaging Chromium

[Hartmut Goebel]

Am 31.08.2018 um 01:38 schrieb Benjamin Slade:
> Speaking from a user-perspective, I would be very much in favour of
> having modern Firefox and Chromium (appropriately de-Googled as much as
> possible, of course) as actual Guix offerings.

+1 (I know, building Firefox is very, very tremulous. Thus many, many
thanks to those working on it.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Firefox 52's end of life, packaging Chromium

[Ludovic Courtès]

Hello,

Benjamin Slade <beoram@gmail.com> skribis:

> Speaking from a user-perspective, I would be very much in favour of
> having modern Firefox and Chromium (appropriately de-Googled as much as
> possible, of course) as actual Guix offerings.
>
> And while there are lots of objectionable things about the www in 2018,
> I don't think being a GNU follower is likely to strongly correlate with
> being anti-web (I suspect the opposite, if anything).

I agree with both statements.  I do see things in today’s www that I’m
unhappy with, but I think it’s important to provide our users with a
recent browser.

I have to say that Andreas, Mark, Marius, and others who worked on
IceCat and Chromium packaging are heroes: it’s a huge effort and we can
be grateful for that!

Ludo’.

Re: Firefox 52's end of life, packaging Chromium

[Pjotr Prins]

On Sat, Sep 01, 2018 at 04:13:53PM +0200, Ludovic Courtès wrote:
> I have to say that Andreas, Mark, Marius, and others who worked on
> IceCat and Chromium packaging are heroes: it’s a huge effort and we can
> be grateful for that!

So many heroes here!

Pj.

Re: Firefox 52's end of life, packaging Chromium

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

On Sat, Sep 01, 2018 at 16:13:53 +0200, Ludovic Courtès wrote:
> I have to say that Andreas, Mark, Marius, and others who worked on
> IceCat and Chromium packaging are heroes: it’s a huge effort and we can
> be grateful for that!

I agree---I am very grateful for their work!

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Firefox 52's end of life, packaging Chromium

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> Benjamin Slade <beoram@gmail.com> skribis:
>
>> Speaking from a user-perspective, I would be very much in favour of
>> having modern Firefox and Chromium (appropriately de-Googled as much as
>> possible, of course) as actual Guix offerings.
>>
>> And while there are lots of objectionable things about the www in 2018,
>> I don't think being a GNU follower is likely to strongly correlate with
>> being anti-web (I suspect the opposite, if anything).
>
> I agree with both statements.  I do see things in today’s www that I’m
> unhappy with, but I think it’s important to provide our users with a
> recent browser.
>
> I have to say that Andreas, Mark, Marius, and others who worked on
> IceCat and Chromium packaging are heroes: it’s a huge effort and we can
> be grateful for that!
>
> Ludo’.

Hear hear!  (Or is it "Here here?")