Hacker News new | ask | show | jobs
by winkeltripel 395 days ago
9 years of the api working, then Google shuts them down. I expect an interface to be consistent after working for 9 years.

I think they're trying to keep their story simple, for the sake of clarity. I believe the nextcloud team when they say they need the permission.

Part of the issue is that nextcloud has many use cases, including ones where your files don't get synced to your mobile device until you touch the file, replacing them with a reference to a file. It's cool cause you can access and manage a tb of pictures or documents from a 64gb android.

2 comments

> I believe the nextcloud team when they say they need the permission.

I don't (and I do use NC). The sentence "SAF cannot be used, as it is for sharing/exposing our files to other apps" is simply wrong and llm_nerd is right that SAF should be able to handle that use case,see

https://developer.android.com/training/data-storage/shared/d...

There are some restrictions regarding which directories you can access, but for most use-cases it should be perfectly fine. It's also not that this should come as a surprise to them. In fact, there's an issue about this from the NC team themselves from August '22:

https://github.com/nextcloud/android/issues/10123

Why they still think SAF cannot be used is a mystery to me.

> I expect an interface to be consistent after working for 9 years

Even if that interface is insecure and harmful to users ?

As an industry we've learnt a lot about how apps siphon and sell your data. And I appreciate this probably doesn't apply to NextCloud but it can be difficult to build an API that is flexible and secure so you will get casualties.

How is this interface "insecure and harmful to users" ?
Shady apps use file access to do tracking of various sorts and simply ingest private data that has nothing to do with their nominal purpose. Sophisticated users probably wouldn't install those apps, and certainly wouldn't agree to their request for filesystem access, but that's not who Google is trying to protect here.

It's obviously not a security problem or a harm when used by an open source file synchronization app, and Google is being unsophisticated with its policy here.

Maybe they should not remove APIs for open source apps then. If you can vet the source code and the app has been built from the source code you vetted, then there is no point in removing capabilities for reasons other than market monopolization and extinguishing features for non-Google developers. After all, these security rules don't apply to Google themselves.

(btw, not singling out Google - IMHO Apple is bad here too. This duopoly in the smartphone space is a major PITA)

It really could.
Do you have links to stories about any of these shady apps that have now been stopped by this policy?
Most of the time, when apps are caught doing something really shady, they're removed from the Play Store for doing the shady thing. A story wouldn't report that they stopped working because of a policy change, but some of these wouldn't make it into the store now:

https://www.bleepingcomputer.com/news/security/apps-with-15m...

https://www.zdnet.com/article/phantomlance-spying-campaign-b...

https://www.welivesecurity.com/2023/05/23/android-app-breaki...

There are also examples of apps using the filesystem to try to detect rooted devices, an invasion of user privacy:

https://www.reddit.com/r/Android/comments/g6cdl6/apps_have_a...

Thanks, definitely looks like it's been abused.

But does the policy solve this problem? The first link is a file explorer app. In theory that app should be granted the permision by Google. They could get established and then start collecting data later. So how does the policy help?

In practice the only way it helps is by Google basically telling everyone other than big trusted orgs no, and that's not an open ecosystem.

Why not just give the user a big fat warning, even telling them that apps which request this permission have been known to steal data in the past, then let them decide for themselves?