Determining the future of ungoogled-chromium

[Eloston]

This is an issue I've been thinking about lately. Your feedback will be greatly appreciated!

The issue of uncertainty

I don't know what ungoogled-chromium should become. This is a major issue. If ungoogled-chromium is to continue growing, there must be a clear objective. To help you gain a better understanding of this issue, let me describe why ungoogled-chromium's objective is not clear. (NOTE: I realize this section is long. But to give this issue proper attention and consideration, I recommend at least skimming it.)

First, the README state that ungoogled-chromium is "a set of configuration flags, patches, and custom scripts". In reality, I think this is misleading; there aren't just some set of changes you can apply on top of Chromium and call it "ungoogled-chromium". Take the "Enhancing Features" section of the README, or the numerous CLI flags for example. Issue #56 is another example of how binary pruning, domain substitution, and the use of Google's pre-built Android SDKs and NDKs end up becoming major issues for adding Android support.

Not only is "ungoogled-chromium" not just about ungoogling, I'd argue that its true value is not clearly understood. Elsewhere on the Internet, there is a large number of people treating ungoogled-chromium as a browser for dealing with privacy issues, and are comparing it to other Chromium or Firefox derivatives like Brave or Waterfox. However, ungoogled-chromium does not have much in terms of privacy; I leave a lot of that to the user. As for myself, I find value in not only "ungoogling", but also the other aspects such as the "enhancing features", domain substitution, binary pruning, and buildkit. There is one comment in particular that caused me to re-evaluate where the value lies in ungoogled-chromium: https://github.com/privacytoolsIO/privacytools.io/issues/274#issuecomment-391922550 (There are a few debatable generalizations made about ungoogled-chromium and Chromium, but that is a discussion for another time. The general idea is correct, however.)

Finally, I believe at the heart of the project's uncertainty are my contradictory preferences. I have used my preferences to guide my decisions in areas that ungoogled-chromium does not dictate:

1. I want ungoogled-chromium to be as unobtrusive and lightweight as possible. That means sticking to the vanilla Chromium experience as closely as possible, and keeping out changes that don't contribute to the goals of this project. However, the goals aren't really clear, so there is a lot of influence from the following requirement.
2. I want ungoogled-chromium to be software that I'd like to use. There is also a variety of personal preferences that impact my decisions here (which are somewhat contradictory between them):
   • I am heavily influenced by Debian's philosophy of FOSS. This is why things like binary pruning (to remove any binaries) or domain substitution (to remove any background connections to proprietary services) exist.
   • I don't like activities to "think for me". I want to know what a certain activity will do and its implications. In other words, I have a bias for control over convenience. This is why flags exist for things like IPv6 probing, the removal of captive portal detection, and the removal of mDNS and Service Discovery in Chromecasts not working #160.
   • I don't like bloat. I want to remove stuff that I don't need or want. This is why some of the patches are as extensive as they are; Even though domain substitution or another patch would've disabled the code already, I don't like to use it.
   • I don't like runtime dependence on online code. This goes back to having control of what my software does (e.g. take the NPM module disaster not too long ago). Also, I don't like the assumption that an Internet connection is always available (maybe in the near future, but not yet). This is why I patched the browser UI to use bundled Google fonts instead of Google's font server, and why I changed DevTools to only use a local copy of its JavaScript code (it usually uses JS code hosted on Google).
   • I like things to be fast, efficient, and error-free as possible. I also like new things. This is why Clang is the default, and why is_official_build=true is set. This is also why I have CI checks, and I'm even thinking about supporting unit tests at some point. You could say I a bit of a perfectionist, but I think that is because I view this project as a hobby (maybe even art, to a slight extent).
3. I want ungoogled-chromium to grow. Clearly, the people that use my browser are not all like me. So to attract more users, I have to keep evolving ungoogled-chromium and myself. I continue to do this through various means, namely its presentation (e.g. the rewrites of the README), and the features that others have requested or contributed. But at the same time, I can't make everyone happy, and I don't know where to draw the lines.

