3 ms·

Take for example an old gallery app that request complete file access. Now the new API adds fine-grained access and removes complete access. What are they gon

Take for example an old gallery app that request complete file access. Now the new API adds fine-grained access and removes complete access. What are they gonna do? Give the old gallery app fake file access, making it completely useless? This would make for a very bad user experience. It works for emulators, because noone expects emulators to be well integrated with the system. But it doesn't work for native apps. Many features cannot be preserved. They could preserve some features, but doing so would result in some weird 50% support for old APIs, which wouldn't be great either. In my view, dropping old APIs entirely makes sense. > I never particularly liked Microsoft but userspace compatibility is something they got right With the result of having absolutely zero sandboxing.

slau 2y ago
Doesn't the operating system show you a prompt to show which files you want to give the app access to? From the app's perspective, nothing has changed. It gets a handle to a directory and can list files in it. Whether that directory contains 1 or 10000 items makes no difference. Just to be clear: I don't disagree with you. I think it's completely normal to have APIs be deprecated, and this means eventually your app will break and be removed from the store. I just don't think this specific example was entirely justified.
- aniviacat 2y ago
  Yeah, good point. I actually use GrapheneOS which does exactly that. I don't know why I didn't think of it.
- ristos 2y ago
  Deprecating an API doesn't mean you have to break work already done. It can just mean that _newer_ apps can't use the deprecated API.
ristos 2y ago
> Now the new API adds fine-grained access and removes complete access. > What are they gonna do? Give the old gallery app fake file access, making it completely useless? Can you elaborate on your example here? Couldn't they just do something like replace oldGalleryAppOpensOrWritesToAnyPlace() to askPermissionsForWhichFilesAndFoldersCanBeWrittenTo() or ifSensitiveDirIsNoLongerAccessibleAskPermissionOnWhichFolderToUseForCompat() ?
bambax 2y ago
>> I never particularly liked Microsoft but userspace compatibility is something they got right > With the result of having absolutely zero sandboxing. With the result of having useful machines that do useful work, instead of toys that "protect" users and prevent them from ever doing anything interesting.
xprn 2y ago
For the file system, the OS could do something similar to what iOS is doing when you want to share a picture - giving the user control over which pictures the app has access to. Yeah, for a gallery app it could render the app quite useless because of the UX, but it would solve the issue itself IMO.
londons_explore 2y ago
> Give the old gallery app fake file access, making it completely useless? Yes. When any API is used for the first time, pop up a toast saying "this legacy app is trying to use File Access permissions. [Allow access to whole device] / [ Restrict to apps own files ]". If the user hits 'allow', grant the legacy API. If the user hits 'restrict', give a fake filesystem. The dialogue box should be provided by the OS, and if the threading model doesn't allow pausing the app to wait for user interaction, simply kill the app to ask the question, and restart it with the permission.
- deleted 2y ago
  [deleted]
- dietr1ch 2y ago
  But will implementing this secure you a promo? What about saying that most apps migrated to the newer and safer api for users? Also, TBH dev convenience is secondary to user safety
  - alexey-salmin 2y ago
    How about user convenience? I'm pissed off that I can't install Euclidea for my kids and it's from 2020, not from 2000. And anyway it's a false dichotomy. If the old API is implemented on top of the new API then it can be as safe as you want it.
- parl_match 2y ago
  Except that legacy app owners regularly get offered money by bad actors, to purchase the apps and take over. Which means that anyone who "Allow access to whole device" suddenly gets a malicious update that cryptolocks them or steals their files. Real scenario, real problem, semi-common attack vector. Enough that it's a serious problem for Google.
  - alexey-salmin 2y ago
    You don't have to give access to whole device. Ask the user what he wants to share, then present the app with a skeleton directory tree where only allowed parts are visible. App can as well think that is has a "full access" whatever that means, it's a matter of terminology.
shaky-carrousel 2y ago
They could intercept file access to common folders, showing you a pop up with the files you would like for the app to see and show only those files to the app.
lordnacho 2y ago
Sure, but why is the API still changing now, after nearly two decades? It should be more or less locked down whether you do "file system is a free-for-all" or "every app is sandboxed". I don't think people are complaining about API deprecation being a thing, either. They complain about it being a thing that happens too often.
alexey-salmin 2y ago
> Many features cannot be preserved Could you present a concrete example, outside of the "system configuration" apps? These are expected to break as the "system" moves on. I fail to see though why 100% userspace apps that often have no permissions whatsoever can't be maintained.
seba_dos1 2y ago
> Take for example an old gallery app that request complete file access. This applies even to apps that don't request any permissions. I have some plain OpenGL games there and they still require this useless maintenance for them, which I'm probably won't be bothering with anymore.

