Allow installing extensions, other than from chrome store

Description

ungoogled-chromium should allow custom system- and user-level extensions

Who's implementing?

[X] I'm willing to implement this feature myself

The problem

One of the primary mechanisms, that allow google to exert control over the chrome ecosystem, is via its chrome store.

e.g. it's easy to predict that manifest-v2 extensions will vanish from chrome store, despite still being able to run when re-enabling manifest-v2

Extensions will always be part of a modern browser experience, so with the main option for extensions being chrome store, users are currently still at the mercy of google, despite running ungoogled-chromium.

It is important to not conflate auto-installing extensions from chrome store, with running custom - possibly local-built - extensions.

Possible solutions

There are several delivery mechanisms, that could allow running UC with custom extensions:

chrome policy
- unclear how to override per-user
- potentially complex impl
search path env-var - this is already proposed https://github.com/ungoogled-software/ungoogled-chromium/pull/2753
hardcode search path: chromium already supports loading extensions from /usr/share/chromium/extensions, so just customizing that path could already be enough
- this seems to have been guix' approach, before switching to env-var
- less possibility for user to override / customize behavior
command line flag
- potentially complex impl
more complex extension management, declarative or otherwise
- would have to be built in the first place, probably not within UC
- would still have to bottom out at a simple mechanism in UC

Resolution of a previous issue seems to suggest, that custom extensions are already possible, because guix already packages extensions for ungoogled-chromium: https://github.com/ungoogled-software/ungoogled-chromium/issues/1281#issuecomment-743410205

However, deeper investigation reveals, that this is possible due to guix patching UC for this: https://issues.guix.gnu.org/44335 This kind of downstream inconsistency is exactly what we should avoid.

Alternatives

Manage the extension directory in the user profile

Doesn't really have a story for auto-updates
No system-level extensions / user might destroy and recreate their profile / user might run multiple profiles

Host an update manifest

see https://github.com/NeverDecaf/chromium-web-store#if-you-are-a-chrome-extension-developer

even higher barrier of entry for regular user

Additional context

One of the primary reasons for google to only allow auto-install from chrome-store is ostensibly to make it harder for vendors to pre-load malicious extensions. However:

It's still plenty easy to do for a bad actor (see Alternatives)
In a free system, this becomes a non-issue, since the whole system is under direct control of the user

References

PR implementing an extensible extension search path: https://github.com/ungoogled-software/ungoogled-chromium/pull/2753
nixpkgs PR for env-var approach: https://github.com/NixOS/nixpkgs/pull/188086
previous issue https://github.com/ungoogled-software/ungoogled-chromium/issues/1281 seems to have somewhat conflated custom with auto-installed exts
guix issue about the env-var approach: https://issues.guix.gnu.org/44335
a nixpkgs issue about auto-installing extensions: https://github.com/NixOS/nixpkgs/issues/158449
- out of scope for this, but could still be enabled

Justification

I opened this issue for multiple reasons:

contributing.md says that "larger" contributions should have associated issues
there seems to be some confusion on whether this is for just nixos, and the original PRs seem to have some convoluted history. so this is an attempt at reasoning through this from first principle
it doesn't really fit with nixpkgs per se, because it would be substantial new behavior for UC

No, this is not happening until it gets decided in nixpkgs upstream.

In what way is nixpkgs to be considered upstream to this?

What decision should be taken by nixpkgs and how would it influence UC?

