I'm not sure there is anyone nice here. This is likely cynical corporate damage control at best or the work of an annoyed Google employee who happens to use this app and took a personal interest. I love Fairmail and as a paid user I'm glad it's back on the PlayStore but nothing about this makes me think better of Google or anyone in charge there.
Especially since the fix seems to have been to expand the table in the privacy policy. On top of that most of these seem to be features you have to explicitly enable.
Yeah, how could Google requiring a developer to disclose data collection be a good thing? Geez people, let's continue the outrage at Google and demand that no developer have to disclose data collection.
> This is likely cynical corporate damage control at best or the work of an annoyed Google employee
I fully disagree with your take.
You are assuming the default is negative. I think your explanation might be possible, but that by default it's wrong, as most people are not cynical/annoyed or any other negative quality.
My fundamental belief is that most people are nice and want to do good things.
If you are surrounded by cynical/annoyed people, you may be in a toxic environment, which may taint your judgement for other situations.
I am assuming the default is negative - for Google.
I work for a far far older engineering company which is built on maintaining good relationships with our customers, vendors and their engineers. It is the exact opposite of the AI driven, frustrating/pointless bot response attitude of big tech companies. I like to think the difference is that we haven't optimised out our humanity yet.
The problem is that Google, Amazon, etc have stripped people from the customer support equation, and outsourced it to chatbots and automated systems, and you're not allowed to reach a human.
Even worst is when actual humans get your cases, but can only reply with templates (like on Seller Central), where they have no problem sending you the same message over and over again.
This should be regulated for monopolies. People should be able to access a human for assistance.
Humans using template responses seems to be one of the biggest complaints the FairEmail dev had - repeated copy-pasting of the same response, despite asking for clarification and even citing European legislation (which Google needs to comply with), asking for them to actually explain in plain language what the problem was.
The description of the problem they gave was inaccurate in any case, which didn't help the developer in working out the problem.
You therefore make a good point - while people often talk about the need for humans, these humans ALSO need to be free-thinking, not bound by a script, and have meaningful escalation paths to use for cases that the process isn't working for.
That's all well and good but I wish we could avoid the entire circus from the start. I hate the power companies have over distribution channels, the eternal struggle between convince and freedom.
The nature of email clients, especially ones that integrate with cloud-hosted spam and filtering services, is that they're naturally going to have trouble with that policy absent great care with specifying exactly what gets collected. The "fix" here seems to have been to update their policy documentation to describe exactly that.
That's one of my issues, of course. With half-automated/decided by unaccountable forces strict reading of the "law" (store policy) you get outcomes like that. It would be much better to have "spirit of the law" reading of the policies, but that requires engaged staff/high touch verification process. Google is unwilling to go that way so our only recourse is to make a ruckus and hope we'll get the ear of someone who can whisper to the emperor.
Which part of the spyware section were they in violation of? Pretty much everything on that table has to be explicitly enabled and does the obvious thing when it is.
He was sending every domain in a user's contact list to a third party service to retrieve favicons if users enabled the service...and not disclosing that.
More importantly, Google told him that he needed to disclose what he was doing, and his response was petulance. You know the type: "I was speeding because I was LATE TO WORK, officer!"
Based on that linked thread, it was off by default, mentioned there might be privacy implementations, and contacted the domain itself (which I would not classify as a third-party - that's the service that is in control of the email address) to retrieve its favicon.
That seems more than reasonable to me (off by default, with a warning!), and would be exactly what I would expect the app to do if I did enable favicons.
From what I can tell he didn't just bulk send every domain, only the ones that are visible in the inbox. If you don't receive mail from a contact, I don't think the app ever uploaded anything.
Still pretty bad, and I don't think Google is wrong to flag the app because of this.
However, Google didn't say "if the user enables a certain setting, your app is uploading domain names from your users' contact list to third party avatar services", it said "you're uploading contact list information without disclosing that in the privacy policy".
They seem to know exactly what the problem was but described it in such a vague way that it definitely reads like an accusation of extracting data.
Both are wrong here, but Google is in a position of power and should be held to a higher standard. I'm sure just listing the hostnames that weren't covered by the privacy policy were enough to prevent this whole situation.
It is good that these things were opt-in but I disagree that the implications were obvious. There is an entire spectrum of implementation options for many of these features regarding how much work is done on the device and how much is done on an external server, and thus what data must be sent to the service. The user needs to have this explained to them so they can make an informed decision.
If every app had a clear table like that, that'd actually would be the bee's knees. Especially if it was front-and-center. Imagine if every code library came with a structure that documented that too (ie, for 3rd party libraries that link to 3rd party services), so the table could be someone automatically generated.
It's akin go a standard privacy "Nutritional Label" that only exists due to forced regulation, and not industry agreement.
This is what Apple has/is moving toward and yet they get ripped to shreds here and on reddit.
As an iOS user, I want even stronger privacy control and disclosures; the current Apple disclosure requirement is still pretty vague. However, it is really nice seeing apps that say "this developer does not collect any user information."
F-Droid is set up better than Apple or Google but it's illegal for me to install F-Droid on an iPhone and while it's legal to install F-Droid on Android Google has intentionally made it unusable without rooting your phone.
And two-thirds of the updates and installs will pop up a dialog from Google requesting you in misleading terms to enable Play Protect if you haven't. Where the entire point of F-Droid for me is to stay out of Google's grasp and ecosystem.
I've been using F-Droid for many years. Currently, I'm on a stock, never rooted OnePlus 8 running Android 11 (OnePlus's OxygenOS). Google services are present, disabled where possible, and I am not signed into a Google account. I install all apps from F-Droid and the Aurora Store; including several banking apps.
I've never seen the Play Protect message you're talking about.
I do have Play Store services enabled and updated. I do "system" app updates (Carrier Services, Android System WebView, Play Services, etc) through the Play Store's update mechanism (which is still available even though I'm not signed in to a Google account). I do "user" app installs (Schwab, Amex, Fastmail, Element, etc) from Aurora and F-Droid.
Yes. I manually update from Play Store too so I didn't notice the difference.
I'm doing that because I've been hit too many times by upgrades that reduced the functionality of apps or changed it in ways I don't like. I'm currently not updating K9 Mail past 5.6 and some useless Samsung apps that I can't uninstall.
How do you figure out if the upgrade is going to be good or not? From reading the reviews? Some other news source? Or do you just try it out and downgrade the app if it's not good enough (does Play Store even allows downgrades)?
It doesn't. I tend to look at the new features but k9 bite me hard. Luckily I had the APK of the old version and they also have a link to download it. Anyway I don't have many apps anymore and I tend to install only open source (I don't trust apps much.) FOSS apps are easier to downgrade.
> I tend to install only open source (I don't trust apps much.) FOSS apps are easier to downgrade.
Yeah, I do the same these days. It's amazing how freeing it is to be able to trust the app you're running, and not have to constantly be on the look out for dark patterns, "integrations" you didn't ask for, sneaky updates, change of ownership due to an "incredible journey" with a FAANG/MAGA company or a Chinese equivalent. I'll take the more limited choice and the general lack of UI polish any day, for these benefits.
yeah, doing this automatically from code would be amazing
(and probably required complex dataflow linting to ensure it)
even for apps that aren't open source, a trusted third party can run an analyzer on the source code to generate something like this; you can also have internal dashes that track what has been shared, how many times, and what triggered the share. you can hook into settings and toggle specific sharing on / off, you can ban certain kinds of sharing entirely.
tools like skyflow are already trying to provide this for regulated PII
If an open source project is really just somebody releasing their own code, they don't have any obligation at all to the end user. If a business is releasing open source code and has some business model that ultimately turns that into profit (even indirectly, for example via selling your private info), then they have an moral obligation to be clear on how they are making money.
On the other hand, the app stores have no obligation to host projects generally.
If they release the source and I'm building the app, maybe you're right but it would be nice to know how they it handles privacy without having to read every single line.
If they distribute the app there is little difference from a closed source install. Again, "read the code and learn what we do about privacy" would be pretty hostile.
In this case it doesn't. I also can't give away meth for free. Distribution of an app that processes personal data without a valid data privacy statement is illegal in the EU and could get the author and/or github into trouble unless they implement an export restriction (eg. EULA that prohibits distribution in the EU).
> Distribution of an app that processes personal data without a valid data privacy statement is illegal in the EU
Is that really true? For example data processors are bound by GDPR but I don't see how the author of this application is a data processor (or a data controller). In fact I'm not sure that legally "app that processes personal data" is the correct description here, considering the very specific meaning of "to process" in this context. If an email client run by a user on his own machine with no involvement of the vendor of that software requires "a valid data privacy statement", then so does probably the user's keyboard driver. And the text formatting engine. And the networking stack. Etc. etc.
Best I can do is offer my interpretation. GDPR applies to "[...] the processing of personal data wholly or partly by automated means" [1]. I take "automated means" to include this app. So when this app runs and processes EU citizens' data, the law applies. But to what or whom...
> I don't see how the author of this application is a data processor (or a data controller)
... I understand as follows: things are generally not responsible under the law, their owners and creators are. If I install and use a software, the GDPR entitles me to knowledge of its personal data processing capabilities if it processes personal data, which this app seems to do. As the GDPR evolved from consumer protection law, I'll employ an analogy: if I win a free vacuum cleaner in a raffle, the product still needs to include a safety guide - the manufacturer or distributor can't delegate safety responsibility to me. GDPR is about personal data safety.
> If an email client run by a user on his own machine with no involvement of the vendor of that software requires "a valid data privacy statement"
Conversely, at least one mainstream email client comes with a data privacy statement [2]. Which doesn't prove my point, it might be just ass-covering.
> then so does probably the user's keyboard driver.
Maybe the operating system's data privacy statement covers this? Otherwise that reasoning appears sound.
Thunderbird's privacy statement literally talks about collecting data on its users through telemetry. If this application doesn't collect any such data for its author, then this point goes away. If you are using the software, then you're processing your own data. I'm not sure that provenance of your tools has any bearing on it. Even just 2(c) in [1] would disqualify it.
> Thunderbird's privacy statement literally talks about collecting data on its users through telemetry.
According to the data privacy statement (DPS) it does more than that, refer to chapter "Set-Up and Configure Your Email": Thunderbird collects your email domain and other technical data to set-up and configure your email account. Other information, like your name, your email messages, and your account’s address book are stored locally on your computer and never sent to us.
"Thunderbird" means the email client, not the web service ("us"). The DPS cleanly separates between data stored locally on the client and data shared with the servers - the DPS addresses both scenarios and it explains which data is stored locally, so their interpretation is that GDPR covers data processed by the application which does not leave the client, too.
> If this application doesn't collect any such data for its author, then this point goes away
The Thunderbird DPS seems to think otherwise, as it describes the locally stored data even if it isn't submitted to the web service. Maybe the DPS doesn't intend to apply a legal interpretation to local data and mentions local data only for contrast to shared data, which the DPS definitely cares about? Hence my in-earlier-comment comment that this might be just ass-covering without legal weight.
I was talking purely about what the GDPR might require you to do. That Thunderbird tells you more in no way necessarily means that GDPR requires it. GDPR doesn't prevent you from voluntary disclosing information. With extremely high likelihood, telling the user that your computer will remember your e-mail address in an application completely under your control that will never send it anywhere else on its own, just so that you wouldn't have to re-type it every time, is not something that GDPR forces you to do. Not to mention that privacy statements don't necessarily have to satisfy just one party. A single privacy statement may incorporate clauses to satisfy all the local requirements that an internationally operating entity making that statement is obligated to satisfy.
> telling the user that your computer will remember your e-mail address in an application completely under your control that will never send it anywhere else on its own, just so that you wouldn't have to re-type it every time, is not something that GDPR forces you to do
That's exactly what the GDPR enforces. You give the app personally identifying data, so the app needs to disclose what it does with the data because storing it on the computer and not sending it anywhere is still data processing. In this case the data privacy statement needs to tell the user that the data is stored but not shared. If you're not doing anything with the data, then don't ask for it.
Please show me where the GDPR talks about the behavior of software as opposed to the behavior of legal entities. To my knowledge, GDPR puts limits on what legal entities do to other people. Software is not a legal entity.
"open source" isn't a very helpful label/designation IMHO with regards to this. "Open source" can describe somebody's hacked together personal project or AOSP, which are wildly different.
Is it? Google would have been fine if FairEmail presented the same data privacy disclosures that its apps and all other apps on the Play Store present. The problem seems to be that the standard data privacy disclosures are too vague (just what data is collected and not what the data is used for), which presents FairEmail in a bad light because it looks no better than alternatives. FairEmail went beyond the standard disclosures in order to explain why it is not so bad.
And also if you stop using it you need to [buy an apple product/root your phone(and then your bank apps don't work)/stop using phones altogether(which doesn't go well pretty much anywhere[•])]. So there's really only the option to give up your privacy to either google or apple.
[•] I personally lasted two months without a phone once (2016 Japan), since 80% of services would outright refuse you if you didn't have one, while the rest would pester and harrass you extensively before finally giving in.
Are you able to use any banking apps? I stopped rooting some time back when that became normal for financial apps, and the ability to monitor/manage account balance from anywhere was hard to give up.
For my bank I can only use their android/ios 2-factor app or their own physical authenticator, which I also have, but I found out the hard way that it's vulnerable to rain when in a pocket of a backpack. It is impossible to do anything without the 2nd factor auth of course.
Generally with much reduced functionality compared to a full app. Can't mobile deposit from the web, and couldn't use a one-time access method to use my bank's ATM without my card (which did only occur once, but it was damn convenient).
Also, one of my banking institutions is a small credit union whose website does not work well on mobile, but has a well functioning android and iOS app.
I think transparency is always good, although one worry I do have is that forcing benign declarations (i.e. what amounts to disclosing that when you turn on X, it does X), creates something similar to "alert fatigue".
People don't read privacy policies. A privacy preserving app that has to put a long-winded policy, despite not leeching your data, becomes even harder to distinguish from a cloud-based email app that scans all your emails, and holds your email usernames and passwords, and harvests contact-name pairings and sells email signature contact info and job titles to lead-harvesting data brokers.
I don't know if that's the best outcome for users, as it might make every policy look the same (long, complex, and wordy, with scary legal language they are forced to add by the platform gatekeeper).
>I think transparency is always good, although one worry I do have is that forcing benign declarations (i.e. what amounts to disclosing that when you turn on X, it does X), creates something similar to "alert fatigue".
My favorite unnecessary warning label is the one on the bag of frozen shrimp I bought at Costco. There's a government mandated "Warning: Contains shellfish (shrimp)"
I don’t think this is about alerting users where data is going proactively; I think this is about having an accounting of where data is being sent, so that we can answer questions about data flows after the fact.
Lots of open source code is released without any profit motive. This sort of code is probably not a huge vector for privacy violations, but we should be clear that the authors are just doing a nice favor to society and owe us nothing.
Should the authors of wget have to describe the fact that communicating on the internet requires talking to servers, and if you use domain names, you'll also have to leak information to DNS servers?
At the end of the day, one of the hardest and most subtle things about it is that expectations (in the form of regulations or just how users think things work) can change in the future, and it means once-mundane decisions that you made are now sending data somewhere it doesn’t belong.
Ultimately, I think that the only solution is going to be a table like this for every product, everywhere: we need to know EVERYTHING that is sent over the wire, WHERE we are sending it, and WHY/WHEN we are sending it. At least then we have all the info we need to look backwards and understand what happened to the data when the landscape inevitably changes.
"The services of all sub-processors are disabled by default. The data subject's data is sent to and processed by sub-processors if and only if explicitly enabled or requested by the data subject."
Let's be honest. This author is going much further than Google in protecting user privacy.
If you look at the changes in the privacy policy, and as others had brought up before, this ban was warranted. There was a lot of data collection happening that wasn't disclosed.
Warranted or not, what is unacceptable is the lack of transparency in the whole process. At least point the developer towards a path into compliance, not just black-holing them altogether.
I agree the process could be improved, but if they post policies and developers fail to read them and follow them they really only have to say they violated their policies.
If interpretation of the policies were consistent, to the point where I could reasonably guess that the violation was in something I changed recently, I would agree with you.
However, both platforms' policy enforcement is often wildly inconsistent. Rules get ignored and then suddenly enforced. Some reviewers are more persnickety than others. Something that's been passing under the radar for years might be suddenly interpreted as in violation of a policy while they're reviewing a minor bugfix. In that situation, "you violated a policy" is useless for figuring out the problem in any reasonably large app.
(That said, it sounds like this dev did get an explanation.)
In this case, it seems like "recency" was a big issue - the change wasn't recent in any sense of the word, since it seems like the feature has been there since at least mid 2020. [0]
The explanation in this case also seemed to focus on a (false) assertion the app uploaded the user's contact list - the app wasn't doing that. If a user turned on fetching favicons (it was off by default, with a red-coloured privacy warning in the app), then the app would fetch a favicon for received emails in non-junk folders, directly from the server in question.
If apps are expected to treat the user's DNS server as hostile, then web browsers had better talk about how they send user browsing history to third parties (by querying DNS!). Similarly, the app connecting to the site and asking for a favicon is not really a leak to a third party, as the domain is owned by the sending user. If they chose to outsource their website to a third party, that's their choice (and problem).
If the app was uploading user contacts to a third party, that would be very bad. It wasn't. But rival apps do (for monetisation etc.) Making benign apps write declarations that suggest it is doing something akin to that is (to be cynical) helpful for Google and other ad/data supported business model actors, who benefit from obscuring their practices by forcing others to make similar-looking declarations.
The rejection notice that the developer posted said "Your app is uploading users Contact List without an adequate disclosure. For further details on the valid prominent disclosure requirement, please review the [linked] section under the User Data Policy".
The developer asserted that they were only leaking the domain names from users contacts, but that's still something that users should be aware of.
Full disclosure, I work for Google so maybe I have some biases, but IMO that's a pretty clear message telling the dev why the app was rejected and how to resolve the issue.
The problem was that this feature existed for many years without issue. There was plenty of disclosure in the app (it was even written in bold red text, I believe).
The developer was guessing as to what was going on, since the feature wasn't new, and the message doesn't appear to match the actual issue (domain names from sent/receives messages, after expressly opting into a feature with a privacy warning on it)
There is an interesting question around whether a domain name really is a privacy disclosure though (and I write this as someone who wants to see more private apps) - if we force apps to disclose mundane trivia, it will distract from the meaningful disclosures. Do we expect Google to disclose in every one of their apps and services that it makes DNS queries, which may reveal information to third parties? Or do we accept that's how the internet works? In this context, it seems like FairEmail was doing the equivalent of making a DNS lookup. If the user doesn't trust their DNS, is this a developer's responsibility to address?
I don't know where the line ought to lie, but I think a major reason it wasn't clear what was wrong and how to resolve it was the time between the feature being added, and the review highlighting this - slow feedback loops kill products.
Don't focus too much on the protocol that is used. Leaking the domains of every mail correspondent is a privacy issue regardless of whether it's done via a DNS lookup or otherwise.
The app didn't upload the user's contact list, only contacted the mail domain to get the favicon.
And this feature was disabled by default and had a warning description if you want to turn it on.
So no, Google didn't clearly said what the problem is because they didn't understand the functionality.
What is disturbing is that this direct contact is the exception and not the norm for their level of customer service. This shows how complacent Google is in their almost dominant position, and will only go to an acceptable level of support if their moderator's AI dark-patterns makes them look bad.
I'm still willing to celebrate this happening. An exception to normally bad behavior, and the first instance of a genuine change in approach, look identical.
Example: how many people here were skeptical of Microsoft having a change of heart regarding open source back in 2012? And now a decade later, it's clear that was genuine.
I'm still not convinced about that. For one, they're running the biggest closed-source Git hosting service (GitHub) and exploiting open-source projects to fuel their paid proprietary service (Copilot).
Nowhere. But I don't think it's fair for proprietary code to use open-source code, especially if it's licensed under the GPL. And having the biggest collection of open-source software run on a proprietary system is just absurd.
You had me until that example. There is no way I will ever trust Microsoft.
Nothing is clear about Microsoft embracing open source. Github isn’t open source. Neither is Windows, SQL Server, or Office. And I’m not thrilled about their involvement with Linux. EEE is in their blood.
Fool me once, shame on you. Fool me twice, shame on me. Fool me thrice, you’re Microsoft.
I'm not surprised that there are people with this view, but I can't agree. They've had 4 years to ruin github, and haven't. Open-sourcing .NET Core, VS Code, powershell, etc and actively creating/supporting WSL is a huge change from their behavior in the 90s.
I don't use any of their software, but watching from a distance they appear to have been moving in a "good" direction for the last decade.
As you say, the problem with Microsoft isn't the licensing. 25 years ago, licensing was among the problems with Microsoft. Today it is not. This is an aspect of Microsoft changing, for the better. https://en.wikipedia.org/wiki/Microsoft_and_open_source#Init...
Install Windows freshly, lots of intentionally misleading privacy options.
Edge is increasing its tactics to get you to set it as the default browser.
Including Teams with a package people paid for anyway (Office 365) to try and take out Slack.
VSCode, Github as on-ramp into paid Github and Azure Devops.
> And now a decade later, it's clear that was genuine.
It's certainly not "clear". Just because they make a code editor you like doesn't mean they're not planning to fuck you over the moment they reach some internal milestones and priorities get shuffled around.
The tech industry moves fast, but the one thing you can always count on is that you should never trust Microsoft, neither as a consumer nor as a business partner.
The beauty of the prank was that the company then had to send a real spokesperson out to explicitly state that "Steve, yes," was the wrong answer to the question, "Do you now accept responsibility for what happened?"
In fact I'll boldly claim you have never seen a genuine change in approach from a company of this size that wasn't forced by a settlement with the government or criminal prosecution(s).
Edit: I'll go ahead and admit I'd love to read about the exceptions to my last paragraph, but only in terms of companies the size of Google.
> I'm still willing to celebrate this happening. An exception to normally bad behavior, and the first instance of a genuine change in approach, look identical.
That why they do it. For you. If the story that got some play in the media gets very publicly fixed (after being completely promoted from the regular support flow), people will will defend them, although nothing has changed.
Which only demonstrates the unconscionability of their behavior.
If I have an issue with Amazon, I get a person. If I have an issue with stripe, I get a person. If I have an issue with literally any other vendor I have a relationship with, I get a person.
With Google, I have a lovely time chatting with auto responders.
They choose to enter the market and fail to serve their customers - that's on them, failure at scale is still failure.
There are countless companies who operate on a much smaller scale than Google that will give you a very hard time trying to get in touch with a (competent) human, which you should easily be able to acknowledge if you live in the same world I do and are being honest. Also I have talked to Google support staff of different levels on numerous occasions. Not saying it's great (I would rate my experience as average across all their products but I am aware that the n is too small to be significant), just that being polemic and pretending it doesn't exist is not helping any serious discourse.
The only thing we learn here is that everyone is trying to figure shit out all the time and customer support is a hard problem.
I don't think people forget that, they need to scale up the responsibility accordingly.
You can't run world-dominating platforms and dodge the responsibility that comes with it. Surely if you rake in tens of billions in profit every single quarter, you have room to do better.
It's core to Google to 'automate' customer interaction. It's the same dark pattern as Byzantine bureaucracy, just without the personell expenses. It serves as a filter; Google's and bureaucracy's interest is to do the absolute minimum, and it works.
Just like with bureaucracy, the winning move is to avoid playing, or not working with the system but around it.
I thought the norm was ‘to get support at Google you should reach out to personal contacts there or hit the front page of HN/get a lot of retweets/otherwise become obvious (in a non-harassing way) to many Google employees’ so this sounds like the norm to me? Maybe we just have different views of what the norm is or what ‘the norm’ means as a phrase.
It's exactly trivial to install F-Droid and once you've done that, then why even care about the trials and tribulations of closed-source serfs of the Google Play Store?
As a developer who makes a decent amount of money on the App Store and Play Store I would pay for premium support. The biggest threat for my business is some AI killing my app on a false positive with no way to resolve the issue.
They should probably give you premium support automatically for free once you reach some threshold of sales. It makes sense for them to retain their share at that point.
Just another data point that the only way to resolve issues like this is to kick up enough fuss on a site like this or on social media so that a real human can look at and resolve your issue.
The best part is that the arsonist who put out their own fire gets to be a hero.
The app store model has been shown time and time again to fail at the very issues it's supposed to solve, especially at scale. I can empathize with the desire for manual curation at an early stage and even blacklists for known malware. However, what we have today is a guilty-until-proven-innocent extortion scheme.
I'm glad this got resolved, but it's not good that it had to be special-cased. Google really needs to fix their policies so that this kind of problem can be fixed through the normal channels that are available to everyone.
Google dropped support for IMAP text authentication on May 30th but didn't enforce it globally until today. If you check the "Allow less secure apps" section of your Google account settings you'll see it's been removed. You must use OAuth2 if you want to continue to use an external email client.
Oh, I see. Thanks. I'm not sure what to do then - I have a Huawei phone so I'm only using fdroid for apps.
The Fdroid version of FairEmail doesn't support gmail with oauth because of "Google security features" (??). It's only supported on the Google Play version.
I'm vaguely aware that there are sites out there where you can download apks, but that seems unwise.
> there are sites out there where you can download apks, but that seems unwise.
You can download Aurora Store form F-Droid. It is a Google Play frontend with an anonymous login mechanism and fetches APKs directly from Google.
You can try installing Fairemail through that but I'm not sure if it will fix the login issue by itself (maybe it also wants the chrome webview or google play services?).
Thanks. I installed FairEmail from Aurora Store and while the gmail oauth option is there, clicking select account gives a brief screen flicker. The store does that say that it needs GSF which apparently means Google Service Framework.
But!! As I was writing this comment, I went to FairEmail again to confirm the behaviour and it seems that my IMAP access has been turned back on and I can receive emails again. No idea why or for how long.
What a ridiculous situation. If I had a time machine I would go back to kill Hitler and also to tell my past self not to sign up for a gmail account.
Google stopped allowing username/password to authenticate to gmail in May. You have to use Oauth2. Not personally familiar on if/how to configure this with FairMail.
In order to continue using non OAUTH apps to access you gmail, you will need to turn on two factor authentication on your google account and then create an "app password" for your email client.
I wrote this as a comment the last time this came up.
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.
It feels like Google ought to have a small team of developer advocates whose sole job is to find apps that are in trouble and then work with the developers like humans.
It doesn't need to be 100 people. Just 10 or 20 even. Just provide some kind of human touch to the support of the developers who make the Android app store worth a damn. Write documentation to better help other developers get out of these kinds of holes. Work to improve the messaging when apps are rejected so that it's easier to know what to do.
It doesn't seem worth putting time and energy into making an app if I know a bot can suddenly end my project and there's nothing I can do about it, and no one whose job it is to help me.
It's a feature, for Google. They get to absolve themselves of any and all responsibility when it comes to their platform. Blame the bots, the system, the software, but not a single person is actually responsible for actions being taken. If we look at Youtube and DMCA, it's clear who Google cares about and it's certainly not individual users.
Considering how many of these "Google killed my X, Y or Z" posts I've seen on Hacker News. This really doesn't feel like anything to celebrate. It is just further proof that Google could, in theory, provide the support at the level necessary for these things, but just won't.
Honestly, I know their job is hard, but if they simply put a legitimate task force together to figure out how to provide support at scale (even if it costs a premium to handle it, or possibly even a premium to do a proper appeal), I could see it helping immensely.
Basically, if you want to do an appeal for something, it will cost, and depending on the violation and how often the violation is, the cost goes up. The appeal requires them to be clear about what the violation is, and what needs to be done to resolve it. Perhaps even make it that if you get an appeal with clear details and you resolve the issue, a certain percentage of the money will be refunded.
Basically, instead of assuming everyone who their algorithms says is total evil is evil, they allow some form of good will that would help businesses, individuals and organizations work with them. I know the spammers and scammers are a huge pain, but then fine, charge them for the cost. The ones that are legit will pay and will work with Google if Google will work with them.
I've been a FairEmail user for a long time, and the product is fantastic, and I'm very happy this got worked out. FairEmail has always been excellent at explaining settings and their privacy ramifications, and I'm hoping that Google's switch to oauth doesn't break Fair Email's ability to check both my work profile email and home email google accounts.
It's absolutely deflating when an app gets removed from a store, and a lot of times the rejection messages are terse and hard to make sense out of, and honestly, the developer has a lot invested in their app.
"All my projects have been terminated after Google falsely flagged FairEmail as spyware without a reasonable opportunity to appeal."
Would anyone classify Google's projects as "spyware". It is, after all, their "business model" to conduct surveillance. Whereas I doubt this author is making Google-sized profits, or even a modest livelihood, from his PlayStore apps, even if the apps were "spyware". Google is the undisputed king of spyware unless the user believes that her interests are always 100% aligned with Google's interests and nothing Google does can ever harm them. In order to hold such beliefs one would also have to ignore the millions in fines Google continues to pay for privacy incursions.
I have been using one of this author's other programs, NetGuard, from FDroid, in lockdown mode, for computer running non-rooted Android. I have not seen anything like it, i.e., a user-controlled application firewall as a standalone app, for iOS. I am not aware of any competing apps for Android either. It appears to be a one-of-a-kind app, AFAICT. If someone knows of better option for selectively blocking traffic from apps, let's hear about it and the reasons why it is better.
The assumption that Google is more trustworthy than any single app author is questionionable. It is that dogma upon which the "app store" concept depends.
For example, can Google really compete with this author with respect to protection from spyware. Let's consider some facts.
The author offers user-controlled protection from spying in NetGuard. Google offers Google-controlled protection from spying in the form of app store vetting. The former is open source, users can compile it themselves, and it does not report back to a mothership. The later is not something any user compiles themselves, it not controlled by the user, it is controlled by Google, it does report back a mothership, and the motherwhip's "business model" depends on that surveillance. The later, namely Android, Google apps and Google "services", are, by definition, spyware. Google collects data about pocket computer owners and uses it in undisclosed ways.
There is simply no way for a pocket computer user to know the many things that Google does with the data it collects from spying. The only instances where she may learn about what Google does with her data are when facts are disclosed in response to discovery requests in litigation and those facts are made public. Even if she becomes aware of such facts, there is generally no way for her to limit what Google does with her data according to her own preferences. NetGuard allows users to selectively block or allow traffic to selected domains on a per app basis.
Not to mention all the legal proceedings brought against Google for privacy related matters that Google has settled despite having the resources to go to trial and have the issues finally decided in Google's favour. Surely Google has has done nothing wrong, and the trial courts would agree, so why does Google choose to settle out of court every time.
177 comments
[ 20.0 ms ] story [ 820 ms ] threadHowever, it is sad that PR campaigns are required to reach out to an actual human being who cares.
/sarcasm
Also the part they were likely mad at was not data collection.
I fully disagree with your take.
You are assuming the default is negative. I think your explanation might be possible, but that by default it's wrong, as most people are not cynical/annoyed or any other negative quality.
My fundamental belief is that most people are nice and want to do good things.
If you are surrounded by cynical/annoyed people, you may be in a toxic environment, which may taint your judgement for other situations.
NB: either one of us could be making a fundamental attribution error https://en.wikipedia.org/wiki/Fundamental_attribution_error and it might be hard to find the truth, as it boils down to beliefs.
thanks for sharing that valuable information with us
I am assuming the default is negative - for Google.
I work for a far far older engineering company which is built on maintaining good relationships with our customers, vendors and their engineers. It is the exact opposite of the AI driven, frustrating/pointless bot response attitude of big tech companies. I like to think the difference is that we haven't optimised out our humanity yet.
Even worst is when actual humans get your cases, but can only reply with templates (like on Seller Central), where they have no problem sending you the same message over and over again.
This should be regulated for monopolies. People should be able to access a human for assistance.
The description of the problem they gave was inaccurate in any case, which didn't help the developer in working out the problem.
You therefore make a good point - while people often talk about the need for humans, these humans ALSO need to be free-thinking, not bound by a script, and have meaningful escalation paths to use for cases that the process isn't working for.
The nature of email clients, especially ones that integrate with cloud-hosted spam and filtering services, is that they're naturally going to have trouble with that policy absent great care with specifying exactly what gets collected. The "fix" here seems to have been to update their policy documentation to describe exactly that.
It works, but it scales badly.
this does not scale well either
More importantly, Google told him that he needed to disclose what he was doing, and his response was petulance. You know the type: "I was speeding because I was LATE TO WORK, officer!"
Further discussion in this comment thread: https://news.ycombinator.com/item?id=31434975
That seems more than reasonable to me (off by default, with a warning!), and would be exactly what I would expect the app to do if I did enable favicons.
Still pretty bad, and I don't think Google is wrong to flag the app because of this.
However, Google didn't say "if the user enables a certain setting, your app is uploading domain names from your users' contact list to third party avatar services", it said "you're uploading contact list information without disclosing that in the privacy policy".
They seem to know exactly what the problem was but described it in such a vague way that it definitely reads like an accusation of extracting data.
Both are wrong here, but Google is in a position of power and should be held to a higher standard. I'm sure just listing the hostnames that weren't covered by the privacy policy were enough to prevent this whole situation.
https://github.com/M66B/FairEmail/blob/master/PRIVACY.md#sum...
Albeit I am undecided whether we should really force every FLOSS developer to create a table like this, apparently Google has decided that yes, we do.
It's akin go a standard privacy "Nutritional Label" that only exists due to forced regulation, and not industry agreement.
As an iOS user, I want even stronger privacy control and disclosures; the current Apple disclosure requirement is still pretty vague. However, it is really nice seeing apps that say "this developer does not collect any user information."
I've never seen the Play Protect message you're talking about.
I'm doing that because I've been hit too many times by upgrades that reduced the functionality of apps or changed it in ways I don't like. I'm currently not updating K9 Mail past 5.6 and some useless Samsung apps that I can't uninstall.
Yeah, I do the same these days. It's amazing how freeing it is to be able to trust the app you're running, and not have to constantly be on the look out for dark patterns, "integrations" you didn't ask for, sneaky updates, change of ownership due to an "incredible journey" with a FAANG/MAGA company or a Chinese equivalent. I'll take the more limited choice and the general lack of UI polish any day, for these benefits.
I'm using F Droid on all my Android devices. They are version 8, 10 and 11. It works with no problem, no root required.
(and probably required complex dataflow linting to ensure it)
even for apps that aren't open source, a trusted third party can run an analyzer on the source code to generate something like this; you can also have internal dashes that track what has been shared, how many times, and what triggered the share. you can hook into settings and toggle specific sharing on / off, you can ban certain kinds of sharing entirely.
tools like skyflow are already trying to provide this for regulated PII
Or at least add it.
MSDS for code!
I don't see any reason why open-source software should get a free pass on privacy issues.
If an open source project is really just somebody releasing their own code, they don't have any obligation at all to the end user. If a business is releasing open source code and has some business model that ultimately turns that into profit (even indirectly, for example via selling your private info), then they have an moral obligation to be clear on how they are making money.
On the other hand, the app stores have no obligation to host projects generally.
Apple has an interest to publish the same apps. It supports their "keep the users in the walled garden" business model.
Both form an unhealty duopoly from both app developers and end users point of view.
Saying they have no obligation to host an app might be correct, but it's a very limited perspective of the whole situation.
If they distribute the app there is little difference from a closed source install. Again, "read the code and learn what we do about privacy" would be pretty hostile.
In this case it doesn't. I also can't give away meth for free. Distribution of an app that processes personal data without a valid data privacy statement is illegal in the EU and could get the author and/or github into trouble unless they implement an export restriction (eg. EULA that prohibits distribution in the EU).
Is that really true? For example data processors are bound by GDPR but I don't see how the author of this application is a data processor (or a data controller). In fact I'm not sure that legally "app that processes personal data" is the correct description here, considering the very specific meaning of "to process" in this context. If an email client run by a user on his own machine with no involvement of the vendor of that software requires "a valid data privacy statement", then so does probably the user's keyboard driver. And the text formatting engine. And the networking stack. Etc. etc.
Best I can do is offer my interpretation. GDPR applies to "[...] the processing of personal data wholly or partly by automated means" [1]. I take "automated means" to include this app. So when this app runs and processes EU citizens' data, the law applies. But to what or whom...
> I don't see how the author of this application is a data processor (or a data controller)
... I understand as follows: things are generally not responsible under the law, their owners and creators are. If I install and use a software, the GDPR entitles me to knowledge of its personal data processing capabilities if it processes personal data, which this app seems to do. As the GDPR evolved from consumer protection law, I'll employ an analogy: if I win a free vacuum cleaner in a raffle, the product still needs to include a safety guide - the manufacturer or distributor can't delegate safety responsibility to me. GDPR is about personal data safety.
> If an email client run by a user on his own machine with no involvement of the vendor of that software requires "a valid data privacy statement"
Conversely, at least one mainstream email client comes with a data privacy statement [2]. Which doesn't prove my point, it might be just ass-covering.
> then so does probably the user's keyboard driver.
Maybe the operating system's data privacy statement covers this? Otherwise that reasoning appears sound.
[1] https://gdpr-info.eu/art-2-gdpr/ [2] https://www.mozilla.org/en-US/privacy/thunderbird/
According to the data privacy statement (DPS) it does more than that, refer to chapter "Set-Up and Configure Your Email": Thunderbird collects your email domain and other technical data to set-up and configure your email account. Other information, like your name, your email messages, and your account’s address book are stored locally on your computer and never sent to us.
"Thunderbird" means the email client, not the web service ("us"). The DPS cleanly separates between data stored locally on the client and data shared with the servers - the DPS addresses both scenarios and it explains which data is stored locally, so their interpretation is that GDPR covers data processed by the application which does not leave the client, too.
> If this application doesn't collect any such data for its author, then this point goes away
The Thunderbird DPS seems to think otherwise, as it describes the locally stored data even if it isn't submitted to the web service. Maybe the DPS doesn't intend to apply a legal interpretation to local data and mentions local data only for contrast to shared data, which the DPS definitely cares about? Hence my in-earlier-comment comment that this might be just ass-covering without legal weight.
That's exactly what the GDPR enforces. You give the app personally identifying data, so the app needs to disclose what it does with the data because storing it on the computer and not sending it anywhere is still data processing. In this case the data privacy statement needs to tell the user that the data is stored but not shared. If you're not doing anything with the data, then don't ask for it.
[•] I personally lasted two months without a phone once (2016 Japan), since 80% of services would outright refuse you if you didn't have one, while the rest would pester and harrass you extensively before finally giving in.
Also, one of my banking institutions is a small credit union whose website does not work well on mobile, but has a well functioning android and iOS app.
[1] https://blog.google/products/google-play/data-safety/
People don't read privacy policies. A privacy preserving app that has to put a long-winded policy, despite not leeching your data, becomes even harder to distinguish from a cloud-based email app that scans all your emails, and holds your email usernames and passwords, and harvests contact-name pairings and sells email signature contact info and job titles to lead-harvesting data brokers.
I don't know if that's the best outcome for users, as it might make every policy look the same (long, complex, and wordy, with scary legal language they are forced to add by the platform gatekeeper).
My favorite unnecessary warning label is the one on the bag of frozen shrimp I bought at Costco. There's a government mandated "Warning: Contains shellfish (shrimp)"
Thanks.
Should the authors of wget have to describe the fact that communicating on the internet requires talking to servers, and if you use domain names, you'll also have to leak information to DNS servers?
At the end of the day, one of the hardest and most subtle things about it is that expectations (in the form of regulations or just how users think things work) can change in the future, and it means once-mundane decisions that you made are now sending data somewhere it doesn’t belong.
Ultimately, I think that the only solution is going to be a table like this for every product, everywhere: we need to know EVERYTHING that is sent over the wire, WHERE we are sending it, and WHY/WHEN we are sending it. At least then we have all the info we need to look backwards and understand what happened to the data when the landscape inevitably changes.
Then google contacted them directly and they un-quit disclosed the workflow of users data and is back in business.
Let's be honest. This author is going much further than Google in protecting user privacy.
However, both platforms' policy enforcement is often wildly inconsistent. Rules get ignored and then suddenly enforced. Some reviewers are more persnickety than others. Something that's been passing under the radar for years might be suddenly interpreted as in violation of a policy while they're reviewing a minor bugfix. In that situation, "you violated a policy" is useless for figuring out the problem in any reasonably large app.
(That said, it sounds like this dev did get an explanation.)
The explanation in this case also seemed to focus on a (false) assertion the app uploaded the user's contact list - the app wasn't doing that. If a user turned on fetching favicons (it was off by default, with a red-coloured privacy warning in the app), then the app would fetch a favicon for received emails in non-junk folders, directly from the server in question.
If apps are expected to treat the user's DNS server as hostile, then web browsers had better talk about how they send user browsing history to third parties (by querying DNS!). Similarly, the app connecting to the site and asking for a favicon is not really a leak to a third party, as the domain is owned by the sending user. If they chose to outsource their website to a third party, that's their choice (and problem).
If the app was uploading user contacts to a third party, that would be very bad. It wasn't. But rival apps do (for monetisation etc.) Making benign apps write declarations that suggest it is doing something akin to that is (to be cynical) helpful for Google and other ad/data supported business model actors, who benefit from obscuring their practices by forcing others to make similar-looking declarations.
[0] https://github.com/M66B/FairEmail/commit/57cf22b1193b43ca979...
The developer asserted that they were only leaking the domain names from users contacts, but that's still something that users should be aware of.
Full disclosure, I work for Google so maybe I have some biases, but IMO that's a pretty clear message telling the dev why the app was rejected and how to resolve the issue.
The developer was guessing as to what was going on, since the feature wasn't new, and the message doesn't appear to match the actual issue (domain names from sent/receives messages, after expressly opting into a feature with a privacy warning on it)
There is an interesting question around whether a domain name really is a privacy disclosure though (and I write this as someone who wants to see more private apps) - if we force apps to disclose mundane trivia, it will distract from the meaningful disclosures. Do we expect Google to disclose in every one of their apps and services that it makes DNS queries, which may reveal information to third parties? Or do we accept that's how the internet works? In this context, it seems like FairEmail was doing the equivalent of making a DNS lookup. If the user doesn't trust their DNS, is this a developer's responsibility to address?
I don't know where the line ought to lie, but I think a major reason it wasn't clear what was wrong and how to resolve it was the time between the feature being added, and the review highlighting this - slow feedback loops kill products.
So no, Google didn't clearly said what the problem is because they didn't understand the functionality.
Example: how many people here were skeptical of Microsoft having a change of heart regarding open source back in 2012? And now a decade later, it's clear that was genuine.
Nothing is clear about Microsoft embracing open source. Github isn’t open source. Neither is Windows, SQL Server, or Office. And I’m not thrilled about their involvement with Linux. EEE is in their blood.
Fool me once, shame on you. Fool me twice, shame on me. Fool me thrice, you’re Microsoft.
I don't use any of their software, but watching from a distance they appear to have been moving in a "good" direction for the last decade.
I prefer that the organization responsible for those abuses stays away from Linux, and anything else I actually use.
As you say, the problem with Microsoft isn't the licensing. 25 years ago, licensing was among the problems with Microsoft. Today it is not. This is an aspect of Microsoft changing, for the better. https://en.wikipedia.org/wiki/Microsoft_and_open_source#Init...
I don't know why anyone would willfully choose obsolescence and wear it as a badge of honor.
Install Windows freshly, lots of intentionally misleading privacy options. Edge is increasing its tactics to get you to set it as the default browser. Including Teams with a package people paid for anyway (Office 365) to try and take out Slack. VSCode, Github as on-ramp into paid Github and Azure Devops.
Same old, same old.
It's certainly not "clear". Just because they make a code editor you like doesn't mean they're not planning to fuck you over the moment they reach some internal milestones and priorities get shuffled around.
The tech industry moves fast, but the one thing you can always count on is that you should never trust Microsoft, neither as a consumer nor as a business partner.
EDIT: unless you're a masochist
No, they probably don't. Take for example this example prank by the Yes Men:
> https://www.youtube.com/watch?v=LiWlvBro9eI
The beauty of the prank was that the company then had to send a real spokesperson out to explicitly state that "Steve, yes," was the wrong answer to the question, "Do you now accept responsibility for what happened?"
In fact I'll boldly claim you have never seen a genuine change in approach from a company of this size that wasn't forced by a settlement with the government or criminal prosecution(s).
Edit: I'll go ahead and admit I'd love to read about the exceptions to my last paragraph, but only in terms of companies the size of Google.
That why they do it. For you. If the story that got some play in the media gets very publicly fixed (after being completely promoted from the regular support flow), people will will defend them, although nothing has changed.
And yet, barely six months ago…
https://news.ycombinator.com/item?id=29579994
It shows what you want it to show.
If anything, their scale should permit them to easily do better.
If I have an issue with Amazon, I get a person. If I have an issue with stripe, I get a person. If I have an issue with literally any other vendor I have a relationship with, I get a person.
With Google, I have a lovely time chatting with auto responders.
They choose to enter the market and fail to serve their customers - that's on them, failure at scale is still failure.
The only thing we learn here is that everyone is trying to figure shit out all the time and customer support is a hard problem.
You can't run world-dominating platforms and dodge the responsibility that comes with it. Surely if you rake in tens of billions in profit every single quarter, you have room to do better.
Just like with bureaucracy, the winning move is to avoid playing, or not working with the system but around it.
i dont even blame you.
It's support prioritization by follower count.
The app store model has been shown time and time again to fail at the very issues it's supposed to solve, especially at scale. I can empathize with the desire for manual curation at an early stage and even blacklists for known malware. However, what we have today is a guilty-until-proven-innocent extortion scheme.
I'm using the fdroid version, so I have to use IMAP instead of oauth2 for gmail (why? who knows, it works for office365).
The Fdroid version of FairEmail doesn't support gmail with oauth because of "Google security features" (??). It's only supported on the Google Play version.
I'm vaguely aware that there are sites out there where you can download apks, but that seems unwise.
You can download Aurora Store form F-Droid. It is a Google Play frontend with an anonymous login mechanism and fetches APKs directly from Google.
You can try installing Fairemail through that but I'm not sure if it will fix the login issue by itself (maybe it also wants the chrome webview or google play services?).
But!! As I was writing this comment, I went to FairEmail again to confirm the behaviour and it seems that my IMAP access has been turned back on and I can receive emails again. No idea why or for how long.
What a ridiculous situation. If I had a time machine I would go back to kill Hitler and also to tell my past self not to sign up for a gmail account.
https://support.google.com/accounts/answer/185833
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.
It doesn't need to be 100 people. Just 10 or 20 even. Just provide some kind of human touch to the support of the developers who make the Android app store worth a damn. Write documentation to better help other developers get out of these kinds of holes. Work to improve the messaging when apps are rejected so that it's easier to know what to do.
It doesn't seem worth putting time and energy into making an app if I know a bot can suddenly end my project and there's nothing I can do about it, and no one whose job it is to help me.
Even the "legit" uses would be enormous let alone people who abuse it.
At the very least, I don't think even 100 people would be able to cover it.
Honestly, I know their job is hard, but if they simply put a legitimate task force together to figure out how to provide support at scale (even if it costs a premium to handle it, or possibly even a premium to do a proper appeal), I could see it helping immensely.
Basically, if you want to do an appeal for something, it will cost, and depending on the violation and how often the violation is, the cost goes up. The appeal requires them to be clear about what the violation is, and what needs to be done to resolve it. Perhaps even make it that if you get an appeal with clear details and you resolve the issue, a certain percentage of the money will be refunded.
Basically, instead of assuming everyone who their algorithms says is total evil is evil, they allow some form of good will that would help businesses, individuals and organizations work with them. I know the spammers and scammers are a huge pain, but then fine, charge them for the cost. The ones that are legit will pay and will work with Google if Google will work with them.
It's absolutely deflating when an app gets removed from a store, and a lot of times the rejection messages are terse and hard to make sense out of, and honestly, the developer has a lot invested in their app.
EFF and EU should respond to Google taking FairEmail off the Play store - https://news.ycombinator.com/item?id=31433051 - May 2022 (51 comments)
FairEmail stopping development after Google falsely flags app as spyware - https://news.ycombinator.com/item?id=31432334 - May 2022 (322 comments)
FairEmail may be Ending Development - https://news.ycombinator.com/item?id=31426915 - May 2022 (6 comments)
Previously:
FairEmail: Open-source, privacy friendly email app for Android - https://news.ycombinator.com/item?id=26386374 - March 2021 (117 comments)
Would anyone classify Google's projects as "spyware". It is, after all, their "business model" to conduct surveillance. Whereas I doubt this author is making Google-sized profits, or even a modest livelihood, from his PlayStore apps, even if the apps were "spyware". Google is the undisputed king of spyware unless the user believes that her interests are always 100% aligned with Google's interests and nothing Google does can ever harm them. In order to hold such beliefs one would also have to ignore the millions in fines Google continues to pay for privacy incursions.
I have been using one of this author's other programs, NetGuard, from FDroid, in lockdown mode, for computer running non-rooted Android. I have not seen anything like it, i.e., a user-controlled application firewall as a standalone app, for iOS. I am not aware of any competing apps for Android either. It appears to be a one-of-a-kind app, AFAICT. If someone knows of better option for selectively blocking traffic from apps, let's hear about it and the reasons why it is better.
The assumption that Google is more trustworthy than any single app author is questionionable. It is that dogma upon which the "app store" concept depends.
For example, can Google really compete with this author with respect to protection from spyware. Let's consider some facts.
The author offers user-controlled protection from spying in NetGuard. Google offers Google-controlled protection from spying in the form of app store vetting. The former is open source, users can compile it themselves, and it does not report back to a mothership. The later is not something any user compiles themselves, it not controlled by the user, it is controlled by Google, it does report back a mothership, and the motherwhip's "business model" depends on that surveillance. The later, namely Android, Google apps and Google "services", are, by definition, spyware. Google collects data about pocket computer owners and uses it in undisclosed ways.
There is simply no way for a pocket computer user to know the many things that Google does with the data it collects from spying. The only instances where she may learn about what Google does with her data are when facts are disclosed in response to discovery requests in litigation and those facts are made public. Even if she becomes aware of such facts, there is generally no way for her to limit what Google does with her data according to her own preferences. NetGuard allows users to selectively block or allow traffic to selected domains on a per app basis.