hn_throwaway_99
14 hours ago
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
13 hours 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
13 hours 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
11 hours 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
11 hours ago
If that's the case then a $700 bond would be sufficient
Gigachad
10 hours ago
Who is paying the security auditor then?
sidewndr46
10 hours ago
That's the point, the security auditor is providing any service other than being a barrier.
therein
6 hours ago
Do you think this may allow us to reintegrate the security auditor back into the productive workforce after a brief period of adjustment?
croes
13 hours ago
Perhaps Google should have pointed this out in its review instead of just recommending read-only access.
reichenstein
6 hours 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.
anal_reactor
6 hours ago
Because of security reasons, my web browser cannot write to "Downloads", but "Downloads/a" works.
Because of security reasons, my file manager cannot access "Android/obb" and I need to use a trick with the "Files" app.
In order to improve user experience, the option to directly mount the SD card via USB has been removed. Now I need to physically remove it from the phone because the Android's default way of handling things simply doesn't work when you have more than a handful of files.
BTW SD cards suck on Android, but when you connect them to the cheapest Chinese USB reader and to your PC, then they're magically 10x faster.
It's clear to me that Google pushes business decisions under the disguise of "improvements". I think that removing the audio jack was the symbol of Google moving away from creating a good OS to monetizing their OS. I really wish there was a viable alternative to Android that I could install on any phone.
MrDresden
7 hours 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.
throwaway314155
11 hours 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
8 hours 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.
threeseed
13 hours 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
13 hours ago
The user can use a file picker to select individual files as well.
fsckboy
11 hours ago
>The user can use a file picker to select individual files as well.
the top comment on this thread says:
It lets an app read and write only files the app owns (or read files a user picks through the file picker control).
which would not include writing picker files. Are you saying picker files could be written?
threeseed
13 hours 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.
NavinF
12 hours ago
Only if you absolutely insist on creating your own special snowflake file picker UI instead of using the OS file picker
IanCal
13 hours 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
10 hours ago
The iOS file picker does have a recent files tab and it seems to be the first one that opens.
crazygringo
13 hours 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.
cyberax
11 hours ago
> So then the app can't have Recent Files functionality.
Yeah, this is an issue. Google really needs to fix this. And there are multiple ways to do that! They can remember that a file was opened by the app earlier, and let it access again for a reasonable period.
They can also allow delegating access on a directory level instead of a binary all-or-nothing approach.
rerdavies
8 hours ago
Android DOES remember permissions for folders that you have opened previously through the picker (although the app does have to code for that); and you can reuse the URLs for files that you have received through the picker, as long as the permissions are still intact. (You can lose them if the app is used infrequently).
Life would be so much easier if the Android File Picker UI weren't so incredibly awful. Has to be the worst piece of UI design I have ever seen. Incredibly difficult to use even if you know exactly what you want.
notpushkin
13 hours 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
10 hours 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.
notpushkin
6 hours ago
In some cases you might want to retain access to the file. I think the OS file picker doesn’t allow that while the Google Picker does.
mvdtnz
8 hours 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
7 hours ago
I’d expect something similar on Android actually – there is the relevant API at least.
SSLy
13 hours 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
13 hours 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
13 hours 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.
hn_throwaway_99
13 hours ago
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.
stickfigure
12 hours ago
> I wouldn't want any text editor app to have full rights to my Google Drive.
What text editor do you use on your laptop/desktop/pc?
Gigachad
10 hours ago
On MacOS, apps like VSCode have to ask permission to read directories if they weren't opened via the OS file picker. So my text editor can not read my Google Drive folder unless I explicitly allow it to.
hn_throwaway_99
12 hours ago
Primarily vim or VSCode, why?
klabb3
12 hours ago
Parent means that your desktop OS is not sandboxed and your editor has permissions to read any file you have access to, including mounted Cloud Drives, as well as showing a custom file explorer (which both Vim and VSCode do, btw) and does not require special scoping on a file-by-file basis to happen in some OS controlled, confusing back-and-forth dance.
The security model on mobile, despite being gate kept and sandboxed to an extreme, still has massive giant glaring problems with malware, phishing and tracking (although that’s more of a feature). To double down on this strategy, by whitelisting, reviewing, authorizing, auditing, and blessing entitlements in holy corporate water – shows an amusing incongruence in contrast with say Linux which by almost every metric is more secure despite none of that, and to a lesser extent, macOS and Windows.
Gigachad
10 hours ago
Linux desktop is not secure at all. Basically anything you install can do anything without limitations. In a few minutes I could whip up a VSCode plugin that sends me your browser session storage and have access to all of your everything.
It's getting a lot better with Flatpak, Wayland, and PipeWire, but the pieces are still being put in place for an actually secure Linux desktop that comes anywhere close to the security of MacOS and iOS.
klabb3
an hour ago
> In a few minutes I could whip up a VSCode plugin that sends me your browser session storage and have access to all of your everything.
Yeah I know but I’m saying despite that Linux is more secure in practice. Most software is not distributed as some random VS code extension, but as FOSS projects and all the checks and balances of the distro maintainers. That’s who keeps you safe at night, and it works remarkably well.
Capability permission in all glory but it’s not a panacea. What happens in practice is that an app asks for permission to your bank account and eternal soul, and then users say “well, I guess I need to if I want this Instagram filter” and there you go. So it’s not as easy as retrofitting sandboxing onto the OS. Neither am I claiming it’s easy to solve. What I am saying is the App Store model is largely security theatre.
Shawnecy
8 hours ago
> Linux desktop is not secure at all. Basically anything you install can do anything without limitations.
This is ridiculously false.
Gigachad
7 hours ago
Every traditional package manager I’ve seen installs programs as root and they can do basically everything including adding services to systemd as root, modifying configs in /etc for example.
It’s only the newer stuff like flatpak that bring in some sanity to the installation process.
ajross
13 hours ago
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!".
fragmede
12 hours ago
I like how ML training is the worst thing you can think of and not stealing your identity and bank account information and all your money or seeing nudes or something actually damaging that normal people care about.
spencerchubb
13 hours 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
13 hours 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
13 hours 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-...
StewardMcOy
11 hours 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
7 hours 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
5 hours 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!).
mgraczyk
13 hours ago
FWIW they don't allow developers to self verify any more (as of this year).
StewardMcOy
11 hours 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.