Regarding privacy enhancement and coordinations between projects

[wchen342]

This is a continuation of #1393 (comment).

I noticed recently there are increasing demands for enhanced anti-fingerprinting features (e.g. font spoofing, favicon fingerprinting, enhanced canvas spoofing, enhanced general fingerprinting resistence). So far such functionalities are implemented on a case-by-case basis, like the canvas random noise and disabling webrtc. And some of them causes problems, like the canvas random noise (#1241, #1139).

I think it will be much better if these separate enhancements can be somehow grouped into a more systematic project, which will make the issues more concentrated. It will also be better if we can have a coordinated effort between projects on this because a cooperated project can attract more contributions rather than doing this inside a single project. Since Bromite, ungoogled-chromium/ungoogled-chromium-android and probably some other chromium-based forks all have a common goal of enhancing privacy, I think this shall be benifical for all. What do you think? @Eloston @csagan5

[csagan5]

I thought the same for the extensions: a project to take care only of that, for the benefit of Chromium forks.

In this case, and possibly some other, I do not think it is necessary some particular form of coordination, what we need is basically:

• (1) use a compatible license
• (2) redirect request for bugfixes/enhancements to the project that "incubates" and maintains the patchset
• (3) make each other aware of better patches by contributing back to the upstream of such patchsets, and have some way to inform downstream for the patchset updates

This way contributors can choose which project to contribute to, and then projects can "horizontally" transfer patches like in a sort of software HGT.

For (3) I have often gone back to the source of the patches I use to see if there are updates or if I can contribute back something; that is also a reason to always keep correct attribution. Perhaps we need to identify how we will be upstream/downstream and what will be the channel/way to get the news about the updates, and then (3) would be solved. If you have other ideas please shoot.

I would suggest to start with 1,2,3 and then in future it is possible to say: these patchsets now need their own stand-alone open source project/organisation (either one for all, or one for each), but I would not start now with that - it feels like it would dilute efforts and add bureaucracy.

[dm17]

Perhaps we need to identify how we will be upstream/downstream and what will be the channel/way to get the news about the updates, and then (3) would be solved.

I imagine it would be structured such that Bromite, Vanadium, and Marmaduke's builds are branches off of ungoogled-chromium. Despite the projects potentially having different goals - it still seems worthwhile to deduplicate work and make sharing their improvements easier.

So basically if each project signs off, then a privacy/security enhancement could be merge into the base ungoogled-chromium. For example:

1. Merge everything each project wants into a base project (ungoogled-chromium)
2. Have each project branch off of the base project with its unique patches
3. Have a review project for each privacy/security enhancement such that it could get merged into the base project

Would that make sense?

And perhaps Marmaduke & the Iridium will want to help out too. As I understand it the only benefit of Marmaduke's ungoogled builds is the addition of some codecs?

[csagan5]

and Marmaduke's builds

No source has ever been released for these, in violation of the spirit of the projects and the open source license.

[thestinger]

We'd like to have a shared base for Vanadium but we don't want to remove Google as an option for features like search where it's simply one of several alternatives and anyone else could easily implement the same service. Similarly, we don't really have a problem with functionality that's not enabled by default as long as it doesn't depend on Play services.

We also care a lot about very quickly updating to the latest releases so invasive patches requiring a lot of maintenance are a problem. Having far more complex patches to accomplish things that could be done in a simpler way isn't something we want. If you wanted to have a shared base it would need to be a new repository because the approach here doesn't really work for us.

[kmk3]

@thestinger 44 minutes ago:

We'd like to have a shared base for Vanadium but we don't want to remove
Google as an option for features like search where it's simply one of several
alternatives and anyone else could easily implement the same service.
Similarly, we don't really have a problem with functionality that's not
enabled by default as long as it doesn't depend on Play services.

We also care a lot about very quickly updating to the latest releases so
invasive patches requiring a lot of maintenance are a problem. Having far
more complex patches to accomplish things that could be done in a simpler way
isn't something we want. If you wanted to have a shared base it would need to
be a new repository because the approach here doesn't really work for us.

How about:

• List all patches from ungoogled-chromium (and maybe similar relevant patches
  from the other projects) on a comment (on a new thread or maybe in here)
• Every project maintainer copies and pastes the list on a new comment, with an
  accept/maybe/deny beside each patch

That way, the common denominator would be found.

If it differs too much from what ungoogled-chromium does, it could be done on
another base on which ungoogled-chromium and everyone else would build upon.
Perhaps a "liberated" Chromium that only removes all (client-side) proprietary
software dependencies (such as Play Services)? It would be nice to have that,
if anything so that distros/roms that currently ship standard Chromium would
replace it with the more libre version (and thus potentially reduce the need to
coordinate patches between distros/roms).

[dm17]

Following up to see if there are fresh ideas on how to have an ungoogled-chromium-base without disrupting ungoogled-chromium, vanadium, bromite, etc. It still seems that it could bring a lot of benefit to each project. It could also bring clarity & ease for testing each other's patches. Overall it seems efficient long-term, but I wouldn't want it to complicate the process of building for multiple architectures (android, musl, glibc, etc). Maybe we should draw out an ideal build pipeline to see what the various projects think of inheriting from it?

[ghost]

@Eloston you may can grab the finger print protection code from ddg browser

Ddg browser are open source as well i think is ok if we want to use it

[specter78]

Brave has also done good work in fingerprint protection. Maybe that can be imported in UC.

[ghost]

Agree @specter78