This is nice:
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.
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.
People don't read privacy policies. A privacy preserving app that has to put a long-winded policy, despite not leeching your data, becomes even harder to distinguish from a cloud-based email app that scans all your emails, and holds your email usernames and passwords, and harvests contact-name pairings and sells email signature contact info and job titles to lead-harvesting data brokers.
I don't know if that's the best outcome for users, as it might make every policy look the same (long, complex, and wordy, with scary legal language they are forced to add by the platform gatekeeper).
My favorite unnecessary warning label is the one on the bag of frozen shrimp I bought at Costco. There's a government mandated "Warning: Contains shellfish (shrimp)"
Thanks.
[•] I personally lasted two months without a phone once (2016 Japan), since 80% of services would outright refuse you if you didn't have one, while the rest would pester and harrass you extensively before finally giving in.
Also, one of my banking institutions is a small credit union whose website does not work well on mobile, but has a well functioning android and iOS app.
Should the authors of wget have to describe the fact that communicating on the internet requires talking to servers, and if you use domain names, you'll also have to leak information to DNS servers?
At the end of the day, one of the hardest and most subtle things about it is that expectations (in the form of regulations or just how users think things work) can change in the future, and it means once-mundane decisions that you made are now sending data somewhere it doesn’t belong.
Ultimately, I think that the only solution is going to be a table like this for every product, everywhere: we need to know EVERYTHING that is sent over the wire, WHERE we are sending it, and WHY/WHEN we are sending it. At least then we have all the info we need to look backwards and understand what happened to the data when the landscape inevitably changes.
Let's be honest. This author is going much further than Google in protecting user privacy.
Then google contacted them directly and they un-quit disclosed the workflow of users data and is back in business.