(https://github.com/ungoogled-software/ungoogled-chromium/pull/2753#issuecomment-2188115010)

I am not convinced that installing extensions declaratively or externally or however is not possible without modifying the source code.

with my nixpkgs chromium maintainer hat on I would like to support declarative extensions management without carrying patches for chromium or ungoogled-chromium.

with my ungoogled-chromium maintainer hat on I don't want us to carry patches that I'm not convinced help downstream packaging or users.

From what I can tell chromium tries to load extensions from these locations currently:

/usr/share/chromium/extensions
~/.config/chromium/Default/Extensions (thats where chromium installs them when using NeverDecaf's chromium-web-store extension; I assume thats true in vanilla chromium for the normal webstore as well)
~/.config/chromium/Default/External Extensions which Michael Adlers' Extension Downloader uses

with my nixpkgs chromium maintainer hat on Given that, it seems clear to me what we can do in nixpkgs: Support installing extensions via /usr/share/chromium/extensions just like we already support enterprice policies for example which already apply globally.

For modifying files in the user's home directory we'll have to use home-manager, there the extension management should conceptually be the same as for Visual Studio Code (which also only supports the default profile currently, by the way).

First off, would you mind elaborating how your response answers my two questions you quoted, @networkException? What kind of decision are you looking for in nixpkgs, and how could it change the situation for ungoogled-chromium? With your UC-maintainer hat on, how would it be different from the decision, that's already been made in guix?

with my nixpkgs chromium maintainer hat on Given that, it seems clear to me what we can do in nixpkgs: Support installing extensions via /usr/share/chromium/extensions just like we already support enterprice policies for example which already apply globally.

That sounds like a solution to this, however, we don't have /usr/share in nixos, and we won't introduce it just for UC, right? Enterprise policies work, because we still have /etc. You can't install extensions from there, only download from chrome store, like programs.chromium.extensions does. So can you elaborate on how specifically to do this, when you say we can already do this? Are you thinking of introducing a mount namespace?

with my ungoogled-chromium maintainer hat on I don't want us to carry patches that I'm not convinced help downstream packaging or users.

What would it take to convince you?

To answer a few other of your points:

Ad ~/.config: As I said, let's please try to leave home-directory poking out of the solution space. chromium already supports /usr/share/chromium/extensions, and it has a real impact when that path is not usable.
Ad vscode: On a surface level this looks like a good point, however
- Its solution of poking around in ~/.config also has drawbacks, and I have seen real-world breakage from it
- All versions of vscode I've looked at, still provide direct access to marketplace, which alleviates the need for extension management to a large degree
- vscode doesn't seem to support a system extensions folder at all
- vscode provides an --extensions-dir flag, which would already enable this use case

That sounds like a solution to this, however, we don't have /usr/share in nixos, and we won't introduce it just for UC, right? Enterprise policies work, because we still have /etc. You can't install extensions from there, only download from chrome store, like programs.chromium.extensions does. So can you elaborate on how specifically to do this, when you say we can already do this? Are you thinking of introducing a mount namespace?

with my nixpkgs chromium maintainer hat on:

I did not have that on my radar, but NixOS not having a global /usr/share is subject for a patch like this to adjust to somewhere in /etc.

Ad ~/.config: As I said, let's please try to leave home-directory poking out of the solution space. chromium already supports /usr/share/chromium/extensions, and it has a real impact when that path is not usable.

I disagree, the home directory is a perfectly fine place to manage per-user extensions

All versions of vscode I've looked at, still provide direct access to marketplace, which alleviates the need for extension management to a large degree

I don't know how this is relevant here but mine doesn't, for example, I choose to not let VSCode access the internet

with my ungoogled-chromium maintainer hat on:

In conclusion I don't see how patching ungoogled-chromium is nessesarry. I will close this issue as Michael Adlers' Extension Downloader is already working for the goal of this issue from my perspective.

with my nixpkgs chromium maintainer hat on:

For NixOS, where other plumbing is required, there seem to be good options for installing extensions declaratively: In the user's home directory using home-manager and system wide with normal NixOS Modules.

I think a good way forward is to prototype the system wide extensions first, allowing new packages and modules changes to happen at once. Then home-manager can leverage the newly added packages for their implementation. This is especially important since the packages are likely going to need to carry some metadata (as chromium hunspell dictionary packages do).

I now agree that my real goal is system-wide extensions, which UC already supports, so OK by me.

ungoogled-software / ungoogled-chromium