slau 2y ago

Doesn't the operating system show you a prompt to show which files you want to give the app access to? From the app's perspective, nothing has changed. It gets a handle to a directory and can list files in it. Whether that directory contains 1 or 10000 items makes no difference. Just to be clear: I don't disagree with you. I think it's completely normal to have APIs be deprecated, and this means eventually your app will break and be removed from the store. I just don't think this specific example was entirely justified.

aniviacat 2y ago
Yeah, good point. I actually use GrapheneOS which does exactly that. I don't know why I didn't think of it.
ristos 2y ago
Deprecating an API doesn't mean you have to break work already done. It can just mean that _newer_ apps can't use the deprecated API.

ristos 2y ago

> Now the new API adds fine-grained access and removes complete access. > What are they gonna do? Give the old gallery app fake file access, making it completely useless? Can you elaborate on your example here? Couldn't they just do something like replace oldGalleryAppOpensOrWritesToAnyPlace() to askPermissionsForWhichFilesAndFoldersCanBeWrittenTo() or ifSensitiveDirIsNoLongerAccessibleAskPermissionOnWhichFolderToUseForCompat() ?

bambax 2y ago

>> I never particularly liked Microsoft but userspace compatibility is something they got right > With the result of having absolutely zero sandboxing. With the result of having useful machines that do useful work, instead of toys that "protect" users and prevent them from ever doing anything interesting.

xprn 2y ago

For the file system, the OS could do something similar to what iOS is doing when you want to share a picture - giving the user control over which pictures the app has access to. Yeah, for a gallery app it could render the app quite useless because of the UX, but it would solve the issue itself IMO.

londons_explore 2y ago

> Give the old gallery app fake file access, making it completely useless? Yes. When any API is used for the first time, pop up a toast saying "this legacy app is trying to use File Access permissions. [Allow access to whole device] / [ Restrict to apps own files ]". If the user hits 'allow', grant the legacy API. If the user hits 'restrict', give a fake filesystem. The dialogue box should be provided by the OS, and if the threading model doesn't allow pausing the app to wait for user interaction, simply kill the app to ask the question, and restart it with the permission.

deleted 2y ago
[deleted]
dietr1ch 2y ago
But will implementing this secure you a promo? What about saying that most apps migrated to the newer and safer api for users? Also, TBH dev convenience is secondary to user safety
- alexey-salmin 2y ago
  How about user convenience? I'm pissed off that I can't install Euclidea for my kids and it's from 2020, not from 2000. And anyway it's a false dichotomy. If the old API is implemented on top of the new API then it can be as safe as you want it.
parl_match 2y ago
Except that legacy app owners regularly get offered money by bad actors, to purchase the apps and take over. Which means that anyone who "Allow access to whole device" suddenly gets a malicious update that cryptolocks them or steals their files. Real scenario, real problem, semi-common attack vector. Enough that it's a serious problem for Google.
- alexey-salmin 2y ago
  You don't have to give access to whole device. Ask the user what he wants to share, then present the app with a skeleton directory tree where only allowed parts are visible. App can as well think that is has a "full access" whatever that means, it's a matter of terminology.

shaky-carrousel 2y ago

They could intercept file access to common folders, showing you a pop up with the files you would like for the app to see and show only those files to the app.

lordnacho 2y ago

Sure, but why is the API still changing now, after nearly two decades? It should be more or less locked down whether you do "file system is a free-for-all" or "every app is sandboxed". I don't think people are complaining about API deprecation being a thing, either. They complain about it being a thing that happens too often.

alexey-salmin 2y ago

> Many features cannot be preserved Could you present a concrete example, outside of the "system configuration" apps? These are expected to break as the "system" moves on. I fail to see though why 100% userspace apps that often have no permissions whatsoever can't be maintained.

seba_dos1 2y ago

> Take for example an old gallery app that request complete file access. This applies even to apps that don't request any permissions. I have some plain OpenGL games there and they still require this useless maintenance for them, which I'm probably won't be bothering with anymore.