Hadn't heard about this. Like what?
They're fixing this with soon with scoped storage api.
Why can't these apps be restricted to certain folders you need them to access?
I also feel like apps which abuse file system permissions to modify the user file system (e.g. create files useless to the user), let alone the system file system should be reported and banned.
Any app should have full rights to write anything to a special directory dedicated for it however. But you can set up a script to purge it or delete specific files from it on a schedule.
In KDE Connect you already need to use the modern API to pick a location for file browsing and it works fine. I picked the entire virtual storage area and that's what's available through remote browsing, but I could've picked a single directory. If all apps supported this, we'd be a lot better off.
Of course, there's a perverse incentive to put off the transition as long as possible so that stalking libraries can make more money. I think Google is moving very closely to forcing the new API with the release of Android 12, which would mean that most app developers can't really put off updating much longer.
Instead they tried to force through a completely new API that isn't compatible with anything that came beforehand, isn't compatible with code that must have a classic file handle and cannot easily be changed (native libraries, parts of the Android API itself), introduces exciting new bugs and has worse performance.
Plus at the same time they seem hellbent on hiding the true, original location of files on the file system, so a) if an app needs to ensure continuing access to a file, it needs to copy it to its own storage (Yay, dozens of copies of the same file) b) this breaks any usages and file formats that don't consist of a single, atomic, fully standalone file (HTML files, playlists, subtitles, multi-part archives, ...).
Please don't write this misleading stuff, nothing about SAF is new. It's just that it was easier for developers to hardcode paths and crap all over the storage than to open the file dialog.
Plus once apps developers were more seriously forced to use the SAF by recent Android versions, I've seen enough bug reports about actual shortcomings and performance problems of the SAF API on the Android bug tracker even for more recent Android versions.
And Google's simultaneous insistence on only allowing inter-app file sharing via content://-URIs has definitively broken all multi-file file formats, with no official replacement available.
Each restriction just makes certain ideas/project impossible or less ideal [1].
Honestly as an Android dev, I will prefer devices come with these restrictions by default. Then there should be a "I don't give a f*ck" button in the device developer options settings.
The option can be hidden behind 10 screens. Audit rails can be added. Anything but completely eliminating power-use in the name of privacy.
1 - I couldn't implement some telemetry in this project because google yanked the ability to read process stats: https://elvischidera.com/2020-11-23-building-distributed-and...
They could have required a permission instead. Or inform the user about the process I'm observing.
The data I was looking to gather has nothing to do with the user, but the task itself.
Another example is the restrictions introduced in the Bluetooth API.
Not all use of these APIs are intended for stalking. It doesn't make sense to keep "dumbing" down devices.
PS: I'm not arguing about the validity of your concerns. I just wanted to add an alternate take which I felt was missing in this thread.
This is a justified blowback. The file explorers and system utilities (apps users actually want to access the whole file system) should be given full rights. Access rights should be managed, not denied for all the apps altogether. I would introduce separate permissions for full file system (incl. OS and other apps files) access, access to user files space only, access to specific directories.
PS: Can anybody recommend a really good file system explorer for Android? I would pay any reasonable single-time price but no ads and no subscriptions please.
It wouldn’t be a perfect replacement for actual color values but it would give more flexibility while not revealing the value.
My guess is that it'd be an OS which would perform tasks Google needs to stay as Google better than Android, and Google may sell these capabilities to devs to further enhance their bottom line.
Can there be a legal frame work where Google and Apple just take your source code and builds it on their farm, and app review is a source-code level review? And Developers that refuse to do these things are just blocked from developing on these platforms?
Talk about throwing out the baby with the bath water on making Apple and Google the equivalent of government with the ability to define the rules on all software that anyone can exist without even considering using actual government :(.
Really? If true, it's so they will be the only source of such tracking info.
Google is like the one eye, it never stops seeking, looking, tracking you.
So... they're reducing their competition? Sounds anti-competitive. They wouldn't know anything about that though.
Many apps I use daily require internal storage permissions and a bunch of them drop random dotfiles with magical IDs in there. Xiaomi even dumps a world readable unique device ID on the emulated SD card. Not all apps require external storage permissions, but even then there's tons of APIs that can be used to fingerprint the device.
Google is trying their absolute hardest to reduce the fingerprinting surface but as long as system APIs that work with user content like these exist, there will always be something to fingerprint users by. If everything else fails, you could just embed a webview that uses all the javascript stalking we've grown so accustomed to.
It's sad but I don't think you can prevent native code from fingerprinting your device. The sandbox just isn't tight enough and users are too willing to give out permissions.
I can see Google using a predefined set of colours in some update instead of the raw colour values to combat this, but that's only one of many ways apps abuse their users' devices. Unless app stores kick out apps that fingerprint devices, I don't think we'll see any non-fingerprinted devices any time soon.