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.
Thankfully it's nowhere that radical, and we can avoid both Android and iOS and build towards a better future, thanks to the recent revival of "real" Linux smartphones.
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.
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.
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.
We've had NFC, banking, etc on rooted phones and even on windows desktops loaded with malware for decades now. Clearly there's a tradeoff that can be made here and the banks still find it worthwhile to offer the extra features and save money on staff even if it occasionally causes fraud.
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.
iOS allows sideloading too. Also just because Apple gains value from developers, the developers also gain value. It's a mutually beneficial relationship.
It is not real sideloading though. Any app that iOS installs needs to be signed with an Apple-issued certificate. You can't install an app on your iOS device without Apple involvement.
There are Android phones sold at least in Russia without Google services at all. People use them mostly fine.
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.
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?
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.
"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.
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.
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.
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.
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.
One founder leaves and the replacement has a different mandate and/or worldview. Happens all the time. You should assume any app requiring contacts and access to photos is exfiltrating them.
You may choose to assume that, or you may choose to believe them due to various other factors. The choice is and should be yours, not Google's. And even if you do choose to assume that, you're aware it's just an assumption, not a fact. But if Google does the assuming for you and gives you their assumption as a fact, you don't have that very important context.
Google is more than welcome to add a disclaimer such as "no claims in the app description have been verified and may change at any time" to all apps - I'd even welcome it. But don't make us lie to our users! (I'm not affiliated with the posting company, but I've had a similar issue in an app with location permissions for use on a simple map)
> 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?
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".
This isn't a case of "not using every part of the permission" (like it often is with the location permission, which you need to scan wifi an bluetooth). It's a case of asserting that an app does something just because it technically could, refusing to listen to any evidence to the contrary and demanding they put this nonexistent anti-feature in the description.
It's like demanding a folder encryption app rebrand 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.
>* It's a case of asserting that an app does something just because it technically could*
Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice.
>It's like demanding a folder encryption app rebrand itself as ransomware because it links against crypto libraries and has the file access permission, or a navigation app as "24/7 tracking app for stalkers" because it has a both GPS location and Internet access.
Not even close. Both your forced analogies involve something inherently negative ("ransomware", "for stalkers"). Google is not forcing this app to call themselves "malware" or anything like the situation in your examples, nor is Google asking the company to rename their application.
> Security should always be considered with what can technically could be done given the current code/permission/etc. Anything else is piss poor security practice.
Yes, "considered", not "assumed and banned on the basis of". If I consider what the app could do and chose to accept that risk (hint: you do that every time you install a program on a desktop OS, which have basically no sandboxing and often auto-update), I should be able to use it. Google is doing the deciding here and that's not ok. "There's nothing stopping the devs from abusing this access in the future" is a reason to be careful, not to completely disallow a piece of software (which is what Google effectively did).
> Google is not forcing this app to call themselves "malware"
Many people on this very forum regularly claim that software that does things like upload your contacts to the cloud for no good reason should in fact be considered malware. An app that explicitly brands itself as privacy-friendly being forced to claim it does something that violates user privacy is largely comparable to being called malware.
Let's try this analogy again: imagine Signal needs to call itself "not actually encrypted messenger" because they could in theory push an update that sent messages unencrypted or even forwared them to the NSA - they have all the required permissions!
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.
You're the first person I've ever heard saying this. People used to complain a lot about Android fragmentation, but J2ME was easily 50x worse. Maybe 100x.
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.
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.
Going back to the original comment, iOS improved the situation from the carrier having veto power over the entire experience to just the phone vendor and the App Store is more open than some of the earlier ones were (standard terms). It also doesn’t have the ad / activity data issues.
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.
I realized my comment could the interpreted the way you did as I was writing it, and left it ambiguous (because that too is a good thing enabled by Android's openness)
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
Today yes, but as Google has been tightening the screws on Android, and as Google becomes ever less welcome outside of USA, I expect this trend to reverse...
Apple is indeed the driving force that improved "targeted advertising, media consumption and unnecessary services subscription" compared to the old "Open the Web Browser and Owe 10 dollars" days by leveraging their iTunes userbase.
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
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.
As a developer from that era - developing for Symbian was absurdly difficult and awkward.
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.
Before Android and iOS, no third-party developer cared about smartphones/PDAs, because they were a tiny sliver of the market and so you couldn't make money targeting them. Bigcorps like Microsoft/Facebook/Twitter might make free apps for these, just to cover them (since their own employees used them); but no ISV cared. If you were an ISV developing paid "apps" for "mobile" at all, you were developing J2ME apps for feature-phones.
That's plainly not true. Sure, there weren't "millions of apps" in the store, but like I mentioned above, there was actual boxed software sold for those platforms.
My point is that no ISV ever bootstrapped or got VC-funded in the 1995-2007 period by making a bet on selling "apps" for the PDA software market; the revenue would be too low to keep the company going, and the TAM would be too low for even longer-term-minded VCs to be interested.
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.)
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?
What? No, no, no. iOS and Android were night and day compared to Symbian and the other operating systems of that era. Aside from the very basic games and super-simple apps, it was virtually impossible to write anything significant for non-Apple/Android devices.
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.
You have forgotten the video calls, have you ? Which is quite understandable, it's not like we use those much even today (in real life, I'm not talking about ads and movies), despite not having to pay extra to the cell carrier !
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.
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.
I don't think that's likely to happen either. If it does, you'll just end up with rooted phone's reporting themselves to the carriers who will likely cut them off.
Also even if it does happen, the users still won't care.
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.
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.
> 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?
“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.)
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.
> 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.
You can't sue them. That's the reason so many non-compliant consent flows are out there, and entire businesses have been built on providing them as a service.
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.
You report them to your local DPA. The DPA will look into the complaint, ask the company to fix the problem and/or start an investigation, and maybe eventually, hand out a fine.
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.
Is there somewhere I can bet money on this not happening? Anyone who has to ask whether something is allowed or not and then how they can "sue" based on the one line comment to their question they couldn't be bothered to search for isn't suing anyone.
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.
I'm sure they are making money off of any data they can, but their actual strategy was pretty clearly buying potential competitors to ensure the company continued to dominate the market even if the facebook site began to lose users: https://www.ftc.gov/news-events/news/press-releases/2021/08/...
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.
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.
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.
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
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.
Look up the Epic/Fortnite situation and the only conclusion from its development and Epic's decisions is that it almost never happens and unless your market is exclusively techies you'd be foolish to consider it viable as your sole release channel.
They tried to make it its main distribution channel to avoid having to pay Play Store fees. They ceased doing it because it was much harder to acquire customers via sideloading despite the product being motherhugging Fortnite than it was to pay the tax on every "micro" transaction.
So why didn't Pokemon Go pull out of Google Play? Your only example is from 6 year and keep the 30% which Google takes? You only have one example from 6 years ago and people only sideloaded there only because it wasn't available on Google Play.
The one example you provided proves the opposite of what you wanted lol
So all they need is 20 years to build up a fanbase in a product universe worth tens of billions of dollars and everyone will be clamoring to sideload their app as well.
But this does contradict your point that "nobody installs apps from outside of Google Play". And, if they're installing something like a loyalty app, they won't care very much whether that QR code leads to Google Play or to an apk. The process is really no different than running an .exe you downloaded on your computer.
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?
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.
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.
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
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.
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.
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
The initial barrier of getting grandma on an iphone is over and the need to dumb down devices to the lowest iq to gain marketshare should be over. It is time to raise the collect iq and at least offer a way to drop the training wheels
>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.
This is funny, but in practice there would be maybe one or two of these bars. Many didn’t work together. These toolbars didn’t stop people from being able to work, eat, or pay their bills. I know. I lived through this era.
>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.
In a way, but not for your reasons, they want to create mass market devices that if you give one to your grandma, little nephew can twist their arm for the root password to install this totally harmless fun app
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.
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.
> 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.
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.
I agree, it's not necessarily only login credentials, but could be a shopping cart. However, no shopping cart is needed until the user adds an item to it. Watching the shopping window doesn't need 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.
GDPR is also nothing about cookies. It is about collecting tracking and marketing data about someone without their permission.
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.
No it’s not, why would you claim it was? The domain TLD is South African (.co.za), the phone number listed is in Cape Town, and it’s a South African registered company.
> 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”;
Ah, got it. Yup, the Dutch office is the original one, there are a bunch of others around the world.
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.
We're an international telco, with two separate local entities & local teams, that are governed by different laws. The voys.nl website most certainly has the cookie consent screen.
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.
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.
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.
>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.
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...
This is a horrible user experience, ends up like iOS where there are great apple apps, and everything else is second class. The great thing of android is that you can choose a different dialer or different sms app, and it can be as good as the preinstalled one
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.
That sounds like iOS? Only Apple apps have access to all the system level capabilities and you can't replace any of the system apps, not even the browser.
It would be fair if one were to conclude that I don't like iOS. But my comment made a few different points, including about google's app quality, not only forcing default apps but also disallowing user choice where it should exist in a pervasive, hard to see way (for the end user), and invasive tracking.
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.
There is Anbox, which just uses the same kernel for Linux and Android. But it is incomplete and not very active. Basically, we don't even need a hypervisor, but apparently it's still not easy.
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.
> 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.
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?
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.
The thing is, there's no way to prove you won't do something in the future if you have the ability to do it. All you can do is promise that you won't, preferably in a legally binding way (such as a privacy policy) and stake your reputation on it. That's the basis of society. Just because someone doesn't believe you doesn't give them the right to force you into a false confession.
The app developer says "all your contacts stay on your phone, we only use the internet for calls". Google says "this app is able to access both your contacts and the internet any time for any purpose". Both of those statements can coexist and be presented to the user for evaluation. The app being required to pretend like it's uploading your data is just lying to the user.
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).
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:
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.
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.
But that's not "discouraged by the system UX" and what better way to get people to use f-droid than offering incentives to use it? Like your favorite app having better features when installed from there?
Sorry, but if you do not believe getting security warnings, having to go into the settings and mangle with configuration, just to be able to install a store downloaded from a website, sometimes go through additional configuration depending on your phone's modifications (looking at you Xiaomi) to then install the actual program you wanted is not "discouraged by the system UX", despite the real world experiences of companies who have tried even simpler things and failed, I'm not sure we can agree on what's viable or not.
The amount of time it took you to type this response is longer than it takes to enable third party sources in settings. Most people do it at some point anyway, such as when downloading an app they want from it's website. There's no mangle about it, it literally pops up with "allow this app to install applications?" and takes you there directly.
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.
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.
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
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.
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
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
A lack of enforcement is definitely not the problem.
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.)
More enforcement will force businesses to remove obnoxious consent flows as those are already in breach of the regulation and it just needs enforcement. Consent should be explicitly opt-in, you can't force it with annoyances, dark patterns or denying the service.
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.
Its objective is not to introduce friction, it's to outlaw spyware
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.
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.
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.
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:
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.
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.
295 comments
[ 2.7 ms ] story [ 282 ms ] threadIf 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.
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.
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!
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.
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.
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
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.
https://github.com/anbox/anbox
https://waydro.id/
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.
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...
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')
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.
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
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.
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.
I didn't see in the post if they sell this or give it away.
https://github.com/deltachat/deltachat-android/issues/82
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.
>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 ...
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.