> set ‘owner only read’ permissions on files it writes to external storage
The usual storage location for apps is in their internal app sandbox. External means outside of the app sandbox and requesting access to external storage is a legacy approach to sharing data between apps.
Conversation
The whole point of external storage is that it's shared storage between apps. The ability to request global access to it was a poor design that started to be phased out in Android 4.4 which introduced granting case-by-case file access instead. 5.0 extended that to directories.
1
2
Scoped storage (developer.android.com/preview/privac) will finally remove the legacy approach to shared storage, by getting rid of storage permissions to request global external storage read / write access. It emulates the legacy approach with a scoped directory but it's not the intended use.
1
2
developer.android.com/guide/topics/p is how apps were supposed to access storage since Android 4.4. It opens a system file picker and the user chooses the files / directories. This way, there are no permissions, and they can select files / directories from external drives or app providers.
1
1
3
Unfortunately, there was massive pushback against Scoped Storage from anti-privacy app developers. They successfully misrepresented the feature and used journalists and power user communities as tools to fight against it. Apps can now opt-out of it until the Android R API level.
1
2
3
Is there any mitigation in a foreseable future? Can deal with this situation and support the Scoped-Storage-like features?
1
1
Scoped Storage will be available within a month or two. The approach is fully compatible with legacy applications as I explained above. There is no need for something like Scoped Storage rather than using the actual feature so I don't really understand the question you're asking.
2
1
GrapheneOS has planned to have a feature like Scoped Storage for many years. This issue was filed in 2016, but it was planned long before that: github.com/AndroidHardeni. The project hasn't had the resources to implement it, but now it can simply fully enable the standard feature.
1
1
3
It would have been better for GrapheneOS if the campaign against this privacy / security enhancement hadn't been successful. Apps using the Storage Access Framework (i.e. having users choose files / directories via the system UI) provides better UX than scoping legacy access.
2
1
4
Users on GrapheneOS will have a worse experience due to that anti-privacy activism and will need to learn to use the system file manager to move files / directories to and from the emulated external storage directories. The scoped access to external storage is for compatibility.
1
2
3
As an example, a third party file manager implemented via SAF will continue working in the Scoped Storage model. It asks the user to choose the access scope, and they can make the explicit decision to select the root of the storage volume but the UI leaves it entirely up to them.
It fits naturally into most apps, since from a user perspective, it simply means that apps are using the system file management interface. Apps requesting the legacy permissions and providing their own interface was usually a worse experience aside from privacy / security issues.
1
1
3
An app can still provide their own file management interface though, by asking the user to select a directory. So, even the case of a generic file manager case still works fine. Obviously, many app developers don't want users to have control, and are completely opposed to this.
1
2
Show replies