I was looking for a ePub reader for Android and several people recommended Lithium. But just before installing it asks permission to read, modify and delete all files on this device or any...
I was looking for a ePub reader for Android and several people recommended Lithium. But just before installing it asks permission to read, modify and delete all files on this device or any connected storage device. And then explicitly warns that it may do so without your knowledge.
I want to know who the hell would give that broad permission to an app? And why would an app asks for permission that obviously goes way beyond simply controlling its own data? Whats the goal?
As an app developer myself, granular permissions is time consuming and people are lazy. For lithium in particular though, I think that’s necessary for auto importing all your books on your device?
As an app developer myself, granular permissions is time consuming and people are lazy.
For lithium in particular though, I think that’s necessary for auto importing all your books on your device?
The m4b file format supports marking the play location in the actual file. That justifies modify. For delete, that is required for atomic file saving (instead of modifying a file, you copy it to a...
The m4b file format supports marking the play location in the actual file. That justifies modify. For delete, that is required for atomic file saving (instead of modifying a file, you copy it to a hidden file, make changes, rename to the old file, and delete the original, so if the program crashes, the file is always valid).
Android doesn't have the granular permissions of say, mainline linux distros. Where you would add the app to a group and give that group relevant permissions to whatever folders you wanted the app...
Android doesn't have the granular permissions of say, mainline linux distros. Where you would add the app to a group and give that group relevant permissions to whatever folders you wanted the app to have access to.
Android just has "file access". Which means if you have an epub in a /books folder, or in your Downloads folder, or wherever, you can open it with the app.
Not saying I necessarily agree with the model, that's just how Android works. It's one of the tradeoffs of making the filesystem mostly invisible to users.
Android uses SELinux, so they could lock things down very tightly. Reading through the docs it looks like the app developer could opt for more constrained access. But they can simply set the...
Android uses SELinux, so they could lock things down very tightly. Reading through the docs it looks like the app developer could opt for more constrained access. But they can simply set the access everything flag, and Google may be lax with allowing them on the play store. My guess is the app devs think it’s not only a convenience to themselves, but also to users.
The version of android I'm using (I have a Pixel) definitely has the ability to only grant an app access to some pictures, at least I've had a pop up that made me choose specific ones the app has...
The version of android I'm using (I have a Pixel) definitely has the ability to only grant an app access to some pictures, at least I've had a pop up that made me choose specific ones the app has access to before. This seems to only work for photos and videos, but there's at least something adjacent to this functionality in there. Perhaps in the future something like this that applies to other file types will be implemented.
To clarify, it's not really all files in the filesystem, because each app has its own directory that no other apps can access, and it also excludes Android system files. But it does include all...
To clarify, it's not really all files in the filesystem, because each app has its own directory that no other apps can access, and it also excludes Android system files.
But it does include all the files that you can access with the "Files" app, which includes things like your downloads directory and photos.
This wide-open permission is pretty bad, but it's a bit more locked down than what software can do on a desktop computer.
This is one of the reasons I use GrapheneOS. You can set granular storage scopes for any app and the app thinks it has been given full access to everything.
This is one of the reasons I use GrapheneOS. You can set granular storage scopes for any app and the app thinks it has been given full access to everything.
I have to say, this is one area where Apple is doing things much better. I'm aware there are limitations to some capabilities on iOS due to this. And that it's not immediately 100% secure: there...
I have to say, this is one area where Apple is doing things much better.
I'm aware there are limitations to some capabilities on iOS due to this. And that it's not immediately 100% secure: there was a time a lot of apps were using clipboard capture frequently without a true "need" to do it.
But the ability to only allow apps to access a specific set of images, for example, is much better than allowing access to your entire photo gallery.
With photos and videos, this functionality does exist on android as of Android 14. I guess not for other files though, which is a shame. Does Apple have this functionality for files that aren't...
I could be wrong, but I think files are sandboxed per-app still, so nothing else can be modified except the files saved by that app (or loaded into the app's folder).
I could be wrong, but I think files are sandboxed per-app still, so nothing else can be modified except the files saved by that app (or loaded into the app's folder).
Correct: applications are fully limited to reading and writing files within a separate Unix user created for the app (they're named along the lines of a UUID). An application can then choose to...
Correct: applications are fully limited to reading and writing files within a separate Unix user created for the app (they're named along the lines of a UUID).
An application can then choose to publish files in a way that makes them visible through the Files app, through a tightly controlled API. This is not direct filesystem access at all: any operations have to pass through this API, and they always involve user input through an OS provided UI. Like an application can request to open a file, and the user has to select it in the OS provided picker UI, and then the API sends the file contents to the requesting app.
I'm not really in the loop for how the APIs are set up these days, but my understanding is there's no way for an application to enumerate files it doesn't directly control, in its own home directory. It can just request a file and if the user provides one through the OS level prompt, it will receive a file and may be able to update it.
Before Apple introduced the Files app, less than a decade ago, there was strictly no passing of files between apps, other than photos.
There definitely is a way to enumerate files the app doesn’t control. I just set up syncthing for my obsidian vault using mobius, a third party syncthing iOS app. It had me select the folder I...
There definitely is a way to enumerate files the app doesn’t control. I just set up syncthing for my obsidian vault using mobius, a third party syncthing iOS app. It had me select the folder I wanted, and I could select the entire Obsidian folder. It can sync and enumerate those files just fine. That part of the API might have been added after the initial release, but is there now.
Although it isn’t technically filesystem access, as a user its functionality identical to access, at least for apps that support it.
I will say the most "complex" file management I'm doing is with an OCR app. I set up a "favorite" in the Files app for an SMB share on my NAS. The OCR app let me select a folder for placing...
I will say the most "complex" file management I'm doing is with an OCR app. I set up a "favorite" in the Files app for an SMB share on my NAS. The OCR app let me select a folder for placing documents, and I picked that favorite.
It works seamlessly, except when my phone has to restart after updates or something. Then I have to remap it. I think this would still apply to local file folders too. It's a simple process but not 100% foolproof.
I was looking for a ePub reader for Android and several people recommended Lithium. But just before installing it asks permission to read, modify and delete all files on this device or any connected storage device. And then explicitly warns that it may do so without your knowledge.
I want to know who the hell would give that broad permission to an app? And why would an app asks for permission that obviously goes way beyond simply controlling its own data? Whats the goal?
As an app developer myself, granular permissions is time consuming and people are lazy.
For lithium in particular though, I think that’s necessary for auto importing all your books on your device?
That doesn't explain the "modify" and "delete" permissions.
The m4b file format supports marking the play location in the actual file. That justifies modify. For delete, that is required for atomic file saving (instead of modifying a file, you copy it to a hidden file, make changes, rename to the old file, and delete the original, so if the program crashes, the file is always valid).
Android doesn't have the granular permissions of say, mainline linux distros. Where you would add the app to a group and give that group relevant permissions to whatever folders you wanted the app to have access to.
Android just has "file access". Which means if you have an epub in a /books folder, or in your Downloads folder, or wherever, you can open it with the app.
Not saying I necessarily agree with the model, that's just how Android works. It's one of the tradeoffs of making the filesystem mostly invisible to users.
Android uses SELinux, so they could lock things down very tightly. Reading through the docs it looks like the app developer could opt for more constrained access. But they can simply set the access everything flag, and Google may be lax with allowing them on the play store. My guess is the app devs think it’s not only a convenience to themselves, but also to users.
The version of android I'm using (I have a Pixel) definitely has the ability to only grant an app access to some pictures, at least I've had a pop up that made me choose specific ones the app has access to before. This seems to only work for photos and videos, but there's at least something adjacent to this functionality in there. Perhaps in the future something like this that applies to other file types will be implemented.
It doesnt have the ability to restrict itself to just epub files only? It has to have access to ALL files?
Vanilla Android does not. If you're able to flash GrapheneOS it does have a feature that allows you to only give access to certain directories.
Vanilla android also has that feature, but the app has to specifically support that. GrapheneOS lets you force that in any app.
To clarify, it's not really all files in the filesystem, because each app has its own directory that no other apps can access, and it also excludes Android system files.
But it does include all the files that you can access with the "Files" app, which includes things like your downloads directory and photos.
This wide-open permission is pretty bad, but it's a bit more locked down than what software can do on a desktop computer.
This is one of the reasons I use GrapheneOS. You can set granular storage scopes for any app and the app thinks it has been given full access to everything.
I have to say, this is one area where Apple is doing things much better.
I'm aware there are limitations to some capabilities on iOS due to this. And that it's not immediately 100% secure: there was a time a lot of apps were using clipboard capture frequently without a true "need" to do it.
But the ability to only allow apps to access a specific set of images, for example, is much better than allowing access to your entire photo gallery.
With photos and videos, this functionality does exist on android as of Android 14. I guess not for other files though, which is a shame. Does Apple have this functionality for files that aren't photos or videos?
I could be wrong, but I think files are sandboxed per-app still, so nothing else can be modified except the files saved by that app (or loaded into the app's folder).
Correct: applications are fully limited to reading and writing files within a separate Unix user created for the app (they're named along the lines of a UUID).
An application can then choose to publish files in a way that makes them visible through the Files app, through a tightly controlled API. This is not direct filesystem access at all: any operations have to pass through this API, and they always involve user input through an OS provided UI. Like an application can request to open a file, and the user has to select it in the OS provided picker UI, and then the API sends the file contents to the requesting app.
I'm not really in the loop for how the APIs are set up these days, but my understanding is there's no way for an application to enumerate files it doesn't directly control, in its own home directory. It can just request a file and if the user provides one through the OS level prompt, it will receive a file and may be able to update it.
Before Apple introduced the Files app, less than a decade ago, there was strictly no passing of files between apps, other than photos.
There definitely is a way to enumerate files the app doesn’t control. I just set up syncthing for my obsidian vault using mobius, a third party syncthing iOS app. It had me select the folder I wanted, and I could select the entire Obsidian folder. It can sync and enumerate those files just fine. That part of the API might have been added after the initial release, but is there now.
Although it isn’t technically filesystem access, as a user its functionality identical to access, at least for apps that support it.
I will say the most "complex" file management I'm doing is with an OCR app. I set up a "favorite" in the Files app for an SMB share on my NAS. The OCR app let me select a folder for placing documents, and I picked that favorite.
It works seamlessly, except when my phone has to restart after updates or something. Then I have to remap it. I think this would still apply to local file folders too. It's a simple process but not 100% foolproof.