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.