[notpushkin]

> IIRC it basically mounts your file store as if it were a filesystem and allows you to completely manage files.

This is not something I’d want a text editor to do! (The search feature is cool though.) If the point really is to make an alternative UI to both Drive and Docs, this makes sense, but again, I wouldn’t expect that.

> With the S3 API, you could implement the search every file in a folder feature

This is useful! Not my point though.

With the S3 API, you usually create one or multiple buckets per app – perhaps even one bucket per user. Your app manages those buckets, so it’s natural that it has access to the whole thing. (You can ask users to plug in their own S3 buckets, but that’s also not something I’d expect from iA.)

With Google Drive API, you mount user’s own Drive storage. This includes all files in it, some created by other apps, some uploaded by the user directly. Your app doesn’t usually need access to everything I have in there.

S3 and Drive are just two completely different products, for different people, with different API security models. You can use S3 as a personal storage space (I do actually, but with Backblaze), and perhaps you can make your app store file uploads on Dropbox for example but it’s not straightforward.

> CASA review is fairly useless

Absolutely. I’m just arguing about intentions actually – granular permissions are net good. The processes at Google are quite ridiculous indeed.

[MagerValp]

> This is not something I’d want a text editor to do!

But this is exactly how it works in Sublime or VS Code or what have you on the desktop. You open a project folder and then you can click any file to edit, add new files, rename them, and so on.

It's been decades since I last used a text editor where you had to open each file individually (CygnusEd!).

[consteval]

This is changing on Desktop, at least Linux. See flatpak, Wayland, and freedesktop portals.

[StewardMcOy]

> With the S3 API, you usually create one or multiple buckets per app – perhaps even one bucket per user. Your app manages those buckets, so it’s natural that it has access to the whole thing. (You can ask users to plug in their own S3 buckets, but that’s also not something I’d expect from iA.)

Then I think we have completely opposite expectations of what a native editor should do here. I don't want to use iA to create an app-specific folder for all of its files, I want to use it to edit all of my existing files in all of my buckets. Who organizes their files by app? Imagine if VS Code could only edit projects in a folder it created to manage files? What about Photoshop? Should I be forced to save images in the Photoshop folder and then move them to my VS Code folder?

I would never "create one or multiple buckets per app," because my life isn't app-centric, it's document-centric.

On S3, I organize my buckets by project, or sometimes by client. On Docs, that's how I organize my folders. 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.

If I'm running an editor, it really does need to "access everything I have in there," including files, created by other apps or uploaded by the user directly.

EDIT: I'm not trying to question the intentions of those who think apps that access all files should be more secure. But the current process is untenable for independent developers, and in my experience, does little to actually improve the security of the app. iA is correct to drop drive support rather than attempt to shoehorn their app into a scope it's not designed for or waste time and money jumping through these useless hoops.

[notpushkin]

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.

[StewardMcOy]

> 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.

[notpushkin]

> 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).