3 ms·

> 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, ha

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

notpushkin 2y ago
> 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 2y ago
  > 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 2y ago
    This is changing on Desktop, at least Linux. See flatpak, Wayland, and freedesktop portals.
- StewardMcOy 2y ago
  > 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.
consteval 2y ago
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 2y ago
  > 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 2y ago
  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 2y ago
    > 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 2y ago

> 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 2y ago
> 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 2y ago
  This is changing on Desktop, at least Linux. See flatpak, Wayland, and freedesktop portals.
StewardMcOy 2y ago
> 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.

consteval 2y ago

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 2y ago
> 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 2y ago
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 2y ago
  > 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.