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
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 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.
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
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.
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.
> 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.
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.
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.
>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
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
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.
> 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.
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.
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.
Of course Google isn't going to look at the code. Most Google App Store apps are not open source, so why would that be a workflow at all?
You have to evaluate those same deliverables that are downloaded to the user.
To be able to infer properties of the build application from the source code review, it has to be shown that the two correspond; the shipped, built version comes from the code that was reviewed.
Poring over someone's source code is a fool's errand. You will never catch everything; people find 25 year old bugs in code that have evaded all previous pairs of eyes.
Google's approach here is poor though; they created these API's and permission model and now have to backpedal on it randomly.
If you want untrusted applications to have access to Contacts, it should be done with abstract tokens that do not reveal any contact details. Each contact is represented by an object handle that provides every imaginable operation you might want to do to, with or by-means-of a contact.
It's possible to design a system whereby some contact properties (e.g. mobilePhoneNumber) are accessible, but the result of the access is an abstract object that doesn't actually reveal the content, only represents its existence. The user interface could be priviled so that, say, a text field widget can be given one of these opaque objects, and then display the actual phone number. The only way to get at it would be to have permission to take a screenshot, and then OCR it.
Google does some pretty surprising levels of static analysis of compiled source, particularly surrounding their API usage. There's a few examples I've run into but the first that pops to mind is when they started requiring a yes/no confirmation dialog before allowing a user to access a non-https resource through the WebView. There was no way a human was running into that on the particular app I was working on. We're not talking advanced static analysis but it's not a simple decompile and grep either.
In another case I had accidentally left some dead/debug AWS access credentials in a build and they sniffed those out too. Notable since that's not even Google-related. They had to have been looking for a particular AWS library method signature and how it was fed. I would bet on their static analysis getting more advanced, in which case it could also be used to prove that OP is using APIs/permissions in a safe manner. But of course they're not incentivized to do that.
Yeah, it wouldn't surprise me if their static analysis saw the contacts being fed into a native binary (which they would definitely struggle to analyse) and threw up a red flag. From that point everything is futile because no one you can actually talk to at Google is empowered to disable the flag.
Google is a vast, schizophrenic organization. They're big enough that they have different teams and internal politics fighting each other all the time. It's not a unified consciousness with consistent incentives. Even if that's a bad take, Google is constantly seen in a negative light on Hacker News. The Google hive-mind doesn't care too much.
Incentives not being present and the company being unable to act on those incentives are very different things. Intel is incentivized to beat Apple, AMD chip performance. That they’re failing to deliver right now doesn’t mean the incentives aren’t present or that they don’t care.
Well, yea. Living things and organizations have incentives. The implication I gleaned from your original comment was that Google's incentive to avoid bad press on HN for its App Store policies is enough that it should use its static analysis abilities "for good". We're not debating the existence of incentives. We're debating the existence of consistent/unified motivation/ability/will to satisfy those incentives. Or are we debating? After your second comment I'm not even sure the point you are trying to make.
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.
I'm not sure what kind of importance you ascribe to HN, but from here outside of SF I feel like Google doesn't give a remotest shit about this gathering, and generally has the feelings sensitivity of a triceratops. Moreover, they're actively undermining power-user workflows on Android—so the attitude can in fact be measured as negative, if only by passing chance.
It was always funny to me reading those stories that Microsoft shares the source of windows with government officials who are worried they have NSA backdoors in a sterile environment: what on earth could you possibly spit from just reading source code? The function won’t be “postToNsa()”
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.
How much time did you put it your “abstract tokens” idea? Was it just something you came up with as you wrote your comment? You’re presenting it as “it’s possible to do this and here’s how” but I’m not really aware of any systems that do this in a practical manner. Out-of-process rendering is definitely a thing it’s not nearly as simple as “just render all sensitive content away from the app and this will solve all problems!”
This seems like the crux of things. Yes, contact information is sent from your phone to the internet. Therefore they need that flag for their app. Seems things are working as intended? The app is still free to tell the user a more nuanced privacy story if they want, right?
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.
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)
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.
> 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!
We had this issue and went back and forth with Google for weeks with no progress. It was infuriating, since the peeps on the other end just cut and pasted responses.
Then, we hashed the Contacts before uploading them and our app was immediately approved.
Subsequently, they decided to ding us on this permission "QUERY_ALL_PACKAGES", which we needed for inviting people you know to our app. Since we were so beaten down, we removed that feature. Congrats Google!
From a user perspective it’s good to hear about apps being forced to remove the “invite everyone you know” feature. It’s time for that obnoxious user-hostile growth hack to stop.
I don't want you to query my packages and I don't want your help to invite people I know to your app. That sounds like a feature that was made for your benefit, not for mine.
So it seems that Google made your app better for me as a user. Congrats Google indeed.
It's not helping them invite your friends to their app (which is impossible). It's helping you invite them if that's something you want to do (probably by listing the messaging apps you have and giving you pre-compose buttons; EDIT: confirmed by sibling comment).
If you don't want to use that feature, don't press the "invite friends" button and that code will likely never run. If you don't want the app to even theoretically have access to your app list, don't give it the permission. Is it not a runtime permission? That sounds like Google's fault, not the app's.
Not to channel the usual Hacker News acid at you but have you considered the optics of “we are using code that requests fairly broad permissions because we couldn’t be bothered to invest in doing a better job that didn’t have to do this”? I don’t see this explanation as being particularly comforting.
> 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?
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.
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.
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.
“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.)
We develop a banking app for families (parents and kids). 2 weeks ago we had to remove the possibility to pick phone contacts to invite other family members because Google claimed we were uploading contacts to our servers (which we did not).
We appealed and it did not work.
We then complied with their request and added to the privacy policy they we have access to the contacts and we might process them, and yet Google still rejected our app.
In the end we just decided to completely remove every code from the app that would allow us to read the contacts on the phone.
This has now made our app UX worse for the 60% of users who used this feature.
Also, mind that we of course offered the option to never grant this permission so nobody was ever forced to give access to their address book.
This is a mistake I see on iOS a lot. You can use a 'system picker' for some things without a permission - photos is the most common one - many apps request full photo library access which I never want to grant when they could just use the system photo picker instead.
In a similar way you could (in iOS) for this same feature just popup the share sheet to send a message. Though I am not familiar with the Android analog.
I believe in recent OS versions, whenever an app requests full library access, the OS asks you if you want to grant it, deny it, or grant a subset of photos which it fakes as the "full library" to the app.
Now, Android does this and only this, which is insane. It won't let you grant access to the main storage, Downloads or any other standard folder even if you explicitly navigate to it and select it.
Afaik access to main storage can only be granted if the app declares the "all files" permission. I'm not sure what's the deal with the downloads folder though
True, but the share modal is terribly broken. It changes every version, the order of icons is different every time you open it, sometimes icons and app names are mixed up...
I don't think google did anything wrong here (at least in the first half), afaik android app privacy permissions don't differentiate between "app has access to contacts locally" and "app has access to contacts remotely".
Probably because this would require thorough code review every time you shipped an update to ascertain as opposed to just identifying whether you accessed a specific API or not.
Of course that would be impossible to differentiate, but adding it to the privacy policy is what Google requests. Adding it and still having it refused can absolutely be blamed on Google.
What I don't get is why does sending contacts need to be added to the privacy policy? The point of the policy is to state what you will and won't do in a legally binding way. If my privacy policy says "the app may access contacts locally, but that information never leaves the device", that means users can sue me if I break that promise and I could even be criminally prosecuted. What more assurance does Google need?
I do not agree. We were explicitly asking for permission to access the contact list, the user was granting it and the user also had the option not to grant it and still use the app by manually entering the phone number.
What happened is that Google blocked our updates claiming we were doing something we were not doing, and even if we did access the entire phone book, the users agreed to it explicitly.
Another issue is that we would have been fine sharing a single contact with the PICK_CONTACT intent, however there's a bug open in Android since 2018 that causes developers to have to ask for the full READ_CONTACTS permission even just to pick a single contact[1].
So in our case Google did not respect the user choice, claimed we were using user data in a way we were not (without any proof whatsoever), still rejected the update even when we added what they asked us to add to our Privacy Policy and in the end they also don't even fix bugs in the Android codebase to allow developers to use more privacy-friendly APIs in their OS.
The permissions don’t differentiate, which is why an honest privacy policy is important. If they have access to the contacts but the policy states that they do not transmit, store, or process the contacts on their servers I can feel safer.
It appears to me that Google is asking companies to lie about their policies or otherwise make it their policy to retain contact data on their servers.
The only reason I can see for this is to make Google seem less bad when it comes to privacy compared to other companies because they can point to all these other companies you’re giving permission to store data with.
The parent comment literally says that their users always had the choice, but don't let me interrupt your knee jerk reaction.
> A win win for everyone is if Google allowed the user to turn this feature on manually in settings post app install but they don’t do that.
That is exactly how the Android permission model already works. But now Google/Play Store is enforcing additional restrictions on developers that use these permissions.
Oh, I wasn’t aware of this. Call it an uninformed reaction, oops. Thanks for pointing out my mistake! Maybe this post will be helpful for iPhone users who think that android users have no control until it’s already too late (I thought that, by default, contacts could already be uploaded before permissions could be revoked by the user)
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.
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.
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.
From my past experience, both Google and Apple fervently defend their built-in caller app, and really-really don't like any other app making regular voice calls. Part of that is that they don't want cloning (they clearly state that your caller app must look obviously different from default system one), which is understandable, but even when it clearly not a clone, they make take it pretty hard, it feels like they would rather just ban it.
Perhaps phones need an API so an application may request a single contact's information as selected by the user, without exposing the entire phone book?
In many phone brands using the PICK_CONTACT intent still requires the READ_CONTACTS permission, which allows to read all contacts. There is also an issue opened for this [1]
I do not. I can tell you that a Xiaomi device I tested was not affected. All Samsung devices I tested as well as Realme (and therefore I assume also Oneplus and Oppo) are affected.
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).
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.
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.
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
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.
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.
The problem is the same as always - automated bullshit black-holing instead of thoughtful review and constructive communication a human could do. Perhaps the latter is impossible (or maybe this is another bullshit) for companies with userbases this huge but do we really need such in the first place?
It’s very difficult to convince a marketing behemoth that their automated systems are harmful when those automated systems’ errors drive users towards said behemoth’s own offerings.
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.
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.
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.
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.
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.
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.
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.
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
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...
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'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.
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 !
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.
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).
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.
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:
Is Google seriously just run by AI at this point? I imagine at some point up the middle management chain it’s just a layer of AI making decisions that no one has the authority to override.
Similar to how Amazon warehouse workers say that they’re working for an algorithm at this point making hiring/firing decisions.
Amazon runs on hire quickly and fire quickly policy (many other businesses have already copied this style of recruitment), which is why they are finding themselves running out of massive pools of workers.
One possibility is that Google Play runs the app in a sandbox, monkey test it by clicking on everything, trace the outgoing connections and sees that one request contains PII from the sandboxed contacts. It could be a third party library that does it.
Play is surprisingly sophisticated, and with Google focusing only on automation, i wouldn't be surprised to see them have this level of testing. This particular test wouldn't even be hard to write.
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.
Even if the app uploads contacts to a server, is that a big deal? A lot of apps do that: WhatsApp, Telegram, Facebook, Instagram, Microsoft Teams, basically any messaging application. Of curse the app should ask permission to do so in accordance to local laws (such as GDPR if we are in Europe), but it shouldn't be a concern of Google.
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.
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
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.
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