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

https://www.voys.co.za/blog/how-google-is-forcing-us-to-make-our-open-source-app-worse/

600 287 4 years ago

voys.co.za

mvletter• 4 years ago

The power they have vs the responsibility they take is completely out of balance.

LOL... I can see Apple developers saying something like this while theu write about it on their even more limited and lockdowned devices.

user3939382• 4 years ago

You can agree that company X does Y thing wrong without deciding that you will make unlimited practical sacrifices in your life to support that position.

If I cut my relationship with every institution I have an ethical problem with, I'd be living in the middle of the woods in a hut.

SpaceL10n• 4 years ago

That can be good thing, imo. Young people have little power to change the world around them, yet they take responsibility for "making the world a better place". I find it inspiring when companies do this too.

yuvalr1• 4 years ago

Alas Google does the exact opposite - they have a lot of power (they essentially verdict an app to life or death, which sometimes means the death of the business), but take very little responsibility for their actions towards app developers.

dspillett3• 4 years ago

This sort of thing is why I intend to never write a mobile app for Google/Apple/other devices.

Though as I never get around to writing my many desktop or web-based app ideas, maybe this isn't much of a problem for Google/Apple/other!

webmobdev• 4 years ago

Yeah. I bought a Mac, an iPad and an iPhone to do mobile development for ios. And then I realised how screwed up and exploitive the whole Apple ecosystem is for developers - they not only want us to pay them annually for the "privilege" of developing on their platform (even though we add value to their platform by creating software for it), but they also want to charge us a commission on each sale (with the bar that we can't tell our customers that the price is higher because of the "Apple Tax"). I decided not to support their platform. And after reading many tales of developers struggle with the illogical bureaucracy of the "app stores", I feel that I made the right decision.

I understand the Google ecosystem is similar, but slightly more bearable because Android allows side-loading. Waiting for the day when legislation / regulation upholds our consumer and computing rights to develop, install and run software on our own devices without ever needing permission from the device makers.

pedro23• 4 years ago

Never? Unless you give up on NFC, banking apps and all those goodies.

charcircuit• 4 years ago

iOS allows sideloading too. Also just because Apple gains value from developers, the developers also gain value. It's a mutually beneficial relationship.

grishka6• 4 years ago

Android is not Google.

ziddoap3• 4 years ago

I'm not familiar with mobile app review process, would any change in code require a re-review/re-submit? If Google approved it as-is, could the developers add a few lines as an "update" and skip over the full review process?

Seems like the ruling is being made on what can be done with the current permissions, rather than what is being done. If that's the case, I sympathize with the devs but I think I support the position Google is taking there.

Off-topic comment: I use NoScript, and the entire text of the article renders for a half second before disappearing and for some inexplicable reason requiring JS to be enabled. If you can render it for that half second, why hide it? Why force me to use JS when you just proved that you can render it without?

Marsymars2• 4 years ago

I'm not familiar with mobile app review process, would any change in code require a re-review/re-submit?

Yes.

jsnell• 4 years ago

It does sound like they're batch-copying the entire contact book into their app at startup, rather than using the Android contact picker. The static analysis problem of determining whether there is / isn't a batch import seems a lot easier than determining with certainty what happens with the contacts after they were saved to disk.

Though the article doesn't actually show any screenshots from the review emails, but just paraphrases them, so we don't even know that their interpretation of the rejection reason is correct.

TheNorthman• 4 years ago

This could, of course, be an explanation. Except for the _stated fact_ that after they removed the batch import, they were still rejected.

exprez135• 4 years ago

Re: the off-topic comment: Same here, but I noticed that Firefox's reader button was still appearing. I was able to read with that without loading the scripts after all.

londons_explore2• 4 years ago

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 unlikely to uncover a well hidden flaw that is intended to allow an evil app developer to steal contacts of users only after the app passes the review process.

capitalsigma• 4 years ago

It seems most likely that there is some static analysis being done to the binary here, or maybe some instrumented JVM that "poisons" bytes that come from the contact list and traces them to see if they ever land on disk or sent on the network. Clearly Google doesn't ban every app with that combination of permissions.

franga200010• 4 years ago

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 uploaded? These are all things Google can verify, they just don't want to.

GordonS• 4 years ago

Seems like the ruling is being made on what can be done with the current permissions, rather than what is being done. If that's the case, I sympathize with the devs but I think I support the position Google is taking there.

Not sure if I'm missing something here, but the "access contacts" permission exists for a reason, and plenty of apps use it - how can it be justified that Google will arbitrarily ban this app, but allow others, even though the authors in this case are clearly willing to do anything to prove no bad intent?

ziddoap3• 4 years ago

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 part of X permission".

squarefoot• 4 years ago

The mobile ecosystem has been built with the sole intent of milking users through targeted advertising, media consumption and unnecessary services subscription, so I find normal that corporations behind the OSes fight hard to maintain the platform as closed as possible (proprietary or seemingly open OSes, closed drivers, locked bootloaders etc). Their deepest fear is seeing their ecosystem conquered by Open Source, or for that matter any other kind of scenario (shareware, donationware, etc) in which users and developers are directly in contact and no middleman is necessary anymore.

Andrex• 4 years ago

Oh man, you should have seen the mobile sphere before Android...

naikrovek3• 4 years ago

no joke. what a hellhole that was.

acdha2• 4 years ago

Before iOS, to be fair. Touchscreens got the attention but the use of the iPod’s popularity to negotiate a non-terrible cellular market was equally transformative. The carriers used to charge something on the order of $50k each to be listed in their app stores and their percentage of revenue was high and negotiated based on your perceived ability to pay: we had several clients bail on J2ME projects because they were being asked to take home less than half of each sale and making 6-7 figure minimum profit commitments to each carrier! The sales person would look at their total corporate revenue to base their first offer on, and they were not quick to negotiate down to our actual budget.

int_19h2• 4 years ago

Before Android and iOS, the dominant smartphone/PDA platforms were Windows Mobile and Symbian. And whatever their usability issues were, I don't recall there being a problem with downloading (or even buying boxed) third-party software directly from the authors and installing it directly.

RobotToaster• 4 years ago

I don't remember having these problems on windows mobile 5.

akira2501• 4 years ago

It was a nascent market, and the first versions of Android and iOS were not significantly better than what was already being offered. Is the suggestion that we wouldn't have put any effort into developing the ecosystem if Google and Apple didn't decide to involve themselves in it?

MisterTea• 4 years ago

You mean it how it barley existed and all we did was talk and text?

Yes. And it was marvelous.

somat• 4 years ago

This is why I say a little prayer of thanks to the internet elders every day that the internet was developed in academia.

I mean sure it is a hive of villinary full of corperate scumbags trying their hardest to steal your freedoms and make you into the perfect consumer. but when I think about how much worse it would be if it had been developed commercially I get this feeling of overwhelming dread and have to go lie down for a while.

Aloha2• 4 years ago

Open Source cell phones is functionally a very very niche market.

They end up costing more than the phone with the big binary blobs from the other android manufacturers, and often have older hardware than the hardware makers are willing to give away specs for.

For what, I'd ask? The users don't care. 98% of Android and iOS users don't even know what open source is, and at least half of those who do know, don't really care that their phone isn't open source.

The people who buy most of the phones by volume and dollars, just want a phone that works well, and lasts 2-5 years.

This was true in the pre-Android iOS version too, I cant remember a Sidekick, PalmOS or Windows Mobile caring much about it either. Most users don't care much about how the sausage is made, provided the sausage is tasty, convenient and cheap.

I donn't think they're afraid of their ecosystem being threatened by Open Source, its not even in their field of vision.

BlueTemplar6• 4 years ago

Perhaps... though I guess they will have to care if they end up being forbidden in most markets outside of the USA - nature abhors a vacuum !

duxup5• 4 years ago

I fear we as users have been trained as well and perpetuate it. People generally don't want to pay, so we're the product, advertising pays ... the whole ecosystem is a mess.

LtWorf2• 4 years ago

It doesn't matter if you want to pay or not. These companies need to make more money than they did the previous quarter. So they need to always find new way to exploit continuously.

Traubenfuchs2• 4 years ago

Analytics cookies are installed on this website to enhance your browsing experience. Such cookies are only used to optimise this website’s performance and enhance user experience. It is not possible to disable analytics cookies on this website.

Now that's just a lie and you know it. Is this legal?

Marsymars2• 4 years ago

“It is not possible” isn’t used by companies to mean “it isn’t physically possible”, it’s used to mean “it isn’t supported by our processes”.

(I’ve been in a frustrating back-and-forth over the past couple days with a company who’s quoting me an outrageous shipping fee, and keeps telling me it’s “impossible” to ship with a different delivery service.)

earleybird• 4 years ago

Can't vs won't.

MaxikCZ• 4 years ago

IIRC: At least in Europe, they needn't ask for essential cookies. They need to ask for cookies used for tracking, profiling, fingerprinting and consent to share collected info with third parties.

The rules also state that the path to reject those cookies must be as easy as it is to accept them, so if they have "accept all" button, they are required to also provide "reject all" button, that has similar visibility and accessibility to the "accept" button.

IIRC At least in EU, what they do is illegal and dark pattern, and hence personally I have no reason to believe their side of story on any topic.

dwaite• 4 years ago

The rules also state that the path to reject those cookies must be as easy as it is to accept them, so if they have "accept all" button, they are required to also provide "reject all" button, that has similar visibility and accessibility to the "accept" button.

The rules also say that you have to be able to _withdraw_ your consent as easily as you provided it, which IMHO 99% of cookie banners fail to provide for.

Traubenfuchs2• 4 years ago

That‘s what I thought. I just started a prolonged burnout vacation. How do I hold them accountable / sue them? I will look it up.

AlexandrB• 4 years ago

With the exception of Signal, I never give apps access to my contacts. If you think that's paranoid, remember how apps like LinkedIn used this kind of information in the past[1]. Thankfully on iOS apps almost always work without contact access (is this mandated by App Store rules?).

It's not clear from the article if the app just asks for access to contacts or requires it, but if you can't make your Voip app work without accessing my contact list, I don't want to use it.

[1] https://www.theverge.com/2013/9/21/4756212/linkedin-accused-...

thebeardisred• 4 years ago

While I don't doubt that you never give apps access to your contacts, how many apps do you use as _dialers_?

londons_explore2• 4 years ago

iOS doesn't even let you change the dialer.

cmsj• 4 years ago

Absolutely the same here. WhatsApp is a nightmare to use without contacts, but I don't care, they are not having my contacts.

Nextgrid8• 4 years ago

Facebook wouldn't have paid billions for just a messaging app. What they really paid for is people's social graphs.

perryizgr8• 4 years ago

To be fair, whatsapp is a messaging app. Almost everybody who uses it, gives it contacts access, because it is absolutely required for that core functionality. It would be horrible to use if I couldn't search my contacts within the app. Or of incoming messages didn't get tagged based on my contacts.

thatguy0900• 4 years ago

Seems like a lost fight to me, if a few friends have these apps your social web is already known to a great extent anyway

0xCMP• 4 years ago

It is, but it's worth being a pain in this respect because it makes it obvious we need a way to limit which contacts an app can see similar to how you can limit photos for an app.

donmcronald2• 4 years ago

Yep. I was just looking at a voicemail / spam blocking one last night and their privacy policy said they use / share and contacts you upload (aka that they upload). The average person has no idea that’s happening.

bryceacc• 4 years ago

there are multiple apps i have encountered that would not let you type in a phone number to start a chat. you HAVE to give contact access and have whatever number you wanted to chat with saved as a contact

binkHN3• 4 years ago

you HAVE to give contact access...

Some apps require this, but the Android API allows apps to access very specific Contact information without having full access to all Contact data.

grishka6• 4 years ago

Thankfully the use of Google Play is not mandatory. You could as well distribute your app from your website and make it update itself — you know, just like people did for ages with desktop software.

turminal• 4 years ago

Yeah, good luck with that. Nearly nobody installs apps from outside Google Play.

naikrovek3• 4 years ago

that's not exactly true, though of course I don't have numbers.

maybe that is something you just don't see a lot, but that happens often?

grishka6• 4 years ago

Huh? One example: everyone did sideload Pokemon Go in 2016 because its availability on Google Play was very limited for a very long time.

pomatic• 4 years ago

I was intrigued by the prospect of a foss voip phone app that's cross platform - but was unable to find the repo. for the app (libary repos are available and obvious, just not the app as a whole). Anyone know where it lives?

captainzidgel• 4 years ago

The website calls it the Voys app but I think it's actually called Vialer: https://github.com/open-voip-alliance/vialer It's the only full app in their repo and it fits the description they gave on the website.

csdvrx• 4 years ago

Does it work with twilio sip trunking?

chooma3• 4 years ago

Indeed, the Voys app is a white-label version of Vialer. See: https://github.com/open-voip-alliance/vialer/blob/9e81baffc3...

pwg• 4 years ago

Does Linphone (https://linphone.org/) not meet that need of cross platform (website claims versions for all major OS'es) and open source (https://gitlab.linphone.org/BC/public/linphone-desktop)?

chunk_waffle• 4 years ago

If this is at all like the Chrome Extension review process, having a privacy policy that is clearly written and describes that you don't upload any contact info (as well as what info you do upload) might go a long way.

secretsatan4• 4 years ago

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 did, how to check final the uploaded binary?

I’m not doubting the article, but the mobile app world is flooded with shady operators at all levels, and i don’t really buy the real paranoid arguments here

asdff• 4 years ago

At the same time, why not just release at least one phone that is developer friendly? People can handle it. All these issues are present on computers that are able to run unsigned code, have sensitive personal info stored on them, etc. Yet the sky is not falling with all this going on with everyone's computer on earth, like how people fear the sky will fall if we opened up the mobile phone.

jtvjan• 4 years ago

It's easy to install unsigned apps on Android, but not being on the Play Store severely limits your reach, since many people only check there for apps instead of searching on the open web.

secretsatan4• 4 years ago

They keep making them but they keep failing, because people want phones that work without needing a computer science degree to understand what is safe and what isn’t.

And myself being an apple guy with a dev account, i can install pretty much what i want

nemothekid• 4 years ago

Yet the sky is not falling with all this going on with everyone's computer on earth, like how people fear the sky will fall if we opened up the mobile phone.

This is because everything was moved to the web and users were beaten over the head with a hammer to never install anything on their computers. The sky was falling and subsequently the desktop software platform hardly exists today.

fsflover• 4 years ago

why not just release at least one phone that is developer friendly?

Google and Apple want to control their users, they don't want to give you an open phone. Instead have a look at Librem 5 and Pinephone, which run GNU/Linux.

jonas21• 4 years ago

On most (if not all) Android phones, you can tap the version 8 times to put it into developer mode and then install whatever you want.

secretsatan4• 4 years ago

Depends what you mean by “sky falling on heads” They’re definitely aren’t concerted efforts in companies to not just open any email attachments

No data breaches occur to insecure passwords

Phishing, let alone spear phishing isn’t a thing

No popular app has ever found to be doing naughty things

We’ll not to the oss crowd anyway, if it does happen, it’s coz they aren’t using open source and checking every line of code

tsimionescu• 4 years ago

Not to mention, given their cookie policy, they claim that they are "very privacy conscious" is dubious at best (no button to directly reject all non-necessary cookies, navigation to a different page to configure cookie preferences, claiming that analytics cookies are required).

I'm going to go ahead and say that probably they are misrepresenting what is happening.

yieldcrv• 4 years ago

I noticed that too

TheCapeGreek• 4 years ago

To give the benefit of the doubt, knowing nothing else about this company:

This is clearly a South African based company. GDPR and cookie may be important compliance but it's not top of the totem pole - the local South African equivalent law (POPI) is more about data processing than cookies. Plenty of sites have not updated their cookie UX for the newer regulations.

I've even noticed some sites serve different forms of cookie consent depending on where you're accessing from. I only started seeing the ability to reject cookies entirely when I travelled to EU recently - before it was always hidden in dark pattern UX.

nedt• 4 years ago

Not only are they tracking without consent. They are also missing very basic settings, like IP anonymization.

veeti• 4 years ago

This line of reasoning can be used to reject and remove access to literally any app or API. Why offer a contacts API if you're not allowed to use it? Who is trustworthy enough to have this privilege?

They should just remove all third party API's to access any user data. Then we can be certain of privacy, with only non-shady actors like Google, Samsung, Facebook, etc. accessing saved contacts.

bakugo• 4 years ago

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 malware, so let's just deal with the root of the problems and remove support for installing third party apps entirely. Everyone should just use apps made by google and nothing else, that way you know there aren't any spooky shady operators hiding under your bed.

pjmlp2• 4 years ago

They already removed filesystem API for quite some time now, you're only allowed to read inside the application directory, anywhere else on the device requires SAF.

https://developer.android.com/about/versions/11/privacy/stor...

forgetbook• 4 years ago

Slippery slope--There's a reasonable middle ground between "disallow all api access" and "allow all api access"

pydry3• 4 years ago

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.

sgc3• 4 years ago

They won't let you call anything but their crappy camera app by intent already, for supposed privacy reasons. As you intimate, what is the point of allowing mobile apps, if they can't access any of the features of the device? Because that is where they are heading, fast. A few crappy google apps that require 24/7 spying to work, and then they "protect you" from everyone else. Sounds like an old school mafia street racket.

LocalH• 4 years ago

Welcome to iOS 1

fencepost• 4 years ago

Everyone should just use apps made by google and nothing else, that way you know there aren't any spooky shady operators hiding under your bed.

You left out 'other'.

Notable because Google long ago left behind 'don't be evil' and now is failing at 'FFS, at least try to not be f*cking creepy.'

getcrunk• 4 years ago

I don't know how it is in all cases, but at least when using java back in the day, the source of a binary was trivial to look at?

And now many apps are written in js

heavyset_go2• 4 years ago

SafetyNet can obfuscate compiled code so that it's a pain to decompile and reverse engineer.

smeagull• 4 years ago

You're right, Google have long been incompetent at managing user generated anything. They should probably stop building things that depend on it, because they're so bad at it.

amluto• 4 years ago

Even if they did, how to check final the uploaded binary?

By requiring and verifying a reproducible build. It would be awesome if open source apps on an app store has a badge indicating which commit of which git tree they came from and only allowed updates that similarly come from public trees.

Even failing that, favoring reproducible builds would add a considerable degree of traceability to the entire distribution process.

lupire• 4 years ago

Even easier for the platform owner: if they have your code, then can compile it themselves.

franga200010• 4 years ago

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 technically preventing me from going on a murder rampage?

chiggsy2• 4 years ago

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.

shadowgovt• 4 years ago

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 work for all companies and requires more trust of Google than many will be comfortable with) would be to offer a feature where the package uploaded to Google for hosting on the Play Store includes source code and they compile it to native... But then you have the problem that a company will have to exfiltrate source code to a third party (even though the third party is the one with total control over their app's existence in the largest Android store).

saagarjha7• 4 years ago

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

jasonjayr• 4 years ago

IIRC, if they attempt to 'hack' this by falsely claiming they are uploading the contacts, they might be on the hook in the future if Google expands the scope of their mandatory pentests:

https://cloud.google.com/blog/products/g-suite/elevating-use...

donmcronald2• 4 years ago

We even sue governments for protecting the privacy of our users.

Lost in translation?

lhobas• 4 years ago

No: Voys is a Dutch company with a South African counterpart. Their Dutch entity sued the Dutch government for not providing enough clarity on how mandatory call logs get processed on the government side.

zerocrates• 4 years ago

I think they meant that the text "We even sue governments for protecting the privacy of our users" probably should have been "We even sue governments to protect the privacy of our users," or "...for not protecting the privacy...," etc.

outworlder• 4 years ago

Probably not a translation, confusing for/to is pretty common for non-native speakers.

(Native speakers on the other hand will say 'loose' vs 'lose', 'rouge' vs 'rogue', or even 'could/should of')

bombcar• 4 years ago

Fun fact, almost all VOIP in the USA comes through Bandwidth.com https://www.bandwidth.com/voice/voip-origination/

betwixthewires4• 4 years ago

So put it in f-droid.

mixedCase5• 4 years ago

And nobody will use it because third party stores are discouraged by the operating system's UX.

betwixthewires4• 4 years ago

Lots of people use f-droid. It's as easy as installing f-droid from browser and then checking a box in settings.

j452• 4 years ago

With Rust and WA emerging it will be interesting to see how long it takes to get a voip client as a PWA that just runs in the browser.

WebOS when with Palm was ahead of it's time from a software perspective and couldn't get the hardware out. The ability for all apps to be JS/HTML only with WebOS would be super interesting.

jeroenhd2• 4 years ago

To get that to work, you'd need to run some kind of WebRTC-to-SIP proxy which would be abused to hell and back.

There seems to be an abandoned open source project that you can use to do this: https://github.com/saycel/Saycel.Phone

3cx also seems to have built a web app for their SIP product: https://www.3cx.com/blog/releases/web-client-pwa/

No need to get Rust or WASM involved. Built-in browser support should allow you to do this stuff with just Javascript.

j452• 4 years ago

There’s def web clients already out there. I’ve seen satchel, just haven’t come across an actively developed one.

Jssip is a neat library but not a client: https://jssip.net/

Twilio also has a web client.

Taking a cursory search of WebAssembly for voip shows some activity:

Webrtc is a little old and using webassembly to introduce other codecs isn’t entirely new or novel: https://cloudtweaks.com/2020/08/deep-customization-webrtc/

Blazer allows using webassembly to make calls from twilio: https://www.twilio.com/blog/making-phone-calls-from-blazor-w...

Another neat use for webassembly and audio is audio production say for podcasts with multiple callers that makes editing a bit easier. https://superpowered.com/js-wasm-overview

Noise cancellation and other dsp effects are something webassembly can meaningfully help with. https://news.ycombinator.com/item?id=30568164

r_hoods_ghost• 4 years ago

Ahh a privacy oriented company, that won't allow you to opt out of their analytic cookies this breaking the law in the EU. Or in other words, not privacy oriented at all.

enriquec• 4 years ago

europe's cookie fiasco is so idiotic - why don't you just disable them in your browser if you care?

Nextgrid8• 4 years ago

Because the EU knows that you don't need cookies or client cooperation to track people as there is enough information the client sends (and has to send for functional purposes - think IP address, user-agent, browser fingerprint) to reidentify it down the line even without a persistent identifier.

If you think clearing cookies will defuse industrial-scale spyware from the likes of Facebook, Google or the various data brokers:

1) Don't waste your time clearing them; modern browsers already heavily restrict third-party cookie access and clear them on their own

2) I have a bridge to sell you

