Support us on Patreon
PayPalCanonical are continuing to advance their own Snap packaging system, with the Ubuntu 24.10 development builds getting a new permission prompt feature.
Detailed in a Discourse forum post from Canonical's Oliver Smith, the Interim Engineering Director for Ubuntu Desktop, it goes over the idea behind this new security feature that has been multiple-years in the making. As Smith explained:
Permissions prompting is a critical tool for privacy and security conscious users to control, manage and understand the behaviour of applications running on their machine. This implementation represents a significant step forward in application security, and distinguishes itself from traditional XDG Desktop Portals by enabling fine-grained access control over unmodified binaries without requiring changes to the application code. By leveraging Ubuntu’s AppArmor implementation, prompting enforces sandboxing and mediates access at the system call level to ensure that every action is tightly controlled and subject to user consent, even for applications that are entirely unaware of this mediation.
The snapd, security and desktop teams at Canonical have collaborated closely over a number of years to bring this feature to life and we’re excited to deliver an initial opt-in implementation to Ubuntu 24.10 focussed on home interface permissions so that we can refine the experience based on your feedback.
It may end up looking something like this:
I like the idea of security prompts, but it does make me think: when is putting all this on the user too much? Prompt fatigue is a very real thing, and people end up ignoring them a lot. Is there any better way though? Likely not, giving the users ultimate control on what apps do is good.
They have plenty of work still to do on it, which is why it won't yet be enabled by default. Some of what they plan to improve over the next few releases include:
- Better default response suggestions based on user feedback.
- Shell integration of the prompting pop-ups (eg full screen takeovers)
- Improved rule management summaries and better messaging of overlapping or redundant prompts.
- Expansion of the prompting system to cover additional snap interfaces such as camera and microphone access.
- Smarter client side analysis of prompts, recommending additional options if multiple similar prompts are detected.
What are your thoughts on this new system?
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
10 comments
QuoteI like the idea of security prompts, but it does make me think: when is putting all this on the user too much? Prompt fatigue is a very real thing, and people and up ignoring them a lot. Is there any better way though? Likely not, giving the users ultimate control on what apps do is good.
I think from a package manager standpoint, there is not much to be done - the solution is apps adjusting to use fewer permissions (and the permission/sandbox/API system needs to be sensible so that apps don't need access to many non-standard things). Not something Canonical could solve.
What I mean is that the issue with permission prompts is often like on Windows everything needing "admin privileges" (overly restrictive standards and overly broad privileges) or mobile where the ecosystem has grown to be so abusive that everything asks for all permissions all the time, often for undesirable reasons (ads, tracking) and users can't enforce any boundaries because they lack leverage. Prompts for like, sites wanting to use your microphone aren't as annoying because few sites will ask for it and it is generally obvious whether it needs it or not.
2 Likes, Who?
I don't really want Linux to turn into nagware like Windows. Surely something involving sane defaults and the ability to adjust permissions with a right-click on the application icon and in one or two other ways, could be good enough?
Meanwhile, if we accept that this is a good and even important thing, it's potentially a problem if Canonical tightly control it like they do a lot of their stuff, with hoops and copyright assignment in the way of outsiders making contributions, and potential difficulty repackaging it as something other than a Snap (which, whatever the inherent utility of them, lots of the community don't like). After all, this doesn't just happen to be packaged as a Snap--they say it represents close collaboration with the snapd team, so like the whole scheme is tightly integrated with Snaps in general. Seems like it could represent an increase in distance between Ubuntu and other flavours of Linux, and greater difficulty with interoperation.
Meanwhile, if we accept that this is a good and even important thing, it's potentially a problem if Canonical tightly control it like they do a lot of their stuff, with hoops and copyright assignment in the way of outsiders making contributions, and potential difficulty repackaging it as something other than a Snap (which, whatever the inherent utility of them, lots of the community don't like). After all, this doesn't just happen to be packaged as a Snap--they say it represents close collaboration with the snapd team, so like the whole scheme is tightly integrated with Snaps in general. Seems like it could represent an increase in distance between Ubuntu and other flavours of Linux, and greater difficulty with interoperation.
2 Likes, Who?
The same way they said "f it" to Flatpak, now they say "f it" to the XDG portals effort for standardisation across the Linux ecosystem. Again. Canonical, awesome...
5 Likes, Who?
QuoteIs there any better way though?investing in building a more complete ecosystem of trustable (necessarily FOSS) apps for which fine-grained permissions aren't necessary
as long as the user and the OS need to rely on apps they cannot fully trust, preventing full access from that app to user data and system features is necessary for privacy and security... but if those apps are to be in any way useful, you must also poke holes in this perfect isolation in a way that allows the app to actually function
this is a conundrum, and a nigh-impossible one to solve, because apps can require a permission for legitimate reasons but use the same permissions for malicious uses
eg: in android 2 and 3 you could block internet access for a calculator app to prevent it from relaying user data to a remote server and even serving ad banners... because a calculator app doesn't need internet to function
google removed this user ability because displaying ads in android apps was generating revenue for google themselves, not just the app publisher...
...but besides that, app publishers learned to blackmail users into allowing permissions that weren't really needed by programatically testing (not just querying) if the permission was granted, and blocking useful functions unless granted... and refined the art of inventing arrangements where the permissions they wanted for ads and data gathering were plausibly tied to some useful function in the app (feature creep and SaaS are means to achieve this)... notto mention straight-up lying that you need internet so a server can do 2+2 or actually moving 2+2 server-side to be able to not be lying (but destroying app perf, reliability, etc)
(any resemblance to always-online single-player games is not a coincidence)
as for user interaction fatigue, this is cooked into Android by design for years already
eg: any single android app that you want to prevent sucking up sensible user data can spread invasive activity over
- normal app permissions page (16 of them)
- additional permissions subpage (9 of them)
- other permissions (5 of them)
- special permissions (17 of them)
- notifications (8 fixed options plus extensible list)
- connection method (2 fixed options)
- background autostart
- app lock
- battery performance
- fullscreen mode
- account sync
- dual apps
- second space
- enterprise mode
- Google Chrome privacy settings used by in-app web browser frames (those can bypass app permissions)
- Google Account privacy permissions such as advertiser ID, interest topics, search history, location history
- Google Play Framework permissions (which sometimes can bypass per-app permissions if called by apps)
- google (and vendor) backups (which can syphon non-user-encrypted settings like wifi passwords and user data from apps (ironically stored in user-inaccessible app content folders)
- OS usage & diagnostics (can send data to vendor but also to app devs)
many of those settings can be hidden or made read-only by app manifest, especially but not exclusively if the apps are preinstalled
android by default now wipes out user-set permissions after some time not using an app... while they claim it helps ensure apps don't keep permissions enabled when not really being useful, it also induces repetitive permissions fatigue by throwing off a user's fine-grained choices if they went through the trouble of actually setting things up... to make things worse, this feature can't be globally disabled and there are 2 independent toggles for the same thing where the most visible one isn't honoured (at least on xiaomi)
It's worth noting most of these settings started out separated by severity, but then google bundled them thematically and made it impossible to eg: grant an app permission to know if i'm connected to the internet without also granting permission to know my currently connected wifi SSID and all other memorized wifi SSIDs and current IP and currently visible nearby wifi SSIDs and signal strength and all the equivalent 3G/4G/5G conection data
Windows 10 and 11 are going down the same road now
All those actors did was erode privacy, but they did so while maintaining a huge plausible deniability of their role in this erosion: "look at all this stuff I tried to do to help you get some privacy! it's just very very very hard!"
If Canonical finds a viable revenue source where closed-source apps are the ones paying for Ubuntu development, they'll also go down this road... this may or may not be what they're aiming at already
What's obvious is that Canonical is investing in creating a vibrant closed-source apps ecossystem inside Linux while at the same time trying to unburden themselves from the vetting work
I say this is problematic, not because their proposed solution allows users to tune permissions (this is choice, it's good, and fine-grained choice is necessary for sandboxing)...
... but because they are implying the initial choice will already be on the user's hands (and no mention of this being optional, as an alternative to sane defaults)
...and because the screenshot notably lacks the all-important anti-nag "deny always" option
...and they're even considering a complete takeover of the user's workflow for permission prompting?! a malicious app could even use repetitive prompting to block a user out of their own desktop, LOL! this is a terrible thing to entertain
All in all it's user prompt hell all over again, which is exactly what's eating away at my ability to endure Android on a smartphone
For a better design, see CyanogenMod's global default permissions management from ~ a decade ago (and probably LineageOS and any other AOSP-derived custom ROM out there nowadays, though I stopped keeping tabs a while back)... any given permission there had a global default, where one option worked like "always deny by default (don't even ask)"
Last edited by Marlock on 13 September 2024 at 10:16 pm UTC
3 Likes, Who?
Kind of following a thought from my previous post a little further . . . I am imagining a situation where everyone outside Ubuntu says "Well, something like that seems kind of useful, but we can't use this without using Snaps (and Ubuntu's Snap repository), which we're not going to do" and goes on to create a more open solution. And then in ten years, everyone except Ubuntu is using this other solution and most people say of the original Ubuntu thing "Why do Ubuntu always have to have NIH syndrome" because they've forgotten it existed first, and eventually Ubuntu themselves grumpily drop the thing in favour of the more open-to-community solution that has more mindshare and development.
1 Likes, Who?
It's late for Canonical, too late I'm afraid. They should have done that a long time ago, let's say back when they replaced native Chromium with snap in Ubuntu 20.04. Snaps for desktop users without graphical tools of configuration, without a transparent way of handling updates, permissions and background processes has been kind of disastrous for Canonical's reputation not to say anything about offering 1:1 parity with native packages. They have lost a good deal of good faith in Linux community. They did something similar again with new apparmor rules and profiles in latest LTS. Flatpak on the other hand has taken off without anyone forcing it into our computers.
0 Likes
pleasereadthemanual Sep 15
Flatpak really needs this! It's good to see Canonical innovating with permission prompts, something sorely missing from Flatpaks.
3 Likes, Who?
pleasereadthemanual Sep 15
Quoting: Marlockinvesting in building a more complete ecosystem of trustable (necessarily FOSS) apps for which fine-grained permissions aren't necessaryAs a proponent of permission prompts in Flatpak for some time now, I want to say this is not primarily about security, but usability.
We have a situation where developers distributing their software through Flatpak (e.g. Bottles) will choose tight security defaults that are actually broken for users, and they need to unbreak them with Flatseal or symlinks to get it to work. If Bottles would just prompt you when you wanted to access a new folder and dynamically alter the permissions, that would be far more usable!
I would really like to be prompted when a program wants to alter its manifest to get access to new permissions rather than needing to alter the permissions manually in Flatseal.
1 Likes, Who?
dziadulewicz Sep 15
Quoting: pleasereadthemanualFlatpak really needs this! It's good to see Canonical innovating with permission prompts, something sorely missing from Flatpaks.
Exactly. Snaps and flatpaks are not going anywhere, they are absolutely needed in modern computing with better safety. Fixes after fixes both get better all the time. And ones complaining for some reason can still always use the old packages, so no need for hate at all in this area
1 Likes, Who?
See more from me