Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I will criticize how Contacts are implemented on Android for this.

For example, I don't want any person who I interact with once or twice a month to have access to my WhatsApp or any other social media app. But I can't do this in Android because once you add contact every damn app has access to that contact list. It's full access or no access if app uses permissions. I need something where I can label contacts to not appear in main contact list.



Android Work Mode has this contact-separating feature: https://f-droid.org/packages/net.typeblog.shelter/


That is not correct.

In Android you have two ways of accessing most things: full access or use the system to access one entry.

You should blame WhatsApp for not supporting the second method.


The fact that an app can choose to "support" a method is a flaw. The app should be completely oblivious to whether what it's seeing is the full list of accounts or a carefully selected one.


My point remains valid. If OS is handling contacts it should have some sort of control over what's getting shared. Theirs no point of providing alternate ways if an app can access full list of contacts.


That is a very odd take away.

The first method is good to have for apps you trust, and requires permission from the user.

https://developer.android.com/guide/topics/permissions/overv...

The second method is what you want with apps you don't yet fully trust or for some other reason don't want to give direct access to your contacts.

https://developer.android.com/training/permissions/evaluatin...


Why would an app developer ever think their own app should use the method reserved for untrustworthy apps?

All incentives suggest the developer should prevent using the app without full permissions being given (basically force the user into giving permission) and only implement the first method.


Because it would be easier for the users and allow some customization you can't otherwise have?

Sure it can be abused, but there are also legit use cases


While I get where you are coming from, but giving that option is a design flaw.

As Android developers, we should only be given one pipe to consume from. The system should then present the user with the ability to choose if that pipe for this particular application is going to be:

"All contacts" / "A subset of contacts" / "No contacts

And even better yet just "A subset of the values for a subset of contacts"


You need a migration path and backwards compatibility. They can't kill all the apps which used the old system.


They can just lie to the old apps. Tell them they're getting the full list when the API is called.


Privacy Guard in Cyanogenmod used to do this I think, at least to fake the list to be empty. It somehow still broke a tiny number of apps (unintentionally, i.e. the app owners didn't purposefully add code to annoy those users) so there seems to have been some flaw between 'empty list with permission granted' and 'empty list with permission not granted'. Regardless, I'm not sure why this didn't become mainline Android aside from that it would come with no benefits to the main developer of Android.


For backwards compatibility, they could just put in some nonsense entries. If the program can figure out those entries are nonsense, it's no longer out of date and it's on them.

Why they didn't do this by default is anyone's guess. Maybe they like app devs more than users. More technology should lie on users' behalf.


Sure sure, I was just saying that this sort of thing already existed in the past (in Cyanogenmod, and that it worked well for 99% of apps even without providing wrong data) but other vendors or even mainline Android never picked it up unfortunately.


What if the app caches some (or fragments of) entries for some good reason? If you're unaware you're getting only one requested contact each time you may be triggering edge case behaviour. What if you have reasonable time-out behaviour which triggers each time now while user chooses which contact to expose to the app? What if the contract list is polled in the background, or when you receive a message to match it up with the right source?


"Yep, this user has exactly one contact, and gee, it happens to be the one they're calling now, how fortuitous! They had a different single contact yesterday, but apparently they've deleted that one and added this one."


If the devs update the code to respond to fake entries, then the program is no longer out of date and thus no longer in need of backwards compatibility.


ideally true. The issue is common person expects things to 'Just Work' - means read/allow contacts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: