Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is forcing us to make our open source VoIP app worse

voys.co.za

Post reply on HN
Print view View original

221–230 of 296 posts

Re: Google is forcing us to make our open source VoIP app worse

#221

Post by saagarjha »

pydry wrote: post #141
bakugo wrote: post #78

Earlier quoted context omitted.

So why not just remove the Contacts API entirely then? If it exists, "shady operators" can misuse it. Oh and, camera apps made by "shady operators" could be sending your pictures to questionable places so why not remove the Camera API as well? And we can't forget that "shady operators" could be snooping through your files so let's remove the filesystem API too. Actually now that I think about it, any app could be mal…

They could just make the contacts API use an inbuilt contact picker than just supplies to the app the contact the user selects each time they make a call. I assume they want google apps to have access to the whole phonebook without looking too suss though.

This doesn’t work when you get an incoming call, and it’s annoying for outgoing ones too.

Re: Google is forcing us to make our open source VoIP app worse

#222

Post by saagarjha »

dougk16 wrote: post #209
kazinator wrote: post #171

Of course Google isn't going to look at the code. Most Google App Store apps are not open source, so why would that be a workflow at all? You have to evaluate those same deliverables that are downloaded to the user. To be able to infer properties of the build application from the source code review, it has to be shown that the two correspond; the shipped, built version comes from the code that was reviewed. Poring ov…

Google does some pretty surprising levels of static analysis of compiled source, particularly surrounding their API usage. There's a few examples I've run into but the first that pops to mind is when they started requiring a yes/no confirmation dialog before allowing a user to access a non-https resource through the WebView. There was no way a human was running into that on the particular app I was working on. We're…

Google generally would have an incentive to not be up in a negative light on Hacker News if they could avoid it, no?

Re: Google is forcing us to make our open source VoIP app worse

#223

Post by savy91 »

refulgentis wrote: post #157
savy91 wrote: post #133

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…

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.

Re: Google is forcing us to make our open source VoIP app worse

#224

Post by savy91 »

binkHN wrote: post #219
clcaev wrote: post #160

Perhaps phones need an API so an application may request a single contact's information as selected by the user, without exposing the entire phone book?

This API exists in Android.

In many phone brands using the PICK_CONTACT intent still requires the READ_CONTACTS permission, which allows to read all contacts. There is also an issue opened for this [1]

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

Re: Google is forcing us to make our open source VoIP app worse

#225

Post by saagarjha »

kazinator wrote: post #171

Of course Google isn't going to look at the code. Most Google App Store apps are not open source, so why would that be a workflow at all? You have to evaluate those same deliverables that are downloaded to the user. To be able to infer properties of the build application from the source code review, it has to be shown that the two correspond; the shipped, built version comes from the code that was reviewed. Poring ov…

How much time did you put it your “abstract tokens” idea? Was it just something you came up with as you wrote your comment? You’re presenting it as “it’s possible to do this and here’s how” but I’m not really aware of any systems that do this in a practical manner. Out-of-process rendering is definitely a thing it’s not nearly as simple as “just render all sensitive content away from the app and this will solve all problems!”

Re: Google is forcing us to make our open source VoIP app worse

#226

Post by saagarjha »

r2sk5t wrote: post #175
esprehn wrote: post #170

Earlier quoted context omitted.

Why do you need to know every app installed on the device to invite people you know?

Because we were using this: https://github.com/EddyVerbruggen/SocialSharing-PhoneGap-Plu... ...and didn't want to invest in this feature.

Not to channel the usual Hacker News acid at you but have you considered the optics of “we are using code that requests fairly broad permissions because we couldn’t be bothered to invest in doing a better job that didn’t have to do this”? I don’t see this explanation as being particularly comforting.

Re: Google is forcing us to make our open source VoIP app worse

#227

Post by saagarjha »

shadowgovt wrote: post #41

Interesting (and disquieting). I can see this from Google's standpoint also... I don't expect them to shoulder the cost of interpreting a binary blob by decompiling it, so they're left with the problem that the trust calculus is that they're observing a user doing something with very sensitive user information in a binary blob they can't introspect. Hypothetically, one possible workaround (that definitely wouldn't wo…

Source code can be just as difficult to analyze as compiled code, especially if you’re trying to do automated analysis on it.

Re: Google is forcing us to make our open source VoIP app worse

#228

Post by dougk16 »

saagarjha wrote: post #222
dougk16 wrote: post #209

Earlier quoted context omitted.

Google does some pretty surprising levels of static analysis of compiled source, particularly surrounding their API usage. There's a few examples I've run into but the first that pops to mind is when they started requiring a yes/no confirmation dialog before allowing a user to access a non-https resource through the WebView. There was no way a human was running into that on the particular app I was working on. We're…

Google generally would have an incentive to not be up in a negative light on Hacker News if they could avoid it, no?

Google is a vast, schizophrenic organization. They're big enough that they have different teams and internal politics fighting each other all the time. It's not a unified consciousness with consistent incentives. Even if that's a bad take, Google is constantly seen in a negative light on Hacker News. The Google hive-mind doesn't care too much.

Re: Google is forcing us to make our open source VoIP app worse

#229

Post by savy91 »

p1necone wrote: post #162
savy91 wrote: post #133

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…

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.

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

Re: Google is forcing us to make our open source VoIP app worse

#230

Post by saagarjha »

alerighi wrote: post #169

Even if the app uploads contacts to a server, is that a big deal? A lot of apps do that: WhatsApp, Telegram, Facebook, Instagram, Microsoft Teams, basically any messaging application. Of curse the app should ask permission to do so in accordance to local laws (such as GDPR if we are in Europe), but it shouldn't be a concern of Google.

Just because someone else does it doesn’t mean it’s the right thing to do.
Post reply on HN