Network permission portal

[sonnyp]

Sandbox apps should be able to request network permission at runtime. This is a discussion to get the ball rolling.

Goal

Applications that do not need the network on start or as part of their core features should be able to request the network permission at runtime in order to be considered safe by GNOME Software or flathub.org.

Users should be informed about the request and allowed to reject it if they don't need or want the application to connect to the internet.

Design

To be considered safe, the permission cannot be given without explicit user consent
The permission dialog should explain in clear terms to the user what it means to give network permission and what is the risk.

Future applications

In the future we might want to use a socks proxy for sandboxed app network which could allow for the following use cases that are out of scope for now:

• Log/inspect network activity
• Restrict network activity (origins, domains, protocols, and ports)
• Measure bandwidth usage
• Restrict bandwidth usage

[Mikenux]

Personally, I would prefer to have a specific badge rather than being asked for network access. For example, it wouldn't make sense to be asked for network access for a chat or web browser app... And, for such applications, you won't mark them as sandboxed because they need permanent network access? In short, it's more complicated than it appears.

[sonnyp]

Please start another discussion if you want to discuss something else.

[Mikenux]

Sorry, I read to quickly, so I made false inferences.

You said that "Applications that do not need the network on start or as part of their core features" need a portal to be marked as "safe" by GNOME Software or flathub. Therefore, I think it is completely normal to wonder what will happen to applications that require permanent access to the network, because this portal should also be used by those to have a dynamic permission (for example, we can choose to start a web browser without network access to view a local website).

Also, just to be sure, does "at runtime" mean "when the application has started" (before using the app when it is ready)?

[Mikenux]

It is better to have network permission (at least for Internet access) when needed.

With an "on startup" permission, the problem arises when the user sometimes wants to use network features, and sometimes not. In this case, the user will not choose to always grant (or not) permission, and will have to be asked each time the app is started.

