I guess I'll take the contrarian view here: the developer violated a reasonable Play Store policy, refused to fix the problem, and received an expected outcome.
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.
I've read the responses from Google that the developer copied and none of them clarifies exactly what's wrong. If this is really the issue then they should have explained it clearly instead of saying that the app is a spyware.
This seems to be the root problem with Google Play's developer experience - no matter how much you ask them what is wrong, they will not tell you (despite this being straight-up illegal in Europe).
You get a copy-paste of the same non-explanation as a non-answer, which is presumably either automated or being sent by a human with no understanding of anything, and therefore might as well be automated.
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.
Suppose I happen to have someone with an @onlyfans.com email address on my contact list. And I run the FairEmail app on my phone while at work. My phone then hits the corporate DNS server with a request for onlyfans.com, even if I haven't emailed that person. Not great.
Or suppose I'm a Russian dissident in Moscow with a list of Ukrainian-government and military contacts on my contact list. I open FairEmail and suddenly my phone does DNS lookups for a dozen sensitive Ukrainian domains. Not great.
Edge cases like this can be multiplied.
It's not malicious. But it's not great. And it seems reasonable to me for the Play Store to require a disclosure before an app does this.
You can literally just hover over a link and the browser (Chrome at least) may initiate the same DNS lookup. Sure, you don't want that in hardcore opsec, but claiming that it's on the same level as sending your contacts to a remote server is outright wrong.
Well if you receive an email from any of those, your email client requests something from those domain names (which a lot of email clients will do by default). So it'd also show in the firewall logs etc..
So that favicon feature should be an optional feature but calling it sharing contact details is really exaggerating it.
EDIT: It is even optional, so yes really it's a non-issue.
My understanding is that this was an optional feature, and turned off by default - a user wanting to use this would need to enable it manually.
If a user turns on a feature to request favicons for received mail, it therefore seems logical that the app has to retrieve favicons. Doing direct retrieval is likely less damaging to privacy than using a central favicon retrieval server.
I use FairEmail so I just checked: Display Favicons is disabled by default and there's a note below the setting that says "there might be a privacy risk" and links to https://en.wikipedia.org/wiki/Favicon
Agreed, 1) it's not sharing contacts, 2) it only pings those domains if you enable the optional feature. This is exactly how I'd want the app to behave, and I honestly can't think of a better way to handle it.
Maybe caching the favicons on a server hosted by the app creator so that no matter what domain the app looks up, it looks like it's contacting FairEmail.
But google didn't ever elaborate or confirm that this was actually the reason for not approving the app. So we can argue about this feature being problematic without even knowing if that's the culprit... In my opinion, it must be very frustrating to deal with Google in this instance.
Or you open a web page and it loads pictures from all of those domains, and worse. You hit whatever DNS resolvers with any number of domains you may not like. Play store Google daddy protecting you or not.
In the hypothetical that you're hiding from an authoritarian state, you can avoid websites because you expect this behavior.
The problem here is the app was deceptively processing contact lists without user consent, and when asked to get user consent, the dev refused. If you're a transparency- or privacy-branded app, then you doubly need to disclose this information to the user.
Yes, in that hypothetical this may be an issue. But if you fear a DNS resolver, it is really not sensible to use Android and any Playstore app without some filtering proxy in between: 1) first for verification in a safe environment and 2) in real dangerous scenarios once you're sure it's safe, and without installing/using any previously unverified apps or any new updates (good luck ensuring that).
Google didn't save anyone, by discouraging an exceptional developer with this kind of privacy policy https://github.com/M66B/FairEmail/blob/master/PRIVACY.md from contributing anything further on to Android app ecosystem, while keeping all the data stealing apps and ad supported apps, and Facebook SDK using apps, in play store.
Thanks for the background; there's usually (not always, but usually:) details and sides and perspectives; it's scary how quickly we can all come to judgment based on single factoid which we integrate into our worldview and spin into something larger. Not to say I don't understand emotions and perception of unfair demands; but I'm grateful to know a slightly bigger picture.
Well read further about the background, in this case, that specific feature doesn't share the contact list, it just queries domain name. it's optional and anyone asking to show favicon for domain names in contact should expect to know that it's going to be queried in this way?
Also, Google didn't give that as the reason for the app being classified as spyware. So it's just the OP being contrarian by taking an optional feature, claiming it shares contact details when it in fact doesn't and everyone voting it up because it sounds reasonable.
Google may not have given the specific reason but isn't it a reasonable guess based on what they told the dev? It seems like it's what the developer thinks the culprit is too. His commit yesterday was to disable it for the Play Store version, and it included the comment of "Google doesn't allow favicons for privacy reasons".
Well, he's been stumbling in the dark and decided to try this but I don't think it's necessarily a reasonable guess. In hindsight, it's easy to look at this commit and see that as being the reason, but if I were the dev, it wouldn't be my first idea, especially since this feature has been there for a while and since it doesn't actually share contact details at any point, it's just a feature related to contacts that optionally retrieves the favicon.
Of course, if I were the dev, I'd eventually try and go through anything that touches contact and disables that to try and see if that solves the problem, but again that shows that Google doesn't communicate at all.
I think part of the issue is it isn't even clear to developers when (or if) the issue is fixed.
It seems that there is firstly no reason or clarification given. Then, it seems the process of reviewing an update can happen out of phase or sync.
That means there's a very weak "compliance oracle" to see if you've correctly identified the right issue or not. And with high latency, likely it will be difficult to find the right issue quickly.
Disabling everything isn't really a good solution in the longer term as a developer - Google needs to learn to communicate with developers via intelligent humans that actually understand what they're doing, and can have a discussion and help get the issue addressed.
Ah well, it seemed reasonable to me because that was one of M66B's first guesses too. His first comments about this publicly mention guessing that it's favicons, but I suppose he could have eliminated several other possibilities first.
I think almost everyone would be agreement that Google can communicate better.
In this era of quick outrage, thank you for doing the job of trying to figure out what is really going on, at the risk of taking the less socially acceptable side.
Thank you for the play-by-play. Had a hard time distilling this.
Maybe it's just me, but the developer at least appears a bit too emotional and impulsive. I'm not clear why this warrants shutting down, but it's not like there is an objective standard on such a decision.
I think it seems like this is a "straw that broke the camel's back" situation - Google's refusal to actually deliver any kind of sensible level of basic communication with developers seems to be the root cause of this.
When they simply copy-paste the same message (with no further clarification or content), it's a perfect example of a chronically broken system.
Google operates at a scale where they are unlikely to face any incentive or enforcement that requires them to follow the laws around this in Europe, which require meaningful individual interaction from marketplace operators. That they can ignore these laws with impunity effectively shows that (in this context) the rule of law is dead.
In my view, it is very hard to blame the developer - they appear to have been trying to understand the issue in good faith, and receiving absolutely nothing of any sense from Google. And their lack of any kind of meaningful human support is hopefully a "canary in the coalmine" for what will happen in future if we don't get a handle on automation of processes and the harm this can cause to real people and businesses.
> this is the sending of information off each user's contact list (the email address domains) to those remote servers. As such, it requires a disclosure to the user.
That's really interesting.. Honestly, I wouldn't have even picked up on that reading the code, as it's only the domain of the email itself. Not any identifiable information.
Feels a little but harsh but fair enough.
I wonder is there an identifiable marker which could say `"User X has a contact list containing gmail, yahoo and protonmail accounts."`
You don't know who the user is at all but you know "A" user has that contact list.
I still don't see the issue. So the application then asks the personal domain for a favicon, how is that an issue? Especially when you consider that this feature is off by default and has a red warning label next to it, that this comes at a privacy risk.
That's actually a really good point I hadn't considered, from the documentation it mentions only suppoorting standard formats and not those such as MS exchange etc. But you're right, there are personalized which are standard.
Man I only read through the source code to point out the issues with Permissions requests. I hadn't even seen the background of spamming your entire contacts list to a remote server.
That's because it doesn't. It's an optional feature, the feature shows the favicon for the domain names on your contact list. In order to do that, the app retrieves the favicon from each domain in your contact list. It does this in the App not in an external server.
So, reading the code, say you have in your contact list:
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.
I think your contrarian view is biased and misleading.
The HTTP request for favicon of each email’s domain, which you hypothesized, might be the issue that Google was thinking of. However, your hypothesis has never been clearly stated during rounds of emails between the developer and Google.
Wouldn’t it be helpful to clarify an issue in reply to the developer, rather than having someone post “a contrarian view” afterwards?
> Certainly I would expect apps to disclose whether or not they are using any information on my contact list
I would expect the app to ask for permissions when first started and that if access to contacts is one of those permissions that I can disable that. Its for the app to work around not having this permission and if part of the app is not working due to not have the permission, so be it.
For as long as I've been aware of the feature it's been opt-in and _does_ have a privacy disclosure. FairEmail is better about its privacy disclosures than most apps are. Maybe they just didn't do it in the Google-approved way?
Looks like he's also shutdown Netguard, another Android app from the same developer: https://netguard.me/ / https://play.google.com/store/apps/details?id=eu.faircode.ne.... I'd never heard of FairEmail, but I've definitely heard of Netguard! It was comfortably the best Android firewall & had 5 million installs or so via Google Play. Ouch.
FairMail is an insanely good Email-App. I have little to compare to, but it's sick how good FairMail is. I'd be surprised if there is something comparably good.
FairEmail and K9 are the only real options on mobile that I know of if you want open source. Comparing the two, I'm much happier on FairEmail though K9 wasn't bad either.
Particularly the link dialog is nice and helps avoid tracking or accidental taps sometimes.
I used K-9 for a long time until I upgraded my phone and K-9 wasn't supported on the newer version of Android so I switched to Faire mail. Has K-9 been updated to support newer versions of Android?
For me, I moved off of K-9 to Fairemail for one reason: OAUTH support. One of my accounts uses Outlook 365 and disabled support for IMAP (and did not allow app passwords).
Netguard is essential software for Android, imo. It is the first app I install on Android devices, as the entire android OS is spyware and all the pre-installed apps try to phone home, constantly.
People dislike Apple's App Store, but I have always found Googles to be worse. The problem with Google's App Store is if you get caught up in the algorithmic kafkaesque maze, it's very hard to get to a real person to get it situated. Apple has been so much easier to work with in this regard.
It is an alternative. And it is infinitely superior than the situation on iOS where you are simply out of options if Apple does not approve. With Android it might be harder than being listed in the Play Store, but at least it is possible and there are massive communities who do so.
I may disagree with an Apple App Store policy or decision, but IME I've never found it kafkaesque. Google's really is a maze.
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 had an app taken down 5 years after the last update for a trademark violation in the store listing: a photo of a logo. The app was a logo identification app (basically). So that was utterly hilarious. I never fixed it. I lol’d so hard I didn’t even care.
If just "slightly" is enough to make people move, there'd be more competitive pressure on Google to improve things, and for Apple to catch up or stay ahead. Don't estimate the power of competition.
Apple's app store policies are far more capricious, e.g. my company's e-commerce app was rejected because the splash screen displays a shopping cart with a Microsoft Surface in it. We've had many more problems fighting Apple's app store than Google's.
I mean you say that, but having done about ~60 releases for the same app on both platforms over the last three years, google has only once caused us an issue (due to changes in privacy policy disclosure requirements that we had to rectify), whereas Apple has prevented us from deploying at least a dozen times over the same period, several times for issues that they hadn't flagged in previous releases, and sometimes having us wait for up to 2 days for re-review.
I guess it's a matter of anecdotes. I certainly don't have enough data (one + a half apps with countless updates) to make any serious claims. For us google has been more trouble, but I've heard other bad stories about apple too.
I'm freshly frustrated because I'm dealing with a random metadata rejection (on an "internal testing" build! nothing has changed!) just now.
The anecdotal remark is fair, it may just come down to the nature of one particular type of app vs another, but on a personal note, I find things like automated metadata rejections a lot less frustrating than fickle human rejections because I can debug metadata and resubmit to receive instant feedback - akin to fighting with a compiler - whereas with apple some issues require multiple days of back and forth with reviewers while I pathologically refresh the review status page. What I find to be most frustrating is when the reviewer responds with a change request, we fix the build, then the next reviewer rejects some other random thing that wasn't mentioned in the previous review, dragging out the release date even longer. Anyway, fuck em both, cheers!
I think the argument is not that the rules are inherently any nicer, but that there's an actual process where you can find out what you did wrong and fix it rather than just being banned out of the blue one day. (I'm not entirely convinced by this argument, on the basis that I've heard unpleasant stories about Apple changing policies and screwing people over, but it's a plausibly valid argument to make.)
Yeah, I've found App Store rejections to be harsh (functionality is not useful? ok) or restrictive, but always parseable. I even successfully asked the reviewer if a certain change would remedy the issue, they said yes, I resubmitted and that was that. Took about 2 days in all.
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.
> I even successfully asked the reviewer if a certain change would remedy the issue, they said yes, I resubmitted and that was that. Took about 2 days in all.
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.
It's possible to dislike both while also pointing out a shortcoming in one compared to the other. Google could do much much better in terms of customers service; they could start by actually having literally any customer service.
Eons ago, I built an Android app which allowed using high quality photos for contacts. I made the "huge" mistake of using a celebrity photo in one of my screenshots. Lo and behold, few months later, my free with no advertising app got removed from the store and the only way to put it back was to create a new app which would have a new URL and none of the ratings or reviews carried over.
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.
There's no possibility of controlling the distribution channel anymore. Some think that web is it, but it isn't. Google Chrome is by far the majority browser, and all they have to do is decide that your website is unsafe:
Nothing is absolute. Even in absence of Google Chrome, you still have all cloud services and ISPs abiding by the laws of the country they operate in.
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.
I work on a cross-platform App used by millions of of people and one day during event that runs on our App google blacklisted out domain as phishing (for all of chromes) because we had too many dots url in the url and too many requests coming into the service to quickly.
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.
> you still have all cloud services and ISPs abiding by the laws of the country they operate in.
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.
Google has been moving in the direction of exercising ever greater control over the web. These little Chrome features aimed at "protecting users" are just parts of it. They control discovery (Google Search), the infrastructure (Google Cloud), the client (Google Chrome), and a very common support channel (Gmail).
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.
> 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.
F-Droid came to be in late 2010 and I built the app in early 2012. As such, I didn't really hear about F-Droid at the time and I assume the user base would have been very small (but still better than nothing).
I'm finding it extremely difficult to have any sympathy for someone who used a celebrity's image for commercial purposes instead of buying some stock photo or hiring a photographer friend and a model.
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.
He did not since he mention it was a mistake. The quotes around huge convey the meaning that he admits the error while finding the punishment disproportionate.
And if you bothered to read my reply to them before you rudely interjected, you would see that I shared that experience and consoled them over it. https://news.ycombinator.com/item?id=31434328
Believe me when I say that I wasn't "sealioning". I hadn't even heard of the word until today, which tells me you're either younger than I am, know the word, and look for opportunities to use it, or you're overly emotionally invested in what others have to say (hence the "touch grass"), or maybe you genuinely believed that to be the case.
FWIW, I hope your day turns out good too (saw the comment before the edit). I don't go looking for confrontations, far from it. I'm sure we'd get along, after all, we're on the same site looking at the same content.
Having once made this mistake in my teens about twelve years ago, just be glad that the copyright owner didn't pursue you over it, it could have been much worse, and is a lesson learned a relatively easy way.
Yeah, parent should have been laying at least 10 years in prison for such a “huge” mistake. Maybe we need to re-introduce back a death penalty for such serious crimes?
Nobody said they should go to jail. We're saying maybe parent commenter is being a tad unreasonable complaining that their app got pulled and banned "without warning" for commercial use of a celebrity's image.
"I didn't break the law that bad, why was I punished so severely!" is exceptionally immature.
I solved this by requesting a new app url from the server, if there is any the app would request the user to install the new app. I even managed to create my own update method.
What is happening with Google? Seems there have been quite a number of
"Google broke it" stories flying around - or am I just seeing
confirmation bias as my negative experiences of Google increase
daily. Search is awful. It can't deliver mail reliably. Is Google
broken inside and turning into a hostile entity?
Among other things, what's happening with Google is the same thing that happens with Facebook and Apple and so on. They got too big, and they don't care, so there are few to no humans involved in human-facing, human-affecting decisions. Humans don't scale well or cheaply, so they automate. Things go sideways as a result. No one cares, because they're too big to have to care about this anymore, and they've switched into parasitic extraction of revenue instead of caring.
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.
> They have the resources to not have these problems.
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.
Well I said X because it doesn't really matter. I'm very confident that my argument is true for X=100, and it's probably true for notably smaller numbers. I don't need exact statistics to know that it's much much less than 3.5 million.
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.
Of course as the number of apps that are coddled or given special treatment gets smaller, the easier it gets to coddle or give special treatment to apps. But how does that help the Play Store overall? How is it fair that a few developers are given special treatment, while everyone else still suffers from the same arbitrary rejections?
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.
> 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.
The AI dream we dreamed of is actually this kind of nightmare in ignorant hands.
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.
It seems like they are the worst example of the stereotype of a software developer. They make out that they are the best examples of technical prowess but not only are they not but they also have no people skills.
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.
They are the other big player. So of course things happen there as lot of entities or nearly all of them actually deal with them. Doesn't mean their decisions or products aren't getting worse for users.
> Doesn't mean their decisions or products aren't getting worse for users.
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.
Have you ever heard of fake competition? That's exactly it.
1. Have evil corp MS
2. See people getting negative vibes about it
3. Create a "don't be evil" corp
4. See people flee there
5. Close the cage.
In my anecdotal experience, there have been a few outrages a month over something Google has f-ed up on HN for years now. I'm not too happy with them, either, but you also have to factor in Google's size - at a billion users, they're bound to have a lot of unhappy ones, even if they would be perfect.
Lastly, HN has been successfully used for contacting Google support in the past, so this also increases the number of posts.
>also have to factor in Google's size - at a billion users, they're bound to have a lot of unhappy ones, even if they would be perfect
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.
> FairEmail stopping development after Google falsely flags app as spyware
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?
lol have you heard of ... Windows 10? No OS collects more usage data. And no you can't disable it. And if you try, it will re-enable tracking after some updates.
Have you heard of… Google? Search, Gmail, Maps, Android, YouTube, Smart Assistants, home security cameras, thermostats, Chrome, and more, and more, and more.
I’ll stick with my assertion that Google collects 1-3 orders of magnitude more data than Microsoft.
Those are services not OS. And Microsoft services are no different. Difference is that Google is more successful (has more users and services and therefore more data).
How would this regulation help in this specific case?
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.
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.
Google makes boatloads of money, but somehow they cannot seem to implement a good people-focused review system for whether or not apps are malicious. "But that doesn't scale", I hear you say. They could simply hire more people, that scales fine. It's quite simply that Google has never been a people company and the culture has never shifted from engineering first to people first. It is a shame, because this leads to an ever more shitty experience for the humans using their stuff.
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".
If you can't properly do the business, you should not be in the business.
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.
> If you can't properly do the business, you should not be in the business.
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.
How does Apple manage to have human reviewers and engineers you can talk with on the phone about App Store issues? It seems like it scales just fine for them.
Do you contend that they are lying when they include this in their rejection emails:
> 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.
Interesting. This was with a minor app that has no users and no name brand. Thus I assumed it was standard. Sorry about that, maybe it's more arbitrary than I thought.
This is exactly where you need regulation. EU can force Google to to create sane policies for removal, or even fine Google when they do stuff like this.
It would certainly be nice if at least their feedback was a bit more meaningful and explained the actual problem, and not just a vague category that they thought most closely fits the issue.
Part of the problem as well here is that the alleged policy violation doesn't gives enough information for a developer to even figure out what behaviour they're seeing, let alone where in a complex app that feature is.
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.
> 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.
I think we're reaching a point where because of the unreliability of the two major platforms there may be a path for developers to go the Youtuber route and start Patreon to fund development. You already see this in certain genres of games (notably adult content) that are typically just hidden on stores.
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.
I suggested that in the forum too. I support quite a few developers through patreon, paypal subscriptions or Github: Calibre, a lot of mister devs, Karabiner Elements (Tekezo), Scummvm (Eugene Sandulenko)
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.
> 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.
Oh yes, I don't mean that's specific to Patreon the platform. It's just that in my limited experience dealing with a not that popular opensource software and dealing with support for an old school shareware back when that was a thing, the most entitled, the least friendly and the most aggressive emails were all from people who didn't donate, didn't pay or didn't contribute to the code (in the case of my opensource project).
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.
I would wager the amount of android users who even know what fdroid is, is < 5%, if not much lower. Getting flagged as spyware or booted from the Play Store effectively destroys any project that relies on funding.
It’s kind of missing the point of having a company shutting down your business without much recourse for objection. I currently have to deal with Google on a matter, and the lengths I have to go through to even get a response is ridiculous. And this is on their ads platform, so technically I am their best kind of client who brings in money.
And there is no alternative, that is the monopoly.
The author has every right to stop accepting the uncalled for abuse from users and drop development and support. I hope he can direct his attention to things that give him joy instead.
Please read his comments. He is overwhelmed and I wouldn’t be surprised if he even felt abused. Users (especially free tier) can be (more often than not) nasty towards developers.
If it he doesn't want to "feel abused" maybe he should not have been shipping people's contact lists off to a third party without their knowledge or permission while claiming to be a privacy-oriented application?
I noticed a lot of threads about how it's good that this (apparently more reliable than K-9 or gmail) app needs to be thrown out and rewritten because of android-side API drift.
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!
Indeed - what a lot of comments on this topic seem to overlook is that a lot of device specific bug fixes have been put into effect for push sync in FairEmail, without battery drain, and while only using IMAP IDLE (therefore avoiding cloud sync or sending email passwords to third party services for push messages).
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...
"The new shell is more advanced, so it's better!" is false equivalence bias. It's more complex, which isn't the same thing as better.
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.
> Unix shell has survived more or less intact for 50 years. That implies no significantly better CLI language has been invented
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.
I realized I never donated. Usually I do this after using an app for a bit. For whatever it's worth, I feel bad so I will do this now still. If you are in the same situation as me:
Years ago I built an Android app that started to finally gather enough users for paying some of my bills. And then I made the irredeemable mistake of switching the app name from "$SocialMediaCompany $MyProductName" (think "Hacker News Comments") to "$MyProductName for $SocialMediaCompany" (think "Comments for Hacker News") and then back again to "$SocialMediaCompany $MyProductName" because I noticed that all "competitors" were using the same format as I originally did and wrongly assumed it's not an offense that would instakill my app.
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.
My experience with ios reviewers is closer to this:
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).
I loved netguard, I donated 20 euros a couple of years ago and was thinking of donating again :(
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.
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_
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.
Most of what you listed is either incorrect, irrelevant or purely subjective. I'm doubting your familiarity with the system.
> 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.
A lot of my analysis is personal and subjective based on 5yoe as a full time Android Dev.
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.
> The main issue he's facing here is your last sentence: He refused to change how the app was configured.
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.
>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.
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.
> 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.
And scoped storage is basically a nuclear bomb. Nvidia is still struggling with it on the Shield/Android TV as it has completely upset the turnip cart in regards to things like Plex Media Server that worked just fine before scoped storage.
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
>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_.
Has the JavaScript culture of rewriting everything every two years purely for the sake of change infected android now too?
1. The issue here is one of failing to maintain the code, so I don't see how calling it unmaintainable is unfair
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.
1. How is he failing to maintain it? There was no single issue with code quality in this situation.
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.
One thing I've noticed about FairEmail is that it is able to do low power push messages via IMAP IDLE, without any kind of external cloud push platform, and maintain this reliably across connectivity state changes.
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.
> it often seems more reliable than Gmail and their own push implementation.
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
I'm not an android dev, can someone weigh in here? Why is using Tasks bad? Who really cares if he uses a design pattern from five years ago? I'm sure my website code is at least twice as old and PHP, should I spend time rewriting that in Kotlin, too?
> 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.
The comments on code quality are somewhat fair, and there are better ways of doing things, but calling it "out of touch" because it's not been rewritten in kotlin is frankly silly.
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...
It's illegal because it crashes the app on the latest versions of Android. It's an illegal operation, not "against the law in N countries" type of illegal, more the "Divide by 0" type of illegal.
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.
I was just documenting issues I saw with the code from a maintainability standpoint.
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.
Having a bunch of legacy code isn’t really a valid reason to block an app from being on the Play Store. Your code review isn’t particularly useful here. It might be if you went “oh this permissions API is not supposed to be used and you can see Google asked the app to use the new API to be approved” but that’s not what seems to have happened here?
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.
> It literally does not function on a modern Android device because of the permissions.
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.
The stuff about APIs is nonsense. The app works fine. It's better and more secure that Google's own email client.
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.
I'm sad to see it go as well. It's my main mail client on Android.
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.
> 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+.
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.
Oh the irony of Google flagging ANYTHING as spyware.
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!'
Did you actally read the thread? His rage-quit feels actually quite tragic right now. Additionally to the insane problems with Google and the PlayStore-enviroment/ecosystem, his girlfriend is currently sick, and taking care of her is his priority.
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.
I like the UI, it works well is easy to configure and gives me everything I need. I tend to dislike new UIs that have hidden defaults, are not configurable enough (because users won't understand) and focus on form over function. FairEmail is great because it's super useable and gets out of my way when I want to do anything.
Google are vile. Decisions like this should always be appealable to an independent tribunal, the way that employment disputes are.
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.
In the UK we have a category of "worker" which is between self employed and employed. I strongly suspect the fact that google play is the sole marketplace for most apps has an effect that brings people into that definition. It is about whether or not a business is captive, and whether it relies entirely on one platform for its customers. These things are what got GMB their victory over Uber in the employment tribunal.
With over 5 million downloads ommon sense says the developer is giving up because it is not worth it, ie not enough people buy the software or donate to support its development.
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.
Hey, I don't like the title of this post. I'm not entirely sure "falsely" is correct.
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.
Is there anyone at google who can help with that? It's sad that the only way to contact Google is by making a big enough stink, but I'd hope that Google would at least have some kind of manual processes for well loved app with a huge amount of downloads like fairemail?
Ultimately the inability to reach an intelligent human at Google that responds with something other than an automated response seems to be the root issue here.
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.
This sucks, Marcel is a great developer. I have donated to this project a few times and I have been using this app for quite some time now. He is very responsive to your emails and questions. I hope he continues to develop.
So, google is flagging an app which competes with an app they make (gmail) as spyware without any real path of recourse, and effectively blocking it from a platform they control? Could this be grounds for an anti-trust suit?
Seriously? I configured all five of my email accounts on FairEmail literally a week ago, because K9 doesn't have a unified inbox. I was even going to pay for it, just so I could snooze mails without having to use the Gmail client.
I am surprised you are saying K9 does not have a unified inbox, because I use it daily (Settings/General Settings/Display/Show Unified Inbox). Do you mean that the way it works does not meet your needs?
> Do you mean that the way it works does not meet your needs?
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.
I just assumed it's sarcastic, pairing a privacy-focused email provider that's shutting down with a "privacy-focused" phone that was actually developed by the FBI as part of a sting operation.
Yes he does sound stressed out, I have done similarly drastic things when I felt like he does. Going cold turkey is sometimes the only way out.
But saying that "annoying" is a very cold understated way of describing Google's actions.
I'm in awe of the work this guy has put in. Google I would hope amongst their developers would recognise that this is an important useful project.
The developer himself it appears could handle the negative comments but they clearly ground him down [1]:
> 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.
Note: the stress comes from the unclear Google requirements.
If you do have any access to the Play Store (you're one degree of separation closer at least) then please ask them to find out what's going wrong.
In that thread he commented that this happened before. Having your "landlord" lock you out on multiple occasions with no clear communication about why is a lot more than simply "annoying".
He may have other sources of stress in his life, but those don't mitigate Google's ownership of killing the app.
"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."
So your employer is the _main reason_ this guy is giving up.
Also you defending your employer in this thread, given the context, is highly insensitive. Makes you look bad, that's why you're getting downvoted.
You should have not commented this, or even better, you should switch to a company that doesn't suck!
They're not annoying, this is stepping on little people just because you can. It's malicious because the process (i.e. Google as an entity and everyone relevant inside of it) does not care, and quite honestly by trying to go online and saying it is okay you make it worse: Any decision maker is going to see folks condoning it and think "can I go a little bit further next time?". That's how we got to this point in the first place.
It seems like this whole situation and fiasco could be avoided if Google didn't try to automate compliance violations that frequently don't give any information about the violation, then provide no actual ability to have a discussion which leads to clarification or information flow outward.
This legislation is a starting point, but if Google and others flout it, it won't achieve anything. Hopefully someone looks at a way to bring an action against Google under it, and bring some change in how developers are treated.
I have a story with FairEmail.
As I'm always looking for 'libre' (or at least open source) alternatives to the apps I use, one day I came across FairEmail. I saw that it had an app in the Playstore and in F-droid... I did a little research in their repository and then I decided to try the F-droid version. I had to enable Google's option for "unsafe" apps to allow me to use my Gmail.
About a week later I get the alert of an attempted login with my Google password.
I decided, after changing my password, to uninstall Fairmail (it was the only place I put my password so it could have been leaked). But I was always left with the doubt that Google might have possibly spoofed that login attempt so that I would just go back to using the official Gmail app.
That's the way Alphabet has to force you to use the official app.
It also happens with Gmail accounts on Thunderbird.
They claim is just because the need of OAuth support for third party email apps.
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...