I've read the responses from Google that the developer copied and none of them clarifies exactly what's wrong. If this is really the issue then they should have explained it clearly instead of saying that the app is a spyware.

This seems to be the root problem with Google Play's developer experience - no matter how much you ask them what is wrong, they will not tell you (despite this being straight-up illegal in Europe).

You get a copy-paste of the same non-explanation as a non-answer, which is presumably either automated or being sent by a human with no understanding of anything, and therefore might as well be automated.

It doesn't identify the client, though.

So the site only learns that the IP has someone on that domain among its contacts. They probably already know more than that, because they've seen some emails being exchanged. Not 100% tight, but definitely less problematic than using Gravatar.

The traffic can be sniffed as the certificate validation looks disabled and it falls back to HTTP. Meaning ISP can take a peek.

But it's definitely not malicious in any way.

Suppose I happen to have someone with an @onlyfans.com email address on my contact list. And I run the FairEmail app on my phone while at work. My phone then hits the corporate DNS server with a request for onlyfans.com, even if I haven't emailed that person. Not great.

Or suppose I'm a Russian dissident in Moscow with a list of Ukrainian-government and military contacts on my contact list. I open FairEmail and suddenly my phone does DNS lookups for a dozen sensitive Ukrainian domains. Not great.

Edge cases like this can be multiplied.

It's not malicious. But it's not great. And it seems reasonable to me for the Play Store to require a disclosure before an app does this.

You can literally just hover over a link and the browser (Chrome at least) may initiate the same DNS lookup. Sure, you don't want that in hardcore opsec, but claiming that it's on the same level as sending your contacts to a remote server is outright wrong.

Well if you receive an email from any of those, your email client requests something from those domain names (which a lot of email clients will do by default). So it'd also show in the firewall logs etc..

So that favicon feature should be an optional feature but calling it sharing contact details is really exaggerating it.

EDIT: It is even optional, so yes really it's a non-issue.

My understanding is that this was an optional feature, and turned off by default - a user wanting to use this would need to enable it manually.

If a user turns on a feature to request favicons for received mail, it therefore seems logical that the app has to retrieve favicons. Doing direct retrieval is likely less damaging to privacy than using a central favicon retrieval server.

I use FairEmail so I just checked: Display Favicons is disabled by default and there's a note below the setting that says "there might be a privacy risk" and links to https://en.wikipedia.org/wiki/Favicon

Agreed, 1) it's not sharing contacts, 2) it only pings those domains if you enable the optional feature. This is exactly how I'd want the app to behave, and I honestly can't think of a better way to handle it.

Maybe caching the favicons on a server hosted by the app creator so that no matter what domain the app looks up, it looks like it's contacting FairEmail.

But in that case, the app creator would have a list of domains which I think is objectively worse from a privacy perspective...

I'm honestly a bit annoyed that OP is the top comment on HN when it exaggerates the impact of this feature.

OP here. You are right.

But google didn't ever elaborate or confirm that this was actually the reason for not approving the app. So we can argue about this feature being problematic without even knowing if that's the culprit... In my opinion, it must be very frustrating to deal with Google in this instance.

Or you open a web page and it loads pictures from all of those domains, and worse. You hit whatever DNS resolvers with any number of domains you may not like. Play store Google daddy protecting you or not.

In the hypothetical that you're hiding from an authoritarian state, you can avoid websites because you expect this behavior.

The problem here is the app was deceptively processing contact lists without user consent, and when asked to get user consent, the dev refused. If you're a transparency- or privacy-branded app, then you doubly need to disclose this information to the user.

Yes, in that hypothetical this may be an issue. But if you fear a DNS resolver, it is really not sensible to use Android and any Playstore app without some filtering proxy in between: 1) first for verification in a safe environment and 2) in real dangerous scenarios once you're sure it's safe, and without installing/using any previously unverified apps or any new updates (good luck ensuring that).

Google didn't save anyone, by discouraging an exceptional developer with this kind of privacy policy https://github.com/M66B/FairEmail/blob/master/PRIVACY.md from contributing anything further on to Android app ecosystem, while keeping all the data stealing apps and ad supported apps, and Facebook SDK using apps, in play store.

How is it without consent? It's an optional feature disabled by default.

> They probably already know more than that, because they've seen some emails being exchanged.

Someone being in your contacts list does not mean you have ever had any contact with them.

Thanks for the background; there's usually (not always, but usually:) details and sides and perspectives; it's scary how quickly we can all come to judgment based on single factoid which we integrate into our worldview and spin into something larger. Not to say I don't understand emotions and perception of unfair demands; but I'm grateful to know a slightly bigger picture.

Well read further about the background, in this case, that specific feature doesn't share the contact list, it just queries domain name. it's optional and anyone asking to show favicon for domain names in contact should expect to know that it's going to be queried in this way?

Also, Google didn't give that as the reason for the app being classified as spyware. So it's just the OP being contrarian by taking an optional feature, claiming it shares contact details when it in fact doesn't and everyone voting it up because it sounds reasonable.

Google may not have given the specific reason but isn't it a reasonable guess based on what they told the dev? It seems like it's what the developer thinks the culprit is too. His commit yesterday was to disable it for the Play Store version, and it included the comment of "Google doesn't allow favicons for privacy reasons".