atriix• 4 years ago

the irony of that, is that all to many times, one must enable cookies to be able to dismiss the, often full screen takeover, cookie notice to "disable" cookies

croes• 4 years ago

Because there wanted cookies and unwanted cookies.

Websites could store my decision to disallow tracking cookies, but somehow they don't do that.

So it's not a european fiasco but website malice.

Nifty3929• 4 years ago

At the risk of stating the obvious, developers are not the customers. Android has millions of customers who benefit from Google's attempt to prevent misuse and abuse. It is far from perfect - but a bias toward protecting the end-user and their data is the correct choice.

In this case, there is a "false positive" where Google thinks something bad is happening when it isn't. They see that contacts are being touched, but they don't know what is being done with that data and assume the worst (as they should).

It would be nice if the accuracy could be dialed-up by inspecting code or other manual processes, but this is labor intensive and therefore expensive for society as a whole, regardless of who pays the price (devs, Google, or users).

Question for Voys: If there was a service where for $10k/yr you had a white-glove app-approval service from Google/Android/Play where they do actually inspect your code, would you pay for it? Maybe you would, and maybe there's a good market there. I don't know.

gg82• 4 years ago

Of course having Google preventing misuse and abuse is a bit like having a fox guard the henhouse!

godshatter• 4 years ago

