Modal announced €508,640 in Sovereign Tech Agency funding on August 27 for Flatpak development and stewardship. The initiative is expected to run through the end of 2027. It funds a roadmap, rather than switching on new permissions in existing applications.
The work that has been commissioned
The announcement includes finer audio and network controls, VPN integration, writing assistance and maintenance. Password auto-fill is listed as research and architectural design. The organizers explicitly allow the plans to evolve.
That distinction is useful when evaluating a desktop today. Funding an implementation, merging it, shipping it in a distribution and updating an application to use it are separate steps. A completed step does not prove the remaining ones happened.
Why audio is a concrete example
The current Flatpak permission documentation says --socket=pulseaudio grants audio input as well as playback, alongside other audio access. A program needing sound output can therefore receive a broader capability than the user expects from the phrase “play audio”.
The funded roadmap proposes PipeWire socket permissions, WirePlumber policy and permission management to distinguish device access. That is a target for development. It should not be described as an already deployed microphone protection across Flatpak applications.
A portal does not cancel an existing broad grant
Think of a hypothetical document viewer. In one configuration it receives broad access to a documents directory. In another, it has no such grant and requests a selected file through a portal. The second path can narrow what is handed to the application.
If the first application also displays a portal dialog, its pre-existing directory access does not vanish. This is why seeing a permission prompt is not sufficient to establish the effective sandbox boundary.
A portal mediates a particular operation. Flatpak also relies on its sandbox and static permissions; the earlier article incorrectly implied that every isolation guarantee ultimately passes through a portal.
Inspect an installed application's declared access
For an installed Flatpak, replace the example identifier with its actual application ID:
flatpak info --show-permissions org.example.App
flatpak override --user --show org.example.App
flatpak override --system --show org.example.AppThese are inspection commands, not permission changes. The first shows permissions and the others help reveal overrides at their respective scopes. They do not constitute a complete security audit or prove what the application has actually accessed. Installation scope and host configuration also matter.
For a future feature, keep a simple evidence chain: implementation release, installed host components, application support and observed behavior. It is a more useful way to follow this funding than assuming the announcement itself changes every manifest or guarantees all delivery by a fixed date.
Separate funded roadmap from shipped functionality; correct PulseAudio permission scope and the claim all sandboxing passes through portals.