Hi all! Bit of a noob here. Could someone help me understand how to interpret the difference between these two dialogs?
This day and age I’d prefer using sandboxed apps, but the next best thing would be apps that have some restrictions. To me it seems that compatibility mode (gPodder) gives the app unrestricted access and permissions, although not root of course, while the ‘without sandboxing’ (ownKeepass) still protects some data.
You have it the other way around, apps that specify no permissions ask for all permissions by default, but those permissions still apply. Meaning it can’t e.g. write to your home dir because there is no permission for that.
Apps without sandbox can do anything they want.
To clarify a bit more: some things simply cannot be done under the current permission framework, for example defining own polkit rules (my BitSailor uses that for fingerprint unlock) or listening for share actions without the app running (e.g. with my BitSailor app you can share text/files even if the app is fully closed).
Neither of the two are possible if the app is sandboxed. Many developers who do non trivial stuff choose to not publish to the store (or publish a version without those features) because of sandbox.
Thx for great answer. Just want to add that Jolla is open for better/more usefull restrictions.
As for gPodder it currently has no SailJail settings yet, I’m actually working on it but it turns out that I need to handle migration a slightly different way than what it looked like with the SDK, I guess it would have been easier had I migrated before the sandbox was introduced but we all make mistakes and have limited time.
Ah thanks, that’s really helpful! So the first dialog is a bit misleading, giving the impression that by accepting you give all the listed permissions.
Right, this is the impression I’ve gotten. The cybersecurity space is getting quite crazy with all the AI automation and stuff so I hope sandboxing can be made easier for developers. You community devs are awesome and I trust your skills and intentions, but still, lately there have been many supply chain attacks and consequent malicious updates, so limiting unnecessary permissions would make sense, even if it’s just a precaution.
Brilliant, thanks for the update! I actually saw you mention that you’re working on an update and was going to ask if you’re planning to apply SailJail at some point 
Arguably you do - but that is what the “compatibility mode” consists of; a set of most permissions.
Right, thanks for the further clarification. So there are those permissions that are NOT included in the list that still restrict what the app can do. And I guess the “Access to protected data, such as contacts, will still be limited.” from the second dialog applies to the compatibility mode as well?
You can find a full list here:
By the way, apps with full access can access even contacts, though perhaps not through official APIs - but nothing prevents you from having a setuid binary which always runs as root thus giving you access to everything.
Oof that sounds scary 
Oh well, just have to be careful with what to install. In some sense Android apps are more secure due to isolation of the compatibility layer?
Actually no as they can access a lot of your user data (as in pictures, downloads etc), much more than a properly configured sailjailed SFOS app can. Plus your contacts if you allow that in AAS settings.
And then you have the Android permission system which is more about the illusion of control than actual control.
I think it’s important to repeat that an app with the default/compatibility permission set potentially could do all the things the permissions allow.
But that doesn’t mean the app needs to or will do that.
In fact the vast majority of these apps will likely not (use or need all of those permissions).
It is not the app that requests those permissions! It’s a fallback mechanism for apps that have been developed before permissions and sandboxing had been introduced to SFOS.
.
I’m curious, could you explain that a bit more?
Not true. They still don’t have write and sometimes not even read access to system files both higher than /home/defaultuser and under /home/defaultuser (“privileged”).
In other words, they have the same access as defaultuser.
Eh, you can just add a setuid on the binary.
Explain. Because I don’t see how that’s possible without root privileges.
Well, if you configure the .spec file to add setuid on the binary file, it runs as root even though you’re not logged in as root. All you need is the standard privileges to install an app. I remember doing that for one SFOS app which needed root access, though it’s been long deleted.
OK, that makes sense. But it goes beyond your original statement.