Can they put it on f-droid and point their users there? Downside is that users don't know what f-droid is and have to install it, upside is they find a new "app store" that has some new techy things on it. Not sure if f-droid gets around having to tell your phone it can run third-party apps, but if it does that would be a win as well.

I didn't see in the post if they sell this or give it away.

danuker• 4 years ago

Completely open source means no place for supposedly secret Firebase Messaging credentials, which requires developers to bend over backwards, if they want reasonably quick notifications:

https://github.com/deltachat/deltachat-android/issues/82

indrora• 4 years ago

All this makes me yearn for the days of Windows 10 Mobile again.

I built a very simple websocket based app and there was not only support for "you need a long lived TCP connection and occasionally might need to read from it" but "you need background services that might depend on the state of the radio" and more.

Honestly it was an absolute dream to develop for, and it's a damn shame upper management seems to have had a fit that they weren't winning out of the gate.

dna_polymerase• 4 years ago

Why do they need to cache contacts ‘locally’. Are they usually stored in the cloud?

nnopepe• 4 years ago

Given that their site thinks itself above GDPR I'm inclined to believe google

zbuf• 4 years ago

Can you be more specific?

z3t4• 4 years ago

Just release the apk from your website

rasz• 4 years ago

I was with you all the way to

We are now decrypting network traffic to show that we are not doing anything with the contacts,

