How I understood it (and I’ve had a proof-of-concept working SailJail implementation for Whisperfish):
Pre 4.0, we had “privileged” apps and “unprivileged” apps. A privileged app could get access to certain directories that the other apps could not. In theory you could request multiple permissions (contacts, pictures, …), but in practice this was just boolean: either you got all “permissions” or you didn’t get any. It has been a work-in-progress since SailfishOS 1.0, without a lot of progress.
Since 4.0, this is completely overhauled, with a totally different system, based on FireJail. In FireJail, applications are confined to a jail, and they can only access data that’s inside the jail (not unlike chroot). “Permissions” are here implemented as access right within this jail: if you get the contacts permission, your jail will get a mounted contacts directory and database. If you get the notification permission, the DBus filter will let notifications pass through.
For me it is currently unclear how an application could get permissions in a dynamic way, at runtime (which is something I’d like to have in Whisperfish), but I think this is something that Jolla does want to figure out eventually. Giving optional permissions at start-up time should be “doable”, because the list of permissions are sourced from the .desktop file, and they could get marked as optional.
As a personal note, I think Jolla is going the right direction here, I found it relatively intuitive to figure out how to get Whisperfish inside the jail, and that was without a lot of documentation. FireJail sounds like a good choice to base things on, although I’d love to read a comparison with e.g. AppArmor and SELinux.
Note that in Koli, 4.0, both permission systems still exist, mostly because of backwards compatibility.