6 ms·

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 her

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.

mgraczyk 2y ago
This is exactly right. 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.
- Gigachad 2y ago
  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.
  - xethos 2y ago
    If you've covered the personal frustration angle, I'll point to how it also changes the financial odds of turning a profit with malware. ~$700 USD for a week (before getting discovered) means you better turn a profit fast - and if you can't, there's not much point getting that full storage scope
    - sidewndr46 2y ago
      If that's the case then a $700 bond would be sufficient
      - Gigachad 2y ago
        Who is paying the security auditor then?
        sidewndr46 2y ago
        That's the point, the security auditor is providing any service other than being a barrier.
        therein 2y ago
        Do you think this may allow us to reintegrate the security auditor back into the productive workforce after a brief period of adjustment?
SSLy 2y ago
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.
- 0cf8612b2e1e 2y ago
  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.
  - layer8 2y ago
    This sounds like the user has to navigate to the file from the app’s file picker each time they want to open the file, instead of being able to open the file from the Files app. This would also mean that the app can’t maintain a “recent files” list (or bookmarks) for the user to be able to quickly reopen a previously opened file, because that wouldn’t be going through the file picker.
    - tadfisher 2y ago
      That is not true; you can hang on to the content URI and metadata to present a Recent Files UI. You need to ask for a persisted write permission for the content URI. You can even use the ContentResolver to check the file's existence and update the metadata (including thumbnail).
      - iggldiggl 2y ago
        Although AFAIK Android's implementation then means that you can end up with duplicate entries for the same file if you open it through differing means (like both through an external file manager as well as within the app's own UI), because those result in distinct content URIs and there are no official APIs that would allow you to confirm whether two separate content URIs are actually pointing to the same file (where that'd make sense, e.g. for files on the local file system at least [1]). [1] I think there are some hacks to work around that issue, but obviously they aren't guaranteed to work all of the time.
threeseed 2y ago
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.
- thatguy0900 2y ago
  The user can use a file picker to select individual files as well.
  - threeseed 2y ago
    So then the app can't have Recent Files functionality. Or open the last file the user was editing as it may have been edited elsewhere. Seems pretty unworkable for a text editor.
    - IanCal 2y ago
      I don't think that's true, doesn't the file picker have recent files in it? > Or open the last file the user was editing as it may have been edited elsewhere. When is this a particular use case? Auto open a file I opened elsewhere?
      - Gigachad 2y ago
        The iOS file picker does have a recent files tab and it seems to be the first one that opens.
    - crazygringo 2y ago
      Those seem pretty minor, and are you sure Google doesn't allow a way for permission on the file to persist? Even if it doesn't, you can access recent files from the Drive file picker.
    - NavinF 2y ago
      Only if you absolutely insist on creating your own special snowflake file picker UI instead of using the OS file picker
notpushkin 2y ago
> 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.
- Gigachad 2y ago
  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.
  - mvdtnz 2y ago
    This is the second time I have seen you in this thread talk about how the iOS picker behaves. This is irrelevant. We're not discussing iOS.
    - notpushkin 2y ago
      I’d expect something similar on Android actually – there is the relevant API at least.
    - consteval 2y ago
      It is relevant, because it demonstrates it's both possible and common. Therefore, complaints about this not working in Android speaks more to insufficiencies in the file picker, not true capabilities. A lot of people are arguing you need more powerful permissions due to hard requirements. Well, it's not a hard requirement in this case, it's a defect with the Android file picker and it should be fixed THERE. If the Android file picker does not currently work this way, which I bet it does.
spencerchubb 2y ago
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.
StewardMcOy 2y ago
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
croes 2y ago
Perhaps Google should have pointed this out in its review instead of just recommending read-only access.
- MrDresden 2y ago
  I'm going to hazard a guess that you haven't been involved in many direct interactions with the Google review process. They are rarely if ever precise or very factual.
- reichenstein 2y ago
  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.
  - 2y ago
throwaway314155 2y ago
> I only read the first part of the article 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.
- mvdtnz 2y ago
  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.
  - throwaway314155 2y ago
    Yeah it's maddening.
- hn_throwaway_99 2y ago
  I didn't "dismiss it so completely". 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.
  - reichenstein 2y ago
    The definition of a well informed, happy, modern man: He reads a couple of lines and goes, "Yep, I know how this article ends. I'm right, he's wrong." Then he watches the first half of a game, switches off the TV, pumps his fist, and says, "My team WINS again." Writes the match report, gets in the shower, soaps himself up, and walks out, unrinsed, fully lathered, super clean.
    - hn_throwaway_99 2y ago
      Happy to have you point anywhere my assumptions are wrong vs. your random bullshit of a creating writing exercise.

mgraczyk 2y ago

This is exactly right. 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.

Gigachad 2y ago
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.
- xethos 2y ago
  If you've covered the personal frustration angle, I'll point to how it also changes the financial odds of turning a profit with malware. ~$700 USD for a week (before getting discovered) means you better turn a profit fast - and if you can't, there's not much point getting that full storage scope
  - sidewndr46 2y ago
    If that's the case then a $700 bond would be sufficient
    - Gigachad 2y ago
      Who is paying the security auditor then?
      - sidewndr46 2y ago
        That's the point, the security auditor is providing any service other than being a barrier.
        therein 2y ago
        Do you think this may allow us to reintegrate the security auditor back into the productive workforce after a brief period of adjustment?

SSLy 2y ago

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.

0cf8612b2e1e 2y ago
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.
- layer8 2y ago
  This sounds like the user has to navigate to the file from the app’s file picker each time they want to open the file, instead of being able to open the file from the Files app. This would also mean that the app can’t maintain a “recent files” list (or bookmarks) for the user to be able to quickly reopen a previously opened file, because that wouldn’t be going through the file picker.
  - tadfisher 2y ago
    That is not true; you can hang on to the content URI and metadata to present a Recent Files UI. You need to ask for a persisted write permission for the content URI. You can even use the ContentResolver to check the file's existence and update the metadata (including thumbnail).
    - iggldiggl 2y ago
      Although AFAIK Android's implementation then means that you can end up with duplicate entries for the same file if you open it through differing means (like both through an external file manager as well as within the app's own UI), because those result in distinct content URIs and there are no official APIs that would allow you to confirm whether two separate content URIs are actually pointing to the same file (where that'd make sense, e.g. for files on the local file system at least [1]). [1] I think there are some hacks to work around that issue, but obviously they aren't guaranteed to work all of the time.

threeseed 2y ago

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.

thatguy0900 2y ago
The user can use a file picker to select individual files as well.
- threeseed 2y ago
  So then the app can't have Recent Files functionality. Or open the last file the user was editing as it may have been edited elsewhere. Seems pretty unworkable for a text editor.
  - IanCal 2y ago
    I don't think that's true, doesn't the file picker have recent files in it? > Or open the last file the user was editing as it may have been edited elsewhere. When is this a particular use case? Auto open a file I opened elsewhere?
    - Gigachad 2y ago
      The iOS file picker does have a recent files tab and it seems to be the first one that opens.
  - crazygringo 2y ago
    Those seem pretty minor, and are you sure Google doesn't allow a way for permission on the file to persist? Even if it doesn't, you can access recent files from the Drive file picker.
  - NavinF 2y ago
    Only if you absolutely insist on creating your own special snowflake file picker UI instead of using the OS file picker

notpushkin 2y ago

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

Gigachad 2y ago
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.
- mvdtnz 2y ago
  This is the second time I have seen you in this thread talk about how the iOS picker behaves. This is irrelevant. We're not discussing iOS.
  - notpushkin 2y ago
    I’d expect something similar on Android actually – there is the relevant API at least.
  - consteval 2y ago
    It is relevant, because it demonstrates it's both possible and common. Therefore, complaints about this not working in Android speaks more to insufficiencies in the file picker, not true capabilities. A lot of people are arguing you need more powerful permissions due to hard requirements. Well, it's not a hard requirement in this case, it's a defect with the Android file picker and it should be fixed THERE. If the Android file picker does not currently work this way, which I bet it does.

spencerchubb 2y ago

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.

StewardMcOy 2y ago

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

croes 2y ago

Perhaps Google should have pointed this out in its review instead of just recommending read-only access.

MrDresden 2y ago
I'm going to hazard a guess that you haven't been involved in many direct interactions with the Google review process. They are rarely if ever precise or very factual.
reichenstein 2y ago
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.
- 2y ago

throwaway314155 2y ago

> I only read the first part of the article 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.

mvdtnz 2y ago
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.
- throwaway314155 2y ago
  Yeah it's maddening.
hn_throwaway_99 2y ago
I didn't "dismiss it so completely". 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.
- reichenstein 2y ago
  The definition of a well informed, happy, modern man: He reads a couple of lines and goes, "Yep, I know how this article ends. I'm right, he's wrong." Then he watches the first half of a game, switches off the TV, pumps his fist, and says, "My team WINS again." Writes the match report, gets in the shower, soaps himself up, and walks out, unrinsed, fully lathered, super clean.
  - hn_throwaway_99 2y ago
    Happy to have you point anywhere my assumptions are wrong vs. your random bullshit of a creating writing exercise.