EFF and EU should respond to Google taking FairEmail off the Play store
social.platypush.tech
social.platypush.tech
FairEmail stopping development after Google falsely flags app as spyware - https://news.ycombinator.com/item?id=31432334 - May 2022 (238 comments)
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'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 ?
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'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.
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.
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.
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.
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.
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.
Just recently, we had 2 customers that had their apps suspended because Google detected a non-existent HockeySDK
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?
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.
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.
Android users it is time you forked out more to support free software developers.
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...