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

[Mikenux]

Wouldn't it be better to have an app that indicates which app to communicate with than to have to indicate an extension? While I don't know how Discord operates, it will allow apps to ask to communicate with Discord, because I doubt Discord is using a list of allowed apps. This will allow this portal to do more things, and avoid developing something specifically for web browsers, namely searching for the app that has the extension given by the browser as allowed. However, this would mean that extensions would have to indicate which app to communicate with. As an advantage, this allows developers to have a trusted model where a specific app can be specified as the app ID + repository + branch, for example.

[Mikenux]

@orowith2os

Seen your comment. Is Discord limited to Rich Presence or is there more than that?

[bayazidbh]

@Mikenux I think so, but there's a lot to Rich Presence - like arrpc, PreMiD, a different Rich Presence extension, the IPC Bridge, mpv-discordRPC.

[Mikenux]

Thanks. This seems only about text data for statuses. If there was some command exchange other than for a status, then Discord is a case. Otherwise, not. If it is only for that, having a portal where data can be parsed and limiting amount of data that can be exchanged is better (or with use of metadata, maybe with wayland), as here we assume any data can be exchanged between apps. For web browsers, limits are max 1 MB from app to browser - sufficiently big for some file transmission - and max 4 GB from browser to app... (and I wonder what are the cases for that...).

[Mikenux]

@Rob--W: A thought on what I describe in the first comment on this thread? In addition, could you tell which cases should be able to send up to 4 GB of data through a web browser? (this is to find out if it is possible to have limits in the portal and which ones)