While not the main point of the article, this footnote really caught my attention and made me further appreciate paid alternatives like Kagi. Perhaps I need to pay for more apps.
While not the main point of the article, this footnote really caught my attention and made me further appreciate paid alternatives like Kagi. Perhaps I need to pay for more apps.
Google’s chaos makes Apple’s control seem reasonable. I can already hear John and Seb typing: “…and this is why the EU shouldn’t turn Apple into Google.” Let’s be real—Google Play and the App Store don’t compete. They collaborate. Same rates, same model, same unchecked power. Call it a monopoly, call it a duopoly. They share the mobile market without too much crossfire: Apple takes those who can or want to pay, Google takes the rest. Google Play is not an alternative to the App Store. It’s not “Go there if you don’t like Apple.” Google Play is a very lazy, very sloppy carbon copy of the App Store. Their collaboration is not metaphorical. It goes beyond the way their shared control over the mobile app market. Apple collects privacy points, then cashes them in by making Google the default search on iPhone. A lot of that privacy-free Search money flows right back from Google to Apple. 20 Billion USD in 2022. In 2020, “Google’s payments to Apple constituted 17.5% of the iPhone maker’s operating income.” (Bloomberg) And no one really cares, as long as it’s convenient. But as a developer in Europe, we’re glad that the EU does.
(emphasis mine)
Based on discussion on Hacker News, what’s going on is that Google is tightening security so that most apps that use Google Drive are required to use the system dialog and only have access to...
Based on discussion on Hacker News, what’s going on is that Google is tightening security so that most apps that use Google Drive are required to use the system dialog and only have access to their own files, instead of being able to read and write all your files like they could before. This breaks some apps that don’t fit the paradigm and they’re only willing to grant an exception if you jump through some hoops to show that your code isn’t doing anything nefarious.
And as usual they aren’t explaining it very well.
I think for small developers, nerfing the app is the way to go. Don’t treat Google Drive as a traditional file system anymore. It’s just a document store that lets you arrange documents in folders.
I’m reminded of how Google doesn’t play by these rules on iOS. You can’t use the Google Photos app without granting access to all your photos; even though iOS lets you grant it selective access, it refuses to work. The only way to avoid it is to use the Google Photos website instead.
This "tightening security" is especially abhorrent to me, as it doesn't let Drive be used as, well, a drive. There is not a single time in my life I thought "Gee, I wish the only way things could...
This "tightening security" is especially abhorrent to me, as it doesn't let Drive be used as, well, a drive. There is not a single time in my life I thought "Gee, I wish the only way things could access my drive is via a tightly controlled API and direct integration with Google." In fact, almost every use case I have for drive is better served by mounting the entire thing as a filesystem, which is frankly how Android should handle it. Of course, that makes it harder for Google to monetize every single aspect of every single service they provide.
Android's filesystem model has also been completely and utterly destroyed by trying to "fix" the security. Best I can tell, it's almost impossible to properly grant permissions for apps to access any file anymore, or to choose where files can be put. This makes it insanely difficult to do things that are easy on Linux.
Ready to fix the filesystem model? All apps are now docker containers. When you install an app, you can choose what folders it has access to, read or write. All cloud providers are mounted as a root-level folder, and you could throw up a warning to users (hey choosing this folder gives access to every file on Drive, if you don't trust this app, create a new folder for it).
This is a lot like the model used that’s been used by macOS for a while now, except instead of choosing the folders/files an app has access to at install, it’s done on demand (the system freezes...
Ready to fix the filesystem model? All apps are now docker containers. When you install an app, you can choose what folders it has access to, read or write.
This is a lot like the model used that’s been used by macOS for a while now, except instead of choosing the folders/files an app has access to at install, it’s done on demand (the system freezes the app until the user has approved/denied). It’s far from perfect but I appreciate knowing when apps are poking around parts of my file system I didn’t ask them to.
Exactly the kinds of restrictions that make my life on what little of iOS I have to use such a pain, are slowly coming to an Android near you. I haven't run into anything insurmountable with...
Exactly the kinds of restrictions that make my life on what little of iOS I have to use such a pain, are slowly coming to an Android near you. I haven't run into anything insurmountable with Android Storage Scopes yet, we'll see if they're more annoying in the next major release, which is quite soon now
I'm not familiar with this app. I do wonder why drive access is a pre-requisite for their use case? Is it just that they need cloud storage? I think this means there's a market for a storage...
I'm not familiar with this app. I do wonder why drive access is a pre-requisite for their use case? Is it just that they need cloud storage?
I think this means there's a market for a storage provider who sells access to developers, not users, and has a reasonable data management privacy strategy. If if gets them out of processes that cost them in excess of 1/6 of their revenue, then it's probably a win even if the developer absorbs the cost.
If the issue is that people then want their stuff synced to drive, perhaps the provider could do it on the back end on the developer's or end user's behalf. Basically become a sane wrapper around the drive API.
There are a good number of cloud storage providers that do the job easily enough from the dev perspective, so it’ll be that Google Drive sync specifically is a user need here - which I can...
There are a good number of cloud storage providers that do the job easily enough from the dev perspective, so it’ll be that Google Drive sync specifically is a user need here - which I can understand, I’d want my documents to go into a system that’s (at least nominally) under my control and platform/device agnostic rather than being tied to a specific writing app.
Server side sync would actually make Google’s policy objections more reasonable here: in that situation, the company really would be accessing Drive on the user’s behalf and the data security implications would be more significant. The hoops to jump through to convince Google to grant that API access would be at best the same as they are now, and at worst significantly more onerous.
It sounds like the problem here is they’re having to jump through those hoops even to allow users on-device access to their own Drive storage via the app, that the requirements aren’t reasonable or logical, and that the processes in place for the developer to meet the requirements and/or communicate with Google about the issue are broken.
I believe it’s a text editor. Which files you can edit with a text editor can be a bit blurry. The way many developer tools work is that you open a project directory (not a file), all those files...
I believe it’s a text editor. Which files you can edit with a text editor can be a bit blurry. The way many developer tools work is that you open a project directory (not a file), all those files appear in the UI, and the tool can edit any files within that directory. A text editor can do search and replace over all your files, for example. This paradigm is what I think of as the Unix way and it’s used by essentially all developer tools, including those for Android, running on desktop OSes.
Another paradigm (introduced by the Mac, I believe) is that a project is a document and each document type is associated with a single application. You open documents with the app for that type. This is limited, but there are alternative ways of sharing data between apps, like cut and paste. Android also has an Intent system for sharing data between apps. This sort of sharing is more under user control - there is UI for it and the app can’t do it invisibly behind the scenes.
The Unix way of doing things doesn’t work very well when you can’t trust your text editor and other tools you use. Google seems to have decided that Google Drive is a document store and that apps that work like a developer tool are suspicious. They want the source code to be audited for tools like that.
I suspect that Google knows more about what malware is doing on people’s phones than we do, they’re pretty appalled by it, and this is an attempt to get it under control by tightening permissions. But power users and the app developers that cater to them are annoyed by it.
This is just one of the ways that mobile OSes are not like desktop OSes. Mobile apps have more restrictive permissions that make them safer for the masses. The wide-open permissions that apps had on Google Drive were kind of a loophole.
I suspect that the future for the Unix way is running in a sandbox. An example is Linux on ChromeOS where Linux runs in a VM. Developers do things that way and everything else runs in a more locked-down OS that makes it safe for people to do their banking on the same machine.
And the developer way of sharing data in the cloud is GitHub (and its competitors). Too difficult for normal users, but not bad once you’re used to it.
While not the main point of the article, this footnote really caught my attention and made me further appreciate paid alternatives like Kagi. Perhaps I need to pay for more apps.
Based on discussion on Hacker News, what’s going on is that Google is tightening security so that most apps that use Google Drive are required to use the system dialog and only have access to their own files, instead of being able to read and write all your files like they could before. This breaks some apps that don’t fit the paradigm and they’re only willing to grant an exception if you jump through some hoops to show that your code isn’t doing anything nefarious.
And as usual they aren’t explaining it very well.
I think for small developers, nerfing the app is the way to go. Don’t treat Google Drive as a traditional file system anymore. It’s just a document store that lets you arrange documents in folders.
I’m reminded of how Google doesn’t play by these rules on iOS. You can’t use the Google Photos app without granting access to all your photos; even though iOS lets you grant it selective access, it refuses to work. The only way to avoid it is to use the Google Photos website instead.
This "tightening security" is especially abhorrent to me, as it doesn't let Drive be used as, well, a drive. There is not a single time in my life I thought "Gee, I wish the only way things could access my drive is via a tightly controlled API and direct integration with Google." In fact, almost every use case I have for drive is better served by mounting the entire thing as a filesystem, which is frankly how Android should handle it. Of course, that makes it harder for Google to monetize every single aspect of every single service they provide.
Android's filesystem model has also been completely and utterly destroyed by trying to "fix" the security. Best I can tell, it's almost impossible to properly grant permissions for apps to access any file anymore, or to choose where files can be put. This makes it insanely difficult to do things that are easy on Linux.
Ready to fix the filesystem model? All apps are now docker containers. When you install an app, you can choose what folders it has access to, read or write. All cloud providers are mounted as a root-level folder, and you could throw up a warning to users (hey choosing this folder gives access to every file on Drive, if you don't trust this app, create a new folder for it).
This is a lot like the model used that’s been used by macOS for a while now, except instead of choosing the folders/files an app has access to at install, it’s done on demand (the system freezes the app until the user has approved/denied). It’s far from perfect but I appreciate knowing when apps are poking around parts of my file system I didn’t ask them to.
Exactly the kinds of restrictions that make my life on what little of iOS I have to use such a pain, are slowly coming to an Android near you. I haven't run into anything insurmountable with Android Storage Scopes yet, we'll see if they're more annoying in the next major release, which is quite soon now
I'm not familiar with this app. I do wonder why drive access is a pre-requisite for their use case? Is it just that they need cloud storage?
I think this means there's a market for a storage provider who sells access to developers, not users, and has a reasonable data management privacy strategy. If if gets them out of processes that cost them in excess of 1/6 of their revenue, then it's probably a win even if the developer absorbs the cost.
If the issue is that people then want their stuff synced to drive, perhaps the provider could do it on the back end on the developer's or end user's behalf. Basically become a sane wrapper around the drive API.
There are a good number of cloud storage providers that do the job easily enough from the dev perspective, so it’ll be that Google Drive sync specifically is a user need here - which I can understand, I’d want my documents to go into a system that’s (at least nominally) under my control and platform/device agnostic rather than being tied to a specific writing app.
Server side sync would actually make Google’s policy objections more reasonable here: in that situation, the company really would be accessing Drive on the user’s behalf and the data security implications would be more significant. The hoops to jump through to convince Google to grant that API access would be at best the same as they are now, and at worst significantly more onerous.
It sounds like the problem here is they’re having to jump through those hoops even to allow users on-device access to their own Drive storage via the app, that the requirements aren’t reasonable or logical, and that the processes in place for the developer to meet the requirements and/or communicate with Google about the issue are broken.
I believe it’s a text editor. Which files you can edit with a text editor can be a bit blurry. The way many developer tools work is that you open a project directory (not a file), all those files appear in the UI, and the tool can edit any files within that directory. A text editor can do search and replace over all your files, for example. This paradigm is what I think of as the Unix way and it’s used by essentially all developer tools, including those for Android, running on desktop OSes.
Another paradigm (introduced by the Mac, I believe) is that a project is a document and each document type is associated with a single application. You open documents with the app for that type. This is limited, but there are alternative ways of sharing data between apps, like cut and paste. Android also has an Intent system for sharing data between apps. This sort of sharing is more under user control - there is UI for it and the app can’t do it invisibly behind the scenes.
The Unix way of doing things doesn’t work very well when you can’t trust your text editor and other tools you use. Google seems to have decided that Google Drive is a document store and that apps that work like a developer tool are suspicious. They want the source code to be audited for tools like that.
I suspect that Google knows more about what malware is doing on people’s phones than we do, they’re pretty appalled by it, and this is an attempt to get it under control by tightening permissions. But power users and the app developers that cater to them are annoyed by it.
This is just one of the ways that mobile OSes are not like desktop OSes. Mobile apps have more restrictive permissions that make them safer for the masses. The wide-open permissions that apps had on Google Drive were kind of a loophole.
I suspect that the future for the Unix way is running in a sandbox. An example is Linux on ChromeOS where Linux runs in a VM. Developers do things that way and everything else runs in a more locked-down OS that makes it safe for people to do their banking on the same machine.
And the developer way of sharing data in the cloud is GitHub (and its competitors). Too difficult for normal users, but not bad once you’re used to it.