Live data from Hacker News

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

voys.co.za

281–290 of 296 posts

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

#281
post #181
post #167

We had this issue and went back and forth with Google for weeks with no progress. It was infuriating, since the peeps on the other end just cut and pasted responses. Then, we hashed the Contacts before uploading them and our app was immediately approved. Subsequently, they decided to ding us on this permission "QUERY_ALL_PACKAGES", which we needed for inviting people you know to our app. Since we were so beaten down,…

I don't want you to query my packages and I don't want your help to invite people I know to your app. That sounds like a feature that was made for your benefit, not for mine. So it seems that Google made your app better for me as a user. Congrats Google indeed.

It's not helping them invite your friends to their app (which is impossible). It's helping you invite them if that's something you want to do (probably by listing the messaging apps you have and giving you pre-compose buttons; EDIT: confirmed by sibling comment).

If you don't want to use that feature, don't press the "invite friends" button and that code will likely never run. If you don't want the app to even theoretically have access to your app list, don't give it the permission. Is it not a runtime permission? That sounds like Google's fault, not the app's.

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

#282

Earlier quoted context omitted.

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.

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

#283

Earlier quoted context omitted.

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 analo…

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

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

#284

Earlier quoted context omitted.

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?

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

#285

I kinda sorta see google’s side. There are just too many shady operators out there who will swear blind they’re completely honest, and maybe they are, but they also employed a third party to write code or maybe just imported a 3rd party lib (i am in no way saying this is the case) As to, why don’t they look at the code? bugger that being standard practise, i’m not handing over my code to google or apple. Even if they…

Google's stance seems to be "even if you don't upload contacts, you need to say you upload contacts because we can't prove you don't". They are equating your technical ability to do something with you doing it. How is that in any way reasonable? I own a knife, does that mean I stab people? Should I have to say "I stab people" when I enter a kitchen so people know they might be in danger because there's nothing techni…

They could change the code after 8 months to exfiltrate your address book, easily. Most businesses pivot for whatever reasons, a giant database of users contacts would be precisely what one would want in order to mitigate unforeseen problems with the business model.

As for your kitchen example, you don't need to say anything. Walk into any room with a weapon and people will know they might be in danger. If I'm in that kitchen, and you walk towards me, I'll move out of arm's reach.

Basically it's the same problem: Assurances are worthless. Rationalization provides seemingly excellent reasons for any course of action. So, the onus is on you to show that no harm will be done. It certainly is not the responsibility of some 3rd party to establish this, that is a coercive worldview.

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

#286

Earlier quoted context omitted.

The code review is done 'black box' - ie. the reviewer doesn't have access to the code. All the reviewer can see is what permissions the app has. They see internet permission and contacts permission, and have to assume that evil code might be uploading the contacts to the internet. There isn't really any other way to do it - even a thorough code audit (a process that would take months for just a single app) would be…

> There isn't really any other way to do it There is, it's called balancing the probabilities. What's more likely - that someone started a company, developed a full-featured VoIP app, set up all the infrastructure to provide their service, made the app open source and established themselves in the market, all just to secretly harvest people's contact lists.......or are they telling the truth and no data is being uplo…

One founder leaves and the replacement has a different mandate and/or worldview. Happens all the time. You should assume any app requiring contacts and access to photos is exfiltrating them.

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

#287

Earlier quoted context omitted.

Google's stance seems to be "even if you don't upload contacts, you need to say you upload contacts because we can't prove you don't". They are equating your technical ability to do something with you doing it. How is that in any way reasonable? I own a knife, does that mean I stab people? Should I have to say "I stab people" when I enter a kitchen so people know they might be in danger because there's nothing techni…

They could change the code after 8 months to exfiltrate your address book, easily. Most businesses pivot for whatever reasons, a giant database of users contacts would be precisely what one would want in order to mitigate unforeseen problems with the business model. As for your kitchen example, you don't need to say anything. Walk into any room with a weapon and people will know they might be in danger. If I'm in tha…

