GitLab

The Extensions app handles extension configuration, updates and removal, but not installation. That is in line with the design outlined in #1968 (closed), which keeps the website/web-extension in charge of that.

Unfortunately that's not the end of the story.

It turns out that the host integration works by registering a binary with the browser, which it then launches as necessary and communicates with the process via stdout. Which is extremely sandboxing-unfriendly to say the least:

• setting it up with the minimal permissions is incredibly cumbersome
• the alternative of registering a script that does flatpak-spawn --host chrome-gnome-shell is slightly less cumbersome, but requires permission to run random programs on the host (not great for browsers!)

This is a problem for all web exensions that use native messaging, so there's some pressure to come up with a sandboxable replacement. Maybe that means we can just wait it out 🤷

But I don't like standing in the way of flatpak adoption, in particular for browsers where sandboxing is particularly desirable.

Off-hand I see two options around the issue:

• change the website to drop the whole plugin/management stuff and expose simple "Install" buttons that use something like gnome-extension:foobar@extensions.example.com, then have a simple schema handler that translates that to the corresponding D-Bus call

  Compelling from a gnome-shell perspective, as most of the work would be on the website; but it's somewhat less nice (the site no longer knows whether an extension is already installed or not), and the change would either render the web extension obsolete (probably not popular with its developers) or make the website more complex if implementating the change as fallback when the plugin/connector aren't available or fail

• add extension browsing/search/installation in the Extensions app

  Probably more appealing for users, but a big increase of the app scope.

Thoughts?

@aday