what network traffic? You said its a local phone dialer ...

kyelewis• 4 years ago

It’s a VoIP app, network traffic is likely.

yazzku• 4 years ago

Two companies should not decide what goes in and out of the mobile ecosystem, or we need to stop non-standard and proprietary ecosystems from becoming a social norm and building infrastructure on top of them.

duxup5• 4 years ago

Personally I would associate access to my contacts with the ability to just upload it.

No reason version 2 can’t do the thing after they upgrade and I already gave permission in version 1.

hedora3• 4 years ago

Well, the app review people could do their jobs and approve version 1, then check version 2.

It is open source, giving them even fewer excuses.

duxup5• 4 years ago

I don’t think that is how the permissions work and to as the app review people to validate every other promise seems absurd.

If the app can see the data, it’s over already.

dima_vm• 4 years ago

From my past experience, both Google and Apple fervently defend their built-in caller app, and really-really don't like any other app making regular voice calls. Part of that is that they don't want cloning (they clearly state that your caller app must look obviously different from default system one), which is understandable, but even when it clearly not a clone, they make take it pretty hard, it feels like they would rather just ban it.

sophacles• 4 years ago

Dear Google. We are one of the most privacy-conscious companies you can find.

I think I found the reason Google is rejecting your app.

savy916• 4 years ago

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.

