[StewardMcOy]

> How so? (I agree that the readonly category doesn’t work for iA, but drive.file should be fine IMO.)

Arguably, I'm not as familiar with iA as I should be, having only tried it briefly a while ago, but IIRC it basically mounts your file store as if it were a filesystem and allows you to completely manage files. Add, rename, delete, etc. And it's not just limited to iA's App's data. Part of the sales point is to be able to go between iA and Google Docs.

And it allows you to search for a string in every file in a folder. Sure, it has to download every file to do that, and that can be a bad idea, but it if you have a folder of 100 files, 100 KB each, that's reasonable. But with drive.file, what are you going to do? Show a picker for each of those 100 files?

And this is for a native app. It would have to load up a web view to show the picker.

> With S3, you only get access to your app’s data, not everything user has.

This is incorrect. With the S3 API, you could implement the search every file in a folder feature I mentioned above, no pickers required. Just use ListObjects (or ListBucket) along with GetObject.

And again, Google is locking this kind of access behind a CASA review, and while I don't want to insult anyone's intentions, CASA review is fairly useless. Even the paid option is more security theater than anything else. And it's a burden put on developers that other services don't require.

[consteval]

IMO, these "insufficiencies" should be addressed by safer APIs. The solution here should NOT be to just grant the app file permissions across the board.

For example, Search could be expressed as a separate permission and API operation. I see no reason why you need full file access to do a text search - the OS API can, and should, handle that.

The trouble here is people store all kinds of things in Google Drive, includes photographs. These could easily be exfiltrated to a server. This could cause identity theft, black mail, you name it. Performing a text search IMO is not a good enough justification for the potential risk of that situation.

[iggldiggl]

> For example, Search could be expressed as a separate permission and API operation.

Then maybe after years Google eventually deigns to add a search API, which is great, except you actually also want to do search and replace and they didn't implement that. Or maybe you want to do search and/or replace with regex support, and the new API doesn't support that either.

[StewardMcOy]

iggldiggl makes some good points about APIs not being flexible enough, but I also have to ask why go through the complexities of extra APIs? If I'm installing an editor and using it to open my files, I already trust it implicitly with all of my data. That means I also trust it to be reasonably free of RCEs that could modify or exfiltrate my data.

I could see your point if this was some fly-by-night web app accessing Google documents. But this is a native app I'm running on my phone or computer. I may have legitimate reasons to access those photos, to embed them into a document.

[consteval]

> already trust it implicitly with all of my data

I don't think this is the case for most people in this scenario - at least in a general sense.

For a typical desktop editor sure, but for a mobile editor that goes through Google Drive I wouldn't expect it to have any access to any file in my Drive. And if it did, this could be trivially be used for many horrible things. Meaning, the "type" of data stored in Google Drive versus someone's Documents folder is very different.

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