OliveTin phones home to developers with PII without consent

[sneak]

OliveTin/internal/config/config.go

Line 93 in 244404a

config.CheckForUpdates = true

The "update check" is enabled by default. This misleadingly named surveillance feature will phone home to the developers of the software at http://update-check.olivetin.app:

OliveTin/internal/updatecheck/updateCheck.go

Line 109 in 49cb2e5

req, err := http.NewRequest("POST", "http://update-check.olivetin.app", bytes.NewBuffer(jsonUpdateRequest))

It's not just checking for updates. It sends to the server personally identifying information (PII), something called an "installation ID", which persists between launches:

OliveTin/internal/updatecheck/updateCheck.go

Line 32 in 49cb2e5

func installationID(filename string) string {

This network-based surveillance is not disclosed to the user and happens without first obtaining consent from the user. The user's PII is transmitted automatically.

[jamesread]

Hey @sneak . First of all, I really appreciate you raising this.

Yep, everything you've said is accurate about how the tracking works - but I would not call this "PII". I've always wondered if people are bothered by this. I've tried my best to make this obvious and transparent (log it on startup, document it, and called out in submissions to Fedora, and other places). But in all this time nobody raised it until you - which I found quite surprising.

I've done my best to explain exactly what is tracked, and why, in this long documentation page; https://docs.olivetin.app/update-tracking.html . My intent is to be open and transparent. I believe most of your implied questions are answered in that page;

Section 8.4.5 explains why OliveTin does this at all (short answer - the versions "out there in the wild" is incredibly useful to me as a developer).

Section 8.4.3 explains why OliveTin uses an installation ID (short answer - so that I know if it's 1 instance, or 10,00 - I don't collect IP addresses).

Section 8.4.9 explains why this isn't "opt in" by default.

Section 8.4.11 explains how to disable this (opt out) as well.

I'd like to end this first comment by just saying, again, I appreciate you being the first to raise this as a potential issue, and have an open mind to your concerns, criticisms, comments, etc.

[sneak]

Your rationale in the linked document for shipping unethical surveillance software seems to be "Chrome does it" (flagship software from a huge surveillance company) and "people wouldn't opt in if they had to opt in".

Neither of these seems reasonable to me. "The collected data is useful to me" is not a justification for violating the rights of users, acting unethically, and breaking the law.

"They wouldn't consent if we asked explicitly, so we assume consent without asking." seems to be the industry standard, I'll grant you that. Imagine how your life would be if you applied this doctrine universally.

[jamesread]

Hey @sneak ,

Let's talk, and discuss - I can see that this means a lot to you (and potentially others too). My mind is open to changing things if it makes sense and there is a consensus that people would prefer OliveTin didn't do this.

The point about "Chrome does it" is a good one - I also don't use Chrome (and try to avoid a lot of Google products when possible). I believe Firefox does a similar thing though, and I think some other Open Source software does this too. I'd be interested in researching more what other community FOSS software does.

The point about "people wouldn't opt in if they had to" - is mostly because I don't think people would see the setting, or would undervalue how useful the information is to the development of OliveTin. It's not because I'm trying to trick people, at all.

Also, you mentioned the project is "breaking the law", and sharing PII information - could you help me out and understand from your experience, what specifically it is that is wrong?

A good way for me to judge what the concensus is, is to see comments / upvotes from other users of the project.

[flammable]

Speaking for myself, I disabled update checking to prevent noise - since I'm using Docker, any updates will be applied when my container is rebuilt. I'm not sure I like the idea of the apps I've installed reporting back, though I can see how that data would be useful to developers. I'm sure other apps do it without giving me control, so I appreciate the config options.

I don't think a persistent random ID is generally considered PII. I found this post that seems to back that up.

[jamesread]

Thanks for the comments @flammable , really appreciate extra input here.

I'm going to ping the community discord server as well, as I think this is an important issue that deserves lots of input.

One possibility it do disable it if nothing is set in tje configuration, but set it to enabled in the example / default configuration - with a link to the docs explaining the option.

As you say, another option is purely "opt in" only.

Another option is removing this service entirely.

I'd like more thoughts though.

[sneak]

How would your life be any different if you didn't have access to the user data you collect via surveillance?

[tuxthepenguin84]

It's not PII and no one is breaking the law.

[sneak]

Unique, randomly-generated identifiers such as these are absolutely PII under GDPR and CCPA. They are identifiers that uniquely personally identify single individuals.

Collecting them without consent and business purpose is a violation of the law in Europe and in California.

[jamesread]

Hey @sneak ,

I'm still really interested in keeping the conversation going, but I would say that the discussion would be more productive if you could move to more of a "helping understand" style of communication, at the moment your communication style to me can sound pretty "accusatory" - which I personally don't mind, but it means we're making slower progress on these issues than we could be.

Unpacking the comments from this thread, I think these are the issues;

RE: Is this PII?
A few other folks here, and on Discord agree that a randomly generated ID (the installation ID) does not constitute personal information. However, when I think about it, I think that the installation ID is much like a session ID cookie used on the web. I know that the EU cookie laws require websites to "ask for consent" (which I think is silly, but it is the law).

I don't know that law in detail, and I don't know if session IDs / installation IDs are considered PII - any extra information / sources you could share here would really help my understanding.

Unique, randomly-generated identifiers such as these are absolutely PII under GDPR and CCPA. They are identifiers that uniquely personally identify single individuals.

The intent here is to track installations, not individuals, therefore I would make the assumption that it's not PII, but European and other laws probably would consider this tracking - and therefore a change here may be warranted.

RE: What could the change be?
I can see from your GitHub profile, and linked repositories that you've raised several issues like this with other open source software projects. I see that you're passionate about this topic, and I want to respond by making any user, or potential user of OliveTin happy :-) That's ultimately my objective!

