The issue here is in wanting that some functionality remains accessible when the screen is locked.
In that case, each app allowed to work in limited fashion while in a locked screen has responsibilities… (which are not architecturally enforced)
Conversation
Taking a note w/ a locked screen for example.
Windows 10 Mobile also had a funny analogous bypass scenario…
At least on iOS, some info is set to not be accessible at all when the screen is locked, with the keys for those being wiped on screen lock.
2
2
iOS and Android require opting into portions of the data not being available when the screen is locked. On iOS, by changing the data class, and on Android via the keystore API. It's rarely used in practice on either platform. It's a little bit more common to use it on iOS.
1
1
Of course, it's possible for the OS to support logging out instead of simply locking and then nearly all data will be protected. Apps have to explicitly opt into being able to run before log in for each component and explicitly opt into each portion of their data being available.
1
1
Hardly any apps opt into running before being logged in and those that do rarely make much of their data available. It's really incredibly rare for apps to do this on either platform. Mostly only used by OS components. Means that at least nearly all data is protected pre-login.
1
In practice, nearly everything leaves the defaults alone. Even supposedly security-oriented apps don't use these features and don't use internal sandboxing features that are offered. Data not being available when locked would have to become default for new API levels to be used.
1
1
Android supports logging out rather than only locking but only for secondary users. Many system components run in the owner user and store data there there so it has to be logged in before using other users.
They regard this as an enterprise feature not normally shown in the UI.
1
1
For iPadOS, Apple supports multiple users, but only for companies and educational institutions. It isn’t exposed at all to customers.
1
1
grapheneos.org/faq#encryption has a detailed explanation of how the encryption works on Pixels including for secondary users if you're curious.
Most of this is the same for AOSP / stock OS and we document where GrapheneOS deviates from them.
Secondary users are a really nice feature.
1
2
The only management that the owner user can really do is deleting the other users or controlling what they're allowed to do like ability to install apps.
They don't expose most controls in standard Settings UI though, similarly to how 'end session' buttons aren't normally shown.
1
1
I find it odd that they don't do more with user profiles and nested profiles. It would be nice if they had nested profiles beyond work profiles.
Work profiles are designed to be managed by an app rather than the user, although people use apps like Shelter to manage them locally.
They put in a bunch of effort to have separate encryption keys for each user along with the ability to purge the keys from memory on logout... but they don't promote using it and there isn't much focus on improving the usability like seeing if other users got notifications.
2
There’s also Samsung’s own secure folder implementation for those…
1
It would be straightforward to turn the support for work profiles into support for an arbitrary number of nested profiles not tied to device management. It's written that way internally already. It's the kind of thing that would be unwise to try to maintain downstream though.
1
Show replies