FairEmail stopping development after Google falsely flags app as spyware
forum.xda-developers.com
forum.xda-developers.com
If you read the details of the Play Store complaint, you will see that they say the app was uploading information from the user's contact list without properly disclosing to the user that this was happening [1]. This is a violation of Play Store policy (a disclosure is required). It's not an unreasonable policy.
You can see in the app's source code where some of this happens [2]. In short, the contact list is read off the device, email addresses associated with each contact are parsed out, and the app does HTTP requests to remote servers to get the favicon associated with each email contact domain. Note that 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.
The developer's response is that he refuses to add a disclosure to the app because he is not uploading "contact info". [3]. Ok... not a great response. Certainly I would expect apps to disclose whether or not they are using any information on my contact list to reach out to third-party servers, even if only domain names. In any case, it's Play Store policy.
In the end, he finally removed the favicon feature. And Play agreed to allow the app back into the store. [4] But he has not yet backed down on shutting down the whole project because he's still upset.
Sources
[1] https://forum.xda-developers.com/t/app-5-0-fairemail-fully-f...
[2] https://github.com/M66B/FairEmail/blob/master/app/src/main/j...
[3] https://forum.xda-developers.com/t/app-5-0-fairemail-fully-f...
[4] https://forum.xda-developers.com/t/app-5-0-fairemail-fully-f...
So, 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.
Saying that this is sharing the contact list is akin to saying that a browser sends your ip to websites you visit.
For example for "And Play agreed to allow the app back into the store. [4]" The linked comment doesn't state this.
You are part of the problem by immediately accepting that post as fact!
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.
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.
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.
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.
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.
Google just has a demented communication policy.
I think almost everyone would be agreement that Google can communicate better.
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.
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.
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.
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.
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.
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.
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.
I'm honestly a bit annoyed that OP is the top comment on HN when it exaggerates the impact of this feature.
Someone being in your contacts list does not mean you have ever had any contact with them.
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.
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.
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.
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.
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?
Particularly the link dialog is nice and helps avoid tracking or accidental taps sometimes.
(it was added to the milestone 17 days ago, but also updated today after the Fairemail news)
It's sad to see that the Dev is stopping work on it because they seemed quite passionate and responsive.
I paid for the pro version to support the app and usually install it from F-Droid but I guess losing the exposure of the play store is a huge blow.
There is no replacement, at the moment.
(I lack any knowledge about Android development, so I'm out. ^^)
ref: https://www.reddit.com/r/fossdroid/comments/utz6dr/alternati...
I am very disappointed to hear this news.
Even more difficult to test this given Google continues to violate their obligation for transparency.
I think using Apple as the reference here is the wrong kind of baseline shift.
I recently had an app pulled from Google about a month after its latest update (the app has been in the store for years) b/c I hadn't checked some new privacy box in the UI. I received no warning prior to the take down or when I last submitted, and the take down message didn't even point me in the UI where I could check this box. After searching SO, I was able to track it down. Then the app was rejected for an unrelated reason that required an appeal. I appealed and they simply stated rejection again. I appealed again asking if they actually read the original appeal and received no response. A week or so later the app was back live - and I only knew because I checked.
I have almost as many apps sideloaded in my phone as apps from Google's play store.
I'm freshly frustrated because I'm dealing with a random metadata rejection (on an "internal testing" build! nothing has changed!) just now.
Play Store rejections are either an algorithmic mystery or reviewer incompetence. I don't mean reviewer incompetence in using the (maybe unintuitive) app. I mean their internal review UI had some kind of unrelated error and they sent me a screenshot of that. Their own console UI even sort of urges you to just resubmit with a potentially meaningless change instead of opening an appeal / request. Feels like it's the worst of both automatic and human review.
You're lucky. I've asked them such questions. Most of the time they refuse to respond. Even if they do, there's a good chance you'll get a different reviewer for your next update with a completely different opinion and interpretation of The Guidelines.
Apple allows none of that. As a hobbyist I find Google to be much more reasonable, paying 25$ once vs 100$ a year for a dev account.
Getting my Apple dev account was such a horrible process, I had to talk to at least 6 people and it took months.
I'll just pay Cook's ransom, guess I have motivation to develop something new if only to justify the dev fee.
That's not really an alternative as only a few nerds will jump through these hoops. The app is as good as dead if you are not in the stores.
Of course not nearly as much, but discoverability in the Play Store is already a mess.
Hell, you can point them to a GitHub artifacts page.
At least it's an option.
[0] https://github.com/k9mail/k-9/issues/655#issuecomment-113164...
[1] https://email.faircode.eu/
[2] https://github.com/M66B/FairEmail/releases
[3] https://news.ycombinator.com/item?id=26386374
The reasonable thing would have been to send a warning asking to change the damn screenshot, which would have taken me literally 10 second to do.
No more app development for me, not unless I control the distribution channel.
What about something like F-Droid? F-Droid users can even add new repos to source apps from if you don't want to submit it to wherever F-Droid sources from by default.
That said, the culture around smartphones unfortunately was poisoned from the beginning so that normal users are suspicious of anything that doesn't come from the "official" corporate app stores, unlike PCs where they'll download just about anything on the internet, so I do sympathize with swearing off app development.
Google has that covered too with their "Google Safe Browsing" crap.
"I didn't break the law that bad, why was I punished so severely!" is exceptionally immature.
It's only commercial use if I made any sort of profit from it, which I didn't. So nope, not commercial.
https://support.google.com/chrome/answer/99020
Sure, users could choose to proceed if they know they want to, but the likely outcome is that you will lose 95% of them.
The point is how much control one has over the end to end distribution. My own website could potentially receive a DMCA take-down, but I can just take down the offending content and continue with my life. In case of Google Chrome, I can't recall the last time I came across such a warning and I surf all over the place, hosting all kind of crap. So it's very unlikely.
So even IF you DO get past the ban-hammer, there is always another ban-hammer just round the corner if you app gets too much traction.
Google is great until you get caught in the web of censorship. Apple is great on the surface but a hot-mess of bugs under the hood.
Devs at chrome seem more compentant then the devs who work who on webkit. Both just serve to reinforce parent companies positions. The APIs that the parent companies use, most of the time, the rest of the APIs, its anyones guess when they will break release to release.
Those typically have due process and transparency. Google has neither.
> In case of Google Chrome, I can't recall the last time I came across such a warning and I surf all over the place, hosting all kind of crap. So it's very unlikely.
I'm not sure how common it is for chrome to mark whole websites, but they do like to warn on executable downloads that are flagged by crappy artificial stupidity anti-virus vendors who have no incentive to reduce false positives. And by warn I mean that Chrome (and other browsers that let Google gatekeep the web, which is most of them including FF) refuses to download the file and makes it obfucated enough to override that decision that many users think they can't download the file.
Example: http://dege.freeweb.hu/
The fact that those are theoretically not absolute (some people use Bing, hosting can be on AWS, and Firefox still exists) is beside the point.
In practice, almost any business is damaged to the point of being unsustainable if Google cuts them off.
You're lucky you weren't sued into the ground for damages.
It was a free app with no advertising, so it was not used in a commercial context.
> I'm finding it extremely difficult to have any sympathy
People have sympathy for much worse things - you should perhaps work on your sympathy. Here's something to help you: the person wasn't a business owner for decades and just wanted to help others with similar issues, hence spending dozens of hours of his personal time to build an app to share for free.
They lived long enough to see themselves become a villain.
Lastly, HN has been successfully used for contacting Google support in the past, so this also increases the number of posts.
Sure, but the things that Google does to make some of their users unhappy and the total lack of recourse Google makes available to them are decidedly far from perfect. That some people are going to be unhappy no matter what is beside the point.
Or at all, relatively. It can take only one heavy impact issue and the public will not care how large any of the numbers are and well things generally go (or, conversely, how poorly, i.e. coal power). Of course with a company at Google scale, there is gonna be a lot more than just one heavy impact issue in no time, and any human only has to really conflict with one of them to be thrown for a loop.
People are just really bad with big numbers and very empathetic with individual cases. The later is actually a really cool feature in humans, but it is an issue when it conflicts with the former.
That is all not to say that Google is doing right, here or in any other set of cases. You decide. I just noticed that the way people arrive at their judgement often suffers from the aforementioned dynamics.
This is what happens when you are a monopoly and there are no competitiors in your space. To simply stop caring about being good.
And, of course, because they're so huge, any problem that affects a "tiny fraction" of their user base affects a whole lot of people.
They have the resources to not have these problems. That's the bit that should be leading to barbarians at the gates, but, isn't.
I'm not sure they do have the resources. We're talking about companies with a user base larger than literally any country on Earth.
The basic problem is that these companies are taking on problems that nobody should ever take on. "Mass curation" is not a problem that can be solved by anyone, and not a thing that should be attempted by anyone. This is why we need personal freedom and not global gatekeepers.
And you have to pay to join the store.
What value exactly would you specify for X? And how many apps in Google Play have at least X thousand users?
And this isn't about a deep check for every single update, this is about deeper checking in case of blocks and bans, which happen at a much slower rate.
By definition, those are the most impactful decisions.
And "this impacts a lot of people so be careful" is the mildest and least problematic kind of "special treatment".
Besides, the small decisions are collectively impactful too. Take 3 million apps, and add up all of their users. Multiple smaller apps may collectively have more users than 1 larger app.
It feels like giving special treatment to more famous apps is just a strategy for Google or Apple to avoid bad press, without making their stores much better.
That's what they do now. I'm suggesting a massive expansion on what apps they treat better, because 'famous' is a very small group.
And I'm not saying they shouldn't treat all apps well. It's just that it's less clear how much that would cost.
What's clear right now is that they aren't even trying.
Also we probably shouldn't have 3 million apps to start with. I bet a lot of those are below even the lowest reasonable quality bar.
Just tried reporting a bug on Android Auto and the submit button is disabled with no error message or tooltip.
I guess their model is to do stuff for "free", don't really provide any useful customer support and keep your costs down. If people don't like it, they are in the wrong and are free to go elsewhere.
Eventually "free" loses its value when everything else is done so badly.
If you are a false positive for Google bots, then you're toast.
Your ad income will vanish, you app will be forgotten and even your very email and associated data underneath is on the brink of lifetime ban.
This is the very essence of Google. If you are big enough as Google, you can swing a huge f* you gesture to the whole world of software developers.
"Don't be evil" - yeah right.
The very first thing Google makes use of their fat cutting-edge language models is banning ordinary people from the whole ecosystem for their tiniest fixable mistakes.
Google scales evil before they scale good. Always have been, always will be.
We as little software developers don't have any significant resource to sue the hell out of Google and they can get away with this pure evil every single day.
Disgraceful. What kind of mentality a person has to have to take money from the biggest spyware vendor and mark others' work as spyware? Or even allow automated systems, built by spyware vendor, to slap a "spyware" label on anything?
I’m kind of inclined to give MS the benefit here.
I’ll stick with my assertion that Google collects 1-3 orders of magnitude more data than Microsoft.
Microsoft is a the world's largest spyware vendor because Google gives their spyware away for free.
I find I sympathise a lot with both narratives about app stores: it does seem that big mistakes are made and sometimes it seems apps are removed anti competitively but it also seems that there are a lot of apps that are basically malware already and forcing app stores to remove fewer apps would lead to more of it.
Because they have businesses that scale: dominated by fixed costs with very small unit costs, where twice as many units have very much less than twice as much total cost to deliver.
> "But that doesn't scale", I hear you say. They could simply hire more people, that scales fine.
No, it doesn't. Hiring more people with any given skill set has superlinear costs very quickly (because of supervision heirarchies and increased quantity even before that increasing the clearing price).
Cost scaling worse than linearly is pretty much what people mean when they say, “Doesn’t scale".
You can't talk to reviewers on the phone.
No, they do not.
> If you have a question about your app's review, send us a message in Resolution Center. If you would prefer to speak over the phone, just let us know in your message, and we'll schedule a call.
- you're not talking to a reviewer or engineer unless you are a high tier dev. Bulks of devs could get standard customer support just hearing their grievances out, the same way emails get canned responses.
- devs don't all get access to the same resources or attention from Apple, and your support tier will largely depend on your revenue. I wouldn't expect a long tail app to get much attention.
Externalizing the costs and internalizing the profits is basically theft from society.
Other examples of externalizing costs and internalizing profits are companies like tobacco companies and drug dealers externalizing the costs of the diseases their products produce (both costs to the direct customers, their families and economy at large form lost productive capacity) while they take the profits of the addictions they produce, and fossil fuel companies externalizing the costs of destroying the climate while internalizing the profits from those dependent on the form of energy they provide.
Just because a business model 'works', for the definition of maintains a profit, does not mean that it should be allowed. For an extreme and easily understood example, if society tolerated murder, then murder-for-hire services could become quite sustainably profitable, and probably scalable (especially by applying technology to the Slaughterbot model) as many people would like to eliminate other inconvenient people. That does not mean we should allow it.
Perhaps, but “it scales” and “it ought to be required even though it does not scale” are not merely different arguments, but different classes of argument (the former factual, the latter moral/ethical.)
The question is the constraints that are applied, and they all overlap.
There is no such thing as a "free market". Every market has constraints ranging from what is physically possible (available materials, transit time, storage space, spoilage, etc.++) to market constraints (what people are interested in making or buying), market conditions (buyers' or sellers' market for what goods/services), and either implied or explicit legal and/or moral constraints.
No market is simply free other than the physical constraints. Every market expects certain standards of buyers and sellers, although those can vary wildly, but the extreme of [don't give your buyer the goods, just kill him and take his money] or [don't pay the seller, just kill him and take the goods] is not tolerated.
The question here is what standards should be required.
I also not here that writing about it, while it is not murdering people, Google is certainly taking the position that it is perfectly OK to murder a customer's business for it's own convenience. Just because that process scales does not mean it should be tolerated.
Moreover, considering the scale of Google's valuation and free cash, I have no question that they could scale up a reasonable level of service so that they are not literally in the business of killing their customers.
The developer in question is based in Europe.
The problem is that an inherent imbalance in scale means you have no effective or proportionate recourse when Google break this law. This legislation requires meaningful human interaction with developers, but as many in this thread have observed, developers can't access a human, only automated processes.
That would be costly for Google and wouldn't easily scale, so clearly they don't choose to follow this law. Trouble is that laws are meaningless without enforcement, and someone to advance that enforcement on behalf of the smaller party.
Maybe in this case, Google didn't act in bad faith, but having such a system in place has a method.
It's something every developer should have in mind before deciding to develop anything on Google platform.
And there is no alternative, that is the monopoly.
> If the app can't be in the Play store anymore, there is no point in continuing supporting this app because about 99% of the users download the app from the Play store.
And some more context:
--- Begin quote ---
The balance
The few euros I receive in return for what's being offered and the fun of developing things are no compensation for the thousands of questions I answer every month, for unfair Play store reviews and for stress about unclear Google requirements.
The verdict
I have not reached a conclusion yet, but the question I am asking myself is why I would continue with the project. Maybe it is the moment, with a sick girlfriend, but I currently don't see it.
Alternatives
GitHub only version: 98% of the audience will be lost.
Strip down the app: more bad reviews
Paid support: more bad reviews
Stop answering questions: more bad reviews
Bad reviews will shift the balance only in the wrong direction.
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.
Input is welcome.
--- End quote ---
I can certainly understand the reasons behind simply abandoning ship at this point. If it's not worth it, it's not worth it.
My only hope now is that Thunderbird on Android will approach the quality without adding any heinous anti-features.
From what I've seen from comments of supporters on patreon, the community tends to be much nicer to the dev than typical forums. It's always strange to me that people who don't want to pay tend to be the worst when it comes to support and politeness.
I would say that it is rather that only a small fraction of people pay, and those are usually the most satisfied users anyway to be willing to pay for the additionnal features. The platform has little to do with it.
And once you help them, they're not necessarily going to donate either or try to help in any way (a big percentage of those problematic users have the mentality of not paying for software ever). So filtering support to only supporters is a good way to stay sane as a developer and stop dealing with negativity.
Then, secondly, when their automation gets it wrong, or there is some misunderstanding over something, there's no ability for the developer to actually have any kind of meaningful or substantive discussion - if you can't work out what the issue is, based on their incredibly high level description, you're out of luck, as you won't get any meaningful intelligent or personal response from anyone - expect templated, automated emails that are not in any way addressing the message you sent.
I have donated to this app and I am genuinely happy with Marcel's efforts to add features. Users aren't always the problem.
On the other hand you don't need to put your app there, except for maybe if you want to attract some users./s
This is certainly not "shipping people's contact lists off to a third party". Is there somewhere else this is happening or are you mistaken?
There's an effect called "survivor bias", which for software, usually means that the older a popular application, the better it is. For instance, Unix shell has survived more or less intact for 50 years. That implies no significantly better CLI language has been invented by the last two generations of programmers.
This idea of just deleting quality software every five years for no reason is setting the field back.
Imagine what things would look like today if Microsoft had managed to replace 100% of unix shell implementations with the DOS command prompt!
Shells are user interfaces, not programming languages. This user interface has been good enough that we have not yet needed to invent a small, portable, ubiquitous, systems programming language [sans user interface]. The interest in making a new more complex shell, rather than a programming language, is the survivor bias. Because we've used user interfaces for systems programming for eons, and that use case hasn't died yet, we must just need a more advanced shell, rather than a different solution.
The idea of rewriting that every few years in a new language, or using new APIs, is counter to the principle of writing robust, reliable software without regressions. In my experience, those writing software that reinvents the wheel every 5 years end up ignoring and externalising the impact of regressions on their users, for the sake of using a new language or framework every few weeks...
False. Network effect is an equally good explanation. In fact, one of the arguments that repeatedly crops up on HN in favour of bash is "it's installed already".
The first thing I install on a Linux box is powershell. Your mention of the DOS shell is a straw man - it hasn't been state of the art on Windows for nearly twenty years.
So you picked a bad example but your point has merit? No. I don't think it does. Kernel devs see problems with fork. Fork is thirty years old, maybe forty? Sometimes things need to change.
https://email.faircode.eu/donate/
IBAN DE31 1001 1001 2620 6925 85 - name Marcel Bokhorst - description FairEmail
I was wrong. Without any prior warning, the app was taken down and I could only submit it as a totally new app with a fixed application name ("X for Y" was considered OK back then). Now I could have done that but a) together with the app takedown, Google ads for this app were disabled as well(!) so all income suddenly vanished and b) It took over a year to get enough users so I could buy a beer or two per month - no way I was going to spend another year starting from scratch again with that app.
I tried to submit an appeal and explain that I'm more than happy to change the name back to "$MyProductName for $SocialMediaCompany" - it takes 10 seconds and it's done. All the rest of the metadata (icon, screenshots, description) were good, the app itself was good.. it was just the title, that didn't pass the review. But no.. all gone in an instant.
In the iOS ecosystem, this would have played out similar to this:
reviewer: Hey, this app name is confusing for the users as it can leave the impression that it's an official app by $SocialMediaCompany (see rule 1.2.3)
me: gotcha, I'll change it
reviewer: Great, you're good to go!
I've been an Android developer from the early beta days and I'm still happily developing apps as my day job but I haven't written any personal Android apps since that time and I don't think I ever will.
reviewer: Hey, you broke our guidelines
me: Okay, which?
reviewer: link to whole guidelines document, doesn't elaborate further
me: Could you please clarify what we have to change?
And then the reviewer either doesn't respond at all, or just refers you back to "the guidelines" (which are more like rules set in stone, rather than guidelines).
Really pissed at Google at the moment. It's frustrating when one of the main reason I'm still on Android stops development because of the short sighted corrupted practices of a behemoth like Google.
The app implementation is out of touch with modern Google Play privacy requirements and APIs.
I read through his code, starting with the Main Activity: https://github.com/M66B/FairEmail/blob/master/app/src/main/j...
1. He's using ancient APIs. All written in Java with Activities instead of Kotlin with a single Activity and many Fragments. There are some fragments but it's definitely an old writing style
2. He's using Tasks for multithreading/event handling
3. Using Handlers & runnables is a terrible idea and intrinsically fragile
4. The way he's handling synchro (persistent foreground service) is _explicitly something Google is targeting for battery issues_
5. This code is entirely unmaintainable. He's got a 3k line service file here: https://github.com/M66B/FairEmail/blob/maser/app/src/main/ja..., nested deeply with multiple different handlers running.
I'm not even going to discuss the fact that he has Logging statements peppered throughout the code etc.
This app looks like a 5+ year old code base, not something persistently maintained.
He also does not appear to use any modern Android APIs that Google requires, despite declaring the following restricted permissions:
1. READ_CONTACTS 2. READ_EXTERNAL_STORAGE
In fact I see him explicitly calling deprecated methods that Google has declared off limits: Line 474 of https://github.com/M66B/FairEmail/blob/master/app/src/main/j... `requestPermissions` is an illegal call, which he has documented as throwing an exception that he can't figure out.
That's absolutely a smoking gun and potentially the reason Google would ban him. ActivityResultLauncher is required for permissions grants.
My summary of this is: This is what bitrot looks like and what happens when you don't manage app scope to handle tech debt. It got too big to maintain.
The issue is that he's not respecting the required APIs. It literally does not function on a modern Android device because of the permissions.
Do you want privacy on your phone? Apps are required to implement the new API for better user control of privacy and permissions.
The developer was incapable of maintaining their app to modern API changes. That sucks but it's like complaining that you can't run a Windows 95 program on Win 7 without having to do some work on it yourself.
The problem is Google has no place making these decisions. This is textbook anticompetitive behaviour. The developer is based in EU so I hope (and expect) that google gets a hefty fine.
And yes, I will be sideloading it.
The GP on this thread is completely ridiculous. "You're not using Kotlin and instead use Java" is the most ridiculous thing on such an issue I've ever seen. Email clients battery usage is a really hard to get right. Especially since Fairmail gives you so many options on the synching behavior. So much so that a lot of iOS email clients actually store mail credentials on a third party server and sync your emails there to send push notifications. That's an absolutely security nightmare and yet that's somehow ok.
Really sucks to have it pulled and even more disturbing to see people here justify it. I can't help but wonder if the person above is a google employee.
The reason it's pulled isn't java vs kot: It's refusing to use the modern APIs that are required for it to function on Android 11+.
My outline specifically mentions the use of illegal calls which will literally just crash on later android versions. He even has his call stack pasted as a comment.
That's not a reason to pull an app. It's a reason to tell users of Android 11+ that the app isn't compatible with their device, but everyone else should still be able to install it.
When you update to Android 11 or 12 it will cease to work well, because it will crash when requesting a permission. You can get around it by manually adding permissions.
When you encounter those issues I suggest forking it and doing the work he refuses to: Use ActivityResultLauncher with registerForActivityResult to request permissions.
Have you or someone else audited the code or what is this based on?
lol. There is no privacy on your phone if you have Google's spyware on it. So your point is complete bullshit.
It literally does. I'm using it on Android 12. Far from "not functioning", it has the most reliable IMAP IDLE support of any Android app that I've tried.
Sad that this has to be stated in 2022. Android is the only platform I have this problem with
It's doing about as good of a job at that as it is in upholding my right to decide what apps to run on my device.
It's remarkable that all that so-called "unmaintainable code" results in an app which is far more powerful, and just as reliable, as Gmail.
https://www.quora.com/What-was-the-code-quality-of-the-initi...
2. Google is absolutely doing a lot to prevent 3rd parties from reading your contacts and sending them to a 3rd party server (like this developer was doing). I'm not saying your data is private, I'm saying you have more control over data privacy... but probably not from Google.
3. You can still run this app on your device. Android Studio is free. Go fork, build & side-load it. It will however crash on later versions of Android. Manually giving it permissions should resolve that through at least Android 13. We'll see what 14 brings.
For now. Google's in the process of killing the ability to sideload apks
2. He is not sending contact list anywhere. If application finds john@gmail.com in your contact list, it makes request for https://gmail.com/favicon.ico it's off by default, and has disclaimer next to it. It poses literally zero privacy risk.
3. I use this app daily on Android 12, and this is last android version available for regular users. There's zero issues with it. I would be very happy if all apps were maintained up to this level. I couldn't care less about java being used in order to make that happen.
I can imagine that the developer would have been more willing to make changes if Google had sent him the list you have compiled here.
That's not very old in the scale of things!
> The way he's handling synchro (persistent foreground service) is _explicitly something Google is targeting for battery issues_
My phone has a terrible battery that will drain in 3 hours while navigating¹, but FairEmail running in the background is not noticeable. I've used K9 before as well and didn't notice any difference in battery use.
¹ worst battery I ever had in a phone, and also the most expensive phone I ever had... thankfully I got it second-hand and didn't pay the full price for this. Got a second one for my mom which was equally bad, so we had her device's battery replaced by samsung for iirc €110, but her battery longevity barely improved. Coincidentally I ruled out an hour ago that it's the screen that causes the drain, my next best guess is the CPU. Not sure why this model is such a battery hog, but anyway FairEmail doesn't impact it.
> This app looks like a 5+ year old code base, not something persistently maintained.
FairEmail was the only app that would receive updates every time the f-droid repository had a new release. Most apps go months between updates but of FairMail there were updates almost daily. And it's just this guy working on it all the time, I don't know where he got the energy. So maybe not the "maintenance" shiny new code patterns you'd like to see, but the maintenance I was very happy about was a constant stream of updates.
Additionally, None of this is justification for removal from the store, the comment calling `requestPermissions` illegal is unjust, there's nothing incorrect about its use here (notwithstanding Play Store policies around contacts). ActivityResultLauncher is a more modern (imo superior) and recommended, but it is not a requirement.
God forbid we have some tolerance for developers who don't want to spend every waking moment rewriting their app to use whatever new API Google have just added...
The out of touch is my personal assessment of reading through the code: They doesn't seem to recognize the benefits of the modern Android code styles which would reduce their workload, decrease the boilerplate they're writing, and increase the stability of the app overall.
The older Tasks & Runnable API is very fragile when it comes to lifecycle changes and will cause crashes regularly. This means that you end up building up a ton of patchy code over time to try and do what Kotlin's lifecycle aware coroutines will do for you.
So of course he spent all his time patching: His code was fragile to begin with. You don't end up so many 3kLOC files without poor architecture.
Look: I've been there. Ripping down fragile monoliths to refactor seems like a waste of time because you'll spend 3 months rewriting code while bugs pile up. It's worth doing though because you'll save 6 months of bug fixes in the future.
When it comes to the APIs there's another comment here that explains explicitly the spyware issue (He was scraping emails and sending them to a 3rd party), but for the Android APIs that he was abusing they're recent privacy focused changes that cannot be ignored.
Sure your website will run fine but fundamentally HTML is very similar to what it was a decade ago. Android's runtime is constantly evolving as the phones change to new demands. Battery usage is something they're exerting more control over, and I personally find that annoying. Privacy is another thing: I'm all for that. The permissions requests he was doing will literally crash the app for modern Android. You cannot request permissions that way anymore because the API has changed to make it more explicit.
It sucks that he didn't care enough to fix it, but here we are. He's done an admirable job limping along the mess of a code base but he hasn't implemented the fixes that were needed for it to work on modern phones.
More like adding features if you look at the changelogs for the near-daily releases
Nobody, definitely not Google Play.
That doesn't mean it's ancient at all. Java isn't deprecated, and using Fragments instead of Activities is just one possible architectural approach.
I think Google recommends Kotlin now, but that's only been the case for a couple of years or so.
Google's constant demands for changes to how Android apps are configured are very annoying to the developer, but even they're not that bad.
The ancient APIs is using Runnables/Handlers with Tasks more than it is using Java.
The single (or reduced) Activities with many fragments will improve stability.
Kotlin has been the official language of Android for a relatively short period of time, true, but it's entirely interoperable with all Java code, and improves maintainability _significantly_.
The main issue he's facing here is your last sentence: He refused to change how the app was configured. Use of illegal calls (which he helpfully posts the Stack Trace as a comment when it fails) means the app just doesn't work on modern Android without having to manually grant permissions.
Has the JavaScript culture of rewriting everything every two years purely for the sake of change infected android now too?
I do have a lot of sympathy of for him. I also maintain an app which I provide for free to my users out of altruism.
I don't "refuse" to change how the app is configured, but I don't have time to constantly rewrite it.
Trying to keep up with the Google treadmill of required changes is extremely difficult for someone with a side project (I don't know if FairEmail is full time for its author). Example: I need to rewrite large portions of my app to use scoped storage, but even using the example code from the Google API docs already gets flagged as deprecated.
It might be tolerable if Android is your day job. I guess that's all Google cares about now - apps large enough to be profitable to give them a cut.
Personally I think Android as an O/S should not break userspace.
I mean, I sympathize, but that's sort of the agreement you make if you want to be in the Play Store, right? Like, if you don't have time to maintain your app, that's totally OK -- but at least you have other methods of distributing your app if you want. But if you want to use Google's distribution platform, following their rules for what is and isn't allowed seems fair.
It depends on how you look at it. That is literally the deal, yes, but it's a poor deal for developers of free apps.
We make Android's platform more valuable, for free, and in return we have to constantly rewrite our apps because of poorly-thought out policies that keep changing.
The suspicion is that many of these changes are unnecessary and a result of Google's notorious "promotion-driven development".
I think the most annoying aspect of it is that Android changes so often and so fast that they can't even keep their own documentation in sync.
Google doesn't care. Change for the sake of change is the name of the game, so apps that aren't maintained professionally are screwed
Indeed, with a good mail server, it often seems more reliable than Gmail and their own push implementation.
I don't know enough about the design patterns expected of an android app, but I think there's something to be said for getting robust functionality on as many versions of android as possible (including older devices), and in then keeping that sync engine stable once it works. Given the amount of per device bugs you encounter, moving to newer APIs is likely to result in a whole host of new regression issues that users won't like.
Definitely is. Gmail doesn't set priority on email, so it gets stuck behind Doze, particularly on devices with more aggressive power management features(Samsung, OnePlus, etc). FairEmail is the most reliable email client I've found on the platform
> All written in Java with Activities instead of Kotlin
...
> The way he's handling synchro (persistent foreground service) is _explicitly something Google is targeting for battery issues_
Yes and Android will kill the app if it violates a constraint. It's not forbidden or won't get your app rejected.
> He also does not appear to use any modern Android APIs that Google requires, despite declaring the following restricted permissions
AAAAA. The use of those permissions is not forbidden, they're even needed for backwards compatibility. On newer Android versions and newer target API level, you probably have to start using the new APIs, but that's normal. This won't get even your app rejected. (Contacts is not special even in that aspect, you just have to have a good reason to use that)
> In fact I see him explicitly calling deprecated methods that Google has declared off limits
Deprecation doesn't mean absolutely forbidden. At worst it means that code won't work on newer Android versions and will throw an exception, won't get you rejected.
> That's absolutely a smoking gun and potentially the reason Google would ban him.
Absolutely none of those things is a sufficient reason for a ban. At worst a rejection might happen for other reasons stemming from legacy code, but I don't even that applies here.
Keeping up with the churn of Android takes work and is difficult for most, but legacy code won't get you a ban like this.
The reason is something else.
Also he targets API 32 so the app will crash if he's not using the right API.
"scraped and sent emails to a 3rd party server" is grossly exaggerating other comments which was also ended up being wrong in their assessment.
> The app implementation is out of touch with modern Google Play privacy requirements and APIs.
Kotlin is never required. I think you might be the one of touch.
Maybe I don't fully grok how APIs are evaluated here, but FairEmail seems to be on API 32 (Android 12L), which is the very latest
It still works great even if there is no further development. I much prefer it to the K-9 email client.
The main thing I love is that it blocks all images by default whilst still keeping the email readable.
Open Source: this is the way.
Google is blocked to the maximum degree possible on every device and network under my control, along with anything to do with microsoft. Funny how they are indistiguishable now. No talent and middle management heavy.
Amazing how fast sites are when they aren't spying on you with google fonts being remotely loaded every time for no reason except to violate your privacy.
'Don't (just) be evil... be the prince of darkness!'
Props for keeping up the apk though. For everyone using the app I hope it'll live on as fork.
I'd find it more appropriate if the (current)top-comment doesn't casually criticize some simple looks of the app as if nothing. I mean if somebody's drowning right now next to me, I don't want to hear commentary about how shitty her/his shoes look like. Well, you didn't choose to be top-comment right now for everybody to see this like on a silver plate, but to everybody else... In real life I'd suggest: maybe discuss this on some other day.
Edit: Not top-comment anymore.
I'd go so far as to suggest that app developers are de facto employees, on that note: a recent ruling in the UK against Uber suggests that those who rely on such platforms are entitled to protections. I'd suggest that could apply here, too.
Google is wrong here, but so is this suggestion. Nothing about publishing on an app store fits the definition of an employee.
This is really not due to Google. Google does this a lot and not all developers rage quit on account of that.
Android users it is time you forked out more to support free software developers.
This one is particularly galling because fair email is actually far superior to k9.
I'm so sick of these giant faceless corporations.
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.
Indeed, Google is actually breaking EU law here (with impunity), due to some 2019 legislation requiring transparent and meaningful communication that is clear, and not automated. Interestingly, that legislation also requires that developers be treated equally, so Google would need to offer that kind of manual process for all developers. Arguably that would be a better outcome for everyone.
EFF and EU should respond to Google taking FairEmail off the Play store - https://news.ycombinator.com/item?id=31433051 - May 2022 (42 comments)
https://news.ycombinator.com/item?id=31432334
FairEmail stopping development after Google falsely flags app as spyware (xda-developers.com)
277 points, 113 comments
I hope to see updates to the app somewhere else.
Yes. I can't give you specifics, because even they are not clear in my head; I just know what FairEmail does out of the box works perfectly for me.
Also, filters. I don't move things out of my Inbox after having read them, so I rely heavily on FairEmail's powerful filtering mechanism. I can tell K9 to sort by unread first, but that isn't the same thing.
edit: Since we're on the topic, what alternatives are there? I know of none off the top of my head.
Apps don't support themselves, you know.
I'm sick of buying especially software and soon as the developers is bored or won't get rich they abandon it ot Jack up the price.