Replacing the WebExtensions portal

[swick]

With improvements in dbus it should become possible it the future again for flatpaked or otherwise sandboxed apps to talk to each other. When support for this lands, we can add a new native messaging system to browsers which uses dbus to open the pipe, as outlined in this comment: #705 (comment)

The need for a WebExtensions portal will then be limited to apps native messaging servers which did not upgrade to the new mechanism and can eventually be removed.

[bayazidbh]

Would this help with Discord IPC and Currently Playing as well? I tried the Discord Flatpak but couldn't find the game I want to show on my Activity through their process selector. The alternative was using arrpc and vencord but that still required poking some holes in the sandbox too.

[TingPing]

Not related to Currently Playing. That needs a host service that does that work for Discord, be it a portal or otherwise.

[Mikenux]

Why not? But:

• It is a Web Browser that wants to communicate with a native app, not an extension, the WB being not reliable from the point of view of a sandboxing system. Access approval is therefore required (regardless of what needs to be said to the user).
• Apps without network access will have access to the network thanks to this talk permission. A portal UI is therefore necessary to inform the user about the possibility of sharing private information (because we cannot control the type of information that the WB and the app will exchange).
• The user must be informed if the WB wants to launch an app, because an extension could possibly be installed automatically by a vendor/distributor/administrator.
• We may want to revoke the talk permission between a WB and an app when a user removes the extension from the WB. I think it makes sense. How can we handle this, since the WB can say that an extension has been removed, even if it hasn't?

[Mikenux]

@swick: Even though there are no security issues, there is privacy. Any app intended to be fully sandboxed cannot communicate with any other. But, regardless of an app's sandbox state, the only parties that can grant permission are the user and the system (if the system has a policy for "privileged" apps, decided by the distributor or an administrator, which seems not to be implemented at the moment). An app cannot decide.

@brunoais: What are you talking about?

[swick]

Any app intended to be fully sandboxed cannot communicate with any other.

That's just wrong.

[Mikenux]

If a fully sandboxed app can communicate with other apps, then there is a problem.

[swick]

There is not.

[Mikenux]

Another aspect to consider is that the permission is supposed to be revoked when an extension is disabled.

[iavael]

Why would authors of hundreds of webextensions care to support linux-specific non-portable messaging system?
What's the plan to motivate extension developers to do extra work supporting dbus-based messaging?
Because even if you make major browsers support dbus-based messaging (which is quite a work by itself), low adoption among extension developers would make this initiative dead on arrival.

[swick]

1. The changes are transparent for the extension.
2. Browsers already have to implement this mechanism for every OS, because it is OS specific
3. Starting apps by executing a file at a specific path is simply not the proper way to start apps on the linux desktop and has not been for decades.
4. D-Bus activation solves the problem of apps being confined and or in containers where a container specific path translation is otherwise necessary
5. D-Bus activation solves the problem of putting the processes in the right cgroup and systemd unit