Hacker News Reader

Comment by aniviacat | Hacker News Reader

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.

View on HN

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

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.

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.

Most users will click on the option that they think will lead to the fewest number of future prompts.

Yes, but it has nothing to do with API versions.

If the new API can give a sensible way to restrict file access without too many prompts, then the old-over-new API layer can do exactly the same.

How can the new API know this?

You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.

The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.

This stuff is highly non-trivial.

> You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.

No. It knows which actual paths the app tries to access. They can be grouped into exactly the same permission bundles (access to camera images, access to downloads etc) which are used for newer apps. Then presented to the user for approval, like they are with newer apps.

The only difference is, you may not get all permission popups at once -- but that's already the case with many newer apps. They only ask for permissions to e.g use camera when you actually need it. And I like it so much better than the old approach when the apps would refuse to run without camera even though I don't need this particular feature.

> The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.

Right, and exactly the same problem applies to new apps natively built against the new API. The app can request unreasonably wide permissions and the user will make the damn popup go away. It's not relevant to the problem of maintenance of old apps.

Except tou can't upload new app version targeting old API version

updates have to use the new api. boom.

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

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.

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

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.

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.

Yeah, good point.

I actually use GrapheneOS which does exactly that. I don't know why I didn't think of it.

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.

> 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() ?

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.

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

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

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.

Reply on news.ycombinator.com