[HN Gopher] FairEmail stopping development after Google falsely ...
___________________________________________________________________
FairEmail stopping development after Google falsely flags app as
spyware
Author : worble
Score : 402 points
Date : 2022-05-19 09:08 UTC (13 hours ago)
(HTM) web link (forum.xda-developers.com)
(TXT) w3m dump (forum.xda-developers.com)
| Diris wrote:
| I love that app, I'm so disappointed
| matwood wrote:
| 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.
| root_axis wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.)
| kall wrote:
| Google would just tell you that your app metadata does not
| comply with the Play Store terms of service and let you
| figure it out by trial and error.
| root_axis wrote:
| 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.
| kall wrote:
| 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.
| root_axis wrote:
| 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!
| black_puppydog wrote:
| "come over here, this side of the pasture is slighly less
| kafkaesque"
|
| I think using Apple as the reference here is the wrong kind of
| baseline shift.
| dchftcs wrote:
| 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.
| matwood wrote:
| 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.
| withinboredom wrote:
| 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.
| nulld3v wrote:
| Sound like a reasonable take down. You are using someone
| else's logo.
| withinboredom wrote:
| It was a screen shot of an app recognizing the logo, with
| their permission.
| nulld3v wrote:
| Ah I see, agreed then.
| aerique wrote:
| It's possible to dislike both.
| lapcat wrote:
| 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.
| kall wrote:
| 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.
| dingleberry420 wrote:
| > 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.
| 999900000999 wrote:
| At the same time, you can just send people APKs or publish to
| F-Droid.
|
| 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.
| dewey wrote:
| > At the same time, you can just send people APKs or publish
| to F-Droid.
|
| 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.
| 999900000999 wrote:
| If you have a solid community users will download the app.
|
| Hell, you can point them to a GitHub artifacts page.
|
| At least it's an option.
| dingleberry420 wrote:
| 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.
| Daedren wrote:
| There are plenty of other stores with reasonable reach,
| such as Samsung, Huawei and Amazon's stores.
|
| Of course not nearly as much, but discoverability in the
| Play Store is already a mess.
| alaricus wrote:
| In Android one can at least sideload apps. You can't do that
| with Apple.
|
| I have almost as many apps sideloaded in my phone as apps from
| Google's play store.
| klabb3 wrote:
| Can anyone summarize the events and the (non?)explanation from
| Google? That thread was quite long.
| Crono wrote:
| You don't have to read the whole thread, the message where the
| mentioned events start is this one: https://forum.xda-
| developers.com/t/app-5-0-fairemail-fully-f...
| darau1 wrote:
| 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 hope to see updates to the app somewhere else.
| [deleted]
| lerela wrote:
| 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?
| darau1 wrote:
| > 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.
| kingofpandora wrote:
| I just _did_ pay for it.
| oxplot wrote:
| 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.
| thecleaner wrote:
| If it was free and not without ads, why not publish the code
| and have people build the APK ?
| oxplot wrote:
| I did -- but only a tiny percentage of users can do that.
| ffhhj wrote:
| 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.
| hammyhavoc wrote:
| Can you clarify whether you used the photo correctly under an
| appropriate license?
| oxplot wrote:
| Nope. Just google searched and dropped it in the screenshot.
| hammyhavoc wrote:
| 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.
| tut-urut-utut wrote:
| 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?
| hammyhavoc wrote:
| Intellectual property law is intellectual property law.
| tut-urut-utut wrote:
| But the law is too lax. We should definitely punish any
| violation with a death penalty. Or at least with the life
| sentence.
| KennyBlanken wrote:
| 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.
| Dylan16807 wrote:
| I think it's very reasonable to be upset if my entire app
| was pulled because google didn't like a screenshot!
| satellite2 wrote:
| 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.
| hammyhavoc wrote:
| Frankly, I asked for clarification.
| noasaservice wrote:
| hammyhavoc wrote:
| 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
|
| Touch grass.
| monkey_monkey wrote:
| That's really not consoling, that's just telling them
| it's lucky they didn't get punished harder.
| hammyhavoc wrote:
| Text lacks tone. I'd buy the dude a beer. I'm very much a
| "it can always be worse" kind of guy. Being able to
| relate is human quality numero uno.
|
| Jumping down the throats of others is a negative trait,
| but I'm not going to call you names or tell you how to be
| because I'm not a control freak.
| monkey_monkey wrote:
| I appreciate you not calling me names. I feel blessed.
| hammyhavoc wrote:
| I'd buy you a cold one, mate. It was a well-intentioned
| comment, and I'm sure yours was well-intentioned too.
|
| I posted this earlier today too around the same time:
| https://forum.xda-developers.com/t/app-5-0-fairemail-
| fully-f...
|
| 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.
|
| Stay healthy and happy.
| monkey_monkey wrote:
| Hammy, I said nothing about you sealioning. I think
| you're getting yourself confused and overwrought.
| hammyhavoc wrote:
| Yeah, you're right, I'm confused between users. I don't
| do well in warm weather, sorry mate.
| indigochill wrote:
| > 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.
| oxplot wrote:
| 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).
| KennyBlanken wrote:
| 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.
| jfoster wrote:
| 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:
|
| 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.
| oxplot wrote:
| 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.
| the_gipsy wrote:
| That's not really comparable.
| [deleted]
| alaricus wrote:
| Google has an anti-privacy agenda. We need to force Google to
| give up it's monopoly on Android.
| tawhk wrote:
| 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.
| easyKL wrote:
| 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.
| gommm wrote:
| 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?
| g_p wrote:
| 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.
| neogodless wrote:
| I see #4 is actually a different link than this one:
|
| https://news.ycombinator.com/item?id=31432334
|
| FairEmail stopping development after Google falsely flags app as
| spyware (xda-developers.com)
|
| 277 points, 113 comments
| [deleted]
| richardboegli wrote:
| Thanks @neogodless, I've updated post to include it too.
| my69thaccount wrote:
| What the fuck? FairEmail is the best email client on Android. If
| they don't fix this, I won't switch to K-9, I'll just switch off
| Android.
| cowtools wrote:
| It's still on f-droid
| megous wrote:
| Will you be developing/maintaining/distributing it?
|
| Apps don't support themselves, you know.
| sam_lowry_ wrote:
| And then what? PinePhone?
| my69thaccount wrote:
| Or Librem
| aerique wrote:
| SailfishOS
| encryptluks2 wrote:
| If they don't fix this I'll switch to using CTemplar on an Anom
| phone. That'll teach them.
| CyMonk wrote:
| ctemplar is shutting down.
|
| https://ctemplar.com/ctemplar-is-shutting-down/
| watusername wrote:
| 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.
| Aeolun wrote:
| To be honest, I can see why he would close all threads. All those
| messages seem exhausting.
| my69thaccount wrote:
| What the fuck? FairEmail is the best email client on Android. If
| they don't fix this, I won't switch to K-9, I'll just switch off
| Android.
| memorable wrote:
| I don't use FairEmail much, but pretty sad to see it go.
| hericium wrote:
| > 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?
| netizen-936824 wrote:
| The biggest spyware vendor? What role is Microsoft playing
| here?
| Aeolun wrote:
| Microsoft is selling to your employer. Google is selling you.
|
| I'm kind of inclined to give MS the benefit here.
| parkingrift wrote:
| One where they collect and sell an order of magnitude less
| data. Maybe 2 orders of magnitude.
| chipsa wrote:
| MS wants to sell software. Google wants to sell ads.
| shkkmo wrote:
| Right, a "vendor" is someone who sells something.
|
| Microsoft is a the world's largest spyware vendor because
| Google gives their spyware away for free.
| jimmydeans wrote:
| It's sad, but I paid for this. So hearing that you gave up
| because it'll be harder to profit sucks.
|
| 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.
| memorable wrote:
| Formatted and clickable links for convenience:
|
| [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
|
| [4] https://news.ycombinator.com/item?id=31426915
|
| [5] https://news.ycombinator.com/item?id=31432334
| crowbahr wrote:
| I just commented on the reddit post about this but I'll bring it
| in here too:
|
| 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.
| Avamander wrote:
| 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.
|
| The reason is something else.
| crowbahr wrote:
| The ban is more explicitly stated in a different comment as
| having scraped & sent emails to a 3rd party server.
|
| Also he targets API 32 so the app will crash if he's not
| using the right API.
| aceazzameen wrote:
| Are we playing a game of telephone by adding extra "facts?"
|
| "scraped and sent emails to a 3rd party server" is grossly
| exaggerating other comments which was also ended up being
| wrong in their assessment.
| YPPH wrote:
| Thank goodness Google is looking out for my privacy!
|
| 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.
| crowbahr wrote:
| 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.
| bhcompy wrote:
| > You can still run this app on your device.
|
| For now. Google's in the process of killing the ability to
| sideload apks
| dzikimarian wrote:
| 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.
| Cthulhu_ wrote:
| I dread to think what gmail's codebase looks like, I've heard
| Stories. Some resources:
|
| https://www.quora.com/What-was-the-code-quality-of-the-
| initi...
|
| https://news.ycombinator.com/item?id=2452126
| andreasley wrote:
| Thanks for actually taking a look.
|
| 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.
| fourthark wrote:
| I don't see what is wrong with an app being 5 years old.
|
| That's not very old in the scale of things!
| alaricus wrote:
| I call bullshit on this. Google should not get to decide this.
| As I consumer I want this app.
| crowbahr wrote:
| Then build & side load it.
|
| 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.
| craftyguy wrote:
| > Do you want privacy on your phone?
|
| lol. There is no privacy on your phone if you have Google's
| spyware on it. So your point is complete bullshit.
| Mindless2112 wrote:
| > _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.
| bhcompy wrote:
| > 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
| alaricus wrote:
| 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.
|
| And yes, I will be sideloading it.
| rjzzleep wrote:
| 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.
| crowbahr wrote:
| Java vs Kotlin is a maintainability issue.
|
| 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.
| yorwba wrote:
| > 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.
| crowbahr wrote:
| Great.
|
| 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.
| dewey wrote:
| > It's better and more secure that Google's own email
| client.
|
| Have you or someone else audited the code or what is this
| based on?
| _emacsomancer_ wrote:
| > 1. He's using ancient APIs
|
| 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
| Aachen wrote:
| 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 navigating1, 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.
|
| 1 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 EUR110, 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.
| Avamander wrote:
| > Who really cares if he uses a design pattern from five
| years ago?
|
| Nobody, definitely not Google Play.
| sdflhasjd wrote:
| 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...
| crowbahr wrote:
| 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.
| aerique wrote:
| So how much time would a rewrite take him you think?
| crowbahr wrote:
| 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.
| dzikimarian wrote:
| Works great on Pixel 6. Used very heavily every day. May
| you share your definition of "modern phone"?
| Aachen wrote:
| > of course he spent all his time patching
|
| More like adding features if you look at the changelogs for
| the near-daily releases
| g_p wrote:
| 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.
| bhcompy wrote:
| > 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
| saagarjha wrote:
| 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?
| dingleberry420 wrote:
| > All written in Java with Activities instead of Kotlin
|
| > 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.
| chimprich wrote:
| > He's using ancient APIs. All written in Java with Activities
| instead of Kotlin with a single Activity and many Fragments.
|
| 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.
| crowbahr wrote:
| 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.
| na85 wrote:
| >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?
| bhcompy wrote:
| It's been that way since at least Android 9
| formerkrogemp wrote:
| Yes, we all exist on treadmills and race the Red Queen
| nowadays.
| chimprich wrote:
| > 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.
| bhcompy wrote:
| 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
| filmgirlcw wrote:
| >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.
| bronikowski wrote:
| That's not great. I just recommended a paid version to a friend.
| icc97 wrote:
| You can still get it from f-droid
| (https://f-droid.org/en/packages/eu.faircode.email/).
|
| 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.
| tut-urut-utut wrote:
| Google should be ashamed. Just cancel an app without a
| possibility to actually appeal to the person.
|
| 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.
| mcv wrote:
| 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.
| g_p wrote:
| 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.
| prox wrote:
| Yup, another case of the Monopoly of Google.
| charcircuit wrote:
| It's not like you can't get the app on android anymore. You
| can download it right now from fdroid.
| FabHK wrote:
| From the author (in the linked thread):
|
| > 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 ---
| BeefWellington wrote:
| 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.
| nicolas_t wrote:
| 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.
| prmoustache wrote:
| > 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.
| nicolas_t wrote:
| 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.
| seanw444 wrote:
| This already exists in things like Liberapay. I've seen
| many projects using it.
| mdrzn wrote:
| He won't be maintaining or supporting it anymore.
| Barrin92 wrote:
| 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.
| prox wrote:
| 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.
| lesgobrandon wrote:
| kyrra wrote:
| manfre wrote:
| 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.
| scarface74 wrote:
| Apple gets criticized for its App Store policies frequently.
| But it hasn't been a frequent complaint that you can't reach a
| human being.
| alaricus wrote:
| Apple is worse. You can't even sideload there.
| scarface74 wrote:
| According to the creator of FairEmail, it doesn't even
| matter that you can side load because that's not where the
| customers are.
|
| Notice, the author didn't say "I will make my apps
| available for sideloading"
|
| _I have removed all my apps from the Play store and I will
| stop supporting and maintaining my apps. Google won._
|
| If sideloading were such a great alternative for Android,
| why aren't most app makers doing it and avoiding Google's
| restrictions and 30% cut?
| alaricus wrote:
| I'm sideloading apps. So I care about it. Apple won't get
| a single cent from me unless they allow sideloading.
| scarface74 wrote:
| Well _you_ may care. But the market doesn't and neither
| does the author of FairEmail - the subject of the
| submission.
| g_p wrote:
| Would it not be a good starting point for Google to follow and
| implement this legislation in Europe as at least a starting
| point?
|
| https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32...
|
| 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.
| alaricus wrote:
| Google's monopoly on Android is pure evil.
| draw_down wrote:
| [deleted]
| icc97 wrote:
| 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.
|
| FairMail is a really good app. [1]:
| https://forum.xda-developers.com/t/app-5-0-fairemail-fully-
| featured-open-source-privacy-oriented-email-
| app.3824168/post-86909365
| kolme wrote:
| Crystal clear, quote:
|
| "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!
| krageon wrote:
| > annoying
|
| 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.
| [deleted]
| ospzfmbbzr wrote:
| 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!'
| [deleted]
| Kuinox wrote:
| EU is working on new regulation to fight this kind of things:
| https://en.m.wikipedia.org/wiki/Digital_Markets_Act
| dan-robertson wrote:
| 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.
| alaricus wrote:
| 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.
| krageon wrote:
| 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.
| dragonwriter wrote:
| > Google makes boatloads of money
|
| 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".
| notreallyserio wrote:
| 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.
| lapcat wrote:
| > How does Apple manage to have human reviewers and
| engineers you can talk with on the phone about App Store
| issues?
|
| You can't talk to reviewers on the phone.
| notreallyserio wrote:
| They certainly offer the option.
| lapcat wrote:
| > They certainly offer the option.
|
| No, they do not.
| notreallyserio wrote:
| 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.
| makeitdouble wrote:
| There could be two angles to this:
|
| - 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.
| lapcat wrote:
| I've never received an email like that. They always just
| say "To view or reply to the message, go to Resolution
| Center in App Store Connect."
| notreallyserio wrote:
| 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.
| lapcat wrote:
| How long ago? I haven't been rejected in 6 months or so.
| It's possible they've improved recently.
| notreallyserio wrote:
| It was some time within the last month.
| lapcat wrote:
| I can't say I ever look forward to rejection, but it
| would be interesting to see if this is a general policy
| shift.
| toss1 wrote:
| 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.
| dragonwriter wrote:
| > 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.)
| toss1 wrote:
| I wouldn't say the difference is that extreme.
|
| 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.
| Swenrekcah wrote:
| If a product is too big for an entity to maintain, then
| that entity needs to scale back their product.
| scarface74 wrote:
| Yet Apple seems to be able to do it...
| g_p wrote:
| The legislation needed here for this specific case is
| arguably already in force - https://eur-lex.europa.eu/legal-
| content/EN/TXT/?uri=CELEX:32...
|
| 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.
| Nicksil wrote:
| https://en.wikipedia.org/wiki/Digital_Markets_Act
| teddyh wrote:
| https://addons.mozilla.org/en-US/firefox/addon/skip-
| mobile-w...
| [deleted]
| dbg31415 wrote:
| 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.
| tauntz wrote:
| 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.
| dingleberry420 wrote:
| 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).
| hammyhavoc wrote:
| Am I right in thinking that this was for a popular platform
| that focuses heavily on voting up and down?
| tauntz wrote:
| You are correct!
| [deleted]
| squarefoot wrote:
| This is sad, however the app is 100% FOSS, so in due time someone
| could continue its development. https://github.com/M66B/FairEmail
|
| Open Source: this is the way.
| k0k0r0 wrote:
| Seems like you found yourself a new hobby.
| squarefoot wrote:
| Heh, I wish I had the skills.
| Jenk wrote:
| It's difficult not to assume some kind of hidden "anti-privacy
| apps" agenda when seeing things like this.
|
| Even more difficult to test this given Google continues to
| violate their obligation for transparency.
| alaricus wrote:
| This is textbook anti-competitive behaviour.
| dt3ft wrote:
| 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.
| pietro72ohboy wrote:
| What abuse are you talking about? Google banned the app. That's
| it.
|
| I have donated to this app and I am genuinely happy with
| Marcel's efforts to add features. Users aren't always the
| problem.
| dt3ft wrote:
| 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.
| KennyBlanken wrote:
| 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_?
| Guzba wrote:
| Could you provide the source code where this is supposed
| to be happening? I see the favicons being discussed, and
| the source clearly shows requests only made to domains: h
| ttps://github.com/M66B/FairEmail/blob/master/app/src/main
| /j...
|
| 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?
| k0k0r0 wrote:
| I'd argue choosing to use PlayStore for downloading Apps is
| already abuse. It's negligience towards the creators.
|
| On the other hand you don't need to put your app there,
| except for maybe if you want to attract some users./s
| sodality2 wrote:
| Marcel made several references to the very high volume of
| support requests and how it contributed to the problem.
| BeefWellington wrote:
| Indeed, I would donate again were Marcel to continue
| development via pure sideloading. FairEmail is _REALLY_
| _REALLY_ good.
| barterr wrote:
| He talks about users expectations and unfair reviews a bit in
| a few comments on that page, I imagine there's more I didn't
| read
| dt3ft wrote:
| This is what I was referring to. Thank you for clarifying.
| [deleted]
| worble wrote:
| Link to the main website: https://email.faircode.eu/ (HN wouldn't
| let me post it)
| pimterry wrote:
| 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.
| schroeding wrote:
| Ouch indeed. NetGuard was such an amazing app! It was so
| useful, not only as a Firewall but also as a debug tool! :(
|
| There is no replacement, at the moment.
| mcv wrote:
| Can't someone fork it and continue development?
| schroeding wrote:
| Yeah, there is even a "fork" banner on the website. But we
| can't take it for granted that someone will actually do it.
|
| (I lack any knowledge about Android development, so I'm
| out. ^^)
| aceazzameen wrote:
| oh no! Netguard is fantastic!
| k0k0r0 wrote:
| 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.
| spicybright wrote:
| Mind giving us a few bullet points of what you like about it
| most?
| forbiddenlake wrote:
| 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).
| Aachen wrote:
| 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.
| m-p-3 wrote:
| Apparently Thunderbird is coming soon, but who knows how
| good it will be on mobile.
| drKarl wrote:
| 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?
| NoGravitas wrote:
| I'm running it on LineageOS 19.1 (Android 12), so it must
| have been.
| g_p wrote:
| I don't think K9 supports XOAUTH authentication over
| IMAP/SMTP yet [0], which is increasingly widely required
| by mail services.
|
| [0] https://github.com/k9mail/k-9/issues/655
| forbiddenlake wrote:
| According to that bug report, K-9 plans to add this
| support in the next version!
|
| (it was added to the milestone 17 days ago, but also
| updated today after the Fairemail news)
| stevesimmons wrote:
| K-9 version 6.0 came out last month.
| aerique wrote:
| I really like AquaMail but the free version is ad-supported
| and the paid version is rather expensive.
| hedora wrote:
| 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!
| 0xbadcafebee wrote:
| "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.
| g_p wrote:
| 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...
| hkt wrote:
| 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.
| jaywalk wrote:
| > I'd go so far as to suggest that app developers are de facto
| employees
|
| Google is wrong here, but so is this suggestion. Nothing about
| publishing on an app store fits the definition of an employee.
| privacyking wrote:
| Shame. This is the only decent android email app. Another one
| killed by Google.
| lizardactivist wrote:
| Google and the U.S. monopoly on e-mail and communication must
| burn.
| [deleted]
| Aachen wrote:
| 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:
|
| https://email.faircode.eu/donate/
|
| IBAN DE31 1001 1001 2620 6925 85 - name Marcel Bokhorst -
| description FairEmail
| na85 wrote:
| God fucking damn it.
|
| This one is particularly galling because fair email is actually
| far superior to k9.
|
| I'm so sick of these giant faceless corporations.
| nicolas_t wrote:
| 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.
| nonrandomstring wrote:
| 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?
| alaricus wrote:
| Google doesn't give a f. That's what is happening.
|
| This is what happens when you are a monopoly and there are no
| competitiors in your space. To simply stop caring about being
| good.
| ergonaught wrote:
| 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.
| lapcat wrote:
| > 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.
| Dylan16807 wrote:
| They definitely have the resources to look into apps with X
| thousands of users before cutting them.
|
| And you have to pay to join the store.
| code51 wrote:
| 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.
| IYasha wrote:
| 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.
| lbriner wrote:
| 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.
| e3bc54b2 wrote:
| > What is happening with Google?
|
| They lived long enough to see themselves become a villain.
| aidenn0 wrote:
| It's not the app store we need, but it's the one we deserve.
| Sebb767 wrote:
| 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.
| thfuran wrote:
| >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.
| Ekaros wrote:
| 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.
| jstummbillig wrote:
| > 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.
| jasonvorhe wrote:
| Not to diss the developer, but am I really the only one who can't
| stand the arcane UI?
|
| Props for keeping up the apk though. For everyone using the app I
| hope it'll live on as fork.
| Aachen wrote:
| Yes. I have absolutely no problems with the UI, no idea what
| you're talking about. Are you sure this is about FairEmail?
| [deleted]
| nicolas_t wrote:
| 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.
| Aeolun wrote:
| I have that when I look ar anything Material Design. It just
| looks really bad to me.
| k0k0r0 wrote:
| 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.
|
| Edit: Not top-comment anymore.
| boole1854 wrote:
| 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.
|
| 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...
| nicolas_t wrote:
| 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.
| g_p wrote:
| 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.
| GravityisaHoax wrote:
| How do other email apps handle this? Do they just disclose it
| in the privacy policy? Or do none of them have this feature?
| crowbahr wrote:
| 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.
| gommm wrote:
| 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.
| BiteCode_dev wrote:
| 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.
| Dylan16807 wrote:
| Nope, they made some important mistakes and admitted it.
|
| You are part of the problem by immediately accepting that
| post as fact!
| megous wrote:
| Did you check the links before congratulating on the fact
| checking?
|
| For example for "And Play agreed to allow the app back into
| the store. [4]" The linked comment doesn't state this.
| paulnpace wrote:
| 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.
| g_p wrote:
| 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.
|
| 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.
| Avamander wrote:
| Implementing BIMI instead of that would've saved him a lot of
| headache I suspect.
| megous wrote:
| You mean this?
|
| https://github.com/M66B/FairEmail/blob/master/app/src/main/j.
| ..
| NikolaNovak wrote:
| 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.
| t0suj4 wrote:
| Just the fact that we're so quickly to jump on Google for
| blocking legitimate violators speaks volumes on its
| reputation.
| gommm wrote:
| 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.
| GravityisaHoax wrote:
| 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".
| megous wrote:
| No it's not a reasonable guess. The favicon code is in
| the git for at least 2 years (didn't bother to click
| Older button more times on github).
|
| Google just has a demented communication policy.
| GravityisaHoax wrote:
| 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.
| gommm wrote:
| 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.
| g_p wrote:
| 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.
| bilekas wrote:
| > 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.
|
| Very harsh.
| CodesInChaos wrote:
| Some of those contacts might use personal domains, or company
| addresses, not just big freemailers.
| bilekas wrote:
| 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.
| wander_homer wrote:
| 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.
| pan69 wrote:
| > 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.
| mordae wrote:
| It doesn't identify the client, though.
|
| 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.
| hvdijk wrote:
| > They probably already know more than that, because they've
| seen some emails being exchanged.
|
| Someone being in your contacts list does not mean you have
| ever had any contact with them.
| [deleted]
| boole1854 wrote:
| 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.
| exyi wrote:
| 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.
| megous wrote:
| 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.
| minsc_and_boo wrote:
| 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.
| megous wrote:
| 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.
| gommm wrote:
| 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.
| g_p wrote:
| 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.
| corney91 wrote:
| 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
| teawrecks wrote:
| 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.
| gommm wrote:
| But in that case, the app creator would have a list of
| domains which I think is objectively worse from a privacy
| perspective...
|
| I'm honestly a bit annoyed that OP is the top comment on
| HN when it exaggerates the impact of this feature.
| boole1854 wrote:
| OP here. You are right.
| sureglymop wrote:
| 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.
| [deleted]
| my69thaccount wrote:
| 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?
|
| 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.
| 2-718-281-828 wrote:
| Maybe he should just offer sexual services to the key employees
| at Google to have the app unterminated.
| dang wrote:
| Please don't do this here.
| 2-718-281-828 wrote:
| It's a reference to the Kitty Lixo story
| (https://news.ycombinator.com/item?id=31436182)
| vfclists wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-19 23:02 UTC)