Google is forcing us to make our open source VoIP app worse
voys.co.za
voys.co.za
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
And myself being an apple guy with a dev account, i can install pretty much what i want
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.
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.
Apple realised that far more than google imho
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
I'm going to go ahead and say that probably they are misrepresenting what is happening.
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.
The GDPR is exactly the same. Even the ePrivacy Directive (the so-called "cookie law") actually covers more than just cookies - any method of storage in a user's terminal (whether browser local storage, or an app's own database) is also in scope.
You don't need to ask permission to store a shopping cart or anything like that as a cookie.
The typical practice seems to be to set a session-cookie unconditionally, to be able to store user-related data within that session, even if the user has not provided any such information.
If not then that's fine.
If you do any tracking and you don't use cookies, you still need permission and if you use cookies but you aren't using them for data mining then you do not need to ask for permission.
> Voys Telecom SA (Pty) Ltd A company with limited liability duly incorporated in terms of the Companies Act of South Africa, 71 of 2008, with registration number: 2013/114285/07, hereinafter referred to as “the Service Provider”;
As far as I can tell though each different country office operates largely independently, almost as a franchise. So it might still be that the South African branch, with a registered local entity and no EU-based customers is more focused on POPI than the GDPR.
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.
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.
https://developer.android.com/about/versions/11/privacy/stor...
https://developer.android.com/training/data-storage/manage-a...
>To limit broad access to shared storage, the Google Play store has updated its policy to evaluate apps that target Android 11 (API level 30) or higher and request "All files access" through the MANAGE_EXTERNAL_STORAGE permission. This policy takes effect in May 2021.
I assume they want google apps to have access to the whole phonebook without looking too suss though.
Neither are the slew of apps that simply fucking break if they dont get access to every last one of your contacts.
Granular permissions intelligently designed do not make for a worse experience they make for a better one.
Frankly, over the last week I have been looking into whether there is a relatively straightforward way to write an app for a mobile linux, because I am at the point I am willing to get rid of several common apps, such as banking apps, to get off this nauseating hamster wheel.
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.'
And now many apps are written in js
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.
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.
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.
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.
But you don’t have to upload every contact neither you have to send any information associated with the number.
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.
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.
Besides, I repeat that Google is big enough that different factions have contradictory incentives. There are people in Google that want bad Play Store press on HN. I'll leave that as a thought exercise as to how that could be true.
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?
Yes.
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.
"Batch import" is querying the system Contacts Provider [0] with essentially a "SELECT *" query. This requires the READ_CONTACTS permission, which is granted by the user via a runtime permissions dialog. "Batch import" under this definition includes the use case of displaying the contacts list in the app's UI, regardless of whether that list is cached offline or uploaded somewhere.
The "contact picker" is an Intent the app sends to the system contacts application, which then returns a single contact. The UI is handled by the contacts app, filtering options are limited/non-existent, and there's no way to display app-specific metadata. It also requires no permissions.
[0]: https://developer.android.com/guide/topics/providers/contact...
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.
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.
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)
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?
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".
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.
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.
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!
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!
So it seems that Google made your app better for me as a user. Congrats Google indeed.
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.
Now that's just a lie and you know it. Is this legal?
(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.)
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.
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.
It might be hard to sell a product that behaves that way to websites though.
The best you can do is to complain to your country's data protection agency (in the UK this would be the ICO, in France the CNIL, etc). The problem is that they aren't enforcing the regulation enough to deter non-compliance. It's cheaper (in fact, free most of the time, the worst you will get is be asked to get into compliance despite breaching the regulation for years) to breach it for as long as you can than to respect it.
How long this takes depends on the problem and the capacity for the DPA. If Google or Facebook are involved in a new data sharing scheme, their cases will get priority over a website not setting cookies right.
Enjoy your vacation.
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.
- 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.
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.
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.
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.
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.
I didn't see in the post if they sell this or give it away.
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.
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.
This issues also hints that at least 4 years ago it was an Android issue and therefore all phones were affected. A lot of users still use phones from 4 years ago that have not been updated to the latest Android version by the manufacturer.
Also, in the issue comments some commenters say that it still happens in Android 11 and Android 10 which at this point are the Android versions that the majority of users have on their phones.
So, to answer your questions in short: all brands who released phones 4 years ago and have not updated the OS with an Android version with the fix can be considered "affected brands". It is a "best case scenario" because it appears also devices with the latest updates still show the same bug (the Realme and Samsung devices I tested were all running on at least Android 10).
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-...
That feels like changing the dialer, even if it's technically not.
Some apps require this, but the Android API allows apps to access very specific Contact information without having full access to all Contact data.
maybe that is something you just don't see a lot, but that happens often?
The one example you provided proves the opposite of what you wanted lol
Oh right, Google Maps and Gmail and who knows what else can have full access to those same contacts.
I think I found the reason Google is rejecting your app.
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!
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.
As the post you directly responded to never said the word never, I'm thinking you where actually responding to the previous comment. In which case: yes, never.
> Unless you give up on
I don't refuse to install apps, I have apps for both my primary banking organisations on my phone, I don't intend to write apps, I don't intend to provide extra fodder for their platforms and claims of their size. Most apps don't need the things that not being a native app means they can not support. NFC there might be uses for, but not that are irreplaceable that I can immediately think of, and you can access things like the phone's camera so other features like NFC might happen in that realm too.
And no, it's not mandatory for developers to use Google Play. It's a bit more work to DIY your app distribution, but you get total independence in exchange. It's ultimately developer's choice to make.
Lost in translation?
[1] blog story: https://www.voys.nl/blog/voys-wint-rechtszaak-van-agentschap...
(Native speakers on the other hand will say 'loose' vs 'lose', 'rouge' vs 'rogue', or even 'could/should of')
iOS didn't move the needle on open source, open bootloaders or anything gp mentioned. All iOS did was shift the balance of power from telecom companies to Apple.
Android was far more open than all that came before it: the source code was available,it used open source & contributed back, and brought a very "PC" mindset[1] to an industry that had always considered handsets to be appliances (save a few Nokia models in the Communicator line).
1. "Intents" that could be handled by any app of the users choosing was very much like "Open with..." on PCs. Even disregarding the open source stuff, Android was very much an open system just for that reason.
Android can be more open but let’s not pretend that a lot of devices have locked bootloaders, too, and has never lived up to that “PC” model due to things like proprietary drivers and apps refusing to run on unlocked devices. The future is very much unsettled here and we need something like legislation to reverse that trend.
Not all Android handsets have unlockable bootloaders - but all handsets with unlockable bootloaders run Android.
However, my main point was that outside of niche devices[1] that are rounding errors for smartphone consumer market share: the vast majority of devices sold with unlockable bootloaders already run Android: I'd guestimate > 95%. Looking at the list of devices supported by LineageOS (after enabling "Legacy Devices") is awe-inspiring. In the past, Samsung, Sony and Motorola had a solid lineup of unlockable devices.
1. I say this as someone who almost succumbed to the temptation of buying the Pine64 phone with the intention of contributing code
Android would not even have launched without the iPhone breaking down those doors, you can hear it first hand from the Handspring/PalmOS/WebOS folks: https://youtu.be/b9_Vh9h3Ohw?t=1609
Around 2007 we tried building an app that scanned barcodes in a store to show you comparison from online stores. Symbian's APIs for cameras were so broken, that we couldn't get a decent enough resolution of photos. Java had permission/ux issues that made the app unfeasible. It was literally impossible to build an app like this back then, even though phones had good enough cameras already.
Not to mention the fact that you needed a whole studio to build and test even a simple app like this - so many variants of OSes, and phones, and every single one had it's own quirks.
And to add an insult to the injury - we had to pirate the SDK, because the official links to SDKs didn't work for a few days, and nobody seemed to notice.
So yeah, in theory the users could download apps to the devices. But in practice it was easier for devs to hack into iPhone 1.0 and build apps there - even before the official app store launch, than it was ever to build something for Symbian and the others.
What probably did happen, a bit, was that ISVs that made software for other markets, may have ported their software to PDAs, and sold that. (E.g. "WinZip for Windows CE", things like that.) But that doesn't mean that these companies were surviving off of this. These were effectively "halo products" (products that don't sell many units, which are made instead to increase the brand perception of key influencers who happen to have such niche interests, and thus influence their [influential] opinion of the rest of the product range through the halo effect.)
Because of that, even before the official launch of an iOS SDK, there were more apps for iPhone (because people hacked it), than there ever were for Nokia.
For WindowsCE, sure there were apps, but phones didn't run Windows really then. Only PDAs.
Wait, also a whole freaking browser : Opera mini - don't say that isn't complex !
Yes. And it was marvelous.
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.
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.
Also even if it does happen, the users still won't care.
Even Apple eventually caved in and is now starting to turn towards the advertising route.
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).
https://cloud.google.com/blog/products/g-suite/elevating-use...
Similar to how Amazon warehouse workers say that they’re working for an algorithm at this point making hiring/firing decisions.
>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 ...
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.
Lottery apps had to do this for years.
If someone wants f-droid they'll do it. The problem is most people don't know what f-droid is. It has nothing to do with UX friction of installing it, there is virtually none.
No reason version 2 can’t do the thing after they upgrade and I already gave permission in version 1.
It is open source, giving them even fewer excuses.
If the app can see the data, it’s over already.
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
Stated as the inverse, what would more enforcement solve?
And, even if it was a solution, what would this additional enforcement actually enforce? A poorly written law, apparently designed to introduce additional friction into simple web browsing, with porous and easily-evaded definitions and vague goals that only apply to a tiny fraction of planetary inhabitants? (Because that seems to be the actual problem.)
Some shitty businesses who outright can't be profitable without stalking will fold which is a good thing (less spyware in the world), most will adapt just fine - executives/shareholders may just have to forego that new yacht or supercar.
> A poorly written law, apparently designed to introduce additional friction into simple web browsing
It's not poorly written. It's written very well to explicitly outlaw the kind of malicious pseudo-compliance you're complaining about. Its objective is not to introduce friction, it's to outlaw spyware (which we've somehow normalized over the past decade).
> with porous and easily-evaded definitions and vague goals
The goals are not porous - in fact the law is intentionally broad enough so that the spirit of any data collection/processing can be taken into account, rather than a specific technicality (which is why focusing on cookies is stupid because GDPR doesn't care whether you do your tracking with cookies, IP addresses or the shipping/billing address your customer provides). The goal of the law is again to outlaw the business model of spyware.
> a tiny fraction of planetary inhabitants
Is the EU that small? Come on.
Then why not just outlaw the spyware? Why go through the theater of "you can use spyware, but you have to get the user to 'agree' to it first, and you're not allowed to offer them anything in exchange"? That's just asking for the dark patterns and malicious compliance/non-compliance that we've gotten.
The spyware is outlawed, and so is coercing users into "agreeing" with it.
The problem is that neither restriction is adequately punished to deter the behavior; as of right now, you're better off profiting off spyware because even if you get caught (which is a very big if), the penalty is merely to ask you to stop doing so (and future compliance isn't monitored, so you can get back to your usual shenanigans once the dust settles).
From a GDPR perspective, it doesn't matter whether you don't ask for consent or coerce users into it - both are outlawed, however, because of lax enforcement, an industry of snake oil has developed to sell companies non-compliant solutions (because actual compliance would put them out of business), along with spreading falsehoods and misinformation to promote said business which is blatantly visible on this very thread.
If you truly want to comply with the GDPR, the answer is to rethink your business model and fire a lot of people. But since it's uncomfortable, everyone would rather pretend they comply by paying for an expensive, not-actually-compliant "consent management platform" and otherwise continuing as usual.
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.
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.
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.
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
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.