refulgentis• 4 years ago

How did you send invites?

savy916• 4 years ago

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.

rawling• 4 years ago

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

lathiat• 4 years ago

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.

savy916• 4 years ago

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

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

p1necone• 4 years ago

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.

CountHackulus• 4 years ago

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.

savy916• 4 years ago

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

ViViDboarder• 4 years ago

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.

psykus• 4 years ago

Is Google seriously just run by AI at this point? I imagine at some point up the middle management chain it’s just a layer of AI making decisions that no one has the authority to override.

Similar to how Amazon warehouse workers say that they’re working for an algorithm at this point making hiring/firing decisions.

kaushikc• 4 years ago

Amazon runs on hire quickly and fire quickly policy (many other businesses have already copied this style of recruitment), which is why they are finding themselves running out of massive pools of workers.

clcaev• 4 years ago

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?

binkHN3• 4 years ago

This API exists in Android.

savy916• 4 years ago

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

qwerty456127• 4 years ago

The problem is the same as always - automated bullshit black-holing instead of thoughtful review and constructive communication a human could do. Perhaps the latter is impossible (or maybe this is another bullshit) for companies with userbases this huge but do we really need such in the first place?

taneq• 4 years ago

It’s very difficult to convince a marketing behemoth that their automated systems are harmful when those automated systems’ errors drive users towards said behemoth’s own offerings.

