Thoughts about merging Inox and ungoogled-chromium

[Eloston]

I'm wondeing what your thoughts are @gcarq about a merge of Inox and ungoogled-chromium. It was brought to my attention recently, and my thoughts are in ungoogled-software/ungoogled-chromium#249 (comment). Additionally, @xsmile has some interesting points in ungoogled-software/ungoogled-chromium#249 (comment)

To be clear, this is not an indirect request to merge; I'm just curious.

[avently]

It will be awesome if you guys will collaborate with each other.
@gcarq making so good patches and PKGBUILD for Arch https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=inox
@Eloston use many patches from other sources. It will be a great team. Speed of new releases will only increase.

[gcarq]

@Eloston I had the same thought some time ago, but for a while I'm just so much involved as long as it works for Arch Linux in favor of other projects.
How is your attitude in regards to patches which are not privacy related? For me one important point is to keep the patchset as small as possible.

As you already mentioned a big plus would be that the development process is more consolidated. But at the same time the collaboration is more complex and takes more effort.

[Eloston]

@gcarq

for a while I'm just so much involved as long as it works for Arch Linux in favor of other projects.

This is has been my attitude towards ungoogled-chromium recently as well (and will probably stay this way after I get around to finishing a few tasks that I have left sitting around).

How is your attitude in regards to patches which are not privacy related? For me one important point is to keep the patchset as small as possible.

I generally don't keep changes that don't affect privacy, but there are a few minor exceptions to this rule. Mostly everything's privacy related, despite the goals of ungoogled-chromium being pretty expansive.

As you already mentioned a big plus would be that the development process is more consolidated. But at the same time the collaboration is more complex and takes more effort.

I agree. And if we are both not going to contribute as much as we used to, then perhaps merging isn't worth the effort. If development isn't going to speed up significantly, then I'm not sure what other benefits would be worth merging for. There really aren't other developers who are committed to these projects in the longterm, so development segmentation isn't really much of an issue.

[csagan5]

I am commenting here on the topic of "multiple projects working towards similar goals" and open source software.

Premise about FOSS

There is this young attempt by @thermatk which explicitly aims at a Chromium FOSS build and a binary without non-free components.

Please note the difference between:

• building Chromium completely from scratch, with simply source code and FOSS build tools
• embedding binary blobs inside the finally packaged Chromium distributable binary

They are two completely separate aspects and a truly 100% FOSS solution would cover both.

Summary

Let me make a summary of how I see the situation these days (just my POV):

• Inox patchset has the most strict requirements in terms of privacy e.g. blocking all connections to Google; also patches have to be about privacy/security exclusively; position about FOSS: ?
• ungoogled-chromium picks a bit from everywhere, tries to offer the best selection and targets Desktop; it is in a way Inox 2.0 as it extends it (still my POV); position about FOSS: ?
• Bromite tries to gets the best practical privacy (= for the masses) on Android with the least (development) maintenance effort and user functionality breakage; no attempts/guarantees to block all connections* to Google servers (like Inox aims to) and no declared FOSS milestones; it also only wants to include privacy patches only.

I am ignoring on purpose other initiatives like Brave and Iridium for the sake of simplicity and because I have seen most interesting activity in Iridium/ungoogled-chromium so far.

• = these days most of the connections to Google servers are blocked anyway thanks to the patches added, but I never reviewed what is still escaping and it is not a formal goal of Bromite

About "similar projects"

I have always refrained from providing Bromite builds for Desktop to better focus my efforts on Android, and because other projects seem to represent well the privacy-seeking effort for Desktop users.
It is however clear that at least in some part we have patches that could be of benefit for all users, for example my recent addition of DNS-over-HTTPS or all the patches I picked from other projects.

In my opinion having different projects that produce different patches is (in the open source sense) a source of richness for this ecosystem. I can however see the negative aspect in case multiple developers are busy with patch-porting efforts (from one Chromium version to another) for the same patches; this is however no reason to call for a "solution" to the inefficiency, as it is sometimes just better to live with the inefficiency rather than try some coordination as said in previous comment.

I think that as far as we all keep publishing patches with reasonable/compatible licenses the situation is only going to improve in the future for the end-users (although it might be a bit messy for the developers).

Reproducibility

What would be even better than building with FOSS tools and producing binaries without any non-free component? Reproducible builds.