I can see you created the consoledonottrack.com website, and I assume you're trying to drum up support for this as a "standard". I can see only 2 projects supporting this so called "standard" listed on your page, but actually I read through your page, I like it, and I'd be more than happy to implement this in OliveTin.

If I did this, does it go some way to helping your concerns?

RE: Exploring explicit consent / opt-in

How would your life be any different if you didn't have access to the user data you collect via surveillance?

My life would not be different, but I would have far less information to help me guide the direction of OliveTin. At the moment the tracking tells me that the vast majority of OliveTin users are using the official container image, on Linux, x86_64, this has helped me prioritize development on making that the best experience possible.

However, maybe this should be explicit consent, and even more obvious to users.

If I made these changes below, do you think this would solve the problem as you see it?

• Change the configuration option from checkForUpdates to optInInstallationTracking
• Assume false (opt-out) if this value is not set in the configuration file
• Assume false (opt-out) if the env var DO_NOT_TRACK is set, always overriding the configuration file
• I would personally like to have optInInstallationTracking: true in the default configuration file, however, I guess explicit consent really means people should do something to consent, so optInInstallationTracking should probably be false in the default configuration file.

Again, I welcome comments and suggestions from everyone here. At this stage I'm still exploring if we think a change is needed, and what that change could be.

[jamesread]

I've been doing some reading, it's interesting to read how other projects have responded here;

Homebrew/brew#6745 (rejected), syncthing/syncthing#6158 (rejected), minio/minio#16205 (rejected), osmandapp/OsmAnd#15058 (rejected), dotnet/sdk#3917 (rejected), netlify/cli#737 (rejected), gatsbyjs/gatsby#19528 (rejected).

It's really interesting to see most of the discussions not getting very far - apathy from other developers, not wanting to be the first, questioning PII (as I've had to do here), etc.

On a review of these other open issues, it seems very few of these have "good reasons" for not implementing DO_NOT_TRACK. Discussions just closed without much actual discussion, or ignored because the conversation wasn't that respectful. There is considerable confusion (like I have), as to if what they're doing is transmitting PII or not.

I want to get to add to the pool of information, for OliveTin, and other projects, and get to the hard facts.

Disclaimer: I am not a lawyer, but I have spent some time reading GDPR, just trying to interpret it using what I think is common sense!