r2sk5t2• 4 years ago

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, we removed that feature. Congrats Google!

esprehn2• 4 years ago

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

r2sk5t2• 4 years ago

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

waqf• 4 years ago

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.

franga200010• 4 years ago

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.

seanhunter• 4 years ago

From a user perspective it’s good to hear about apps being forced to remove the “invite everyone you know” feature. It’s time for that obnoxious user-hostile growth hack to stop.

datavirtue2• 4 years ago

Too late. Probably the single biggest user exploit responsible for Facebook's popularity.

alerighi• 4 years ago

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.

saagarjha7• 4 years ago

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

kazinator• 4 years ago

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 over someone's source code is a fool's errand. You will never catch everything; people find 25 year old bugs in code that have evaded all previous pairs of eyes.

Google's approach here is poor though; they created these API's and permission model and now have to backpedal on it randomly.

If you want untrusted applications to have access to Contacts, it should be done with abstract tokens that do not reveal any contact details. Each contact is represented by an object handle that provides every imaginable operation you might want to do to, with or by-means-of a contact.

It's possible to design a system whereby some contact properties (e.g. mobilePhoneNumber) are accessible, but the result of the access is an abstract object that doesn't actually reveal the content, only represents its existence. The user interface could be priviled so that, say, a text field widget can be given one of these opaque objects, and then display the actual phone number. The only way to get at it would be to have permission to take a screenshot, and then OCR it.

