Conversation

I'll need to explain it to GrapheneOS users, and they'll need to deal with it rather than apps adapting. There will be another fight next year with Android R. Maybe next time, journalists will push Google to ship this important privacy feature instead of spreading FUD about it.
2
This Tweet was deleted by the Tweet author. Learn more
The simple answer is no, they can't do that, because they can't do it today. Apps can't access files outside of their own app sandbox / directories without consent. That's the status quo already. The issue is that there's a coarse permission for a shared external storage volume.
1
1
Scoped Storage drops support for this coarse access control model and storage permission, similar to how it went away for external drives in Android 4.4. Users can still grant access to the entire storage volume since when the app requests access the user can choose any scope.
1
2
Apps have everything they need to avoid using the coarse, privacy-unfriendly storage permissions. The issue with the design is those coarse permissions existing at all. Apps demand them and aren't designed to work without them, and they store private data in that shared storage.
1
2
Scoped Storage removes those permissions and works around legacy apps designed around them by providing a scoped view of external storage, emulating the way it used to work. Removing it forces apps to use SAF (added in Android 4.4), where the user selects files/directories.
1
2
There are still some fairly coarse options available for things like media. An app like WhatsApp could decide to approach it by requesting Photos access and storing media in shared photo albums. It becomes much clear to users though, and it gives them granular control in general.
1
2
Then again this is kind of apples and oranges though since we're talking about app isolation as well as shared storage. If the KVM just provides a pass-through to shared storage without a storage management layer (think apparmor for storage), then we're back to square one.
2
The apps are sandboxed and there is an access control model for anything shared between them already. Users are explicitly granting external storage access to the app storing data and the app messing with it. It has fine-grained alternatives. The issue isn't a missing feature.
1
The apps already do run with a unique user / group id and more importantly in a unique per-app instance of the untrusted_app SELinux domain which provides far stronger isolation than the traditional uid/gid sandbox. Apps have ways to explicitly share data / communicate though.
1