4 ms·

Warranted or not, what is unacceptable is the lack of transparency in the whole process. At least point the developer towards a path into compliance, not just b

by m-p-3 4y ago

Warranted or not, what is unacceptable is the lack of transparency in the whole process. At least point the developer towards a path into compliance, not just black-holing them altogether.

encryptluks2 4y ago
I agree the process could be improved, but if they post policies and developers fail to read them and follow them they really only have to say they violated their policies.
- lolinder 4y ago
  If interpretation of the policies were consistent, to the point where I could reasonably guess that the violation was in something I changed recently, I would agree with you. However, both platforms' policy enforcement is often wildly inconsistent. Rules get ignored and then suddenly enforced. Some reviewers are more persnickety than others. Something that's been passing under the radar for years might be suddenly interpreted as in violation of a policy while they're reviewing a minor bugfix. In that situation, "you violated a policy" is useless for figuring out the problem in any reasonably large app. (That said, it sounds like this dev did get an explanation.)
  - g_p 4y ago
    In this case, it seems like "recency" was a big issue - the change wasn't recent in any sense of the word, since it seems like the feature has been there since at least mid 2020. [0] The explanation in this case also seemed to focus on a (false) assertion the app uploaded the user's contact list - the app wasn't doing that. If a user turned on fetching favicons (it was off by default, with a red-coloured privacy warning in the app), then the app would fetch a favicon for received emails in non-junk folders, directly from the server in question. If apps are expected to treat the user's DNS server as hostile, then web browsers had better talk about how they send user browsing history to third parties (by querying DNS!). Similarly, the app connecting to the site and asking for a favicon is not really a leak to a third party, as the domain is owned by the sending user. If they chose to outsource their website to a third party, that's their choice (and problem). If the app was uploading user contacts to a third party, that would be very bad. It wasn't. But rival apps do (for monetisation etc.) Making benign apps write declarations that suggest it is doing something akin to that is (to be cynical) helpful for Google and other ad/data supported business model actors, who benefit from obscuring their practices by forcing others to make similar-looking declarations. [0] https://github.com/M66B/FairEmail/commit/57cf22b1193b43ca9795f7561bdb0427427ed734 https://github.com/M66B/FairEmail/commit/57cf22b1193b43ca979...
Rebelgecko 4y ago
The rejection notice that the developer posted said "Your app is uploading users Contact List without an adequate disclosure. For further details on the valid prominent disclosure requirement, please review the [linked] section under the User Data Policy". The developer asserted that they were only leaking the domain names from users contacts, but that's still something that users should be aware of. Full disclosure, I work for Google so maybe I have some biases, but IMO that's a pretty clear message telling the dev why the app was rejected and how to resolve the issue.
- orangecat 4y ago
  "Uploading the contact list" is not a reasonable description of requesting a favicon from a contact's domain.
- g_p 4y ago
  The problem was that this feature existed for many years without issue. There was plenty of disclosure in the app (it was even written in bold red text, I believe). The developer was guessing as to what was going on, since the feature wasn't new, and the message doesn't appear to match the actual issue (domain names from sent/receives messages, after expressly opting into a feature with a privacy warning on it) There is an interesting question around whether a domain name really is a privacy disclosure though (and I write this as someone who wants to see more private apps) - if we force apps to disclose mundane trivia, it will distract from the meaningful disclosures. Do we expect Google to disclose in every one of their apps and services that it makes DNS queries, which may reveal information to third parties? Or do we accept that's how the internet works? In this context, it seems like FairEmail was doing the equivalent of making a DNS lookup. If the user doesn't trust their DNS, is this a developer's responsibility to address? I don't know where the line ought to lie, but I think a major reason it wasn't clear what was wrong and how to resolve it was the time between the feature being added, and the review highlighting this - slow feedback loops kill products.
  - jhugo 4y ago
    Don't focus too much on the protocol that is used. Leaking the domains of every mail correspondent is a privacy issue regardless of whether it's done via a DNS lookup or otherwise.

