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

[filips123]

I agree with @iavael. Currently, the actual communication is done through stdin/stdout, which works basically the same in all operating systems, and is supported in virtually every programming language, without any extra code or libraries. Handling D-Bus is more complicating and often requires additional libraries, if any even exist for the language the native messaing cost is written in.

The changes are transparent for the extension.

They aren't transparent to the native messaging host, which is commonly developed by the same people as the extension. So, it's not really transparent to them.

[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]

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)

[rugk]

Backlink to a user having the same problem with LibreOffice + integration in Zotero/Firefox.

Anyway, my personal opinion is: Let's get that PR for NativeMessaging merged first, finally and not get distracted in these discussions. You know, perfect is the enemy of good and we're waiting for this very long, already. 😉

[Mikenux]

@rugk: I know 😉 But, here, it is for the long-term solution (I forgot to say it), so unrelated to the PR which is for the short-term solution ("quick" fix). The discussion can therefore continue.

[Mikenux]

App Request: extension vs. app + extension:

• extension. The portal will search for an app having the extension. Any app having this extension in its allow list will be shown.
• app + extension. The portal will directly search for the app and check if it has the extension in its allow list. This has the advantage that the request can be denied if the app does not exist or when the app does not have the extension in its list (if it exists).

[Mikenux]

Another thing: Data exchange allowed when app has the focus. What would be interesting to know is if it is only for the requesting app or also for the requested app.

[Mikenux]

For that, the app needs to be aware when it has the focus.

Additionally, trust checking between apps must take place every time the request (for communication/data exchange) is made, so that trust revocation by any of the apps can be handled.

[Mikenux]

I think what is also wanted is to be able to disallow the use of portal permissions and/or to redisplay portal windows when an app receives data from another app.

[Mikenux]

There is a problem I just thought about.

I designed my proposals for neighboring files so that an app uses the right proposal for its case: it's case exclusivity. Here, native messaging allows to get credentials and, I guess, to exchange files. There were already discussion and code for a credential portal, and we know that a portal should be used to exchange files between apps. Thus, with native messaging, it does not seem possible to ensure case exclusivity. I don't know, at least currently, how this could be handled (I'm just reporting the problem).