I only read the first part of the article, but having dealt with Drive API scopes and their issues previously, I feel there is just a major misunderstanding here.
The "fully open" Drive API read/write scopes should be highly restricted by default (because they essentially give you access to a user's entire drive), and these are the ones that Google added much more stringent security requirements a couple years ago, e.g. requiring a security audit.
However, there is also a much less sensitive Drive API scope, 'drive.file', which is non-sensitive. It lets an app read and write only files the app owns (or read files a user picks through the file picker control).
Thus, I don't understand why the ia.net app would require more than the drive.file scope. I have no doubt that Google's messaging wasn't clear on the transition process when they first created drive.file scope (and I personally wasted a ton of time with bugs in Google's own file picker when using that scope), but it is a much better solution.
I just finished the process to get drive.readonly for my app. It was a huge pain in the ass, and Google was not very helpful. Google recommends you pay $720 for a CASA lab assessment, which consists of some random dude in an apartment in SF running an open source script against a .zip of your codebase, then that guy emails Google saying you "passed".
However, the goal is noble, to prevent malware and scam apps from accessing people's drives. It doesn't sound like the app from the article needs these more restricted scopes.
Being a huge pain in the ass probably does filter out a lot of trivial malware that doesn’t have the resources to jump though these hoops, especially when it might only last a week or so before they get shut down and have to start again.
Don't you think it makes sense to read the whole article before dismissing it so completely?
This forum should really have a rule to discourage shallow dismissals to somewhat counteract the negative effects of the whole "don't talk about RTFA" rule.
Not only does this forum have no such rule, you are in fact in violation of the website's guidelines for pointing out that this chap didn't read the article. Which is bananas.
It was clear to me from the first half I read that the author completely misunderstood and was unaware of the Drive API scope changes that Google made. There is nothing I wrote that would have been contradicted by the rest of the blog post.
Well, it's not like we don't know about the default file picker. If we'd switch our customers to that clunky, buggy piece of brittle UX bricolage, they start throwing stones. And you know what: They'd be right. They usually are right. They just don't know or care what it costs to build that they don't want to pay for. And understandably, since everything else in Google world comes completely free of charge.
Some experts here seem to think that “It’s great that Google takes security seriously. I don’t want just any app getting access to my Drive.” Guys...
You think this is air you're breathing? CASA isn’t real security. It’s a very badly played security theater. There are plenty of holes, MI CASA SU CASA, that real hackers can use to steal your selfies and credit card info. You still think we’re not informed enough? We never wanted access to Google Drive. We don’t care about your Google Drive or anyone’s Drive at all.
We don’t have, want, or ever asked for access to your files. And don’t start with, “But you could be hackers!” We’re not. Google has our entire history—7 years with them, 14 years building apps, and 20 years as a company. They have our code, user feedback, passports, phone numbers, bank info, and confidential documents. But they still pass the security theatre burden onto us, making us pay KPMG for audits. Not because it makes things safer. It's so they can lean back, do nothing, and then lift both hands and then point fingers in case things go wrong. That scales nicely.
You know what is a much better way to care about safety? A human mind that knows, checks and cares. Oh, that doesn't scale? Okay, so let's increase bureaucracy. Yeah, bureaucracy will make things safer. Safety by bureaucracy was always the best great hacker barrier. Or is it the opposite? Bureaucracy makes you calculable. If I were a hacker, I'd welcome bureaucracy.
Doesn't that mean that the app wouldn't be able to edit a document created elsewhere.
Including documents created by their own web or desktop client.
And it's odd that Google thinks that writing to files is significantly worse than reading. What benefit does a hacker have to update your private photos or bank details versus reading them.
it's a text editor. Users expect to edit files in any random directory they'll make on drive, not in the containment scope that doesn't work with users' writing habits.
From the description, the app launches an OS controlled file picker. Once the human picks a file, the app is given a file handle with read/write permissions. Any file is fair game to be used within the app, but the application does not get to know anything about the file system.
I wouldn't want any text editor app to have full rights to my Google Drive. I literally recently implemented a similar feature (not for a text editor but for an app that needed to pull files from many different sources), and it's not that hard, i.e. giving easy access to local files and then using the picker control for "Drive imports".
The problem here is the original app developer had full, willy-nilly Drive access, and when Google rightfully locked down this level of access (and, mind you, didn't prohibit - I've gone through the Drive restricted scope verification process and it's not as hard as this blog post is making it out to be), the developer didn't take the time to see what was necessary to comply.
Again, I have no doubt Google could have given better instructions on how to migrate to the drive.file scope or how to use the restricted scopes. But Google has been warning about this for many years now, so seems like this dev just scrambled at the last minute.
To be blunt: how do you know it's not an exfiltration app that will suck down your entire Drive and upload it to their sponsor's ML training engine?
Text editors are great, but hand-installed editors[1] running on the local filesystem of a developer-maintained personal device are a very different threat model than an app available to everyone in the Play Store.
[1] And even then they tend strongly to be boosted by a large community of (usually) open source developers attesting to it, usually by inclusion in something like a "Linux Distro" which carries a strong promise of well-audited software. Emacs and VSCode and whatnot skate on reputation, basically, but the community tends to frown on "here: download my new binary tool for all your editting needs!".
> Create new Drive files, or modify existing files, that you open with an app or that the user shares with an app while using the Google Picker API or the app’s file picker.
Yeah, this should do the trick. From the cursory look seems like there’s no Google Picker UI for Android though?
Google actions are somewhat ridiculous here (they should audit iA’s app, not their cloud), but the reason is pretty solid IMO. If you choose an overly broad scope, be prepared for scrutiny.
You don't need a google drive specific picker. Drive adds itself in to the OS file picker, on iOS at least. And that lets any app access any file without even using the drive api or having an api key. The key point is that iOS and Android control that access so the app can't open a file the user didn't select.
If you want that functionality, you can do it easily for files the app created itself, or if you want access to literally everything without user oversight, you need a security audit.
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.
yeah I think android's policy is pretty reasonable here. if you're gonna have read/write access to everything in my google drive, you should be scrutinized pretty heavily.
We've had to go through this process for the app I have, and it definitely was cumbersome and makes the process a huge pain. Fortunately, after a while Google often lets you switch to a Tier 1 assessment, which involves using various tools to analyze your code and make improvements without shelling out a ton of money.
At the same time, Google is in a tough spot here. The files and documents in your Google Drive (or Gmail) are incredibly sensitive. One possible solution is using the https://www.googleapis.com/auth/drive.file OAuth scope, which only lets you access files a user has explicitly shared with the app. I'm curious if iA Writer has limitations that makes this a bad user experience, but from a user security point of view, I can see why I want the apps that get to see my whole Google Drive audited too.
As a user of Google drive, I’m so glad it works like this. I have a ton of random apps that store stuff in my drive that I don’t fully trust, and it’s very reassuring that they only have permission to read the files that they created.
I’m certain that if the full drive access was easy to get, they would all use that as the path of least resistance. And some of those apps would be sucking all of my data out to some random server.
I'm very sympathetic to that approach. But I think it has to be tempered at least a little bit with reputation. iA has been making Writer for 12 years now and it's always been a premium, highly user-respecting app. If they can't get through that bureaucracy, it probably can't be done.
Granted, past performance doesn't mean they'll be perfect forever. It's not a guarantee. It should carry some weight, though. I can't think of many devs I'd trust with my data as much as iA. Omni Group, I guess. Agile Tortoise. There's a set of devs who stake their business on their sterling reputations. It should be possible for that gang to at least contact a human to answer their questions.
It feels like a situation where we just need laws to make it illegal to do a data grab like this and apps in country's without those laws should get the scrutiny.
I think a random phone app WOULD do that because there are no repercussions for doing so. Facebook, LinkedIn, and then late comers ruined the phone ecosystem by doing all the shady things they did when you wanted to do one simple useful thing. I should be able to grant contact information to an app so that it can connect me with my friends on the service. I should not have to worry about all of my contact information being harvested for spam and sold to anyone the company thinks they can make a buck from.
But I also can't imagine using a program on my computer that was prevented from having full access to my file system if I wanted it to have it. MacOS slowly killing the system is making me considering switching to a different OS for the first time in over a decade
Yup. And it needs to be something that has to be done regularly, either every time the app updates or on a fixed schedule. Otherwise you would get a similar ecosystem that happened with some browser extensions, where a benign developer goes, writes an useful app, gets the permissions for that and a user base, then some shady company comes and acquires the app and updates it to use the permission to suck up all data.
Sure it's an annoying process for developers, but Google has to think of the user privacy when creating the policies around these kind of permissions.
Recently, there have been scam Android apps in India that request access to users’ contact lists. These apps then blackmail users by threatening to send deepfake videos to their contacts, falsely accusing them of heinous acts like rape.
Tragically, some individuals have even committed suicide due to this blackmail(1). So dozens of people have actually killed themselves because they mistakenly gave a permission on their phone.. just let that sink in.
Google is in a difficult position. On one hand, they need to protect user data with strict security measures. On the other hand, these measures can be seen as overly restrictive. It’s a delicate balance, and unfortunately, there’s no easy solution.
To some extent, if you can’t afford a yearly audit, you can’t afford unlimited access to users sensitive documents. It’s much like handling credit card data or toxic waste. Most people and small orgs should avoid it at all costs.
Thankfully Google offers a lot of less risky permission scopes that don’t require audits.
Yeah that seems totally fair. How many users really intend to give full access to an app made by someone that can't afford $500/year? Most non-devs would be sketched out
I respect the "fine we'll take our ball and go home then" approach to put some actual pressure on Google.
I do wonder if they could have just chosen to stop offering Google Drive support on Android and instead pivot to storing content on their own servers with a simple data export option, or using something like Dropbox instead.
It really seems like this latest cloud compliance battle was just the straw that broke the camel's back, and the real problem is that the Android app wasn't earning that much money as it was, so this was a convenient time and reason to kill it.
Why do all android app roads always lead to Google's app store? Why not move everything to another app store, such as Amazon's? All the code, work, time, and other sacrifices aren't worth giving them a shot?
If you use non Play Store stores on a device with the Play Store you will get a lot more prompts constantly reminding you of how unsafe it is and how comfy and warm it was back on the Play Store.
Google are damned if they do and damned if they don’t on that, but it is deserved, they have burned so much goodwill in the Android space.
Some comments are asking, “Why not just ditch Google Drive support?” Well, how would a cloud-enabled writing app do on Android without Google Drive support? About as well as the same app on iOS without iCloud support — roadkill, I expect.
I’ve used iA Writer on many platforms for years and I love it. It’s a simple Markdown editor that stores stuff in your cloud of choice. There are a million of these apps, but iA Writer has been high quality and regularly updated for a long time.
Why not use the storage access framework, which is agnostic to where the files are being saved whether local or remote? By selecting the file to open or naming it to save, you choose a destination and permission is implicitly granted to that location for that file. Could be google drive or the local file system or any cloud provider app that supports SAF. No storage permissions needed, and it's been around for years and years.
It seems like the entire fight is over Google Drive, which is not a hard requirement for pretty much any Android app. While Google's behavior here strikes me as ridiculous, dropping Drive support seems much more rational than dropping Android support entirely.
This was just the author's current issue on Android. In another month or two it would have been something else. I fought similar battles for the better part of a decade before finally giving up when Google's policies made it so that even keeping apps running (at least in my case) was an economic non-starter. The sheer amount of bureaucratic B.S.[1] they constantly fling at you while simultaneously bit-rotting existing applications is insane.
[1] Sometimes it's related to their store listing policies which are constantly changing, sometimes it's related to taxation in a specific country, sometimes it's related to laws in a specific country, sometimes it's actually related to software (on-device or web services!) they are forcing you to update/change etc. etc.
It’s less manual than that, the app opens the OS file picker which has unlimited access, the user selects the file, the file is then made available for the app to access, the app can then save it to Google drive.
What it can’t do is grab your entire drive file list and contents the moment you sign in.
Apps can be local-first, reading and writing to files on the device. Then each user can choose their own syncing service like Syncthing or Resilio Sync, which runs in the background and automatically syncs those files to your other devices.
The bureaucracy involved in getting anything into any of the app stores basically make them untenable for side-project/one-man-band developers. At first it felt like a democratization of distribution, but now it's completely turned around, and is worse than before app stores, as the app store is effectively a monopoly on that particular platform (yes, I know you can get around that on Android, but most people won't/don't). And desktop OS are trying to move that way as well. I guess web-apps are probably the only real solution.
Readit News
The "fully open" Drive API read/write scopes should be highly restricted by default (because they essentially give you access to a user's entire drive), and these are the ones that Google added much more stringent security requirements a couple years ago, e.g. requiring a security audit.
However, there is also a much less sensitive Drive API scope, 'drive.file', which is non-sensitive. It lets an app read and write only files the app owns (or read files a user picks through the file picker control).
Thus, I don't understand why the ia.net app would require more than the drive.file scope. I have no doubt that Google's messaging wasn't clear on the transition process when they first created drive.file scope (and I personally wasted a ton of time with bugs in Google's own file picker when using that scope), but it is a much better solution.
I just finished the process to get drive.readonly for my app. It was a huge pain in the ass, and Google was not very helpful. Google recommends you pay $720 for a CASA lab assessment, which consists of some random dude in an apartment in SF running an open source script against a .zip of your codebase, then that guy emails Google saying you "passed".
However, the goal is noble, to prevent malware and scam apps from accessing people's drives. It doesn't sound like the app from the article needs these more restricted scopes.
Don't you think it makes sense to read the whole article before dismissing it so completely?
This forum should really have a rule to discourage shallow dismissals to somewhat counteract the negative effects of the whole "don't talk about RTFA" rule.
It was clear to me from the first half I read that the author completely misunderstood and was unaware of the Drive API scope changes that Google made. There is nothing I wrote that would have been contradicted by the rest of the blog post.
Some experts here seem to think that “It’s great that Google takes security seriously. I don’t want just any app getting access to my Drive.” Guys...
You think this is air you're breathing? CASA isn’t real security. It’s a very badly played security theater. There are plenty of holes, MI CASA SU CASA, that real hackers can use to steal your selfies and credit card info. You still think we’re not informed enough? We never wanted access to Google Drive. We don’t care about your Google Drive or anyone’s Drive at all.
We don’t have, want, or ever asked for access to your files. And don’t start with, “But you could be hackers!” We’re not. Google has our entire history—7 years with them, 14 years building apps, and 20 years as a company. They have our code, user feedback, passports, phone numbers, bank info, and confidential documents. But they still pass the security theatre burden onto us, making us pay KPMG for audits. Not because it makes things safer. It's so they can lean back, do nothing, and then lift both hands and then point fingers in case things go wrong. That scales nicely.
You know what is a much better way to care about safety? A human mind that knows, checks and cares. Oh, that doesn't scale? Okay, so let's increase bureaucracy. Yeah, bureaucracy will make things safer. Safety by bureaucracy was always the best great hacker barrier. Or is it the opposite? Bureaucracy makes you calculable. If I were a hacker, I'd welcome bureaucracy.
They are rarely if ever precise or very factual.
Including documents created by their own web or desktop client.
And it's odd that Google thinks that writing to files is significantly worse than reading. What benefit does a hacker have to update your private photos or bank details versus reading them.
The problem here is the original app developer had full, willy-nilly Drive access, and when Google rightfully locked down this level of access (and, mind you, didn't prohibit - I've gone through the Drive restricted scope verification process and it's not as hard as this blog post is making it out to be), the developer didn't take the time to see what was necessary to comply.
Again, I have no doubt Google could have given better instructions on how to migrate to the drive.file scope or how to use the restricted scopes. But Google has been warning about this for many years now, so seems like this dev just scrambled at the last minute.
Text editors are great, but hand-installed editors[1] running on the local filesystem of a developer-maintained personal device are a very different threat model than an app available to everyone in the Play Store.
[1] And even then they tend strongly to be boosted by a large community of (usually) open source developers attesting to it, usually by inclusion in something like a "Linux Distro" which carries a strong promise of well-audited software. Emacs and VSCode and whatnot skate on reputation, basically, but the community tends to frown on "here: download my new binary tool for all your editting needs!".
Yeah, this should do the trick. From the cursory look seems like there’s no Google Picker UI for Android though?
Google actions are somewhat ridiculous here (they should audit iA’s app, not their cloud), but the reason is pretty solid IMO. If you choose an overly broad scope, be prepared for scrutiny.
If you want that functionality, you can do it easily for files the app created itself, or if you want access to literally everything without user oversight, you need a security audit.
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.
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-...
At the same time, Google is in a tough spot here. The files and documents in your Google Drive (or Gmail) are incredibly sensitive. One possible solution is using the https://www.googleapis.com/auth/drive.file OAuth scope, which only lets you access files a user has explicitly shared with the app. I'm curious if iA Writer has limitations that makes this a bad user experience, but from a user security point of view, I can see why I want the apps that get to see my whole Google Drive audited too.
[1] https://developers.google.com/drive/api/guides/api-specific-...
I’m certain that if the full drive access was easy to get, they would all use that as the path of least resistance. And some of those apps would be sucking all of my data out to some random server.
Granted, past performance doesn't mean they'll be perfect forever. It's not a guarantee. It should carry some weight, though. I can't think of many devs I'd trust with my data as much as iA. Omni Group, I guess. Agile Tortoise. There's a set of devs who stake their business on their sterling reputations. It should be possible for that gang to at least contact a human to answer their questions.
I think a random phone app WOULD do that because there are no repercussions for doing so. Facebook, LinkedIn, and then late comers ruined the phone ecosystem by doing all the shady things they did when you wanted to do one simple useful thing. I should be able to grant contact information to an app so that it can connect me with my friends on the service. I should not have to worry about all of my contact information being harvested for spam and sold to anyone the company thinks they can make a buck from.
But I also can't imagine using a program on my computer that was prevented from having full access to my file system if I wanted it to have it. MacOS slowly killing the system is making me considering switching to a different OS for the first time in over a decade
Sure it's an annoying process for developers, but Google has to think of the user privacy when creating the policies around these kind of permissions.
Deleted Comment
Tragically, some individuals have even committed suicide due to this blackmail(1). So dozens of people have actually killed themselves because they mistakenly gave a permission on their phone.. just let that sink in.
Google is in a difficult position. On one hand, they need to protect user data with strict security measures. On the other hand, these measures can be seen as overly restrictive. It’s a delicate balance, and unfortunately, there’s no easy solution.
(1) https://www.thequint.com/news/india/bbc-chinese-loan-app-doc...
But the audit would cost them two months of revenue, every year.
So:
> So, as of today, we’re not just accepting our frozen-in-carbonite fate. We’re embracing it. We’re going to take the app offline.
By making a native app, you're donating free developer time to the platform owner. If they're not making it worth it for you, screw them.
Thankfully Google offers a lot of less risky permission scopes that don’t require audits.
I do wonder if they could have just chosen to stop offering Google Drive support on Android and instead pivot to storing content on their own servers with a simple data export option, or using something like Dropbox instead.
It really seems like this latest cloud compliance battle was just the straw that broke the camel's back, and the real problem is that the Android app wasn't earning that much money as it was, so this was a convenient time and reason to kill it.
https://en.wikipedia.org/wiki/List_of_Android_app_stores
This is because it is where there is the traffic.
If you use non Play Store stores on a device with the Play Store you will get a lot more prompts constantly reminding you of how unsafe it is and how comfy and warm it was back on the Play Store.
Google are damned if they do and damned if they don’t on that, but it is deserved, they have burned so much goodwill in the Android space.
I’ve used iA Writer on many platforms for years and I love it. It’s a simple Markdown editor that stores stuff in your cloud of choice. There are a million of these apps, but iA Writer has been high quality and regularly updated for a long time.
https://www.youtube.com/watch?v=C28pvd2plBA
[1] Sometimes it's related to their store listing policies which are constantly changing, sometimes it's related to taxation in a specific country, sometimes it's related to laws in a specific country, sometimes it's actually related to software (on-device or web services!) they are forcing you to update/change etc. etc.
What it can’t do is grab your entire drive file list and contents the moment you sign in.
Apps can be local-first, reading and writing to files on the device. Then each user can choose their own syncing service like Syncthing or Resilio Sync, which runs in the background and automatically syncs those files to your other devices.