> Google keeps harassing the developer as it considers the app as "spyware", but it refuses to provide ANY details about their findings, or inform the developer on what they are supposed to change to get the app approved again.
It seems like about 9/10 times when Google removes an app it's because it is actually doing some very shady spyware type stuff. I'll be interested to see what this email app is doing. And just being open source means nothing. Nobody knows what code was submitted to the Play store.
Very often, the policy violation cited is very very broad, and "worst case", but not enough information is given to find the specific issue.
In this case, it is my understanding that firstly it isn't clear what the actual allegation is (making it very unhelpful for the developer, as they can't meaningfully respond), but that the suspicion is it may be linked to an (off by default) option to show the favicon of a sending email domain.
That would entail making a DNS request to the domain in question, and then looking for a favicon on the domain. That doesn't seem in any way related to spyware as it's off by default, user requested, and not sending information to a third party.
Valid point around the exact APK uploaded for distribution - I'm not sure of the state of the art for reproducible builds on Android, but the full gradle configs are in the repo for creating GitHub or Play Store releases as far as I can see - if reproducibility in android has got any better, you can likely get to the same binary, modulo API keys and similar, as the developer seems pretty diligent at tagging releases etc.
and as a counterpoint: FDroid gave FairEmail a clean bill of health.
FairEmail, if popular, would give users the unfortunate ability to sidestep an appendage of the lucrative ecosystem of googles surveillance capitalism by eschewing the default email client.
Why would google care about the email client people use. They may care about the email provider people use, because that‘s where all data passes through. But I‘m fairly certain that for all they care, you could have your mail printed or view them as an expressive modern dance piece.
Personally I don't know, as I use K-9 Mail from F-Droid.
But from the viewpoint of an advertising company, keeping the option open to insert ads, even if they may not be doing so at this time, is in their best interests.
FDroid clearly didn't detect how the app queries contacts from an external server. Neither does FDroid check if the app uses newer better APIs to conduct its activity.
That suggests you don't know what you are talking about. You are talking about a very popular app. If it is doing something shady shouldn't there be hard evidence by now?
Imagine if the power company cut off people’s electricity in error 1/10 of the time. That’s insane and dangerous.
Apps are an important part of the economy and having a false positive rate of 10% when the consequence is severely harming a company is unacceptable.
Not sure if it means regulators should get involved but Google (and to a certain extent Apple) have had this problem for many years and it doesn’t seem like market forces are going to change their policy.
I think the angle to take here is that Google is being anticompetitive by blocking a mail competitor from Android. So I think anti-trust is the existing set of laws that apply and hopefully will be pursued.
Hopefully it’s just Google’s stupidity and not malice, but I think all the data to determine that is private and confidential to Google so requires some legal compulsion for evidence in order to investigate.
If this statistics is true, then Google is removing lots and lots of legitimate apps. This is exactly why a monopoly is bad. 90% is nowhere close enough accuracy for such a system.
Looking at the code, it wasn't uploading contacts - rather it retrieved the favicons by looking on the domain in question, when a user turned that feature on manually.
Some apps do upload user contacts - they take the whole list, and cart it off to their own server. The app doesn't seem to be sending anything to its own server - it's fetching something the user asked it to fetch.
You should also know that this is the developer of the popular Xposed modules XPrivacy and XPrivacyLua.
These modules allow one to 'spoof' data to apps on Android, such as the wifi SSID, device identifier, etc. It is a lot more fine grained and in depth than Androids default permissions.
Not saying that has something to do with this but it is something to keep in mind, politically speaking.
> Email clients alternative to Gmail, as well as any app that accesses what Google deems "sensitive user data" (including emails, calendar, fit data etc.) will now require an expensive (talking of at least $4500 a year) and intentionally cumbersome certification process, and such a certification needs to be renewed on a yearly basis
Isn't Google required under the GDPR to verify the security and privacy compliance of any third party apps they send user data to? This really starts to cast doubt on the rest of the story for me; any app developer who hasn't been hiding under a rock since 2010 must know why modern companies insist on certifying third party apps with API access.
It doesn't, but in this scenario the data is flowing directly from Google to third party code without the customer sitting in the middle. Even under the much more lax US privacy rules, user consent isn't a panacea - Facebook was famously fined $5 billion for allowing users to authorize data sharing with Cambridge Analytica.
Respond how exactly? The last thing you want to do as an organization like this is to take action and then find out that the removal was warranted. I think it is up to the app developer to supply sufficient information to show that it was not warranted.
In another posts, someone already showed where they are essentially uploading contacts to remote servers. I agree it sucks cause I had seen the app on F-Droid and it looks like it was actively developed, but the developer stopping development because of the Play Store removal doesn't help instill confidence. Otherwise, they'd just continue development and support F-Droid and alternative Play Store initiatives.
Some sort of competition related action would be the obvious answer. Google is using their market power to harass an alternative to their data collection funded services.
That is why it is called Play Store policies. You want to go after an anti-competitive company, at least target Apple first who won't even let you sideload apps.
The developer is obligated to prove that they aren't guilty of something without being told what that thing is?
Other people's detective work is just guessing. Google has not given any specific instructions, and so they cannot be followed. It IS on Google to be fair here. If the action is so hainous, then they can certainly say "this action is not allowed" so that the developer can satisfy them. List all the reasons why Google might not do that, and find a single one of them that's valid.
Why do the threads about FairMail contain so much misinformation? It wasn't uploading the contacts to any server. It was fetching favicons from the domains of each contact. That too was opt-in. It feels like there is an effort to discredit Fairmail here.
The developer was scraping contact lists and using that to query third party servers. That is explicitly forbidden by google without permission from the user. He then repeatedly refused to fix the issue.
They should perm-ban folks like this who don't take user privacy concerns seriously.
Separately, it looks like he is using unsupported API calls potentially which are going to cause crashing problems - that may be a factor in their eval.
Having dealt with situations where user error / issues were 99 to 1 the source of problems, the majority for just a failure to read the instructions, whoever has to deal with this stuff on the google side has got to be annoyed at both these app devs and their social media followings.
It seems like this was an opt-in feature, that was off by default, that allowed users to have a domain's favicon shown alongside the message. It doesn't seem like any contact info was sent. Indeed, if you go to the effort of turning on favicon showing, it also seems pretty obvious and intuitive the app will retrieve the favicon. And the way it's done here seems to be more privacy preserving than having a central server do this (and see what you request).
This feels a bit to me like Google saying "web browser leaks details of your requests to a third party" - alarming, until you realise the third party is the DNS server, and that's how the internet works.
It's a bit harsh, but I would have thought that the domain filtering would be done on device and favicon retrieval also on device. I must check the source code tbh.
It appears domain filtering and favicon retrieval are indeed done on the device, looking at the code. It also appears to be off by default, requiring a user to turn it on manually. It looks like this also excludes any mail in the junk folder (to preserve privacy even when someone turns this on, presumably)
I can't see how to do it in any more private way than this - it seems akin to a claim of "browser leaks details of requests to a third party", where said third party is the user's DNS server.
Which HTTP server? the getFavicon method requests the favicon from each domain, so any one email provider only gets a single request for a favicon. It doesn't send all the contact info to any single server.
So reading the code, say you have in your contact
b@acme.com
a@acme.com
c@google.com
The code makes a single request to acme.com (to get the favicon) and one to support.google.com to get that favicon (there's a special case for google to avoid getting the new doodle of the day). That's it.
I don't really see how that's sharing contact details.
It was getting the favicon for the domain name of the emails not sending the actual contact list to anyone so you're spreading misinformation by shortening this to "The developer was scraping contact lists and using that to query third party servers".
Also that's very different than "sending/sharing contact list data.", it's not, it's querying the domain names to get the favicons. So I get why the author wouldn't want to declare that he is doing that when he isn't.
To repeat what I said below, reading the code, say you have in your contact list:
b@acme.com a@acme.com c@google.com
The code makes a single request to acme.com (to get the favicon) and one to support.google.com to get that favicon (there's a special case for google to avoid getting the new doodle of the day). That's it.
No one gets the contact list, the most anyone gets is that your ip requested a favicon.
He does use users contact lists without clear disclosure. He uses their contact list to retrieve DOMAIN favicons. That's better than systems retrieving gravatars or similar which I thought this was.
My guess is still technically a violation (using contact list to generate a bunch of HTTP requests). For some folks this could be sensitive maybe (if contact list has some onlyfans.com "friends" on it and your corp DNS / web tracking thing starts flagging it for the weekly report).
But not as bad as I feared. That said, the whole, I refuse to change x is going to fall flat with google who probably don't care about nuance that much.
FairEmail is one of 5 apps I have ever felt motivated to purchase the pro version. It's unparalleled in it's performance, privacy, and battery efficiency. Don't give up Marcel
56 comments
[ 3.0 ms ] story [ 264 ms ] threadIt seems like about 9/10 times when Google removes an app it's because it is actually doing some very shady spyware type stuff. I'll be interested to see what this email app is doing. And just being open source means nothing. Nobody knows what code was submitted to the Play store.
In this case, it is my understanding that firstly it isn't clear what the actual allegation is (making it very unhelpful for the developer, as they can't meaningfully respond), but that the suspicion is it may be linked to an (off by default) option to show the favicon of a sending email domain.
That would entail making a DNS request to the domain in question, and then looking for a favicon on the domain. That doesn't seem in any way related to spyware as it's off by default, user requested, and not sending information to a third party.
Valid point around the exact APK uploaded for distribution - I'm not sure of the state of the art for reproducible builds on Android, but the full gradle configs are in the repo for creating GitHub or Play Store releases as far as I can see - if reproducibility in android has got any better, you can likely get to the same binary, modulo API keys and similar, as the developer seems pretty diligent at tagging releases etc.
FairEmail, if popular, would give users the unfortunate ability to sidestep an appendage of the lucrative ecosystem of googles surveillance capitalism by eschewing the default email client.
Because the "client" is where advertising can be most easily inserted to monetize that user.
But from the viewpoint of an advertising company, keeping the option open to insert ads, even if they may not be doing so at this time, is in their best interests.
This means nothing.
If Google removes apps for invalid reasons 1/10 the time, that's a big window for abuse.
Really?
That suggests you don't know what you are talking about. You are talking about a very popular app. If it is doing something shady shouldn't there be hard evidence by now?
Apps are an important part of the economy and having a false positive rate of 10% when the consequence is severely harming a company is unacceptable.
Not sure if it means regulators should get involved but Google (and to a certain extent Apple) have had this problem for many years and it doesn’t seem like market forces are going to change their policy.
I think the angle to take here is that Google is being anticompetitive by blocking a mail competitor from Android. So I think anti-trust is the existing set of laws that apply and hopefully will be pursued.
Hopefully it’s just Google’s stupidity and not malice, but I think all the data to determine that is private and confidential to Google so requires some legal compulsion for evidence in order to investigate.
Just recently, we had 2 customers that had their apps suspended because Google detected a non-existent HockeySDK
1: https://news.ycombinator.com/item?id=31434975
Some apps do upload user contacts - they take the whole list, and cart it off to their own server. The app doesn't seem to be sending anything to its own server - it's fetching something the user asked it to fetch.
Isn't Google required under the GDPR to verify the security and privacy compliance of any third party apps they send user data to? This really starts to cast doubt on the rest of the story for me; any app developer who hasn't been hiding under a rock since 2010 must know why modern companies insist on certifying third party apps with API access.
It most certainly does not prohibit customers disclosing their own data to third parties.
Saying the GDPR prevents me from letting my email client access my contact list is insane
In another posts, someone already showed where they are essentially uploading contacts to remote servers. I agree it sucks cause I had seen the app on F-Droid and it looks like it was actively developed, but the developer stopping development because of the Play Store removal doesn't help instill confidence. Otherwise, they'd just continue development and support F-Droid and alternative Play Store initiatives.
Other people's detective work is just guessing. Google has not given any specific instructions, and so they cannot be followed. It IS on Google to be fair here. If the action is so hainous, then they can certainly say "this action is not allowed" so that the developer can satisfy them. List all the reasons why Google might not do that, and find a single one of them that's valid.
https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
They should perm-ban folks like this who don't take user privacy concerns seriously.
Separately, it looks like he is using unsupported API calls potentially which are going to cause crashing problems - that may be a factor in their eval.
Having dealt with situations where user error / issues were 99 to 1 the source of problems, the majority for just a failure to read the instructions, whoever has to deal with this stuff on the google side has got to be annoyed at both these app devs and their social media followings.
I currently use FairEmail, so that's a concern for me, but I'd not heard that it was happening in this conversation so far.
This feels a bit to me like Google saying "web browser leaks details of your requests to a third party" - alarming, until you realise the third party is the DNS server, and that's how the internet works.
I'm not too sure if that is actually the case. I'm only going on what the developer has mentioned in the forum about it, specifically here : https://forum.xda-developers.com/t/app-5-0-fairemail-fully-f...
From his own words :
> The app most certainly doesn't upload any contact info, unless maybe your email address to login to the email server.
> but they don't provide any details about what the app presumably is doing wrong.
Where are you getting the info that it was scraping contact lists and sending it to 3rd party ?
It's a bit harsh, but I would have thought that the domain filtering would be done on device and favicon retrieval also on device. I must check the source code tbh.
An interesting case though.
I can't see how to do it in any more private way than this - it seems akin to a claim of "browser leaks details of requests to a third party", where said third party is the user's DNS server.
So reading the code, say you have in your contact
b@acme.com a@acme.com c@google.com
The code makes a single request to acme.com (to get the favicon) and one to support.google.com to get that favicon (there's a special case for google to avoid getting the new doodle of the day). That's it.
I don't really see how that's sharing contact details.
Also that's very different than "sending/sharing contact list data.", it's not, it's querying the domain names to get the favicons. So I get why the author wouldn't want to declare that he is doing that when he isn't.
To repeat what I said below, reading the code, say you have in your contact list:
b@acme.com a@acme.com c@google.com
The code makes a single request to acme.com (to get the favicon) and one to support.google.com to get that favicon (there's a special case for google to avoid getting the new doodle of the day). That's it.
No one gets the contact list, the most anyone gets is that your ip requested a favicon.
He does use users contact lists without clear disclosure. He uses their contact list to retrieve DOMAIN favicons. That's better than systems retrieving gravatars or similar which I thought this was.
My guess is still technically a violation (using contact list to generate a bunch of HTTP requests). For some folks this could be sensitive maybe (if contact list has some onlyfans.com "friends" on it and your corp DNS / web tracking thing starts flagging it for the weekly report).
But not as bad as I feared. That said, the whole, I refuse to change x is going to fall flat with google who probably don't care about nuance that much.
FairEmail stopping development after Google falsely flags app as spyware - https://news.ycombinator.com/item?id=31432334 - May 2022 (238 comments)
Android users it is time you forked out more to support free software developers.