7 ms·
> 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 t
by 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 agoThis 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.
- notpushkin 2y agoOkay, 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.