Related ongoing thread:

FairEmail stopping development after Google falsely flags app as spyware - https://news.ycombinator.com/item?id=31432334 - May 2022 (238 comments)

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.

> He then repeatedly refused to fix the issue.

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 ?

He may not be intentionally “uploading” contact info, but the HTTP server could be configured to keep log of all the contacts email addresses.

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

[email protected] [email protected] [email protected]

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.

Yeah I read the runthrough here : https://news.ycombinator.com/item?id=31432334

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.

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.

Can you provide a source for the contact list scraping?

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.

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.

This has some details and a code link: https://news.ycombinator.com/item?id=31434975

Thank you!

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:

[email protected] [email protected] [email protected]

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.

I took a look at code. This is an edge case.

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.

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

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.

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.

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.

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.

In my experience 9/10 times are spurious detections.

Just recently, we had 2 customers that had their apps suspended because Google detected a non-existent HockeySDK

> about 9/10 times when Google removes an app it's because it is actually doing some very shady spyware type stuff

If Google removes apps for invalid reasons 1/10 the time, that's a big window for abuse.

"It seems"???

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?

Could you post the source for the 9/10 claim? Thanks!

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.

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.

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.

> Why would google care about the email client people use.

Because the "client" is where advertising can be most easily inserted to monetize that user.

But they don’t. Or does the default mail client on Android come with built-in advertisement?

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.

I trust FDroid more than I trush Google.

I'd rather not trust either. Right now both can impersonate any developer out there and nobody would be any wiser.

true. but fdroid has the better track record.

> FDroid gave FairEmail a clean bill of health.

This means nothing.

according to boole1854[1] the app was uploading contacts to be able to download favicons, without disclosing that it was uploading contacts.

1: https://news.ycombinator.com/item?id=31434975

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.

Common sense says the developer is giving up because it is not worth it, ie not enough people buy the software or donate to support its development.

Android users it is time you forked out more to support free software developers.

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

If that were true, wouldn't Google have to verify the security and privacy compliance of every browser out there?

I confess that I don't have a clear understanding of why browsers never seem to count in privacy discussions.

The GDPR prohibits companies sharing customer data with third parties without consent of the customer.

It most certainly does not prohibit customers disclosing their own data to third parties.

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.

That was mostly because the data sharing was intentionally opaque.

Saying the GDPR prevents me from letting my email client access my contact list is insane

Also, if I run software then it's first party.

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

Roger this

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.

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.

It's actually up to Google to prove this, both logically and legally.

https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...

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.

Nah we can do both.

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.