jeremyjh• 4 years ago

It’s a VOIP phone - it has to actually have the number.

6510• 4 years ago

Sorry if this is a dumb question but how does it use the number if it isn't uploaded?

benced• 4 years ago

It was always funny to me reading those stories that Microsoft shares the source of windows with government officials who are worried they have NSA backdoors in a sterile environment: what on earth could you possibly spit from just reading source code? The function won’t be “postToNsa()”

AlexThrowAway• 4 years ago

The function won’t be “postToNsa()”

How about "_NSAKEY"?

In practice Microsoft's thousands of unintentional backdoors would be indistinguishable from a small number of intentionally placed ones. Spy agencies don't even have to bother.

dougk163• 4 years ago

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 not talking advanced static analysis but it's not a simple decompile and grep either.

In another case I had accidentally left some dead/debug AWS access credentials in a build and they sniffed those out too. Notable since that's not even Google-related. They had to have been looking for a particular AWS library method signature and how it was fed. I would bet on their static analysis getting more advanced, in which case it could also be used to prove that OP is using APIs/permissions in a safe manner. But of course they're not incentivized to do that.

saagarjha7• 4 years ago

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

chippiewill• 4 years ago

Yeah, it wouldn't surprise me if their static analysis saw the contacts being fed into a native binary (which they would definitely struggle to analyse) and threw up a red flag. From that point everything is futile because no one you can actually talk to at Google is empowered to disable the flag.

saagarjha7• 4 years ago

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!”

hedora3• 4 years ago

Why not put it on f droid, and make it really, really clear that the play store version is defeatured?

jaimex2• 4 years ago

Offer a side-load option for performance till Google pull their heads out their rears.

Lottery apps had to do this for years.

Brian_K_White• 4 years ago

Why does the api and the permission exist if there is no such thing as a legitimate use of it?

Oh right, Google Maps and Gmail and who knows what else can have full access to those same contacts.

jakeogh• 4 years ago

or... dont use the walled garden... fdroid, and aurora (for closed apps)

codazoda• 4 years ago

I’d rather add new contacts to an app like this than use share my existing ones. There’s just too much info there.

Too• 4 years ago

One possibility is that Google Play runs the app in a sandbox, monkey test it by clicking on everything, trace the outgoing connections and sees that one request contains PII from the sandboxed contacts. It could be a third party library that does it.

Play is surprisingly sophisticated, and with Google focusing only on automation, i wouldn't be surprised to see them have this level of testing. This particular test wouldn't even be hard to write.

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

Related Stories