Google contacted me directly to help restore FairEmail on the Play Store
faircode.eu
faircode.eu
https://github.com/M66B/FairEmail/blob/master/PRIVACY.md#sum...
Albeit I am undecided whether we should really force every FLOSS developer to create a table like this, apparently Google has decided that yes, we do.
It's akin go a standard privacy "Nutritional Label" that only exists due to forced regulation, and not industry agreement.
Or at least add it.
MSDS for code!
As an iOS user, I want even stronger privacy control and disclosures; the current Apple disclosure requirement is still pretty vague. However, it is really nice seeing apps that say "this developer does not collect any user information."
I'm doing that because I've been hit too many times by upgrades that reduced the functionality of apps or changed it in ways I don't like. I'm currently not updating K9 Mail past 5.6 and some useless Samsung apps that I can't uninstall.
Yeah, I do the same these days. It's amazing how freeing it is to be able to trust the app you're running, and not have to constantly be on the look out for dark patterns, "integrations" you didn't ask for, sneaky updates, change of ownership due to an "incredible journey" with a FAANG/MAGA company or a Chinese equivalent. I'll take the more limited choice and the general lack of UI polish any day, for these benefits.
I've never seen the Play Protect message you're talking about.
I'm using F Droid on all my Android devices. They are version 8, 10 and 11. It works with no problem, no root required.
(and probably required complex dataflow linting to ensure it)
even for apps that aren't open source, a trusted third party can run an analyzer on the source code to generate something like this; you can also have internal dashes that track what has been shared, how many times, and what triggered the share. you can hook into settings and toggle specific sharing on / off, you can ban certain kinds of sharing entirely.
tools like skyflow are already trying to provide this for regulated PII
I don't see any reason why open-source software should get a free pass on privacy issues.
If an open source project is really just somebody releasing their own code, they don't have any obligation at all to the end user. If a business is releasing open source code and has some business model that ultimately turns that into profit (even indirectly, for example via selling your private info), then they have an moral obligation to be clear on how they are making money.
On the other hand, the app stores have no obligation to host projects generally.
If they distribute the app there is little difference from a closed source install. Again, "read the code and learn what we do about privacy" would be pretty hostile.
Apple has an interest to publish the same apps. It supports their "keep the users in the walled garden" business model.
Both form an unhealty duopoly from both app developers and end users point of view.
Saying they have no obligation to host an app might be correct, but it's a very limited perspective of the whole situation.
In this case it doesn't. I also can't give away meth for free. Distribution of an app that processes personal data without a valid data privacy statement is illegal in the EU and could get the author and/or github into trouble unless they implement an export restriction (eg. EULA that prohibits distribution in the EU).
Is that really true? For example data processors are bound by GDPR but I don't see how the author of this application is a data processor (or a data controller). In fact I'm not sure that legally "app that processes personal data" is the correct description here, considering the very specific meaning of "to process" in this context. If an email client run by a user on his own machine with no involvement of the vendor of that software requires "a valid data privacy statement", then so does probably the user's keyboard driver. And the text formatting engine. And the networking stack. Etc. etc.
Best I can do is offer my interpretation. GDPR applies to "[...] the processing of personal data wholly or partly by automated means" [1]. I take "automated means" to include this app. So when this app runs and processes EU citizens' data, the law applies. But to what or whom...
> I don't see how the author of this application is a data processor (or a data controller)
... I understand as follows: things are generally not responsible under the law, their owners and creators are. If I install and use a software, the GDPR entitles me to knowledge of its personal data processing capabilities if it processes personal data, which this app seems to do. As the GDPR evolved from consumer protection law, I'll employ an analogy: if I win a free vacuum cleaner in a raffle, the product still needs to include a safety guide - the manufacturer or distributor can't delegate safety responsibility to me. GDPR is about personal data safety.
> If an email client run by a user on his own machine with no involvement of the vendor of that software requires "a valid data privacy statement"
Conversely, at least one mainstream email client comes with a data privacy statement [2]. Which doesn't prove my point, it might be just ass-covering.
> then so does probably the user's keyboard driver.
Maybe the operating system's data privacy statement covers this? Otherwise that reasoning appears sound.
[1] https://gdpr-info.eu/art-2-gdpr/ [2] https://www.mozilla.org/en-US/privacy/thunderbird/
According to the data privacy statement (DPS) it does more than that, refer to chapter "Set-Up and Configure Your Email": Thunderbird collects your email domain and other technical data to set-up and configure your email account. Other information, like your name, your email messages, and your account’s address book are stored locally on your computer and never sent to us.
"Thunderbird" means the email client, not the web service ("us"). The DPS cleanly separates between data stored locally on the client and data shared with the servers - the DPS addresses both scenarios and it explains which data is stored locally, so their interpretation is that GDPR covers data processed by the application which does not leave the client, too.
> If this application doesn't collect any such data for its author, then this point goes away
The Thunderbird DPS seems to think otherwise, as it describes the locally stored data even if it isn't submitted to the web service. Maybe the DPS doesn't intend to apply a legal interpretation to local data and mentions local data only for contrast to shared data, which the DPS definitely cares about? Hence my in-earlier-comment comment that this might be just ass-covering without legal weight.
That's exactly what the GDPR enforces. You give the app personally identifying data, so the app needs to disclose what it does with the data because storing it on the computer and not sending it anywhere is still data processing. In this case the data privacy statement needs to tell the user that the data is stored but not shared. If you're not doing anything with the data, then don't ask for it.
People don't read privacy policies. A privacy preserving app that has to put a long-winded policy, despite not leeching your data, becomes even harder to distinguish from a cloud-based email app that scans all your emails, and holds your email usernames and passwords, and harvests contact-name pairings and sells email signature contact info and job titles to lead-harvesting data brokers.
I don't know if that's the best outcome for users, as it might make every policy look the same (long, complex, and wordy, with scary legal language they are forced to add by the platform gatekeeper).
My favorite unnecessary warning label is the one on the bag of frozen shrimp I bought at Costco. There's a government mandated "Warning: Contains shellfish (shrimp)"
Thanks.
[•] I personally lasted two months without a phone once (2016 Japan), since 80% of services would outright refuse you if you didn't have one, while the rest would pester and harrass you extensively before finally giving in.
Also, one of my banking institutions is a small credit union whose website does not work well on mobile, but has a well functioning android and iOS app.
Should the authors of wget have to describe the fact that communicating on the internet requires talking to servers, and if you use domain names, you'll also have to leak information to DNS servers?
At the end of the day, one of the hardest and most subtle things about it is that expectations (in the form of regulations or just how users think things work) can change in the future, and it means once-mundane decisions that you made are now sending data somewhere it doesn’t belong.
Ultimately, I think that the only solution is going to be a table like this for every product, everywhere: we need to know EVERYTHING that is sent over the wire, WHERE we are sending it, and WHY/WHEN we are sending it. At least then we have all the info we need to look backwards and understand what happened to the data when the landscape inevitably changes.
Let's be honest. This author is going much further than Google in protecting user privacy.
Then google contacted them directly and they un-quit disclosed the workflow of users data and is back in business.
EFF and EU should respond to Google taking FairEmail off the Play store - https://news.ycombinator.com/item?id=31433051 - May 2022 (51 comments)
FairEmail stopping development after Google falsely flags app as spyware - https://news.ycombinator.com/item?id=31432334 - May 2022 (322 comments)
FairEmail may be Ending Development - https://news.ycombinator.com/item?id=31426915 - May 2022 (6 comments)
Previously:
FairEmail: Open-source, privacy friendly email app for Android - https://news.ycombinator.com/item?id=26386374 - March 2021 (117 comments)
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.
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.
So no, Google didn't clearly said what the problem is because they didn't understand the functionality.
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.)
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/57cf22b1193b43ca979...
Would anyone classify Google's projects as "spyware". It is, after all, their "business model" to conduct surveillance. Whereas I doubt this author is making Google-sized profits, or even a modest livelihood, from his PlayStore apps, even if the apps were "spyware". Google is the undisputed king of spyware unless the user believes that her interests are always 100% aligned with Google's interests and nothing Google does can ever harm them. In order to hold such beliefs one would also have to ignore the millions in fines Google continues to pay for privacy incursions.
I have been using one of this author's other programs, NetGuard, from FDroid, in lockdown mode, for computer running non-rooted Android. I have not seen anything like it, i.e., a user-controlled application firewall as a standalone app, for iOS. I am not aware of any competing apps for Android either. It appears to be a one-of-a-kind app, AFAICT. If someone knows of better option for selectively blocking traffic from apps, let's hear about it and the reasons why it is better.
The assumption that Google is more trustworthy than any single app author is questionionable. It is that dogma upon which the "app store" concept depends.
For example, can Google really compete with this author with respect to protection from spyware. Let's consider some facts.
The author offers user-controlled protection from spying in NetGuard. Google offers Google-controlled protection from spying in the form of app store vetting. The former is open source, users can compile it themselves, and it does not report back to a mothership. The later is not something any user compiles themselves, it not controlled by the user, it is controlled by Google, it does report back a mothership, and the motherwhip's "business model" depends on that surveillance. The later, namely Android, Google apps and Google "services", are, by definition, spyware. Google collects data about pocket computer owners and uses it in undisclosed ways.
There is simply no way for a pocket computer user to know the many things that Google does with the data it collects from spying. The only instances where she may learn about what Google does with her data are when facts are disclosed in response to discovery requests in litigation and those facts are made public. Even if she becomes aware of such facts, there is generally no way for her to limit what Google does with her data according to her own preferences. NetGuard allows users to selectively block or allow traffic to selected domains on a per app basis.
Honestly, I know their job is hard, but if they simply put a legitimate task force together to figure out how to provide support at scale (even if it costs a premium to handle it, or possibly even a premium to do a proper appeal), I could see it helping immensely.
Basically, if you want to do an appeal for something, it will cost, and depending on the violation and how often the violation is, the cost goes up. The appeal requires them to be clear about what the violation is, and what needs to be done to resolve it. Perhaps even make it that if you get an appeal with clear details and you resolve the issue, a certain percentage of the money will be refunded.
Basically, instead of assuming everyone who their algorithms says is total evil is evil, they allow some form of good will that would help businesses, individuals and organizations work with them. I know the spammers and scammers are a huge pain, but then fine, charge them for the cost. The ones that are legit will pay and will work with Google if Google will work with them.
The nature of email clients, especially ones that integrate with cloud-hosted spam and filtering services, is that they're naturally going to have trouble with that policy absent great care with specifying exactly what gets collected. The "fix" here seems to have been to update their policy documentation to describe exactly that.
It works, but it scales badly.
this does not scale well either
More importantly, Google told him that he needed to disclose what he was doing, and his response was petulance. You know the type: "I was speeding because I was LATE TO WORK, officer!"
Further discussion in this comment thread: https://news.ycombinator.com/item?id=31434975
That seems more than reasonable to me (off by default, with a warning!), and would be exactly what I would expect the app to do if I did enable favicons.
Still pretty bad, and I don't think Google is wrong to flag the app because of this.
However, Google didn't say "if the user enables a certain setting, your app is uploading domain names from your users' contact list to third party avatar services", it said "you're uploading contact list information without disclosing that in the privacy policy".
They seem to know exactly what the problem was but described it in such a vague way that it definitely reads like an accusation of extracting data.
Both are wrong here, but Google is in a position of power and should be held to a higher standard. I'm sure just listing the hostnames that weren't covered by the privacy policy were enough to prevent this whole situation.
It's support prioritization by follower count.
The app store model has been shown time and time again to fail at the very issues it's supposed to solve, especially at scale. I can empathize with the desire for manual curation at an early stage and even blacklists for known malware. However, what we have today is a guilty-until-proven-innocent extortion scheme.
Example: how many people here were skeptical of Microsoft having a change of heart regarding open source back in 2012? And now a decade later, it's clear that was genuine.
Nothing is clear about Microsoft embracing open source. Github isn’t open source. Neither is Windows, SQL Server, or Office. And I’m not thrilled about their involvement with Linux. EEE is in their blood.
Fool me once, shame on you. Fool me twice, shame on me. Fool me thrice, you’re Microsoft.
I don't use any of their software, but watching from a distance they appear to have been moving in a "good" direction for the last decade.
I prefer that the organization responsible for those abuses stays away from Linux, and anything else I actually use.
As you say, the problem with Microsoft isn't the licensing. 25 years ago, licensing was among the problems with Microsoft. Today it is not. This is an aspect of Microsoft changing, for the better. https://en.wikipedia.org/wiki/Microsoft_and_open_source#Init...
Install Windows freshly, lots of intentionally misleading privacy options. Edge is increasing its tactics to get you to set it as the default browser. Including Teams with a package people paid for anyway (Office 365) to try and take out Slack. VSCode, Github as on-ramp into paid Github and Azure Devops.
Same old, same old.
I don't know why anyone would willfully choose obsolescence and wear it as a badge of honor.
It's certainly not "clear". Just because they make a code editor you like doesn't mean they're not planning to fuck you over the moment they reach some internal milestones and priorities get shuffled around.
The tech industry moves fast, but the one thing you can always count on is that you should never trust Microsoft, neither as a consumer nor as a business partner.
EDIT: unless you're a masochist
No, they probably don't. Take for example this example prank by the Yes Men:
> https://www.youtube.com/watch?v=LiWlvBro9eI
The beauty of the prank was that the company then had to send a real spokesperson out to explicitly state that "Steve, yes," was the wrong answer to the question, "Do you now accept responsibility for what happened?"
In fact I'll boldly claim you have never seen a genuine change in approach from a company of this size that wasn't forced by a settlement with the government or criminal prosecution(s).
Edit: I'll go ahead and admit I'd love to read about the exceptions to my last paragraph, but only in terms of companies the size of Google.
That why they do it. For you. If the story that got some play in the media gets very publicly fixed (after being completely promoted from the regular support flow), people will will defend them, although nothing has changed.
And yet, barely six months ago…
Just like with bureaucracy, the winning move is to avoid playing, or not working with the system but around it.
It shows what you want it to show.
If I have an issue with Amazon, I get a person. If I have an issue with stripe, I get a person. If I have an issue with literally any other vendor I have a relationship with, I get a person.
With Google, I have a lovely time chatting with auto responders.
They choose to enter the market and fail to serve their customers - that's on them, failure at scale is still failure.
The only thing we learn here is that everyone is trying to figure shit out all the time and customer support is a hard problem.
You can't run world-dominating platforms and dodge the responsibility that comes with it. Surely if you rake in tens of billions in profit every single quarter, you have room to do better.
If anything, their scale should permit them to easily do better.
It doesn't need to be 100 people. Just 10 or 20 even. Just provide some kind of human touch to the support of the developers who make the Android app store worth a damn. Write documentation to better help other developers get out of these kinds of holes. Work to improve the messaging when apps are rejected so that it's easier to know what to do.
It doesn't seem worth putting time and energy into making an app if I know a bot can suddenly end my project and there's nothing I can do about it, and no one whose job it is to help me.
Even the "legit" uses would be enormous let alone people who abuse it.
At the very least, I don't think even 100 people would be able to cover it.
I'm using the fdroid version, so I have to use IMAP instead of oauth2 for gmail (why? who knows, it works for office365).
The Fdroid version of FairEmail doesn't support gmail with oauth because of "Google security features" (??). It's only supported on the Google Play version.
I'm vaguely aware that there are sites out there where you can download apks, but that seems unwise.
You can download Aurora Store form F-Droid. It is a Google Play frontend with an anonymous login mechanism and fetches APKs directly from Google.
You can try installing Fairemail through that but I'm not sure if it will fix the login issue by itself (maybe it also wants the chrome webview or google play services?).
But!! As I was writing this comment, I went to FairEmail again to confirm the behaviour and it seems that my IMAP access has been turned back on and I can receive emails again. No idea why or for how long.
What a ridiculous situation. If I had a time machine I would go back to kill Hitler and also to tell my past self not to sign up for a gmail account.
It's absolutely deflating when an app gets removed from a store, and a lot of times the rejection messages are terse and hard to make sense out of, and honestly, the developer has a lot invested in their app.
After reading what I could read, seems like there was a legitimate security concern, and rather than work on it the dev just sort of said, "Meh, I don't want to do non-dev things, let's just cancel this project. It's not fun anymore." Paraphrased.
He also wrote:
> Core problem
> Google. There is no sensible way to appeal in case of bad reviews or alleged violations of Play store policies.
> People. They are generally pretty demanding and on the other hand everything should be free.
> Myself. An old and grumpy developer, who maybe should retired.
I 100% believe all of those points, but especially with open-source devs... most people who do those projects do them to avoid "real software" -- what I mean by that is the process that it takes to make enterprise software or software at scale. Project Managers, Product Owners, UX Designers, QA Testers, Security Consultants, etc. Most open-source projects tend to be the software equivalent of some guy in his garage building a model train set... just something you can do for fun to flex your skills. Focus on building, but not having to deal with the overhead of communicating, taking input, and compromising with others.
Anyway, building a side project is fine. But... like in another post someone was complaining about the certification cost of dealing with Google Data as a 3rd Party Developer... and like... I can't get on board with the sympathy bandwagon there. I want there to be a stringent process before Google even gives app developers the ability to request access to my data -- even if it's on my behalf.
And so... back to the analogy, building a model train is fine, but like... wanting to build a fully operational train all by yourself, and have others use it, ride on it, rely on it... at some point, it needs to turn into a "real" project. One of the hardest things about dealing with open-source projects is all the original creators of those projects who just don't want to play nice, and don't want to grow a team to grow and support their code.
One thing I've done when an agency or company I work for has used open-source code, we try and at least set up a lunch and learn with the creator. Good to get their vision of where the code is going, good to have that line if we need them to fix bugs. But like... 99% of the time, I know that any input we give... there's just no point. The creator doesn't want input, he only really wants to play in his basement with his model train. Buy him lunch, give him as big of a guest lecture stipend as I can, and move on.
i dont even blame you.
However, it is sad that PR campaigns are required to reach out to an actual human being who cares.
I fully disagree with your take.
You are assuming the default is negative. I think your explanation might be possible, but that by default it's wrong, as most people are not cynical/annoyed or any other negative quality.
My fundamental belief is that most people are nice and want to do good things.
If you are surrounded by cynical/annoyed people, you may be in a toxic environment, which may taint your judgement for other situations.
NB: either one of us could be making a fundamental attribution error https://en.wikipedia.org/wiki/Fundamental_attribution_error and it might be hard to find the truth, as it boils down to beliefs.
I am assuming the default is negative - for Google.
I work for a far far older engineering company which is built on maintaining good relationships with our customers, vendors and their engineers. It is the exact opposite of the AI driven, frustrating/pointless bot response attitude of big tech companies. I like to think the difference is that we haven't optimised out our humanity yet.
thanks for sharing that valuable information with us
/sarcasm
Also the part they were likely mad at was not data collection.
Even worst is when actual humans get your cases, but can only reply with templates (like on Seller Central), where they have no problem sending you the same message over and over again.
This should be regulated for monopolies. People should be able to access a human for assistance.
The description of the problem they gave was inaccurate in any case, which didn't help the developer in working out the problem.
You therefore make a good point - while people often talk about the need for humans, these humans ALSO need to be free-thinking, not bound by a script, and have meaningful escalation paths to use for cases that the process isn't working for.