4 ms·

Strong disagree. Part of my disagreement comes from the fact that the process is inconsistent and time-consuming from Google's end. If you read more of the art

Strong disagree. Part of my disagreement comes from the fact that the process is inconsistent and time-consuming from Google's end. If you read more of the article, you can get a glimpse of how poorly it's run. And iA have been lucky here. Some apps submit to Google for OAuth approval and get stuck waiting for approval for years. But another part comes from the fact that drive.file access is not enough for some apps, and iA Writer falls into that category. Some apps really do need full access. (But Google told them they only need read-only access, lol.) Additionally, having been though the CASA process, it has been pure security theater. No offense to the people working on it, because I'm sure they have good intentions, but letting developers run a python script on their app to self-report vulnerabilities really doesn't solve anything. I suspect this is why Google took away the free option and are requiring a review by a security lab. The problems with this is that Google only guarantees a minimum cost, not a maximum cost, and that not every company is in a position to let the lab Google has partnered with see their code. And finally, I'm skeptical at how much a security lab is going to find with a quick check on a small payment. And frankly, Google Drive access is not worth the cost. Even if it's $500/year in fees, + time working with the lab (which, as iA pointed out, can be a huge opportunity cost), in most cases, the kinds of apps that need full access won't suffer $500/year in damages by removing Google Drive support. And Google Drive doesn't exist in a vacuum. There are other cloud storage solutions out there. Amazon doesn't make developers jump through their ridiculous hoops to access the S3 API.

notpushkin 2y ago
> But another part comes from the fact that drive.file access is not enough for some apps, and iA Writer falls into that category. How so? (I agree that the readonly category doesn’t work for iA, but drive.file should be fine IMO.) > Amazon doesn't make developers jump through their ridiculous hoops to access the S3 API. With S3, you only get access to your app’s data, not everything user has. If that’s what you want drive.file or drive.appfolder permissions are what you need: https://developers.google.com/drive/api/guides/api-specific-auth https://developers.google.com/drive/api/guides/api-specific-...
- StewardMcOy 2y ago
  > 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.
mgraczyk 2y ago
FWIW they don't allow developers to self verify any more (as of this year).
- StewardMcOy 2y ago
  Which is why I said > I suspect this is why Google took away the free option and are requiring a review by a security lab.
  - mgraczyk 2y ago
    thanks, missed that!

notpushkin 2y ago

> But another part comes from the fact that drive.file access is not enough for some apps, and iA Writer falls into that category. How so? (I agree that the readonly category doesn’t work for iA, but drive.file should be fine IMO.) > Amazon doesn't make developers jump through their ridiculous hoops to access the S3 API. With S3, you only get access to your app’s data, not everything user has. If that’s what you want drive.file or drive.appfolder permissions are what you need: https://developers.google.com/drive/api/guides/api-specific-auth https://developers.google.com/drive/api/guides/api-specific-...

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

mgraczyk 2y ago

FWIW they don't allow developers to self verify any more (as of this year).

StewardMcOy 2y ago
Which is why I said > I suspect this is why Google took away the free option and are requiring a review by a security lab.
- mgraczyk 2y ago
  thanks, missed that!