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.
Conversation
GrapheneOS's use of KVM is totally where my mind was going regarding compartmentalizing the apps. I can see scoped storage as a stopgap measure IF the android devs felt that upcoming device processors were not going to be powerful enough to run full-on KVM.
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
Reminds me of the iOS vulnerability where apps were/are still writing sensitive user info to shared storage and others have the ability to scrape it. e.g. apps that were denied location services can scraper data saved saved by apps that did have access to location services.
1
For this kind of thing, it's definitely the app devs who are are not thinking about security enough while designing software (I'm assuming here the devs have the option of alternatively saving data to an app-specific memory area).
2
Granted this is twitter and not github, a solution for this "scraping of sensitive data on shared storage" could be to have the OS enforce the categorization of data into two classes...
1
One for media/user generated data (data the user actively created and is meant to be portable like pics etc), and a second for app-specific user data (data that is the result of privacy permission settings and that is required for the app to run).
1
The former would be on shared storage and be managed by scoped storage, and the latter would be only accessible to the app. The enforcement of this might have to be both OS-based and code review based prior to granting access to the app stores which is a whole other thing.
1
Scoped storage docs say "apps targeting Android Q by default (as well as apps that opt into the change) are given a filtered view into external storage. Such apps can see only their app-specific directory and specific types of media, [...]"
1
Coming from a focus on privacy and security, having scoped storage opt-in for apps that don't target android Q by default seems like a gaping hole in the spirit of scoped storage (unless I'm missing something of course).
2
1
1
It was mandatory, and that was changed due to widespread outrage over Scoped Storage due to a successful misinformation campaign against it. That's what I was talking about here:
twitter.com/DanielMicay/st
It's still going to be mandatory, but it has been delayed by a year to R.
Quote Tweet
Replying to @DanielMicay @Ishan_Ishana and 4 others
However, since the Scoped Storage model being mandatory has been delayed until the next major API level in Android R, apps can keep relying on the legacy storage model for an extra year and users will have a worse experience with those apps with the feature enabled universally.
Removing the coarse access control model via Scoped Storage is clearly the best approach and is what they want to do, but Google didn't care enough about privacy to fight a campaign against it that had successfully turned user communities and the media against it in advance.
2
1
So, it has been delayed by at least a year to Android R. It will become mandatory for the Android R API level, but it could take even longer for it to be enabled for apps targeting legacy API levels. The implementation works and it's a compatibility/usability vs. privacy choice.
1
1
Show replies