IIUC, the OARS data for flatpak apps is publisher defined, so a very rough sketch of what this would look like would be something like:
- snap publisher specifies OARS data in their snap, probably through a snap.yaml mechanism or something that inherits data from some centralized location for the app’s unique ID (appstream?)
- snap admin installs said snap
- snap admin sets policy for said snap
- snap user confined by malcontent tries to run the snap
4.1. something internal to
snap run, probably i.e. snap-confine which runs with elevated permissions before dropping back to the user would ask snapd if running this snap is allowed for this user
4.2. snapd would receive the check and then consults malcontent (is malcontent a daemon? maybe it actually would consult accounts-service?) on whether the app is allowed to run
4.3. if the snap is not allowed then snap-confine would fail in a similar way to flatpak
Does that kinda like the user expectation? Of course there would need to be some sort of robust fallback mechanism where if malcontent is not available or not running or broken or something snaps could still run, and this also implies there may be some form of attack by DOS’ing accounts-service or malcontent to allow a snap to run because snapd does not get a response from it in time. I’m curious what flatpak does in that situation.
An interesting extension to this might be the per-machine classification of snaps whereby a snap admin can specify a certain application’s OARS data or something like that if the snap itself does not provide such data but the admin still wants to limit it’s usage by other snap users.
/me also notes that malcontent does not appear to be in the ubuntu archive on focal at least