Is this PII?
Article 4 ( https://gdpr-info.eu/art-4-gdpr/ ), bullet 1 gives a definition of "personal data".

(1) ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

This does not seem to match OliveTin's usage, where a randomly generated installation ID is generated (simply a UUID). Yes this is uniquely identifiable to an installation, but not a person. I went on to read further;

Recital 30 ( https://gdpr-info.eu/recitals/no-30/ ) covers "Online Identifiers for Profiling and Identification", and does explicitly call out "cookie identifiers" - OliveTin does't use cookies, but it's installation IDs are basically the same as session IDs. Unfortunately it's not clear in my interpretation if "cookie identifiers" cover session IDs. I would err on the side of caution and assume they do.

However, it's entirely possible that John installs OliveTin on Server1 (installation ID: 123), and also on Server 2 (installation ID: 456) in his home network; given that OliveTin does NOT record John's IP address, his name, or anything else like that (anything that is "personal data", there is no way to track that installation 123 and 456 both belong to John.

This summary page is a helpful read; https://gdpr-info.eu/issues/personal-data/ , in particular;

Last but not least, the law states that the information for a personnel reference must refer to a natural person.

Consent
The conditions for consent seem to be defined in Recital 32 ( https://gdpr-info.eu/recitals/no-32/ and https://gdpr-info.eu/art-7-gdpr/ ), it certainly seems to suggest a user needs to "do something", and cannot accept a default (even an example config). The key issues page here is also a helpful summary; https://gdpr-info.eu/issues/consent/

---

Here's my action plan;

1. Wait for a reply from @sneak on my previous post, RE the question; "If I did this, does it go some way to helping your concerns?"
2. Wait for a reply from @sneak on my previous post, RE the question; "If I made these changes below, do you think this would solve the problem as you see it?"

If the answer to both is "yes", I think it's safest to err on the side of caution.

[sneak]

Please do not derail the discussion wrt the proposed do not track environment variable. I have not raised it here and it is irrelevant to this issue.

You mentioned "[my] concerns". To the best of my knowledge I have not expressed any. My issue report contains facts, not my own opinions, other than my assessment of the reasonability of the existing choice made the developer of the software that assumes the user consents to network surveillance.

Please do not expect further replies from me.

It is objectively unethical to put users under surveillance without their informed consent in advance - full stop.

It is objectively a violation of laws in several jurisdictions to track users with unique identifiers without consent.

You have all of the information you need. I have unsubscribed from this thread, as it has nothing to do with me or my opinions.

[sneak]

One thing you did correctly note is that getting software developers to understand the realities of consent or privacy law is a mostly futile waste of time.

The industry is so addicted to the validation from "big (completely unactionable) number on dashboard go up" that they will defend nonconsensual and illegal surveillance even when no profit or business use case is involved.

I never should have proposed an opt out standard to anyone, as it confuses developers into forgetting that putting users under surveillance without affirmative and informed consent is unethical, no matter how that surveillance is carried out.

[jamesread]

@sneak I think I've gone above and beyond to work with you here, please don't give up. Let's talk.

Let me simplify; I suggested an idea what would "fix" - I need you tell me if it does? If not, help me understand what I missed here.

[sneak]

To be clear: I am not a user of your software; I was repelled by the surveillance. There is nothing to fix for me.

If your software doesn't spy on users, there is no ethical issue. If your users choose to opt in to transmitting their data to you, you should be fine. It sounds like you want to change to opt-in consent - this is how Debian does it, and it is ethical to proceed this way, as you are not deceiving users if they provide informed consent.

[Node815]

I will comment that as long as OliveTin does not record my actions in the app (Number of clicks etc) or yaml code I set up, and report back to home base, then I am fine. The UUID is fine if it helps you like you said as far as I'm concerned. :)

Adding an opt-in for inbuilt update checks is a great idea to help satisfy the concerns about automatically doing checks.

[kmcbride3]

FWIW - and I don't fit into a jurisdiction that currently has the GDPR laws in place, so I'm not exactly up to speed on them either, but I do think that the proposed changes to make it OPT-IN (with the default configuration file/Dockerfile examples having it checked) seems like a reasonable change...

However, if you wanted to be completely sure you're in compliance, it would need to be explicit. It would be more work, but perhaps a one-time prompt at the top of the homepage on new installs (and then an option in the settings afterwards) explaining what you're requesting consent to capture (as already documented in https://docs.olivetin.app/update-tracking.html).

Personally, I'd opt in as I don't think you're capturing anything harmful (in my opinion).

[bulletsp0nge]

I know this is an old thread. My apologies for reviving it, and sorry about the long rant. I work for the DOD, and we go through PII training yearly so I found this very interesting. I do not represent the views of any organization by the way. These are my opinions only. I looked into the GDPR guidelines. I am no lawyer either, but it seems to come down to PII (Personal Identifying Information.) But what is PII exactly? Easy. Names, addresses, Social Security numbers, Drivers Licenses, etc. So, how is a randomly created ID number considered as PII by the OP? If you give me a database full of ID numbers, I would not be able to link them to any actual human being. You would need names, addresses, SS#s. So, it is not PII. There are also guidelines in the GDPR websites that state that if a company has less than 250 employees, they are basically exempt. Does OliveTin has 250 employees? No need to answer as it is a moot point. I also read OliveTin's section 8.4 about tracking. It is well documented. Nothing devious going on as far as I can tell. As it should be, it is the always the user's responsibility to read what they get themselves into. So, this issue comes across as a "Crying Wolf" case. Notice that I did not address the OP directly. The development team has replyed eloquently and thoroughly to the OP's issue. I cannot say the same for the OP's responses. If you read this OP, get off your high horse. Shaming someone for not being ethical (which is not the case here) while calling yourself a "hacker" in your profile seems more like you are throwing stones in a glass house. Anyway, don't bother replying to me OP. I am done with you and your non-issue. OliveTin team, thank you for such a great piece of software. End of rant and transmission.