Live data from Hacker News

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

voys.co.za

241–250 of 296 posts

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

#241
post #141
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.

> I assume they want google apps to have access to the whole phonebook without looking too suss though. This is why I hope Google and Apple both get forced to give up control of either the OS or the app marketplaces. No company should own both the platform and have a privileged place on that platform like they do today. MS didn't even have this level of control on Windows and they still got an antitrust lawsuit...

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

#243

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…

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.

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

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

#244

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, bu…

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

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

#245
post #78

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…

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…

No post body was provided.

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

#246

Earlier quoted context omitted.

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

How exactly was the sky falling?

http://static.spiceworks.com/images/how_to_steps/0000/3886/t...

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

#247

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?

I think Google stopped caring about their reputation long ago. It's all lock-in and advertising increases now.

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

#248
post #62

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.

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

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

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

#249
post #7

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

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

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

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

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.

Post reply on HN