Desktop Portals

Simpler specifications for Linux desktop APIs.

XDG Desktop Portals do a good job at standardizing Linux desktop APIs. However, they are not perfect either. So this is a space to explore ideas beyond XDG Desktop Portals.

Goals

Security Boundaries as Files Access

Mount namespaces are great. The question "does this application have permission to use this API" should therefore usually be expressed as "does this process have access to this file?".

Meaningful User Interaction

Access to privileged interfaces should require a user interaction. To avoid warning fatigue, these interactions should not just be confirmation dialogs, but offer meaningful interaction. They should not just ask if an action may happen, but how it should happen.

Actions that are triggered by a user interaction (e.g. taking a screenshot) are out of scope for this project because they should be provided by compositors or by privileged wayland clients. The relevant interfaces also need to be standardized, but that is a separate topic.

Compatibility and Security Considerations

Every interface should have clear documentation on compatibility with existing systems (including XDG Desktop Portals) and its threat model.

Avoid Dependencies

While the XDG Desktop Portal developers do a good job of providing a uniform platform API, it is often clear to see that those are the same people who also work on Flatpak and Gnome. Notably, only a small number of sandboxing mechanisms are supported.

This project, on the other hand, should be truly independent. Dependency on other parts of the systems should be kept to a minimum. Where not avoidable, it should be clearly documented.

Avoid D-Bus

I believe D-Bus is a major factor why many projects beyond the big desktop environments do not adopt portals. It is complex and verbose and generally no fun to work with, while providing little benefits.

The main issue with D-Bus is that it breaks the security-boundaries-as-file-access rule: All interfaces are accesible on a single socket. XDG Desktop Portals need to rely on hacks like xdg-dbus-proxy to work around that.

Avoid Authentication

Many XDG Desktop Portals require that they have a reliable way to get an app ID for the calling process. They then use this ID e.g. to check permissions or to show a corresponding app icon.

This approach has a couple of issues. For one, there is no standard for providing those app IDs, so there is special code for each supported sandboxing mechanism. What is worse, each process can only have a single app ID. For nested sandboxes, only the outer-most app ID is used. That means that a sandboxes application can not launch children that are even more restricted.

This project, on the other hand, tries to see how far we can get by only using security-boundaries-as-file-access.