With a "when needed" permission, the user has their files protected from Internet access (from the app's perspective and if it is fully sandboxed), and Internet access can only be granted for target files.

However, a "when needed" permission requires:

• Isolating selected files;
• Giving network (internet) access to these isolated files, and not to the app.
• The app to be able to display a window to connect to a web service, with Internet access and isolated from the app.

Here, this is the case for apps that can share files with web services. Another case that can be discussed, if what I mentioned above is possible, is the case of streaming (especially for apps that have recording and streaming options like OBS Studio). I don't know if there are other cases.

[smcv]

I think there's limited value in having a long discussion about what people want, if there is nobody with the necessary level of knowledge and availability to be able to say what is and isn't possible, and actually write the code. (I am not that person: I'm responsible for too many projects already and I have very limited time available for flatpak and xdp.)

The elephant in the room here is: is a network portal even implementable? If it isn't possible, then it can't happen, however desirable it might be to have one.

If it is indeed implementable, I don't see a way for this to happen without significant amounts of design and coding in both the app framework (Flatpak, Snap, etc.) and the portal. In Flatpak, I believe this would require unsharing the network namespace, having some sort of bridge (slirp4netns or similar) between the app's netns and the host machine's netns, and then having that bridge be remote-controllable so it will selectively block or allow traffic under xdg-desktop-portal's control (presumably starting in a state where nothing is allowed, and selectively allowing things from there). I don't know how feasible that is. Has anyone attempted to prototype it?

In non-Flatpak app frameworks, if the app framework has a way to do the equivalent of what I described for Flatpak, then it would have to do that, and if not (for example if it unconditionally shares the host netns with the app), then this feature will be impossible to implement for that framework.

[sonnyp]

Dynamic network portal is something the GNOME Foundation is considering funding as part of a government open-source program. Even if only a prototype.

Technical feedback and thoughts are very welcome.

Thank you @smcv

[sonnyp]

flatpak/flatpak#1202

[redstrate]

What exactly is the true goal of the portal, apart from being marked "safe"? What exactly is the network portal trying to prevent, that isn't solved already with the network permission we do have?

The only reason given so far is to get a nice green "safe" badge. (Trying not to word it like I'm mean, I'm only curious :D) Onward, what safety difference is there between an application with unfettered network access, compared to one that prompts before every network access? Is it to prevent malicious applications, or give more transparency to users? I think it's important to mark this line in the sand.

Apart from the reasoning, I would argue that it's really bad UX to give users control over the stopping applications from interacting with the network (which it almost always needs.) I suspect that's why almost no operating system gives you that knob, or if they do you have to go searching for it. At most they'll give you permissions for allowing local network access, which is a much rarer case.

To be considered safe, the permission cannot be given without explicit user consent
The permission dialog should explain in clear terms to the user what it means to give network permission and what is the risk.

If I can ask, under what conditions would a user be expected to not give network access to an application? A non-comprehensive list of cases I can think for typical network access:

• For browsers, chat applications, and social media clients like Tuba they will always check "yes".
• In more nuanced applications like Blender (where the main application normally doesn't connect to the network but add-ons might) will users say "no" in the beginning, and then later never figure out that inadvertently broke something?
• Tooling and utility apps like Insomina or a YouTube video downloader allow users to connect to any arbitrary URL, so a network box here will always be "yes'd"

Apart from the portal, would it make sense to let applications explain why they need to connect to the network? That way users can make the distinction between "unsafe because we have no real idea what it's doing" and "it's for playing videos from the internet :)". I also think it makes sense to have a way to prevent local network access, and have that separate from allowing internet access.

[sonnyp]

As I said "Applications that do not need the network on start or as part of their core features"

I never thought this would be useful beyond that. Although there are more things we can do but I'd rather start small.

What exactly is the true goal of the portal, apart from being marked "safe"?

I added the following goal to make it more explicit: "Users should be informed about the request and allowed to reject it if they don't need or want the application to connect to the internet."

that isn't solved already with the network permission we do have?

It's always on, user doesn't get a say.
Only expert users can override it but also you're then in unknown/unsupported territory.

I suspect that's why almost no operating system gives you that knob

Most platforms don't have the capabilities to do this, and the ones who do rely on adtech to make a profit.
Incentives are not aligned.

(Trying not to word it like I'm mean, I'm only curious :D)

No worries, "This is a discussion to get the ball rolling."
Happy to challenge the idea and make progress collectively. This is new territory for everyone.

I've been starting multiple separate conversations on this topic, here is another one that addresses a more specific use case https://floss.social/@sonny/112248762450342782

[Mikenux]

• For browsers, chat applications, and social media clients like Tuba they will always check "yes".

Of course. In such cases, it would be better to have it by default rather than asking for it. But further design and consideration is required to make the best decision.

For other cases, it's a matter of having a Download portal, as also suggested in the comments of Sonny's post. An Upload portal will also be necessary (this is what I indirectly talk about in my comment). However, this is something to discuss later as these are cases that seem complex.

@sonnyp:Don't forget to open discussions here when you have something ready 😉. For anonymous telemetry, there are already three problems:

• The server that anonymizes the data that must be trusted (as it seems to be presented in your post). We may wonder why we should necessarily trust a server, here Flathub. Local treatment is preferred, if possible.
• You mentioned Flathub as a server, which is also a repository. Other parties or repositories may want the same thing, which are also intermediaries that the user should trust.
• You can have "Terms and Conditions", regardless of the parties - the end server or any other anonymizing server, but remember that the portal itself cannot guarantee these terms and conditions, nor trust in any server.
• "Make public": also here, a portal cannot guarantee this to users.

[Obsessee]

As a general rule of thumb it seems that Flatpak is trying to move away from sandbox holes to more dynamic matters of permission handling like portals. I think based on that reason alone this idea for a portal should be considered. Furthermore, I think it's a good idea to introduce a network portal because it further improves the ability to follow the 'principle of least privilege'.

A portal that would be able to communicate and deliver the following for applications would be of benefit, granted I am not intensily familiar with other ways of accessing this information:

• Ability to turn on and off network/internet access (Already doable via existing permission)
• Determine granularity of access to network (Local network, Internet)
• Communicate the type of connection (Wi-Fi, Wired, Cellular)
• Whether the connection is metered (Easily determine whether to reduce network usage)

This would also nicely integrate with the future applications as described by OP:

• Measure & restrict bandwidth usage per app (E.g. Set a daily data cap per application)
• Log/inspect network activity (Measure all connections entering and exiting the sandbox)
• Restrict network activity to only certain types (origins, domains, protocols, and ports)

I think this portal idea is a great idea, and would be of great use in unifying different network managers into a single usable API for application developers.

[Mikenux]

I re-read and realized you wrote this:

Sandbox apps should be able to request network permission at runtime.

I think it would be better if apps had the option to make the request when they need network access rather than only at runtime. Requesting at runtime is relevant for web browsers, while requesting when needed is relevant, for example, for task apps (tasks can be stored locally or be synchronized). As such, there might be two types of dialogues, in the following directions (wording to express direction, not wording necessarily for dialogues):

• At runtime: "The web browser needs access to the network now...". But the app might work without it.
• When needed: "Task App needs network access for the requested feature / the feature you triggered...". This emphasizes that the request for network access follows an action triggered by the user.
• Specify that this is not mandatory.
• Code: "When needed" cannot be requested at runtime.

[Mikenux]

I had forgotten that I had already talked about something like this in a previous comment.

Difference between the two:

• Previous comment: If there is process/file isolation.
• This comment: If there is only on/off permission.

Another note for on/off permission: if the app wants to request access at startup (rather than when needed), that's something the app developer/packager must declare, as it's flatpak/xdp that needs to show the permission dialog to make sure it's presented at startup.

[allanday]

I'm a UX designer for GNOME, Fedora and Red Hat Enterprise Linux, and from a UX perspective I have some fairly major concerns about this proposal. I think that it needs wider discussion before any work is done on it.

Ultimately network access requests will have a negative UX impact: it's yet another authorization request that people will have to deal with, and my sense is that it will be quite surprising and confusing for users. One of the main reasons for this is that network access requests are not something that people are used to on other platforms.

Network access is also a technical implementation detail which has a wide range of applications, meaning that legitimate reasons for using the network will not be apparent to users, and could be difficult to explain. Access to files or a camera is something that people readily understand. Network access is rather different.

[Mikenux]

Additionally, the network includes the local area network which is accessible using IP addresses. Currently in GNOME, networking is reduced to Internet access. This is something I'm blocked on, because explaining what it means can be difficult and that it would lengthen the text of the request (while it is mainly Internet access that is targeted).

[mcatanzaro]

I'd say the portal should never prompt the user to allow network access; I would just automatically grant it. This means all apps would effectively have network access, though, so it would reduce security rather than improve it. Might still make sense if the goal is to filter everything through a socks proxy. Will that work for really everything, though? I'm not sure if e.g. WebRTC and RDP will be able to handle it.

As for Flathub and GNOME Software, I'd say the safety algorithm is just a little too strict and network access should be considered unproblematic rather than cause to degrade the app's safety state.

[Mikenux]

An app cannot be completely marked as safe due to network access, as this is a way to go out of the sandbox (with the current permission). Looking at the current Software 46 wording, it says "Probably Safe" with "Has network access" for an app that simply has network access as a "bad" permission. I don't think it's such a warning that users won't install an app if it makes sense to them that it has network (Internet) access (e.g. a web browser, a chat app).

Requesting network (Internet) access is useful in the case of app that do not need it for their core features, as already said. This is the case, for example, of task managers and calendar apps where tasks and events can be stored locally and synchronized using an Internet connection if wanted; synchronization is not mandatory so neither is the network in these cases. However, if network access is granted, it is for the app, not for the specific feature (the app can then share tasks or events stored only locally).

Might still make sense if the goal is to filter everything through a socks proxy.

Filter what to allow or disallow what?

[swick]

I understand the desire behind the idea to make it impossible for a malicious app to exfiltrate anything. I don't think that's a realistic goal however. The sandbox prevents a malicious app from exfiltrating data that it doesn't have access to, but to be useful, users will give apps (malicious or not) enough access to be useful to them.

IMO the big issue with flatpak networking right now is that it has the exact same access as the host and can connect and expose tcp and udp services on all of localhost. The German AusweisApp (government online identification app) for example works by a browser connecting to a well-known tcp port, so all flatpak'ed apps can access, and man-in-the-middle it as well.

We really have to fix this by not giving access to localhost and ideally also not to the local network by default. A portal to get access to the local network would be much easier to understand.

Anyway, my point is that unfortunately this is focusing on the wrong thing. It's something one might explore some time into the future but there are more pressing and easier targets when it comes to networking and flatpak.

[Mikenux]

To really know what to do, I think we need to know:

• What the dynamic network permission currently in development will actually do (I assume it it because there is a mockup).
• How long it will take to develop the missing important things.

[AdrianVovk]

Another aspect to consider:

Some in GNOME are very interested in local-first networking. Things like apps syncing with each other across your devices and with your friends. I've spent a while planning a "local first" portal with @adzialocha from @p2panda, to enable this kind of functionality without giving apps networking permissions. Notably: this portal wouldn't prompt for permission and would let apps talk to other instances of themselves across devices / friend groups (done in a way that the user ultimately controls).

I think increasing the friction of using the network would give incentive for apps to try more local-first approaches. Instead of asking for network permissions (which allow for anything including tracking, leaking personal data, and ads), an app could rely on the OS's built-in peer-to-peer local-first network plumbing to get a connection to other instances of itself running on other devices. Such apps wouldn't have (or even need) a network connection.

My point is: we're working on ways to make great app experiences work without a network connection (by leaving the networking to the OS). Network permissions aren't actually necessary to make a chat app, or a document sharing app, or etc. We can build other platform features into the OS to make networking less important. Once we do that, I think starting to lock down networking (especially for new apps) would be great.

I also agree that prompting for network permissions every time for every app would be quite annoying from a UX perspective right now. Maybe we could do something like this:

• Have a network portal that prompts for network access, and explains that an app might use this to upload personal data and track you.
• Apps that don't collect and upload personal data could ask for an entitlement ([Feature request]: Entitlements, like on the proprietary systems flatpak#5721: --entitlement=org.flatpak.Network.NoTracking) that lets the app bypass the prompt. The app would still need to ask the portal for networking, but there would be no prompt. The user could still revoke network access from settings. If an app starts collecting and uploading local user data, it would lose the entitlement and prompt the user the next time.
  • This is essentially the feature Apple and Google built into their app stores, where app developers declare what kind of tracking they do. Except we'd tie it into the network permission: apps that track don't get to talk to the network until the user confirms that they understand that the app will track them.
• Eventually, apps using the static network permission would be labeled as unsafe by app stores, explaining that they can upload your personal information and track you without your knowledge or permission
• Apps using the local-first APIs don't have to worry about any of this, and we'd strongly recommend that apps use this if at all possible.

[Mikenux]

For local network, see #1365. Additionally, you should take into account in your reasoning that apps can have both local network and Internet-based functionality (e.g., gaming, remote access).

[swick]

Yes, completely agree that his is a great direction to to take but it's going to be a lot of work to get the local-first stuff off the ground as well. It also doesn't change that we currently have a security hole because we expose localhost and local network by default.