The thing is, there's no way to prove you won't do something in the future if you have the ability to do it. All you can do is promise that you won't, preferably in a legally binding way (such as a privacy policy) and stake your reputation on it. That's the basis of society. Just because someone doesn't believe you doesn't give them the right to force you into a false confession.

The app developer says "all your contacts stay on your phone, we only use the internet for calls". Google says "this app is able to access both your contacts and the internet any time for any purpose". Both of those statements can coexist and be presented to the user for evaluation. The app being required to pretend like it's uploading your data is just lying to the user.

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

#288

Earlier quoted context omitted.

> There isn't really any other way to do it There is, it's called balancing the probabilities. What's more likely - that someone started a company, developed a full-featured VoIP app, set up all the infrastructure to provide their service, made the app open source and established themselves in the market, all just to secretly harvest people's contact lists.......or are they telling the truth and no data is being uplo…

One founder leaves and the replacement has a different mandate and/or worldview. Happens all the time. You should assume any app requiring contacts and access to photos is exfiltrating them.

You may choose to assume that, or you may choose to believe them due to various other factors. The choice is and should be yours, not Google's. And even if you do choose to assume that, you're aware it's just an assumption, not a fact. But if Google does the assuming for you and gives you their assumption as a fact, you don't have that very important context.

Google is more than welcome to add a disclaimer such as "no claims in the app description have been verified and may change at any time" to all apps - I'd even welcome it. But don't make us lie to our users! (I'm not affiliated with the posting company, but I've had a similar issue in an app with location permissions for use on a simple map)

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

#289

Earlier quoted context omitted.

I'm not arguing that it's justified here but not elsewhere . Selective enforcement of rules is one of my biggest gripes with companies. I'm also not arguing that applications shouldn't be able to use contact permissions, obviously some applications will need it. But I do think that if you need X permission, you should be evaluated against everything that the permission grants and not just "we promise not to use Y par…

This isn't a case of "not using every part of the permission" (like it often is with the location permission, which you need to scan wifi an bluetooth). It's a case of asserting that an app does something just because it technically could, refusing to listen to any evidence to the contrary and demanding they put this nonexistent anti-feature in the description. It's like demanding a folder encryption app rebrand itse…

>* It's a case of asserting that an app does something just because it technically could*

Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice.

>It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation app as "24/7 tracking app for stalkers" because it has a both GPS location and Internet access.

Not even close. Both your forced analogies involve something inherently negative ("ransomware", "for stalkers"). Google is not forcing this app to call themselves "malware" or anything like the situation in your examples, nor is Google asking the company to rename their application.

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

#290

Earlier quoted context omitted.

This isn't a case of "not using every part of the permission" (like it often is with the location permission, which you need to scan wifi an bluetooth). It's a case of asserting that an app does something just because it technically could, refusing to listen to any evidence to the contrary and demanding they put this nonexistent anti-feature in the description. It's like demanding a folder encryption app rebrand itse…

>* It's a case of asserting that an app does something just because it technically could* Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice. > It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation…

> Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice.

Yes, "considered", not "assumed and banned on the basis of". If I consider what the app could do and chose to accept that risk (hint: you do that every time you install a program on a desktop OS, which have basically no sandboxing and often auto-update), I should be able to use it. Google is doing the deciding here and that's not ok. "There's nothing stopping the devs from abusing this access in the future" is a reason to be careful, not to completely disallow a piece of software (which is what Google effectively did).

> Google is not forcing this app to call themselves "malware"

Many people on this very forum regularly claim that software that does things like upload your contacts to the cloud for no good reason should in fact be considered malware. An app that explicitly brands itself as privacy-friendly being forced to claim it does something that violates user privacy is largely comparable to being called malware.

Let's try this analogy again: imagine Signal needs to call itself "not actually encrypted messenger" because they could in theory push an update that sent messages unencrypted or even forwared them to the NSA - they have all the required permissions!

Post reply on HN