Okay, I think we’re almost on the same page here. Tl;dr: I agree that giving access to files one by one is not a right scope for iA, but I think giving access to all files is much much worse. It shouldn’t be all or nothing.
> Imagine if VS Code could only edit projects in a folder it created to manage files?
This would indeed be untenable! And of course granting access to individual files doesn’t work for VS Code too. If you grant access to a whole folder at a time though, it’s much more reasonable: it will be able to access the project I’m working on, but not my /etc/passwd (unless I explicitly open it of course). This is how it works on desktop Linux with Flatpak for example, as another poster mentioned around here. I have no idea if Google Drive can do that, but it should.
> If I download a new editor, I expect it to be able to edit any and all of the files without fuss, whether they're on my local disk, on S3, or on Google Drive.
I would expect that as well, but I also would like to choose what it should have access to.
It’s reasonable to expect VS Code to be able to move files around in your project, for which it needs full access to the project folder. It’s also reasonable to be able to jump to a definition somewhere in /usr/include. But it shouldn’t be able to arbitrarily access all your stuff unless you let it.
Same thing with iA Writer. If I’m working on a book and have one chapter per file, it should have access to the whole folder to be able to show the list of chapters, create new ones etc. It shouldn’t have access to my family photos archive or the tax return I’m preparing or something.
Based on what I gather from iA’s website, giving access on a folder basis should be the perfect solution for them. I have no idea if Google supports this, and if it doesn’t then I agree they should drop the support altogether: giving access file by file doesn’t work, and having one big “iA Writings” folder is just janky.
> does little to actually improve the security of the app
Technically, maybe. It does help a lot in case the app actually gets hacked though, or if the developers go rough and decide to mine your data or something.
> if Google supports this, and if it doesn’t then I agree they should drop the support altogether
Last time I used it, the file picker was by file, not folder, and was fairly janky. By that I mean it was slow and cumbersome to use. Selecting one file was bad enough, let alone multiple.
But selecting an entire folder would definitely be better, assuming that the experience could be much improved. I still think there needs to be a way to bypass it for apps that truly need access to every single file--even at the risk of attackers exploiting the app or the developer deciding to turn evil--but that's getting sidetracked from the real argument. So for now, let's assume I agree that the select a folder solution is perfect.
The real issue is that Google should not be the arbiter of what apps are allowed that kind of access, and they certainly shouldn't be making small developers jump through the expensive, ineffective CASA hoop to get it.
That's the real reason iA's discontinuing development on Android, and they're right to do so. Google Drive should have a permissions model that allows for users to control how much access an app should have. That would solve the issue without the unnecessary bureaucracy, the mistakes (like suggesting an editor be read-only), and added expense that other platforms don't put on third-party developers.
> Last time I used it, the file picker was by file, not folder, and was fairly janky.
Well, that sounds like Google haha. I’d drop it just for that reason alone, to be honest.
> The real issue is that Google should not be the arbiter of what apps are allowed that kind of access, and they certainly shouldn't be making small developers jump through the expensive, ineffective CASA hoop to get it.
Absolutely. In case of whole Drive access, I think a big scary warning should suffice here: the user should understand what they get into, but still be able to continue if they want. Perhaps the warning can be made less scary if the app passes an audit (something more suitable than CASA, of course).
> Imagine if VS Code could only edit projects in a folder it created to manage files?
This would indeed be untenable! And of course granting access to individual files doesn’t work for VS Code too. If you grant access to a whole folder at a time though, it’s much more reasonable: it will be able to access the project I’m working on, but not my /etc/passwd (unless I explicitly open it of course). This is how it works on desktop Linux with Flatpak for example, as another poster mentioned around here. I have no idea if Google Drive can do that, but it should.
> If I download a new editor, I expect it to be able to edit any and all of the files without fuss, whether they're on my local disk, on S3, or on Google Drive.
I would expect that as well, but I also would like to choose what it should have access to.
It’s reasonable to expect VS Code to be able to move files around in your project, for which it needs full access to the project folder. It’s also reasonable to be able to jump to a definition somewhere in /usr/include. But it shouldn’t be able to arbitrarily access all your stuff unless you let it.
Same thing with iA Writer. If I’m working on a book and have one chapter per file, it should have access to the whole folder to be able to show the list of chapters, create new ones etc. It shouldn’t have access to my family photos archive or the tax return I’m preparing or something.
Based on what I gather from iA’s website, giving access on a folder basis should be the perfect solution for them. I have no idea if Google supports this, and if it doesn’t then I agree they should drop the support altogether: giving access file by file doesn’t work, and having one big “iA Writings” folder is just janky.
> does little to actually improve the security of the app
Technically, maybe. It does help a lot in case the app actually gets hacked though, or if the developers go rough and decide to mine your data or something.