- commit
- c64c0bb698e4410e94f75b26fde0d6f70ef993cf
- parent
- 9345c90bcb7535c1e0593ab331fedec791241493
- Author
- Tobias Bengfort <tobias.bengfort@posteo.de>
- Date
- 2026-03-14 10:44
add README
Diffstat
| A | README.md | 74 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 files changed, 74 insertions, 0 deletions
diff --git a/README.md b/README.md
@@ -0,0 +1,74 @@ -1 1 # Desktop Portals -1 2 -1 3 Simpler specifications for Linux desktop APIs. -1 4 -1 5 [XDG Desktop Portals](https://flatpak.github.io/xdg-desktop-portal/) do a good -1 6 job at standardizing Linux desktop APIs. However, they are not perfect either. -1 7 So this is a space to explore ideas beyond XDG Desktop Portals. -1 8 -1 9 ## Goals -1 10 -1 11 ### Security Boundaries as Files Access -1 12 -1 13 Mount namespaces are great. The question "does this application have permission -1 14 to use this API" should therefore usually be expressed as "does this process -1 15 have access to this file?". -1 16 -1 17 ### Meaningful User Interaction -1 18 -1 19 Access to privileged interfaces should require a user interaction. -1 20 To avoid [warning fatigue](https://en.wikipedia.org/wiki/Alarm_fatigue), these -1 21 interactions should not just be confirmation dialogs, but offer [meaningful -1 22 interaction](https://youtu.be/bIzJyp8sb70?si=rt0cVjmeg5A2W7MF&t=934). They -1 23 should not just ask *if* an action may happen, but *how* it should happen. -1 24 -1 25 Actions that are *triggered* by a user interaction (e.g. taking a screenshot) -1 26 are out of scope for this project because they should be provided by -1 27 compositors or by [privileged wayland -1 28 clients](https://blog.ce9e.org/posts/2025-10-03-wayland-security/). The -1 29 relevant interfaces also need to be standardized, but that is a separate topic. -1 30 -1 31 ### Compatibility and Security Considerations -1 32 -1 33 Every interface should have clear documentation on compatibility with existing -1 34 systems (including XDG Desktop Portals) and its threat model. -1 35 -1 36 ### Avoid Dependencies -1 37 -1 38 While the XDG Desktop Portal developers do a good job of providing a [uniform -1 39 platform API](https://www.youtube.com/watch?v=CHNJFkzIsxA), it is often clear -1 40 to see that those are the same people who also work on Flatpak and Gnome. -1 41 Notably, [only a small number of sandboxing -1 42 mechanisms](https://github.com/flatpak/xdg-desktop-portal/issues/1382) are -1 43 supported. -1 44 -1 45 This project, on the other hand, should be truly independent. Dependency on -1 46 other parts of the systems should be kept to a minimum. Where not avoidable, it -1 47 should be clearly documented. -1 48 -1 49 ### Avoid D-Bus -1 50 -1 51 I believe D-Bus is a major factor why many projects beyond the big desktop -1 52 environments do not adopt portals. It is complex and verbose and generally no -1 53 fun to work with, while providing little benefits. -1 54 -1 55 The main issue with D-Bus is that it breaks the -1 56 security-boundaries-as-file-access rule: All interfaces are accesible on a -1 57 single socket. XDG Desktop Portals need to rely on hacks like -1 58 [xdg-dbus-proxy](https://github.com/flatpak/xdg-dbus-proxy) to work around -1 59 that. -1 60 -1 61 ### Avoid Authentication -1 62 -1 63 Many XDG Desktop Portals require that they have a reliable way to get an app ID -1 64 for the calling process. They then use this ID e.g. to check permissions or to -1 65 show a corresponding app icon. -1 66 -1 67 This approach has a couple of issues. For one, there is no standard for -1 68 providing those app IDs, so there is special code for each supported sandboxing -1 69 mechanism. What is worse, each process can only have a single app ID. For -1 70 nested sandboxes, only the outer-most app ID is used. That means that a -1 71 sandboxes application can not launch children that are even more restricted. -1 72 -1 73 This project, on the other hand, tries to see how far we can get by only using -1 74 security-boundaries-as-file-access.