A €508,640 public investment in Flatpak is aimed at five places where a Linux desktop sandbox still cannot ask for narrowly defined access: audio, networks, VPN control, writing assistance and password autofill. That focus matters more than the round number. If the work lands as planned, app developers should have fewer reasons to request broad access merely because the desktop lacks a smaller, purpose-built permission. The two-year project announced by Modal Collective is funded by Germany's Sovereign Tech Agency and is expected to run through the end of 2027.
The announcement reached 199 points and 115 comments in the Hacker News discussion when MrKeyoor's brief captured it, a measure of developer attention rather than proof that the plan will succeed. The technical case comes from the project roadmap and Flatpak's design. Flatpak's documentation says an app starts inside an isolated environment and must receive explicit access to host files, network connections, devices and other services. Portals are the mediated APIs that let an app request a specific resource without holding a permanent static permission.
The audio permission exposes the wider problem
Today, Modal says, Flatpak cannot separate audio output from microphone access. The funded work proposes a static PipeWire socket permission, a WirePlumber policy for device access and a portal through which users can grant audio capabilities. The practical target is simple: an app that only needs to play sound should not receive microphone access along with it. That turns one coarse permission into a decision the system can explain and enforce, according to the published roadmap.
This is the pattern behind desktop portals. A sandbox cannot be useful if it never crosses its boundary, but every permanent opening weakens the boundary. XDG Desktop Portal describes its interfaces as a way for confined apps to interact with the system through defined D-Bus APIs. Existing portals already cover tasks such as opening a file, printing and taking a screenshot. Desktop-specific backends handle the user interface and system integration behind that shared API.
Networking is the second large gap in the proposal. The project plans to isolate an app's network access from the host and introduce scopes for the host, local network and internet, along with port-specific permissions. An internet client may need the public network without also seeing printers, media boxes or development services on the local LAN. Modal's proposal would give stores and users a vocabulary for that distinction instead of treating network access as one switch. The announcement presents this as commissioned work, not a completed Flatpak feature.
A planned VPN portal goes further because a VPN client needs to manage a connection at the system level. The team says the API will be modeled on Android and iOS approaches so third-party VPN apps can perform that job from a sandbox. The exact interface is still design and implementation work. Modal explicitly warns that plans may change as development begins, which is an important limit on any claim about compatibility or release timing in the project announcement.
Passwords and writing tools need shared services
The writing-assistance portal in the roadmap is meant to let sandboxed apps share a system dictionary. Modal also points to richer services, such as grammar suggestions from an installed writing app. A shared portal could keep each editor from bundling its own integration path or seeking unrelated host access. The roadmap names spell checking as the direct use case and richer suggestions as a possibility, so those extensions should be read as design room rather than a promised product.
Password autofill is at an earlier stage. The project funds research and architecture for a secure portal intended to replace current Native Messaging approaches that Modal calls insecure. No final API is announced. That makes this work different from a feature with an implementation already waiting to merge: the funded output may first be a design that app developers, password-manager authors and desktop projects can review before code is adopted.
These portals will matter outside a single desktop only if the common interface and its backends move together. The portal documentation for desktop developers explains that the service is split into a shared frontend and desktop-specific backends. GNOME, KDE and other environments can present native permission dialogs while apps call the same interface. A specification alone does not give users a working prompt; their desktop also needs a backend that implements it.
The less visible work may decide whether the portals ship
The budget also covers an entitlement system for declaring static portal permissions. Modal says those declarations should help app-store reviewers inspect capabilities before publication and could support access for tools such as third-party accessibility software. For developers, this suggests that permission metadata may become more structured and more visible during review. The announcement does not yet publish a manifest syntax or migration schedule.
Another item, called intents, would let apps declare services they can handle. The roadmap examples include deep links into an app and native handling for particular web URLs. This is plumbing for routing an action to the right sandboxed application, an area where mobile platforms have long had formal contracts. Flatpak's proposal remains abstract at this stage, and the roadmap gives no compatibility promise for existing apps.
Maintenance work takes a substantial place beside the new interfaces. The plan calls for porting portal code to libdex, adding integration tests and improving system permission dialogs. Those jobs lack the instant visibility of a VPN client appearing in an app store, but they affect whether a security API behaves consistently across releases. The Modal announcement describes all three as funded infrastructure and maintenance tasks.
The project team named by Modal has Sebastian Wick and Adrian Vovk leading the technical work, while Kateryna Mikhailova and Cade Diehm provide organizational support. Para-Real Ltd. is the supporting organization, and Modal is a co-organizer. Eight named contractors cover engineering and design. Modal says it wants to expand the group of people who understand this part of the stack and put more formal structures around Flatpak, rather than spend the grant only on a queue of patches.
A previous grant shows what funding can and cannot do
There is a useful recent comparison. A 2023 and 2024 Sovereign Tech Fund investment put €1 million into GNOME and related desktop infrastructure. The project's final report records work on a USB portal, portal documentation, Flatpak sandbox groundwork and maintenance of Flatpak core. It also describes features that landed only in part or remained blocked after the funded period. Public money bought concentrated engineering time, but upstream review, cross-project integration and distribution adoption still determined when users saw the result.
That earlier work makes the new Flatpak project less speculative than a clean-sheet security proposal. Some contractors are returning from the GNOME effort, and the roadmap extends the same portal model into resources that remain too broad or unavailable. The GNOME report says its USB work allowed an app to enumerate devices and request access without exposing all USB hardware. The new audio and network plans apply a similar idea to different system boundaries.
Flatpak's reach raises the value of fixing those boundaries. Modal identifies Fedora Silverblue, openSUSE Aeon, SteamOS and GNOME OS as image-based systems that use Flatpak as their main application distribution method, and names GNOME, KDE and elementary as major desktop ecosystems that prefer it. Those are claims from the project organizers, not usage-share figures. They do explain why a portal change can affect several distributions without each one designing a separate packaging interface.
The investor is also explicit about why it funds work outside Germany. The Sovereign Tech Agency says its fund invests globally in open software components used by Germany and Europe. Its model treats shared libraries, standards and developer tools as digital infrastructure whose maintenance produces benefits across many products. In this case, the money flows through a German public program to contributors working on a cross-distribution Linux system.
What developers should watch through 2027
None of the five portal areas is ready for developers to target today on the strength of this announcement. The first useful artifacts will be specifications, prototype implementations and review threads that show how permissions are represented. Backend support will then decide which desktops can expose the new controls, while toolkit support will decide how much work ordinary applications must do. Flatpak's current documentation notes that toolkits can use existing portals transparently, but that convenience depends on support for each interface.
Store policy is another open question. Entitlements could make requested capabilities easier to audit, yet the announcement does not say which stores will enforce them or how older Flatpak versions will react. Network scopes will need behavior that developers can test, and the VPN design will have to define who can create, inspect and end a connection. Password autofill needs a threat model before an API can be judged safer than the mechanism it replaces. These are implementation questions implied by the roadmap, not failures in work that has barely started.
The project announcement supplies two public Matrix rooms, #flatpak:matrix.org and #xdg-desktop-portals:matrix.org, for following the work. By the end of 2027, the meaningful scorecard will be concrete: merged portal specifications, working backends on more than one desktop, integration tests that exercise denial as well as approval, and apps that can drop broad permissions after adopting the new APIs. Until those pieces appear, €508,640 is a funded attempt to narrow five trust boundaries, not evidence that the boundaries are already closed.