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.
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
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.
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.
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.
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.
> If we'd switch our customers to that clunky, buggy piece of brittle UX bricolage, they start throwing stones.
I mean like... have you tried asking them?
I use the Obsidian app on Android with the default file picker is fine for my usage. I barely even notice it, and as a Syncthing user it ensures I get a native and compatible experience.
This arguing over "safety" when Google's stance is entirely logical does not give me a good feeling about your product. Your job, as a developer that relies on Google and Apple to ship your app, is to jump through their hoops. Grandstanding your userbase doesn't sell new licenses, it makes people question relying on you at any point in the future - it hurts iA's brand more than it hurts Google. As an Obsidian user this basically confirms my suspicion that most SAAS-based Markdown editors are totally overengineered and (apparently) not a reliable choice if you only use the Play Store.
It's your call. Putting up with Apple and Google's bullshit sucks, but it's also literally your job as a provider of support to those platforms. If Google's behavior is enough to make you react like this, I half expect the Windows, iOS and MacOS builds will join Han Solo by the end of the year.
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.
You do not need to request any sort of OS permission or Drive API access to read or write Drive files that are selected using the system document picker. You do need to specify that you want a writable file when you open the picker. The system will grant your app write permission for that file URI only.
> 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.
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.
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.
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.
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).
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.
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!".
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.
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.
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.
I don't know about VSCode, but IntelliJ and Sublime have access to files all over the filesystem (on MacOS). Maybe they once asked me for permissions "to all files" a zillion years ago - I don't remember - but isn't that exactly what the app developer in the article is asking for?
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.
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.
> 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.
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.
While this is true, in practice it's more secure than you'd see on most operating systems.
The reason being that the software is typically from a centralized, trusted repo that has been vetted by maintainers. The software is typically OS and it's not the app developer who releases it to you, the customer. It's the maintainer who packages it and will even apply custom fixes to it.
Yes, there's some trust here. But historically, there's very little examples of rogue Debian maintainers doing something naughty. Whereas on, say, the Play Store, the app dev distributes the App to you and the Play Store just does some preliminary black-box checks. They're not getting the code and packaging it like a debian maintainer would.
Some distros, like Debian, even FORCE app devs to use the system provided libs - they can't statically link their own library code. So they're pinned to a particular version of openSSL, libc, wlroots, libpng, etc. This prevents a huge variety of supply chain attacks. You can't bundle a compromised version of any one of the libs.
And lastly, in stable distros the software typically goes through many routes before landing on a customer device. For debian, you're looking at months of real-world usage in testing and unstable before you see the software. This finds out vulnerabilities - this is why, for example, debian stable never had to deal with the XZ vuln. This isn't true for direct-to-customer app stores.
> 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.
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.
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.)
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.
IMO, these "insufficiencies" should be addressed by safer APIs. The solution here should NOT be to just grant the app file permissions across the board.
For example, Search could be expressed as a separate permission and API operation. I see no reason why you need full file access to do a text search - the OS API can, and should, handle that.
The trouble here is people store all kinds of things in Google Drive, includes photographs. These could easily be exfiltrated to a server. This could cause identity theft, black mail, you name it. Performing a text search IMO is not a good enough justification for the potential risk of that situation.
> For example, Search could be expressed as a separate permission and API operation.
Then maybe after years Google eventually deigns to add a search API, which is great, except you actually also want to do search and replace and they didn't implement that. Or maybe you want to do search and/or replace with regex support, and the new API doesn't support that either.
iggldiggl makes some good points about APIs not being flexible enough, but I also have to ask why go through the complexities of extra APIs? If I'm installing an editor and using it to open my files, I already trust it implicitly with all of my data. That means I also trust it to be reasonably free of RCEs that could modify or exfiltrate my data.
I could see your point if this was some fly-by-night web app accessing Google documents. But this is a native app I'm running on my phone or computer. I may have legitimate reasons to access those photos, to embed them into a document.
> 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.
> 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!).
> 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.
Okay, 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.
> if Google supports this, and if it doesn’t then I agree they should drop the support altogether
Last time I used it, the file picker was by file, not folder, and was fairly janky. By that I mean it was slow and cumbersome to use. Selecting one file was bad enough, let alone multiple.
But selecting an entire folder would definitely be better, assuming that the experience could be much improved. I still think there needs to be a way to bypass it for apps that truly need access to every single file--even at the risk of attackers exploiting the app or the developer deciding to turn evil--but that's getting sidetracked from the real argument. So for now, let's assume I agree that the select a folder solution is perfect.
The real issue is that Google should not be the arbiter of what apps are allowed that kind of access, and they certainly shouldn't be making small developers jump through the expensive, ineffective CASA hoop to get it.
That's the real reason iA's discontinuing development on Android, and they're right to do so. Google Drive should have a permissions model that allows for users to control how much access an app should have. That would solve the issue without the unnecessary bureaucracy, the mistakes (like suggesting an editor be read-only), and added expense that other platforms don't put on third-party developers.
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's not clear why they even need full access to users drives without the users input. Drive offers plenty of apis that let you store and access files that don't require these hoops. There is no security audit required if you pick the scope that only lets you open files the app created. You can also let the user use the OS file picker to open any file.
I get that it's a pain for them to rewrite the integration to use these new scopes, but it's ultimately a huge win that this free for all access has been locked down.
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
It already is illegal to write malware that steals your files. But software is global. Anon individuals in shitty countries don't care about your countries privacy laws.
So we get both privacy laws, and technical restrictions that put the user in control of their files.
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.
The truly scary thing about undiscovered lies is that they have a greater capacity to diminish us than exposed ones. When people cheat in any arena, they diminish themselves-they threaten their own self-esteem and their relationships with others by undermining the trust they have in their ability to succeed and in their ability to be true. Cheating is the most disrespectful thing one human being can do to another. If you aren’t happy in a relationship, end it before starting another one. respect a person who is loyal in a relationship, by cheating on him or her. If you succeed in cheating on someone, don’t think that the person is a fool, realize that the person trusted you much more than you deserve. If you notice any suspicious act on your partner if he or she is cheating. You need to write MR FRED to help you remotely spoof on the target phone to retrieve text messages, call logs, social media activities, bank information and many more. They deliver the best services and get you the peace of mind you deserve. Email: hackxtechn (at) Gm Ail C Om. Best wishes…
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.
> 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.
I am an F-Droid user, and I have only ever seen this a single time, when I first enabled sideloading in a pop-up. Maybe it's only a Samsung thing, but I have never gotten a Play Store nag related to third-party software stores in my life.
That's because everyone is using the google store. If a critical mass of software moved to an <alternative store>, maybe even become cheaper (because that store only takes 20% instead of 30%), people would switch.
It's like chat applications... if most of your friends are using MSN messenger, you'll be using it too... if most of them also use icq, and it's cheaper than MSN, and it also has two more friends that don't use MSN, you'll switch to icq.
Users have basically no reason to move over because they have no problems with the play store. Apps only move over for their own business reasons like saving on fees or avoiding privacy restrictions.
...or avoiding freedom of speech limitations (telegram).
etc.
The problem is, that you now have to go to that services' site, download the apk there and then get promptet "an update is available", download, install, etc., with the benefits of a package management system. You have alternative stores like f-droid, but there are almost no apps there, that would make "normal users" install it... for now. Same for others.
The fees can be avoided by making the subscription on the web ui and then continuing to use the main app.
The speech restrictions maybe have some merit, but right now Telegram basically only restricts extreme hate speech / borderline terrorist content to mobile users. The majority of users don’t care to access this anyway.
Telegram restricts a lot of stuff on the play store version, be it piracy related or just basic news from eg. russian sources or any other country that the EU/US/google doesn't like. App downloaded directly from telegram.org doesn't have such limitations. Considering the pressures from EU, I guess they'll have to censor that too relatively soon... maybe even everything pro-trump. Sometimes you want other news sources than the bbc/cnn.
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.
For apps that use the local system, and after fighting through google's restrictions, syncthing has been a dream between my android, windows + linux systems. I Don't have to think about it.
The restrictions imposed by the platform is why each app needs to have it's own half-implemented sync to it's own platform or some other cloud provider.
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.
I have an opensource android app on the app store. I was a little annoyed/worried that the 'Verify your Play Console Developer account' was going to be super painful since I'm not running a business or trying to make money off my app. The messaging was, shall we say, confusing. They wanted you to choose a verification deadline for some reason. The email talked about a D-U-N-S number, and an official document verifying your identity.
When my verification time came up, I basically didn't have to do anything. I checked a checkbox saying I was an individual, not a business/organization. I didn't have to verify my identity (maybe I did that when I first created the google play account).
Even though my situation was not the same as the OP's, I do have a lot of sympathy for them. Its a pain to distribute apps through the play store (or the app store). I would opt out of there were a real alternative.
We have a similar experience developing for android. They ask us to change things constantly, fill out endless paperwork, most of which is irrelevant to us (we have to verify a payments account for our free, ad free, no in app sales app). Every so often it's a random change to requirements around this permission or that, or more information needed for a security or data policy.
Why do the apps even need direct access to Google drive? Android should give a generic API to access a folder with files and whether this folder lives in local storage or Google drive or even another provider should be the user's decision.
This seems ok at first glance, and you can “kind of” get this feeling. And android and iOS you can bring up a generic file picker that will let the user select any file or save a file to a user chosen location, and then the application gets access to an opaque file handle to read/write there. Platforms like Google Drive, Box, DropBox, OneDrive and local files are all options here.
Unfortunately as far as I remember there is no way to gain access to that location persistently. Your copy of the file through this mechanism is just a copy of that file, so I couldn’t say have 50 files in my app that I granted access to being in some file system location that syncs (like google drive) without having constantly be repicking that file location.
There is. At least on iOS, your google drive files show up in the Files app as well as in the OS file picker. They are just as accessible as locally stored files.
Any app which can open files can open files stored on Google Drive. What apps can't do is open files the app did not create, without the users input, without getting a security audit. Which seems perfectly fine to me.
I think the main issue is it's just different to how it was before and Google won't be grandfathering in old apps. So you have to rebuild the integrations to use the new APIs which mostly let you do the same thing but it's still not a trivial drop in replacement.
Casa approval is a necessary step, we have gone through that for one of our apps approval that requires Google drive write access.
Yes you are essentially asking users to give a whole lot of information because giving access to Google drive technically also gives access to a lot of the Gmail attachments because people tend to save them in Google drive.
You can't fault Google with being trying to be too careful. If you think this was painful try accessing the shopify marketplace.
Wow. This is unbelievable. I'm wondering about creating only a PWA or building Android + iOS apps and this article made me decide with going PWA-only, I'm not going to deal with this. The competition in the official app stores is so big that it is not really worth it anyway
This is all downstream of stuff like the Cambridge Analytica scandal - the public views misuse of these APIs as the fault of the institution so they’re now incredibly cautious about access.
I really would have expected an app like iA to not depend on either Google or Apple's sync - because both suck in their own rights. iCloud is just technically inferior by the way - I mean most of the time it's a coin toss on whether and how it works even for their own usage like iCloud Tabs, iCloud Messages and Photos and what not.
As of now I try to avoid any app that is married to either Google (drive or whatever is the latest there) or Apple (iCloud) sync. Because my experience with these has been really inferior. Anyway that means I have to either use a Google a/c which I do not use anymore for personal needs or iCloud which is clearly inferior.
Imho it's better to offer an e2ee custom server wherever you can (preferably on top of some open standard/spec). I am past "but I would rather trust robustness of Google and Apple's backend" after these 3-4 years.
And I can completely relate to the pain of supporting all those Android models and their sub-models and their sub-sub-models. It used to be a real nightmare when I had to deal with that.
----------
Having said - I have felt the might of these big companies in a very small way recently. My Play Store account (which I kept for learning/testing purposes - sharing apps among friends etc) was terminated even though I fulfilled the criteria 2 days before the last date. No refund was provided either because I could not find out how to add a bank account and they didn't share even though I had asked them 3 weeks in advance for that info. I would ask "how to add a bank account" and they would reply with the same text "… please add a bank account for refund…" and I would again immediately reply asking "..but how the hell I can add a bank account - there is no info on this in your docs and whatever I could find doesn't even apply because I can't see those settings in the first place"… and they would respond with the exact same text again and again and again. I checked - I was indeed communicating with humans.
After the last day I received the final response: "…was deleted..requirement... T&C.. and there will be no further response". That was it.
Are you sure that's still true? iCloud use to have its issues, no doubt. I don't remember the last time I had to deal with any of that. It's been a couple years at least.
Supporting the play store is increasingly not worth the trouble. It's already questionable from a revenue standpoint and they're making it an ever more hostile place for all but the biggest corporate developers.
Funny Google requires a phone and email for Play Store users to contact, yet most of the major apps contact email addresses are "we dont read this; No Reply. But here is our crappy forum"
This mirrors my experience with Android, ported a game, jumped through all the regulatory hoops, got in on the app store, then endless bureaucratic nonsense to keep it there.
I'm (or was) a hobbyist programmer on Android. I have a handful of free apps but Google has made it so onerous to actually get things in the store these days. I've given up; it may be worth the time of a big software studio to handle all the busywork they make you do these days, but it certainly isn't for a hobbyist. Yes, I know Apple is supposed to be even worse, but Android was supposed to be the reasonable platform in regard to this nonsense.
>"In order to get our users full access to their Google Drive on their devices, we now needed to pass a yearly CASA (Cloud Application Security Assessment) audit. This requires hiring a third-party vendor like KPMG."
This is just plain extortion. I am curious how much masqueraded kickbacks Google gets from those auditors.
There are few things more depressing than having to deal with companies like Accenture, EY, KPMG etc. It's a world of FUD, upsell, more consultants, nothing getting done, lots of slides, new "junior senior Global Consultant for Microservices" type stuff. They are literally a cancer on innovation and just getting things done.
They destroy the ethos of a company through deliberate intransigence.
AI alwayd ahd a pretty major apple lean, and from the post's misunderstanding of google drive permissions (global vs file scopes), it's clear that is still true. About not to matter though since they are killing the android app.
It's a pity systems like remotestorage.io or Tim Berners-Lee's Solid hasn't gotten serious traction.
Ideally there wouldn't even be Google Drive integration! Ideally we'd just have a mount on our devices that syncs. This is how I use Logseq, for example. It's a little weird and frustrating that mobile phones seem to lack virtual filesystem support (like FUSE), so the sync app in use is just rsyncing to local storage, basically, which is kind of fine, but it means there's no chance to have say my home movies collection available directly from my phone.
This story isn't really one about Android or mobile, but the general beatdown on mobile really squaders what should be the most impressive expansive electronic device to have filled the world.
I don't know why anybody develops anything for these scumbag companies (Apple and Google). There's plenty of money to be made making software for the web. I have never written a single line of Android or iOS code and have had a very successful career so far. Supporting these companies is a choice.
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.
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.
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.
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
If that's the case then a $700 bond would be sufficient
Who is paying the security auditor then?
That's the point, the security auditor is providing any service other than being a barrier.
Do you think this may allow us to reintegrate the security auditor back into the productive workforce after a brief period of adjustment?
> 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.
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.
Yeah it's maddening.
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.
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.
This is funny but he actually was right
Happy to have you point anywhere my assumptions are wrong vs. your random bullshit of a creating writing exercise.
Perhaps Google should have pointed this out in its review instead of just recommending read-only access.
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.
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.
> "Google pushes business decisions under the disguise of 'improvements'"
...while systematically sabotaging design improvements under the disguise of "strategy". Ask people on the Android design team.
> If we'd switch our customers to that clunky, buggy piece of brittle UX bricolage, they start throwing stones.
I mean like... have you tried asking them?
I use the Obsidian app on Android with the default file picker is fine for my usage. I barely even notice it, and as a Syncthing user it ensures I get a native and compatible experience.
This arguing over "safety" when Google's stance is entirely logical does not give me a good feeling about your product. Your job, as a developer that relies on Google and Apple to ship your app, is to jump through their hoops. Grandstanding your userbase doesn't sell new licenses, it makes people question relying on you at any point in the future - it hurts iA's brand more than it hurts Google. As an Obsidian user this basically confirms my suspicion that most SAAS-based Markdown editors are totally overengineered and (apparently) not a reliable choice if you only use the Play Store.
It's your call. Putting up with Apple and Google's bullshit sucks, but it's also literally your job as a provider of support to those platforms. If Google's behavior is enough to make you react like this, I half expect the Windows, iOS and MacOS builds will join Han Solo by the end of the year.
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.
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.
The user can use a file picker to select individual files as well.
>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?
You do not need to request any sort of OS permission or Drive API access to read or write Drive files that are selected using the system document picker. You do need to specify that you want a writable file when you open the picker. The system will grant your app write permission for that file URI only.
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.
Only if you absolutely insist on creating your own special snowflake file picker UI instead of using the OS file picker
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?
The iOS file picker does have a recent files tab and it seems to be the first one that opens.
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.
> 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.
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.
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.
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.
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).
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.
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!".
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.
I was trying to be trendy and hip and avoid hyperbole. But yeah, that too. Also boring stuff like corporate espionage and malware distribution.
Are you assuming that the ML company does not sell its training data to scammers or others that will sell to scammers?
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.
> 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?
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.
I don't know about VSCode, but IntelliJ and Sublime have access to files all over the filesystem (on MacOS). Maybe they once asked me for permissions "to all files" a zillion years ago - I don't remember - but isn't that exactly what the app developer in the article is asking for?
Primarily vim or VSCode, why?
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.
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.
> 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.
> Linux desktop is not secure at all. Basically anything you install can do anything without limitations.
This is ridiculously false.
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.
While this is true, in practice it's more secure than you'd see on most operating systems.
The reason being that the software is typically from a centralized, trusted repo that has been vetted by maintainers. The software is typically OS and it's not the app developer who releases it to you, the customer. It's the maintainer who packages it and will even apply custom fixes to it.
Yes, there's some trust here. But historically, there's very little examples of rogue Debian maintainers doing something naughty. Whereas on, say, the Play Store, the app dev distributes the App to you and the Play Store just does some preliminary black-box checks. They're not getting the code and packaging it like a debian maintainer would.
Some distros, like Debian, even FORCE app devs to use the system provided libs - they can't statically link their own library code. So they're pinned to a particular version of openSSL, libc, wlroots, libpng, etc. This prevents a huge variety of supply chain attacks. You can't bundle a compromised version of any one of the libs.
And lastly, in stable distros the software typically goes through many routes before landing on a customer device. For debian, you're looking at months of real-world usage in testing and unstable before you see the software. This finds out vulnerabilities - this is why, for example, debian stable never had to deal with the XZ vuln. This isn't true for direct-to-customer app stores.
> 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.
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.
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.
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.
I’d expect something similar on Android actually – there is the relevant API at least.
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.
> 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-...
> 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.
IMO, these "insufficiencies" should be addressed by safer APIs. The solution here should NOT be to just grant the app file permissions across the board.
For example, Search could be expressed as a separate permission and API operation. I see no reason why you need full file access to do a text search - the OS API can, and should, handle that.
The trouble here is people store all kinds of things in Google Drive, includes photographs. These could easily be exfiltrated to a server. This could cause identity theft, black mail, you name it. Performing a text search IMO is not a good enough justification for the potential risk of that situation.
> For example, Search could be expressed as a separate permission and API operation.
Then maybe after years Google eventually deigns to add a search API, which is great, except you actually also want to do search and replace and they didn't implement that. Or maybe you want to do search and/or replace with regex support, and the new API doesn't support that either.
iggldiggl makes some good points about APIs not being flexible enough, but I also have to ask why go through the complexities of extra APIs? If I'm installing an editor and using it to open my files, I already trust it implicitly with all of my data. That means I also trust it to be reasonably free of RCEs that could modify or exfiltrate my data.
I could see your point if this was some fly-by-night web app accessing Google documents. But this is a native app I'm running on my phone or computer. I may have legitimate reasons to access those photos, to embed them into a document.
> 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.
> 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!).
This is changing on Desktop, at least Linux. See flatpak, Wayland, and freedesktop portals.
> 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.
Okay, 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.
> if Google supports this, and if it doesn’t then I agree they should drop the support altogether
Last time I used it, the file picker was by file, not folder, and was fairly janky. By that I mean it was slow and cumbersome to use. Selecting one file was bad enough, let alone multiple.
But selecting an entire folder would definitely be better, assuming that the experience could be much improved. I still think there needs to be a way to bypass it for apps that truly need access to every single file--even at the risk of attackers exploiting the app or the developer deciding to turn evil--but that's getting sidetracked from the real argument. So for now, let's assume I agree that the select a folder solution is perfect.
The real issue is that Google should not be the arbiter of what apps are allowed that kind of access, and they certainly shouldn't be making small developers jump through the expensive, ineffective CASA hoop to get it.
That's the real reason iA's discontinuing development on Android, and they're right to do so. Google Drive should have a permissions model that allows for users to control how much access an app should have. That would solve the issue without the unnecessary bureaucracy, the mistakes (like suggesting an editor be read-only), and added expense that other platforms don't put on third-party developers.
FWIW they don't allow developers to self verify any more (as of this year).
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.
thanks, missed that!
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.
[1] https://developers.google.com/drive/api/guides/api-specific-...
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's not clear why they even need full access to users drives without the users input. Drive offers plenty of apis that let you store and access files that don't require these hoops. There is no security audit required if you pick the scope that only lets you open files the app created. You can also let the user use the OS file picker to open any file.
I get that it's a pain for them to rewrite the integration to use these new scopes, but it's ultimately a huge win that this free for all access has been locked down.
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
It already is illegal to write malware that steals your files. But software is global. Anon individuals in shitty countries don't care about your countries privacy laws.
So we get both privacy laws, and technical restrictions that put the user in control of their files.
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.
(1) https://www.thequint.com/news/india/bbc-chinese-loan-app-doc...
The world would benefit of a better solution that is for the Indian Justice system deal with the issue.
Or you just put the burden on the developer who has a very high interest in jumping through hoops since money is on the other end.
Perhaps, but we must all play the cards we are dealt.
The truly scary thing about undiscovered lies is that they have a greater capacity to diminish us than exposed ones. When people cheat in any arena, they diminish themselves-they threaten their own self-esteem and their relationships with others by undermining the trust they have in their ability to succeed and in their ability to be true. Cheating is the most disrespectful thing one human being can do to another. If you aren’t happy in a relationship, end it before starting another one. respect a person who is loyal in a relationship, by cheating on him or her. If you succeed in cheating on someone, don’t think that the person is a fool, realize that the person trusted you much more than you deserve. If you notice any suspicious act on your partner if he or she is cheating. You need to write MR FRED to help you remotely spoof on the target phone to retrieve text messages, call logs, social media activities, bank information and many more. They deliver the best services and get you the peace of mind you deserve. Email: hackxtechn (at) Gm Ail C Om. Best wishes…
In short, Google bureacratized them almost to death over Google Drive access, and then offered up a solution where they pay KPMG for an annual audit.
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.
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?
https://en.wikipedia.org/wiki/List_of_Android_app_stores
You get a lot of organic installs from Google Play Store, and almost none from alternative stores like Huawei or Amazon Store.
This is because it is where there is the traffic.
Not all stores are created equal.
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.
> 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.
I am an F-Droid user, and I have only ever seen this a single time, when I first enabled sideloading in a pop-up. Maybe it's only a Samsung thing, but I have never gotten a Play Store nag related to third-party software stores in my life.
Can confirm, only issue to me sometimes is managing updates.
Do those fdroid installed apps auto update?
As of v1.19 and Android 12, yes. That's not a nag regardless.
So that change was in February 2024 and only for Android 12 and above which is <50% of the Android market.
If you don't believe this is deliberate nagging I don't know what to tell you.
I used iOS before Android, I know what nags look like.
Many do these days, actually.
Ask Epic Games. The short answer is that you will not make very much money from your Android app if it isn't in Google's store.
That's because everyone is using the google store. If a critical mass of software moved to an <alternative store>, maybe even become cheaper (because that store only takes 20% instead of 30%), people would switch.
It's like chat applications... if most of your friends are using MSN messenger, you'll be using it too... if most of them also use icq, and it's cheaper than MSN, and it also has two more friends that don't use MSN, you'll switch to icq.
Users have basically no reason to move over because they have no problems with the play store. Apps only move over for their own business reasons like saving on fees or avoiding privacy restrictions.
...or avoiding google fees for in app purchases.
...or avoiding freedom of speech limitations (telegram).
etc.
The problem is, that you now have to go to that services' site, download the apk there and then get promptet "an update is available", download, install, etc., with the benefits of a package management system. You have alternative stores like f-droid, but there are almost no apps there, that would make "normal users" install it... for now. Same for others.
The fees can be avoided by making the subscription on the web ui and then continuing to use the main app.
The speech restrictions maybe have some merit, but right now Telegram basically only restricts extreme hate speech / borderline terrorist content to mobile users. The majority of users don’t care to access this anyway.
Telegram restricts a lot of stuff on the play store version, be it piracy related or just basic news from eg. russian sources or any other country that the EU/US/google doesn't like. App downloaded directly from telegram.org doesn't have such limitations. Considering the pressures from EU, I guess they'll have to censor that too relatively soon... maybe even everything pro-trump. Sometimes you want other news sources than the bbc/cnn.
Which actually violates Google Play terms of service, and runs the risk of having your account and your apps permanently delisted.
I ended up converting links to my Github sponsorship page to a page that accepts donations through Google Play over concerns about exactly this.
you need a store where the cost to use it in parallel is so low that companies are willing to take the chance.
One of those costs imposters and bad players using the alternative store.
I would settle for apps proving the files for sideloading on their website, and the vast majority wont even do that.
I've tried a couple of alternate stores, including Amazon's store. Absolutely zero revenue. And insane amounts of paperwork.
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.
https://www.youtube.com/watch?v=C28pvd2plBA
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.
What would that workflow look like - users copy their files from Drive to their device, edit them, and then put them back on Drive?
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.
Bring-your-own-sync!
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.
That sounds miserable. This is why apps end up enshittified with forced cloud services.
For apps that use the local system, and after fighting through google's restrictions, syncthing has been a dream between my android, windows + linux systems. I Don't have to think about it.
The restrictions imposed by the platform is why each app needs to have it's own half-implemented sync to it's own platform or some other cloud provider.
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.
I have an opensource android app on the app store. I was a little annoyed/worried that the 'Verify your Play Console Developer account' was going to be super painful since I'm not running a business or trying to make money off my app. The messaging was, shall we say, confusing. They wanted you to choose a verification deadline for some reason. The email talked about a D-U-N-S number, and an official document verifying your identity.
When my verification time came up, I basically didn't have to do anything. I checked a checkbox saying I was an individual, not a business/organization. I didn't have to verify my identity (maybe I did that when I first created the google play account).
Even though my situation was not the same as the OP's, I do have a lot of sympathy for them. Its a pain to distribute apps through the play store (or the app store). I would opt out of there were a real alternative.
We have a similar experience developing for android. They ask us to change things constantly, fill out endless paperwork, most of which is irrelevant to us (we have to verify a payments account for our free, ad free, no in app sales app). Every so often it's a random change to requirements around this permission or that, or more information needed for a security or data policy.
Why do the apps even need direct access to Google drive? Android should give a generic API to access a folder with files and whether this folder lives in local storage or Google drive or even another provider should be the user's decision.
It has, it is called Storage Access Framework, but many still don't accept that is the way of the future in sandboxed OSes.
https://developer.android.com/guide/topics/providers/documen...
Yeah, the way of the future that amongst other things immediately breaks all and any file formats that don't consist of a single atomic file.
This seems ok at first glance, and you can “kind of” get this feeling. And android and iOS you can bring up a generic file picker that will let the user select any file or save a file to a user chosen location, and then the application gets access to an opaque file handle to read/write there. Platforms like Google Drive, Box, DropBox, OneDrive and local files are all options here.
Unfortunately as far as I remember there is no way to gain access to that location persistently. Your copy of the file through this mechanism is just a copy of that file, so I couldn’t say have 50 files in my app that I granted access to being in some file system location that syncs (like google drive) without having constantly be repicking that file location.
On iOS, an app has access to its own folder in at least iCloud Drive that can be accessed via the app or via the Files App.
Google drive also has this functionality where apps can persistently access any files they created.
There are a ton of options here that don’t involve unlimited access to all files.
I don't know about iCloud, but on Drive there is no way to see those files outside the app, it really limits what you can do as a user.
Not to mention that it likely means that iA's own apps on other platforms can't access those files either. So much for the cloud.
There is. At least on iOS, your google drive files show up in the Files app as well as in the OS file picker. They are just as accessible as locally stored files.
Any app which can open files can open files stored on Google Drive. What apps can't do is open files the app did not create, without the users input, without getting a security audit. Which seems perfectly fine to me.
What is possible on one platform is not necessarily possible on another. The focus of this discussion is on Android.
I charitably assume Android has a file picker. I just don't have a device to verify it with.
It has via SAF, which is the right way on modern Android, but op apparently isn't keen in using it.
ElI5: what is the problem then? Why would I want to give a random app access to all of my files on Google Drive?
I think the main issue is it's just different to how it was before and Google won't be grandfathering in old apps. So you have to rebuild the integrations to use the new APIs which mostly let you do the same thing but it's still not a trivial drop in replacement.
I don't use the app but my guess the point is to be able to keep a paper you're writing synchronized across multiple devices.
Casa approval is a necessary step, we have gone through that for one of our apps approval that requires Google drive write access.
Yes you are essentially asking users to give a whole lot of information because giving access to Google drive technically also gives access to a lot of the Gmail attachments because people tend to save them in Google drive.
You can't fault Google with being trying to be too careful. If you think this was painful try accessing the shopify marketplace.
Wow. This is unbelievable. I'm wondering about creating only a PWA or building Android + iOS apps and this article made me decide with going PWA-only, I'm not going to deal with this. The competition in the official app stores is so big that it is not really worth it anyway
This is all downstream of stuff like the Cambridge Analytica scandal - the public views misuse of these APIs as the fault of the institution so they’re now incredibly cautious about access.
> Cambridge Analytica scandal
Would it be considered a scandal if happened in 2022.
I really would have expected an app like iA to not depend on either Google or Apple's sync - because both suck in their own rights. iCloud is just technically inferior by the way - I mean most of the time it's a coin toss on whether and how it works even for their own usage like iCloud Tabs, iCloud Messages and Photos and what not.
As of now I try to avoid any app that is married to either Google (drive or whatever is the latest there) or Apple (iCloud) sync. Because my experience with these has been really inferior. Anyway that means I have to either use a Google a/c which I do not use anymore for personal needs or iCloud which is clearly inferior.
Imho it's better to offer an e2ee custom server wherever you can (preferably on top of some open standard/spec). I am past "but I would rather trust robustness of Google and Apple's backend" after these 3-4 years.
And I can completely relate to the pain of supporting all those Android models and their sub-models and their sub-sub-models. It used to be a real nightmare when I had to deal with that.
----------
Having said - I have felt the might of these big companies in a very small way recently. My Play Store account (which I kept for learning/testing purposes - sharing apps among friends etc) was terminated even though I fulfilled the criteria 2 days before the last date. No refund was provided either because I could not find out how to add a bank account and they didn't share even though I had asked them 3 weeks in advance for that info. I would ask "how to add a bank account" and they would reply with the same text "… please add a bank account for refund…" and I would again immediately reply asking "..but how the hell I can add a bank account - there is no info on this in your docs and whatever I could find doesn't even apply because I can't see those settings in the first place"… and they would respond with the exact same text again and again and again. I checked - I was indeed communicating with humans.
After the last day I received the final response: "…was deleted..requirement... T&C.. and there will be no further response". That was it.
Are you sure that's still true? iCloud use to have its issues, no doubt. I don't remember the last time I had to deal with any of that. It's been a couple years at least.
Yes I am sure and it is still true.
They’re removing API access to Google Photos as well now the only “integration” is for other apps to open the Google Photos app https://news.ycombinator.com/item?id=41604241
Supporting the play store is increasingly not worth the trouble. It's already questionable from a revenue standpoint and they're making it an ever more hostile place for all but the biggest corporate developers.
Funny Google requires a phone and email for Play Store users to contact, yet most of the major apps contact email addresses are "we dont read this; No Reply. But here is our crappy forum"
This mirrors my experience with Android, ported a game, jumped through all the regulatory hoops, got in on the app store, then endless bureaucratic nonsense to keep it there.
I'm (or was) a hobbyist programmer on Android. I have a handful of free apps but Google has made it so onerous to actually get things in the store these days. I've given up; it may be worth the time of a big software studio to handle all the busywork they make you do these days, but it certainly isn't for a hobbyist. Yes, I know Apple is supposed to be even worse, but Android was supposed to be the reasonable platform in regard to this nonsense.
>"In order to get our users full access to their Google Drive on their devices, we now needed to pass a yearly CASA (Cloud Application Security Assessment) audit. This requires hiring a third-party vendor like KPMG."
This is just plain extortion. I am curious how much masqueraded kickbacks Google gets from those auditors.
There are few things more depressing than having to deal with companies like Accenture, EY, KPMG etc. It's a world of FUD, upsell, more consultants, nothing getting done, lots of slides, new "junior senior Global Consultant for Microservices" type stuff. They are literally a cancer on innovation and just getting things done.
They destroy the ethos of a company through deliberate intransigence.
> And before anyone says this is the price of an “open” OS—well, we don’t have this problem on Windows.5
Cue drum roll...
AI alwayd ahd a pretty major apple lean, and from the post's misunderstanding of google drive permissions (global vs file scopes), it's clear that is still true. About not to matter though since they are killing the android app.
Progressive Web App.
you don't need app stores
Just move everything to your own storage instead of Google Drive. And maybe have your desktop or web app interface with Google drive.
Sounds like Google has turned into Nokia. History repeats itself.
It's a pity systems like remotestorage.io or Tim Berners-Lee's Solid hasn't gotten serious traction.
Ideally there wouldn't even be Google Drive integration! Ideally we'd just have a mount on our devices that syncs. This is how I use Logseq, for example. It's a little weird and frustrating that mobile phones seem to lack virtual filesystem support (like FUSE), so the sync app in use is just rsyncing to local storage, basically, which is kind of fine, but it means there's no chance to have say my home movies collection available directly from my phone.
This story isn't really one about Android or mobile, but the general beatdown on mobile really squaders what should be the most impressive expansive electronic device to have filled the world.
I don't know why anybody develops anything for these scumbag companies (Apple and Google). There's plenty of money to be made making software for the web. I have never written a single line of Android or iOS code and have had a very successful career so far. Supporting these companies is a choice.