(If you've read through all of the above, then I thank you for your time commitment, and your interest.)

What should ungoogled-chromium be?

If ungoogled-chromium is to continue growing, we must set a clear and appropriate vision for it. This is where I need help: What do you think ungoogled-chromium should be? When writing your answer, here are some points you may consider:

• Should I break this project up and define a more concrete and narrower definition of "ungoogling"?
  • Examples: Maybe fingerprinting deception mechanisms should be removed? Perhaps domain substitution and binary pruning can be optional for packagers of ungoogled-chromium, as they can just be mechanisms to help us write patches that implement "ungoogling"?
• Should I change the scope of ungoogled-chromium to more align with my preferences (and perhaps change the name as well)?
  • Examples: Should ungoogled-chromium become a Chromium derivative that emphasizes more on privacy and FOSS (which aligns more with my preferences), in addition to removing Google-specific behavior (e.g. Google host detection, connecting to Google servers)? Should domain substitution and binary pruning be considered essential features of the browser?
• The above two questions can be generalized as follows: Should the browser be split up to let other developers determine how they want to package ungoogled-chromium (e.g. like Android, Linux distros, even Windows to an extent), or should it more strictly control the entire process of the browser creation (e.g. iOS, Chrome, perhaps Brave)?
• Are there other relevant considerations or ideas?

Feel free to take your time to reflect and answer. I will leave this issue up for a while to ensure everyone can properly respond.

(EDIT: Original text has been removed since it is no longer relevant. You may use the drop-down menu at the top of this comment to view the original topic.)

[bsd-source]

I would prefer ungoogled-chromium to remain as is and not a separate distribution. Branching too far from chromium would be a huge nightmare for updating security issues etc. Patching and pruning chromium code would probably be best. I think the difficult part is to make sure the build process works properly for each operating system. Also determine which operating systems will be supported. I would prefer that the patches for each operating system become completely separate from one another and not rely on a patch sequence as it currently is. It currently seems that for example changing a patch for debian can possibly affect other operating system builds. Maybe there can be maintainer(s) for each OS. If modifications are made to patches for a specific OS it should not affect the build process of another. Although if patches are modified and can benefit other OS'es that ungoogled supports I think the maintainers for those OS'es should inspect the patches to see if they could be applied to the maintainers OS build.

I too like a lean mean browser without unnecessary bloat.

[qvint]

what about flags like use_sysroot=false, proprietary_codecs=true, enable_swiftshader=false, or enable_nacl=false?

These args have nothing to do with "ungoogling" and should be left to concrete distros. For example, in Fedora repository, proprietary codecs must be disabled due to US laws, but in RPM Fusion they are allowed. You can split this git repo to ungoogled-chromium, ungoogled-chromium-debian, ungoogled-chromium-gentoo etc., update them independently or delegate their maintenance to other people. This is how the project could grow: more people, clear responsibility areas.

[black-ish]

So first I'm no dev, so my point of view will come from a pure windows "user/consumer" perspektive here.

Imo unggogle-chromium is how that piece of software should have been from the start, any and all dependecies from web services (google etc.) should not exists it should be a "pure" browser and mostly get security updates and some "nice" new features that don't exist but are useful for a practical reasons or simply privacy reasons.

For ex. my request ( #625 ) comes from the simple fact that there are already so many flags to set that you "should" use because those "features" should be enabled by youself if you have something to use them with (certain webpages, need for debuging etc.).
Chromium contains things I simply will never use but there is no real option to disable or change them without certain flags set. (Many things can be added later with extensions for each ones needs.)
To add to that, that those flags won't be set if you open a link from another program because in the registry those extra flags aren't there, it simply calls for chrome.exe.

And I also do not want a piece of software to "think for me", it needs to be clear how the sofware accomplishes a task and what it will do, in as detailed as possible.

In regards to the thing that CHEF-KOCH mentiones, I find it a little concerning that Cent Browser is mentioned, because it's closed source and even if you disable everything it still connects to 3 IPs and two DNS requests are send at startup, one to google and another to centbrowsers website, and I would like to know why it still does that, for many people that is a concern and not a desired "thing" that should happen at all.

With the general state of browsers now (bloated, lack of transprancey without scouring the source code, Chromium/Chrome being now almost a monopol) I think a "minimal" browser even if a little "crippled" but working on all sites and even if based on Chromium is needed.

I would say that the general direction I would like to see ungoogled-chromium to head is: minimal, no-dependency, user options, portable (preferably by default, also means nothing written to registry).
That way it should already be a very good base for everyone that would like to fork it imo.

Edit:
Cent Browser does have many features that Chromium/Chrome should actually have since the beginning (imo) like the ability to switch Tab behaviour, download viewer button like Firefox, ability to toggle HTML5 canvas fingerprinting etc.

So that can also be a way look to in terms of features. Just my two cents.

[Eloston]

Just a heads up anyone who has read the post: to everyone who has already read the post: I have made a few clarifications, namely how my personal "requirements" affect ungoogled-chromium (they're actually preferences I use when the ungoogled-chromium goals are not clear). I have also expanded on the "What should ungoogled-chromium be?" section to clarify what particular issues I am having.

To those that have responded already: Thank you for your insights. Let me try to summarize your points: @AZDPS and @qvint are leaning more towards breaking up the project and clarifying what "ungoogling" entails, leaving more control to builders and packagers in what they want "ungoogled-chromium" to be. However, @black-ish seems to lean more towards a scope change for the browser, which means the ungoogled-chromium developers have to decide more in terms of building and packaging. Are these summaries correct?

[ghost]

Personally I'm using UC on Manjaro Linux as a daily driver. I really like it how it is at the moment, so there are just some things I'd like to see in the future:

• merging useful privacy / security patches (especially fingerprint deception and stopping google connections) from other Browsers (e.g. Brave)
• making packaging as dynamic as possible, so that you can easily choose wheter you just want an ungoogled browser (no fingerprint deception etc) or 'more features' like additional features that are useful, but not directly related to ungoogling.
• I'm not sure if we really need an Android variant as there already exists Bromite which includes some of UC's patches. IMO it does a pretty good job.
• automatic building system for all platforms including Arch AUR (maybe using a free service or running a build server by donations).
• please don't remove binary pruning or domain substitution, as they are useful. Maybe add some sort of whitelist for domain substitution.

Thank you for your effort. I really appreciate this project.

[bsd-source]

@AZDPS and @qvint are leaning more towards breaking up the project and clarifying what "ungoogling" entails, leaving more control to builders and packagers in what they want "ungoogled-chromium" to be.

I'm not leaning towards separate projects. Just separate patches for each OS distribution. I prefer not to see patches from one distro affecting another distro build process.

I like the direction you are going with with the project. I do think the project lacks OS patch maintainers. Unfortunately, I don't have the coding knowledge to fix the Windows safe browsing patches.

[jlj2]

To be able to meet points 2 & 3 ("I want ungoogled-chromium to be software that I'd like to use" and "I want ungoogled-chromium to grow. Clearly, the people that use my browser are not all like me. So to attract more users, I have to keep evolving ungoogled-chromium and myself"), maybe there could be two browsers:-

1. A base browser ('ungoogled-chromium'?), which just provides source and, say, a portable Linux version. Developers could adapt/patch for requirements of their target OS (and links for their source files and any unofficial binaries could be placed on your readme file?) I am unfamiliar with the concepts though e.g. "fingerprinting deception mechanisms", "domain substitution", binary pruning". Could command-line flags be used for this version, ideally, for those who have requested this?
2. Your ideal browser (stripped, FOSS, etc.) under a different (related?) name, patched from the aforementioned 'base browser' and offered as a fork of yours on another repository. Again, binaries could be built for the platforms that you and others consider attractive.

Those two flavours may keep even more people happier and therefore enjoy greater input and growth.

Further point: In a link offered above, someone writing as a contributor to Chromium development appears to indicate that Chromium is already privacy-minded, as far as you agree to the terms if you sign in, etc e.g. even if and when you sync data, it's encrypted, etc. Perhaps any representation of ungoogled-chromium as a 'privacy-minded' browser going forward could be reviewed - perhaps in favour of 'unblobbed' 'unbloated', etc. Keeping the name 'ungoogled-chromium' would still be relevant and might be preferable (even for either of the browser versions suggested above) after all these years due to valuable product recognition.

[Peacock365]

I think Ungoogled-Chromium is fine as it is. All I (and I suppose many others) want is a Chrome / Chromium variant with as much Google stripped out as possible. If I wanted more features or a different UI I'd choose Vivaldi or Brave.

As Microsoft has announced to switch to the Blink rendering engine in Edge, the dominance of Blink has grown stronger. I also use Firefox (and derivatives), as I like its customization options in about:config or userChrome.css. However, more and more settings need to be changed in Firefox in order to keep it as private as possible, ever since Mozilla decided to introduce BS like Pocket / Mr Robot / Cliqz etc. There is also the issue of the Gecko rendering engine: Firefox has around 10% market share left, and Chrome (other browsers using Blink not included) has something like 70%. With Microsoft's recent move, Blink will have 80% market share soon, I suppose. Fewer and fewer web admins will optimize for other engines than Blink (and Safari, I guess), so I am not sure how viable Gecko is at this point and how long Mozilla can keep it up. Eventually, they'll have to throw in the towel and use Blink as it will be the only rendering engine website admins test against.

With Blink dominating the market, I've searched a browser that uses this rendering engine but respects privacy at the same time. Chrome and Opera were out. Knowing Windows 10's behavior, I am not too optimistic when it comes to the Edge of the future, as far as privacy is concerned.

Again, I like the Chrome / Chromium interface and ease of use, and Ungoogled-Chromium is therefore my best bet at the moment. If this project did not exist, I'd probably use Brave for privacy reasons.

I feel like continuing to "ungoogle" the more and more spyware-infested Chrome / Chromium is an uphill battle in itself, and I somewhat doubt that you'd have time to introduce much if any additional features. Throwing the spyware code out is a full-time job. Keep it clean, keep it unbloated, keep all of Chromium except for the privacy-evading stuff. As Firefox is going downhill and as Blink becomes a de facto monopoly, a "Chrome without Google" is a much needed asset now and in the future. I wouldn't change much if anything, the project is doing fine and will be of higher relevance going forward.

[siric]

Should I change the scope of ungoogled-chromium to more align with my preferences (and perhaps change the name as well)?

With the entire market favoring chromium based browsers, I wouldn't mind seeing a "new" browser based on ungoogled-chromium. A purified chromium. Chromium Pure?

This project in it's current state is ideal for developers who know how to use build tools. However, it isn't gaining as much traction as we'd all like to see because there are no pre-built binaries and no auto-updates, so it makes it hard for the general public to consider using this, even though there might be many people who stand behind the same philosophy (no bloat, privacy respecting, secure, etc). For this to happen I believe this project will need more contributors, people who stand by the same philosophy and can keep up with the fast paced development of chromium and release binaries in time, to avoid running behind on security fixes. It would position itself well next to Brave because even though Brave does use ungoogled-chromium's patches, is open source and respects privacy just as well, it also adds bloat (Brave Rewards, baked in adblocker and https everywhere, bloated new tab page, upcoming sync functionality, etc). Vivaldi isn't even worth the mention as it's not open source. So I would say there is definitely room for a purified chromium browser, if done right.

[bsd-source]

Brave - Suppose to be working towards pay to browse. No way.
Vivaldi - Closed source. Not fond of the GUI.
Iridium - I currently use this. Seems to have the same goals as ungoogled-chromium.

If you are actually considering a name change I like:

pure-chromium
chromium-pure

But ungoogled-chromium is fine as well.

[mowanotm]

I'm not an active user of ungoogled-chromium, please take my opinion with a grain of salt.

ungoogled-chromium means two things to me, Lightweight and Up-to-date (in terms of security and compatibility).
I use ungoogled-chromium as a supplement for my main Firefox, as a compatibility reference, a quarantined WebGUI, a host for fishy chrome extensions and a backup browser when system under load.
Advanced feature is never my reason to use ungoogled-chromium. If ungoogled-chromium were heading into competition with Brave and Iridium, getting more unique for standing out from the crown, I would probably not pick ungoogled-chromium in the first place.
I just need a bland browser, with chromium compatibility and up-to-date security patch, nothing more. Chromium is not Firefox after all.

I'm in no position to request the project stay in its niche and unpopular path.

[caada]

you have 2 options:

ungoogled-chrome, garble the places chrome phones home. this was the original intention of ungoogled-chrome. I personally prefer ungoogled-chrome stays like this. this is a simple approach; modifications will be fast, won't break the code, so everyone can compile. we can have fast updates. we are aware that when we use google services, we are subject to tracking.

lite-chrome, in this, you are talking about chrome browser with just the blink engine. everything about google is removed. of course, everyone would love to have something like this; however, this is not practical. since google always adds more tracking, code will eventually break and that sounds to be the case right now with the project. you need to put lots of effort in this. that's probably why you are talking about "popularity". if you want to go this way, I suggest to start a new project.

[ik9999]

The above two questions can be generalized as follows: Should the browser be split up to let other developers determine how they want to package ungoogled-chromium (e.g. like Android, Linux distros, even Windows to an extent), or should it more strictly control the entire process of the browser creation (e.g. iOS, Chrome, perhaps Brave)?

@Eloston, you are doing 90%+ work on this project for free, so if you will choose to extend the scope of this project, which will require even more of your time, consider accepting some kind of donations.

[xsmile]

Should I break this project up and define a more concrete and narrower definition of "ungoogling"?

Keeping the key features as a requirement, maybe with the addition of patches from the borrowed features, and marking the enhancing features as optional might be an alternative. That way you can have a clear definition of the project without dropping some interesting patches not directly related to the core idea. For example, I don't want to miss the recent HTTPS patch, although I do not consider it a key feature of ungoogled-chromium. Where to draw the line is a good question and this is also a question of maintenance.

I consider binary pruning and domain substitution to be more of a fail safe but still an important part of this project. Auditing the changes of each Chromium release is impossible and both help to maintain a Google free browser, especially if a feature with connectivity was left intact after all patches were applied.

Should I change the scope of ungoogled-chromium to more align with my preferences (and perhaps change the name as well)?

I believe that for the most part you should decide in which direction this project will be heading. After all this is your hobby and I imagine that you want to keep an interest in it. The project name doesn't matter much to me.

Should the browser be split up to let other developers determine how they want to package ungoogled-chromium (...), or should it more strictly control the entire process of the browser creation (...)?

Assuming the current philosophy, the building process needs to be controlled to a certain extent by altering the source and by providing sets of patches and GN flags. Certain settings can be overridden during building as long as they don't violate the key ideas. Either way, what happens after this step should not be your responsibility anymore.

[MalevolentGrin]

#640

treating ungoogled-chromium as a browser for dealing with privacy issues... However, ungoogled-chromium does not have much in terms of privacy; I leave a lot of that to the user.

Take the project in a Pro Privacy direction? From Human Dignity is derived one's (negative) rights to privacy. Everyone has something to keep secret: one's private thoughts [individualism], and one's intimate self (which cannot be taken, but only given freely).

https://github.com/privacytoolsIO/privacytools.io/issues/274#issuecomment-391922550

Firefox and Chrome and every other Browser does connect straight from the start with default settings to several domains, to update the disconnect filter list or for the safebrowsing mechanism etc.

The problem with these defaults is FAILure to collect INFORMED Consent from the user. This poses a business model threat to google: explaining how not charging user money allows google to profit from user. [Privacy Raping].

#640

[2] I have a bias for control over convenience.

I have this not-blind-trust bias also. Google has done nothing to earn my trust and everything to have me embrace the nomenclature Privacy Raping as profit. It is crass but apt.

I don't like bloat. I want to remove stuff that I don't need or want.

This is why I adblock. I not only minimize data harvesting but I feed the system lies.

I don't like runtime dependence on online code

This is another example of non-trust with which I agree.

[3] I want ungoogled-chromium to grow. Clearly, the people that use my browser are not all like me

I find myself in parity with your values in this scope thus far.

What do you think ungoogled-chromium should be?

1. Minimalism
2. Honor the user's dignity: Privacy Rights are sacrosanct. Collect Informed Consent before exposing them to harm.
   2b. blocking
   2c. disinformation

should fingerprinting deception mechanisms should be removed

no.
[disinformation] the entire userbase should appear to have the same fingerprint. E pluribus unum with a twist

Perhaps domain substitution and binary pruning can be optional for packagers of ungoogled-chromium

Any easy built kit for others sure, but would that more than double your effort?

should ungoogled-chromium become a Chromium derivative that emphasizes more on privacy and FOSS (which aligns more with my preferences), in addition to removing Google-specific behavior (e.g. Google host detection, connecting to Google servers)?

YES

other developers determine how they want to package ungoogled-chromium

What are the numbers for people doing this now?

should it more strictly control the entire process of the browser creation

You have a firm grasp on the important of privacy, and as a single issue we can all stand together on it ultimately doesn't matter how or why you have reached this valuation to this end.

#PrivacyMatters

Yes, this is an exacting discipline few will adopt as vigorously but by example we can save more people from inadvertently self harming.

[nicolasmaia]

I'm okay with things as they are, but as others have said, the pre-built binaries and auto-updates would be the only thing I'm still missing from this project. That's about it.

[fosslinux]

I want ungoogled-chromium to be as unobtrusive and lightweight as possible.

+1

I am heavily influenced by Debian's philosophy of FOSS. This is why things like binary pruning (to remove any binaries) or domain substitution (to remove any background connections to proprietary services) exist.

I am a huge fan of FOSS and on all my computers require a FOSS-only system. I think these two features (binary pruning and domain substitution) are vital to ungoogled chromium.

I don't like activities to "think for me". I want to know what a certain activity will do and its implications. In other words, I have a bias for control over convenience. This is why flags exist for things like IPv6 probing, the removal of captive portal detection, and the removal of mDNS and Service Discovery in #160.

Same. I think all of these should be enabled by default (I can't remember if they are).

I don't like runtime dependence on online code. This goes back to having control of what my software does (e.g. take the NPM module disaster not too long ago). Also, I don't like the assumption that an Internet connection is always available (maybe in the near future, but not yet). This is why I patched the browser UI to use bundled Google fonts instead of Google's font server, and why I changed DevTools to only use a local copy of its JavaScript code (it usually uses JS code hosted on Google).

I never want this to be the case. With this dependence, air gapped systems are basically rendered useless.

Perhaps domain substitution and binary pruning can be optional for packagers of ungoogled-chromium

No. As I said, these two are vital to ensuring a fully-FOSS browser. Even if you do make them optional, please make sure that they are enabled by default.

Some further thoughts are below, just things I had thought of, especially in relation to goals.

The name states the main goal:
To remove Google from the picture of Chromium.

Chromium/Chrome is a great browser, but what primarily prevents me from using it is Google. Google is a for-profit, and has had many occurrences of data/privacy leaks.

https://www.independent.co.uk/life-style/gadgets-and-tech/news/google-chrome-incognito-mode-personal-data-private-browser-a8502386.html
https://hackernoon.com/data-privacy-concerns-with-google-b946f2b7afea
https://www.cnbc.com/2018/09/26/google-changes-chrome-browser-in-response-to-privacy-advocate-critics.html
https://www.makeuseof.com/tag/browser-leaking-online-secrets/

This brings me to one of the other goals that I think should be an integral part of ungoogled chromium - privacy. In this day and age, internet privacy is dying. We need more applications that a) can be verified that are private (FOSS, I'll talk about this shortly) and b) care about the users privacy. Ungoogled Chromium can be one of these.

I believe security should also be a goal of ungoogled chromium. AFAIK, Chromium has never had an independent security audit done and is not written with the goal of security in mind.

At some point, as a person who would like to work in infosec, I would love to do a security audit of Chromium. Security patches should be put into ungoogled chromium, however should also be submitted to upstream. If the patch is rejected, it should stay in ungoogled chromium, however be removed if accepted in upstream.

This can be summed up as Chromium is a great browser, but has been too much Google-fied. It needs a better focus on security and privacy.

[intika]

Very interesting topic ! keep it clear and simple right?! :) here are my comments :

• Feedback in here could represent a minority (this should be took in consideration)

• UC is mainly fine as it is this is what made it successful so careful on drastic changes (you already have an opinion/feedback from reddit where you got 89% upvotes and it brought the project more than 1000 stars which mean almost 100% of people that read that article liked the project here are some statistics about uc on my other post)

• UC experience should be the same over different platform and therefore patches should be separated in 2 sections, core patches (security/privacy/etc.), patches that are necessary for this or that platform (core patches should never be present on a platform and not on an other one). therefore i think it's important to have a more solid core patches.

• Following this point i think UC should be kept centralized as much as possible, spiting is inevitable i know but this should be done with care to keep the experience the same. (so avoid too different version because of platform patches that would handle a core feature)

• According to the statics i listed here; your personal preference seems to make happy most of your users (me included) i think the key here is just to avoid features that break the usage.

• Give choice ! this one is very important, (its somehow already the case and i think it's one of the key element that are making UC popular) this point is about: 1. Applying all changes that does not break usability 2. Give the user the choice for the rest over flags or command parameter.

• One very important thing is a clear and well defined updater (i know distro's repo are taking care of that where UC is published) but an update system for other builds should be developed.

• Android can bring a lot of users, i think android version is a must BUT this should come after taking care of the main project roadmap. (i know android is very difficult to do regarding "core patches/features" may be separating android version from main UC could be a way to go)

• Also as other already reported back binary pruning and domain substitution, should be kept as they are useful.

• I think UC should get a new name, and change the chrome trademarks even if the project is amazing it's kind a lack of identify while it is using chromium trademark. thus said the project should continue to stick to main Chromium. and not deviate too much to keep things simple and manageable therefore keeping the current patching system.

• The name and domain: @AZDPS pure-chromium i like it :) may be just 'Pure' is better (those 2 issues should be considered Project Name? #642 and A website? #335)

• Considered question 1 definition: you are already defining what 'ungoogling' mean by your personal action/decision and it's working, you just need convert your personal key elements to a feature or core element for the project and while converting them eject what could break the usage and keep the feature as a choice.

• Considered question 2 scope: already answered on question 1 answer, but one important thing, UC should not derive a lot from chromium for maintenance/update/etc.

• Considered question 2 name: yes the name should be changed (personally not for me) but to get more users this is a key element (example i get a lot of audience by renaming Privafox to Librefox)

• Considered question 3 splitting: may be for android because its a lot different but not for the rest, similar user experience is a key element. (i already answered with the proposition of core/distro patches)

One last advice is decide and just go for it whatever you decide don't wait you can still change/adapt it afterward.

[Eloston]

Thank you all for your responses. After considering your perspectives and my own motivations for this project and beyond, I have decided to opt for a mixture of the proposed solutions. ungoogled-chromium's name will remain (for now) and so will its effective goals (which will be clarified in the new README). However, I will more cleanly separate "core" features that remove Google integration from "extra" features that provide additional privacy/security/control enhancements. In addition, I will be fragmenting the ungoogled-chromium repo into multiple repositories under the ungoogled-software organization for each individual platform.

The refactoring progress will be tracked in #651.

[csagan5]

I did not notice this issue before, some (late) feedback:

• having the name contain a trademark of a company is problematic and it will always be the case, so I would suggest to loose it whenever possible to avoid any potential future issue; IANAL but this is probably the feedback you would get from any lawyer, you can also contact one through EFF (although probably you will get a referral and not an official endorsement)

Everything I have read here and also @Eloston decisions make sense, my 2 cents:

• the build system is the most important part also related to making FOSS builds; this is a concern which has before popped up to my attention (for the Android targets) with https://gitlab.com/thermatk/Unobtainium and more recently in Gclient hooks optimizations & removal of non-free binaries nikolowry/bromite-builder#4; however, the holy grail here would be to upstream a "FOSS mode" build in Chromium itself; I am saying this because otherwise patch maintenance is a relatively big burden for any downstream
• the build system would ideally be very flexible and allow customization of the patchsets to use
• @Eloston you should not inflate this project to become so big that it takes away all your free time and drains your energy: try to split it in a way that you are still motivated and happy to work on it, and delegate parts to collaborators (as you feel fit) that might want to contribute their time; I am suggesting this as a general rule of thumb if you see the project increasing in size outside your comfort zone

I have also read the privacytools.io issue (my comment here: https://github.com/privacytoolsIO/privacytools.io/issues/274#issuecomment-452332784); I disagree that a privacy violation must be proven before disabling an integration, as the user should always have choice regardless, but I agree that for some other patches (like fingerprinting) there should be scientific proof before adoption and use (and I have tried to follow the scientific approach in such "experiments" with fingerprinting mitigations).

[Eloston]

@csagan5

having the name contain a trademark of a company is problematic and it will always be the case, so I would suggest to loose it whenever possible to avoid any potential future issue; IANAL but this is probably the feedback you would get from any lawyer, you can also contact one through EFF (although probably you will get a referral and not an official endorsement)

You're right, but it's hard for me to decide on a good name. I'm not sure how I would let others submit feedback and vote on names either. Also, I need the name to be decent enough since it takes work to change the name. So, I have been leaving the name alone since no one's had any large issues with it yet.

try to split it in a way that you are still motivated and happy to work on it, and delegate parts to collaborators (as you feel fit) that might want to contribute their time; I am suggesting this as a general rule of thumb if you see the project increasing in size outside your comfort zone

This isn't an issue under the current system. Nowadays, I spend most of the time on this project responding to feedback on GitHub, reviewing code, and making any foundational or DevOps-related changes. I don't really know how to delegate responsibility for feedback response or code reviewing on a project run by volunteers (assuming it's possible), and the changes I make are things I find interesting (which take time in a good way).

[nchv]

Disclaimer: I haven't read the replies by others.

I like everything you have written in 1-3 as it aligns quite well with my thinking. It is also very nice of you that you are willing to know what others want too. However IMO you should be careful with trying to satisfy everyone. Not only because it is impossible but also because it may derail the project away from the good thing it already is. Also bear in mind that people use it because of what it is, not because of what it could be.

What should ungoogled-chromium be?

I have tested pretty much all existing browsers and so far UC is the only one which does that:

• truly privacy respecting: zero non-requested connections
• supporting well the modern web and security standards
• FOSS (of course - no binary blobs)

I think this is the mainline which you should keep. How you will organize work with other developers is up to you.

Are there other relevant considerations or ideas?

I have been thinking about the licensing part several times (and the name "ungoogled"). I haven't looked at all the licenses of Chromium and if there may be some potential legal traps that may influence this project negatively. So to ensure it will keep growing as a true FOSS, this is something which you should probably look into (even if that means consulting a lawyer). Of course - I don't know, you may have done that already. Just sharing thoughts.

And most importantly: don't ever give it in the hands of anyone who would "re-google" it (or corrupt it in another way).

In case you are asking about new features:

Those should all align with the mainline. I think it was mentioned in some issues that making it fully capable to do what Tor Browser does would be good (e.g. separate tor circuits for new tabs and other things which TBB does). Perhaps opening a communication channel with the TOR community may make them leave the "private" Firefox which they have been hacking for years. Another good communication channel would be with the developer of uMatrix and uBO which are really irreplacable extensions when it comes to security and privacy.

Ideally when it grows big enough (as in: enough developers), ideally it would split completely from Chromium and continue with its own code base.

Also: I am not sure if GitHub should be trusted long term. ;)

---

BTW regarding clang there are some guys who say both GCC and Clang suck:

https://suckless.org/sucks/

(It's an interesting site as a whole, might give you some good ideas)

[ghost]

@Eloston, Do you have any suggestions? #642
Not sure if you wanted me to also reply here;

How about simply calling it Libre (https://www.wordnik.com/words/libre)
adj. With very few limitations on distribution or improvement; including source code.

[summersab]

So, I've only skimmed this thread because it's long (and I'm lazy . . . er, I mean, "efficient"). That's said, I'm currently an Iridium user, but I'm looking to switch to UC because they no longer have someone maintaining their Debian builds. I opened an issue asking what was needed and also proposed the idea of joining forces with UC:
iridium-browser/tracker#293

I don't know if such a move would make sense, but it might help both projects if you worked together.

Another idea that is probably a stretch (and not in line with the goals of the project as a whole) would be including very select extensions that are useful for everyday privacy. For example:

• https://gitlab.com/KevinRoebert/ClearUrls
• https://github.com/EFForg/https-everywhere/
• https://github.com/EFForg/privacybadger (probably too advanced for average users and would cause headaches)

These could either be included by default or offered to be installed at first-run.

[artemislena]

@summersab I'd certainly be careful with two of those. Privacy Badger doesn't add any benefit if you use uMatrix, and it can actually be a lot worse for privacy because what sites are blocked is based on what sites you have previously visited, while quite a few tracking sites will not be blocked at all… As for ClearURLs, the same functionality is afaik provided by Netguard (which iirc is basically uBO + ClearURLs). Some people may have similar issues with other extensions… So, adding any may actually be detrimental, at least in some cases. It also might become harder to maintain as updates for these extensions would have to be provided.