Hacker News Reader

Comment by savy91 | Hacker News Reader

We develop a banking app for families (parents and kids). 2 weeks ago we had to remove the possibility to pick phone contacts to invite other family members because Google claimed we were uploading contacts to our servers (which we did not).

We appealed and it did not work.

We then complied with their request and added to the privacy policy they we have access to the contacts and we might process them, and yet Google still rejected our app.

In the end we just decided to completely remove every code from the app that would allow us to read the contacts on the phone.

This has now made our app UX worse for the 60% of users who used this feature.

Also, mind that we of course offered the option to never grant this permission so nobody was ever forced to give access to their address book.

View on HN

Did you ask permission to access all the user's contacts, or open a contact picker to let them pick a single contact?

This is a mistake I see on iOS a lot. You can use a 'system picker' for some things without a permission - photos is the most common one - many apps request full photo library access which I never want to grant when they could just use the system photo picker instead.

In a similar way you could (in iOS) for this same feature just popup the share sheet to send a message. Though I am not familiar with the Android analog.

I believe in recent OS versions, whenever an app requests full library access, the OS asks you if you want to grant it, deny it, or grant a subset of photos which it fakes as the "full library" to the app.

I believe Android does this too, letting users pick a specific directory they want the app to have access to

Now, Android does this and only this, which is insane. It won't let you grant access to the main storage, Downloads or any other standard folder even if you explicitly navigate to it and select it.

Afaik access to main storage can only be granted if the app declares the "all files" permission. I'm not sure what's the deal with the downloads folder though

You could definitely use the share modal on Android. Clicking to invite would pop it up, let you choose which app to use, and then which contact.

True, but the share modal is terribly broken. It changes every version, the order of icons is different every time you open it, sometimes icons and app names are mixed up...

But it's not good UI for sharing app. It should have Contact Picker API like photo.

Contact picker, but also that requires the READ_CONTACTS permissions.[1]

[1] https://issuetracker.google.com/issues/118400813?pli=1

I don't think google did anything wrong here (at least in the first half), afaik android app privacy permissions don't differentiate between "app has access to contacts locally" and "app has access to contacts remotely".

Probably because this would require thorough code review every time you shipped an update to ascertain as opposed to just identifying whether you accessed a specific API or not.

Of course that would be impossible to differentiate, but adding it to the privacy policy is what Google requests. Adding it and still having it refused can absolutely be blamed on Google.

What I don't get is why does sending contacts need to be added to the privacy policy? The point of the policy is to state what you will and won't do in a legally binding way. If my privacy policy says "the app may access contacts locally, but that information never leaves the device", that means users can sue me if I break that promise and I could even be criminally prosecuted. What more assurance does Google need?

I do not agree. We were explicitly asking for permission to access the contact list, the user was granting it and the user also had the option not to grant it and still use the app by manually entering the phone number.

What happened is that Google blocked our updates claiming we were doing something we were not doing, and even if we did access the entire phone book, the users agreed to it explicitly.

Another issue is that we would have been fine sharing a single contact with the PICK_CONTACT intent, however there's a bug open in Android since 2018 that causes developers to have to ask for the full READ_CONTACTS permission even just to pick a single contact[1].

So in our case Google did not respect the user choice, claimed we were using user data in a way we were not (without any proof whatsoever), still rejected the update even when we added what they asked us to add to our Privacy Policy and in the end they also don't even fix bugs in the Android codebase to allow developers to use more privacy-friendly APIs in their OS.

[1] https://issuetracker.google.com/issues/118400813?pli=1

The permissions don’t differentiate, which is why an honest privacy policy is important. If they have access to the contacts but the policy states that they do not transmit, store, or process the contacts on their servers I can feel safer.

It appears to me that Google is asking companies to lie about their policies or otherwise make it their policy to retain contact data on their servers.

The only reason I can see for this is to make Google seem less bad when it comes to privacy compared to other companies because they can point to all these other companies you’re giving permission to store data with.

How did you send invites?

This is the flow:

- parent creates a child account and has to provide the child phone number

- we create a child account and sms via Twilio with a token to the child to complete sign up

- the child uses the token (via a deep link) received via sms and claim their account

There is no "mass invitation" feature.

Reply on news.ycombinator.com