Blog: "Flathub Safety: A Layered Approach from Source to User"

[cassidyjames]

Covering how Flathub handles safety all in one place, with lots of links out to the docs. Will squash before merging.

[bbhtt]

Suggested change

	Once an app is developed, it must be submitted to Flathub for consideration to be hosted and distributed. At this stage, humans from Flathub review the app to ensure it follows the [requirements](https://docs.flathub.org/docs/for-app-authors/requirements). Of note:
	Once an app is developed, it must be submitted to Flathub for consideration to be hosted and distributed. At this stage, humans from Flathub review the app to ensure it follows the [requirements](https://docs.flathub.org/docs/for-app-authors/requirements). Of note:

"humans from Flathub" -> Flathub reviewers ?

[cassidyjames]

Ah I think I specified "humans" to clarify I don't mean some "review bot" or something—plus "reviewers review" would sound awkward. I'm not opposed to rephrasing this somehow though.

[bbhtt]

human Flathub reviewers?

[bbhtt]

The bot is not supposed to comment repeatedly, it should edit comments to update links.

[sonnyp]

Thanks a lot for doing this!

[sonnyp]

are unchanging per release of an app.

Apps can change static permissions between releases. But there is a review needed when that happens. Probably worth mentioning and linking to https://docs.flathub.org/blog/improved-build-validation/

EDIT: it is mentioned in the Updates section

On static permissions I think it would be helpful for people to understand that

1. Useful for apps who do not implement portals
2. Useful when we don't have a portal for something yet (like audio recording)

[sonnyp]

I suggest splitting portals and static permissions in 2 sections and start with static permissions

I can make a suggestion if you like

[sonnyp]

I can also suggest a paragraph about informing users about the safety level of apps

[cassidyjames]

I suggest splitting portals and static permissions in 2 sections and start with static permissions

I had them that way initially, but combined them a bit. I am specifically trying to address a misconception we keep seeing repeated that "Flatpak permissions are all static, and super broad," when in reality the story should be to use Portals—and static permissions are basically a fallback.

[cassidyjames]

I can also suggest a paragraph about informing users about the safety level of apps

Yeah that could be expanded in the "App Store Clients" section for sure. I wrote that section when the post was already longer than I really wanted, so I kind of kept it brief—but expanding it a bit to cover the safety level could make sense. Suggestion welcome!

[sonnyp]

First, Flathub has granted a small handful of trusted partners (including Mozilla and OBS Studio)

Slightly off topic
I wonder if we should have a public list somewhere

[sonnyp]

Suggested change

	### Portals & Static Permissions
	Most permissions can be requested and granted on demand via an API called [Portals](https://flatpak.github.io/xdg-desktop-portal/docs/). These permissions do not need to be given ahead of time, as desktop environments provide the mechanisms to give user consent and control over them e.g. by indicating their use, directly prompting the user before the permission is granted, and allowing revocation.
	
	
	Portals include APIs for handling auto-start and background activity; access to the camera, clipboard, documents, files, location, screen casting, screenshots, secrets like passwords, trash, and USB devices; setting global shortcuts; inhibiting suspend or shut down; capturing input; monitoring memory, network, or power profiles; sending notifications; printing; setting a wallpaper; and more. In each case, the user’s desktop environment (like GNOME or KDE) manages if and how a user is notified or prompted for permissions—and if the permission is not granted, the app must handle it gracefully.
	Apps must also define any [static permissions](https://docs.flatpak.org/en/latest/sandbox-permissions.html) they need to function. These are clearly defined up front and include access to resources such as the network, Bluetooth, and audio devices. For regular file handling such as opening or saving, apps can use the File Chooser portal. In some cases apps may only make sense with permanent access to specific a folder, in which case a narrowly-scoped static permission (e.g. read-only access to the user’s Music folder) may be used.
	Static permissions are designed to be as narrowly-scoped as possible and are unchanging per release of an app. They are not designed to be modified by an end user except in cases of development, debugging, or [reducing permissions](https://docs.flathub.org/docs/for-users/permissions). Due to this, Flatpak always prefers apps to use Portals over static permissions whenever possible.
	### Dynamic permissions
	Most permissions can be requested and granted on demand via an API called [Portals](https://flatpak.github.io/xdg-desktop-portal/docs/). These permissions do not need to be given ahead of time, as desktop environments provide the mechanisms to give user consent and control over them e.g. by indicating their use, directly prompting the user before the permission is granted, and allowing revocation.
	
	
	Portals include APIs for handling auto-start and background activity; access to the camera, clipboard, documents, files, location, screen casting, screenshots, secrets like passwords, trash, and USB devices; setting global shortcuts; inhibiting suspend or shut down; capturing input; monitoring memory, network, or power profiles; sending notifications; printing; setting a wallpaper; and more. In each case, the user’s desktop environment (like GNOME or KDE) manages if and how a user is notified or prompted for permissions—and if the permission is not granted, the app must handle it gracefully.
	Portals is a fairly new addition to the Freedesktop ecosystem; desktop environments need to implement them and app developers are increasingly adopting them.
	You can use the [Door Knocker](https://flathub.org/apps/xyz.tytanium.DoorKnocker) app to see which portals are available on your system.
	### Static permissions
	Static permissions are set by application developers at build time. They allow exposing specific resources from the host into the sandbox which makes them accessible as if the sandbox was not there. They serve multiple purposes:
	1. Give Flatpak apps access to basic and safe resources such as Wayland for which dynamic permissions would not make sense
	2. Make apps who haven't implemented portals yet to be functional
	3. Provide a solution when a portal is not available yet for a specific feature
	See also
	* [Sandbox Permissions on flatpak.org](https://docs.flatpak.org/en/latest/sandbox-permissions.html)
	* [Permissions on flathub.org](https://docs.flathub.org/docs/for-app-authors/requirements#permissions)
	Static permissions are reviewed by Flathub human reviewers when a new application is submitted and when they are updated between releases.

[cassidyjames]

D'oh! I saw this after I hit merge, of course. It's super duper late for me here and I wanted to wrap this up before I went to bed, but I can review this tomorrow. Sorry!

[bbhtt]

I'll apply this in a followup.