Reproducible builds are in my opinion the true holy grail here, and I simply do not commit to FOSS or reproducible builds for Chromium/Bromite because I am aware of the big effort it would be to do so (I am however looking out for those patches/efforts ☺️ ).

Closing note

@gcarq @Eloston can you please comment on the FOSS aspect? e.g. would you be interested in any of these:

• building using no Google-provided binary
• building a binary that contains no 3rd-party binary blob
• reproducible builds

I am trying to make a summary here that perhaps might be an useful orientation for other contributors.

[gcarq]

@csagan5

with the least (development) maintenance effort and user functionality breakage;

That also aligns with my goal. Most of the patches could be written in a more elegent way, but merging that every time would probably be infeasible in the long run.

I'm all in for FOSS on this project:

• don't include blobs
• remove existing blobs and removing the ability to reload blobs (like it worked with Google HotWord)
• use system libraries for builds wherever possible (optimum is of course not using any provided binary)

Reproducible builds are awesome, but hard work. Some discussion about this happend in #69.
I just know that Arch Linux did some effort in this regard and did the base work for reproducible builds with pacman 5.1. Not all packages are reproducible right now, with chromium on that list. That being said the diff doesn't look too intimidating

[Eloston]

@csagan5

FOSS is something I've been striving for since ungoogled-chromium's inception for all platforms.

Inox patchset has the most strict requirements in terms of privacy e.g. blocking all connections to Google

I'd also like to add that ungoogled-chromium takes this further with features like domain substitution, which are then caught by a internal blocking and logging mechanism (block-trk-and-subdomains.patch).

with the least (development) maintenance effort and user functionality breakage

All of us strive for this, but I favor user flexibility of browser behavior over maintenance effort. Everyone has different use cases, especially technically-inclined users who tweak their experience down to individual flags; I don't want to impose any one party's opinions on the browsing experience.

ungoogled-chromium picks a bit from everywhere, tries to offer the best selection and targets Desktop
it is in a way Inox 2.0 as it extends it (still my POV)

That is one way to look at it. ungoogled-chromium broadened its scope once I discovered Inox and Iridium (which was quite early in the project's lifetime). There's not much that I won't allow when it comes down to it.

Android support is "in the works", but there's not much push for it right now. I'm still working on a redesign of ungoogled-chromium's infrastructure (the last for a while I hope), so I might consider working on it in the future.

building using no Google-provided binary

This is one of the mission statements of ungoogled-chromium, and it will stay that way.

As you know, this is what is holding back Android support in ungoogled-chromium.

(The only exceptions right now are DOM distiller models, and the ICU data file.)

building a binary that contains no 3rd-party binary blob

This is already done in all ungoogled-chromium Linux builds dependent on system libraries (except just DOM distiller models). Other than being targeted for Android, I don't really see any differences of @thermaltk's Unobtanium and ungoogled-chromium; in fact, I may consider including the work from Unobtanium in ungoogled-chromium.

On Windows and macOS, I give the users an option to additionally download and unpack 3rd party tools to substitute the ones that Google uses (mainly LLVM). All other binaries are basically user installed toolchains like Visual Studio or Xcode, which are required by Chromium.

EDIT:

reproducible builds

I would also like to have reproducible builds, but I don't know the state of this for all supported platforms.

[thermatk]

Hello!
I've kind of finished freeing for now, had to move to gitlab to get more repo size limit.
https://gitlab.com/thermatk/Unobtainium
The result looks huge, but it works

[csagan5]

@gcarq @Eloston thanks for your replies, it makes the overview more clear.

That is one way to look at it.

Yes, sorry - just my "external" POV, but I am actually glad all these projects/efforts exist.

@thermatk that looks good! I am going to try picking at least some of those patches (re: bromite/bromite#65)

[Eloston]

@csagan5

Yes, sorry - just my "external" POV, but I am actually glad all these projects/efforts exist.

No offense taken; it's just a perspective I didn't consider before.

[csagan5]

@Eloston sure :)

For the records, I just realised that some unattributed patches (disabling GCM, battery etc) I picked from ungoogled-chromium/Inox are actually from Iridium, so now I am going through the list (https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/log/) and picking them again with Jan Engelhardt's original commit messages; I see that he has done a really good job there, but I agree that merging together the prefs is probably better than having one patch per default pref change.

I am also finding the first commits (1 and 2) about disabling build with Google-provided toolchain, really interesting.

Edit: I find some commit messages genuinely hilarious, like this one - I am glad to have them in the patches