Well, he's been stumbling in the dark and decided to try this but I don't think it's necessarily a reasonable guess. In hindsight, it's easy to look at this commit and see that as being the reason, but if I were the dev, it wouldn't be my first idea, especially since this feature has been there for a while and since it doesn't actually share contact details at any point, it's just a feature related to contacts that optionally retrieves the favicon.

Of course, if I were the dev, I'd eventually try and go through anything that touches contact and disables that to try and see if that solves the problem, but again that shows that Google doesn't communicate at all.

I think part of the issue is it isn't even clear to developers when (or if) the issue is fixed.

It seems that there is firstly no reason or clarification given. Then, it seems the process of reviewing an update can happen out of phase or sync.

That means there's a very weak "compliance oracle" to see if you've correctly identified the right issue or not. And with high latency, likely it will be difficult to find the right issue quickly.

Disabling everything isn't really a good solution in the longer term as a developer - Google needs to learn to communicate with developers via intelligent humans that actually understand what they're doing, and can have a discussion and help get the issue addressed.

No it's not a reasonable guess. The favicon code is in the git for at least 2 years (didn't bother to click Older button more times on github).

Google just has a demented communication policy.

Ah well, it seemed reasonable to me because that was one of M66B's first guesses too. His first comments about this publicly mention guessing that it's favicons, but I suppose he could have eliminated several other possibilities first.

I think almost everyone would be agreement that Google can communicate better.

Just the fact that we're so quickly to jump on Google for blocking legitimate violators speaks volumes on its reputation.

In this era of quick outrage, thank you for doing the job of trying to figure out what is really going on, at the risk of taking the less socially acceptable side.

Did you check the links before congratulating on the fact checking?

For example for "And Play agreed to allow the app back into the store. [4]" The linked comment doesn't state this.

Nope, they made some important mistakes and admitted it.

You are part of the problem by immediately accepting that post as fact!

Thank you for the play-by-play. Had a hard time distilling this.

Maybe it's just me, but the developer at least appears a bit too emotional and impulsive. I'm not clear why this warrants shutting down, but it's not like there is an objective standard on such a decision.

I think it seems like this is a "straw that broke the camel's back" situation - Google's refusal to actually deliver any kind of sensible level of basic communication with developers seems to be the root cause of this.

https://forum.xda-developers.com/t/app-5-0-fairemail-fully-f...

When they simply copy-paste the same message (with no further clarification or content), it's a perfect example of a chronically broken system.

Google operates at a scale where they are unlikely to face any incentive or enforcement that requires them to follow the laws around this in Europe, which require meaningful individual interaction from marketplace operators. That they can ignore these laws with impunity effectively shows that (in this context) the rule of law is dead.

In my view, it is very hard to blame the developer - they appear to have been trying to understand the issue in good faith, and receiving absolutely nothing of any sense from Google. And their lack of any kind of meaningful human support is hopefully a "canary in the coalmine" for what will happen in future if we don't get a handle on automation of processes and the harm this can cause to real people and businesses.

> this is the sending of information off each user's contact list (the email address domains) to those remote servers. As such, it requires a disclosure to the user.

That's really interesting.. Honestly, I wouldn't have even picked up on that reading the code, as it's only the domain of the email itself. Not any identifiable information.

Feels a little but harsh but fair enough.

I wonder is there an identifiable marker which could say `"User X has a contact list containing gmail, yahoo and protonmail accounts."`

You don't know who the user is at all but you know "A" user has that contact list.

Very harsh.

Some of those contacts might use personal domains, or company addresses, not just big freemailers.

I still don't see the issue. So the application then asks the personal domain for a favicon, how is that an issue? Especially when you consider that this feature is off by default and has a red warning label next to it, that this comes at a privacy risk.

That's actually a really good point I hadn't considered, from the documentation it mentions only suppoorting standard formats and not those such as MS exchange etc. But you're right, there are personalized which are standard.

Man I only read through the source code to point out the issues with Permissions requests. I hadn't even seen the background of spamming your entire contacts list to a remote server.

That's because it doesn't. It's an optional feature, the feature shows the favicon for the domain names on your contact list. In order to do that, the app retrieves the favicon from each domain in your contact list. It does this in the App not in an external server.

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

Saying that this is sharing the contact list is akin to saying that a browser sends your ip to websites you visit.

I think your contrarian view is biased and misleading.

The HTTP request for favicon of each email’s domain, which you hypothesized, might be the issue that Google was thinking of. However, your hypothesis has never been clearly stated during rounds of emails between the developer and Google.

Wouldn’t it be helpful to clarify an issue in reply to the developer, rather than having someone post “a contrarian view” afterwards?

As other people below have mentioned it's not even enabled by default and has a privacy warning on it

> Certainly I would expect apps to disclose whether or not they are using any information on my contact list

I would expect the app to ask for permissions when first started and that if access to contacts is one of those permissions that I can disable that. Its for the app to work around not having this permission and if part of the app is not working due to not have the permission, so be it.

Implementing BIMI instead of that would've saved him a lot of headache I suspect.

You mean this?

https://github.com/M66B/FairEmail/blob/master/app/src/main/j...

How do other email apps handle this? Do they just disclose it in the privacy policy? Or do none of them have this feature?

For as long as I've been aware of the feature it's been opt-in and _does_ have a privacy disclosure. FairEmail is better about its privacy disclosures than most apps are. Maybe they just didn't do it in the Google-approved way?

Preference that defaults to false: https://github.com/M66B/FairEmail/blob/master/app/src/main/j...

As to it being contact info, the file is literally called ContactInfo.java.