by m-p-3 4y ago

Warranted or not, what is unacceptable is the lack of transparency in the whole process. At least point the developer towards a path into compliance, not just black-holing them altogether.

encryptluks2 4y ago

I agree the process could be improved, but if they post policies and developers fail to read them and follow them they really only have to say they violated their policies.

lolinder 4y ago
If interpretation of the policies were consistent, to the point where I could reasonably guess that the violation was in something I changed recently, I would agree with you. However, both platforms' policy enforcement is often wildly inconsistent. Rules get ignored and then suddenly enforced. Some reviewers are more persnickety than others. Something that's been passing under the radar for years might be suddenly interpreted as in violation of a policy while they're reviewing a minor bugfix. In that situation, "you violated a policy" is useless for figuring out the problem in any reasonably large app. (That said, it sounds like this dev did get an explanation.)
- g_p 4y ago
  In this case, it seems like "recency" was a big issue - the change wasn't recent in any sense of the word, since it seems like the feature has been there since at least mid 2020. [0] The explanation in this case also seemed to focus on a (false) assertion the app uploaded the user's contact list - the app wasn't doing that. If a user turned on fetching favicons (it was off by default, with a red-coloured privacy warning in the app), then the app would fetch a favicon for received emails in non-junk folders, directly from the server in question. If apps are expected to treat the user's DNS server as hostile, then web browsers had better talk about how they send user browsing history to third parties (by querying DNS!). Similarly, the app connecting to the site and asking for a favicon is not really a leak to a third party, as the domain is owned by the sending user. If they chose to outsource their website to a third party, that's their choice (and problem). If the app was uploading user contacts to a third party, that would be very bad. It wasn't. But rival apps do (for monetisation etc.) Making benign apps write declarations that suggest it is doing something akin to that is (to be cynical) helpful for Google and other ad/data supported business model actors, who benefit from obscuring their practices by forcing others to make similar-looking declarations. [0] https://github.com/M66B/FairEmail/commit/57cf22b1193b43ca9795f7561bdb0427427ed734 https://github.com/M66B/FairEmail/commit/57cf22b1193b43ca979...

Rebelgecko 4y ago

The rejection notice that the developer posted said "Your app is uploading users Contact List without an adequate disclosure. For further details on the valid prominent disclosure requirement, please review the [linked] section under the User Data Policy". The developer asserted that they were only leaking the domain names from users contacts, but that's still something that users should be aware of. Full disclosure, I work for Google so maybe I have some biases, but IMO that's a pretty clear message telling the dev why the app was rejected and how to resolve the issue.

orangecat 4y ago
"Uploading the contact list" is not a reasonable description of requesting a favicon from a contact's domain.
g_p 4y ago
The problem was that this feature existed for many years without issue. There was plenty of disclosure in the app (it was even written in bold red text, I believe). The developer was guessing as to what was going on, since the feature wasn't new, and the message doesn't appear to match the actual issue (domain names from sent/receives messages, after expressly opting into a feature with a privacy warning on it) There is an interesting question around whether a domain name really is a privacy disclosure though (and I write this as someone who wants to see more private apps) - if we force apps to disclose mundane trivia, it will distract from the meaningful disclosures. Do we expect Google to disclose in every one of their apps and services that it makes DNS queries, which may reveal information to third parties? Or do we accept that's how the internet works? In this context, it seems like FairEmail was doing the equivalent of making a DNS lookup. If the user doesn't trust their DNS, is this a developer's responsibility to address? I don't know where the line ought to lie, but I think a major reason it wasn't clear what was wrong and how to resolve it was the time between the feature being added, and the review highlighting this - slow feedback loops kill products.
- jhugo 4y ago
  Don't focus too much on the protocol that is used. Leaking the domains of every mail correspondent is a privacy issue regardless of whether it's done via a DNS lookup or otherwise.