Yes! If it’s not opt in.

Software should not make outgoing connections or accept incoming connections unless requested by the user.

* * *

Why? In a world where the vast majority of computers are internet connected. This is just how software is constructed nowadays. Especially web development which is ahead of the ancient development practises common in libre software. Just open your network tab and see how many requests it makes without asking you.

yes, but all that is user hostile stuff that nobody really wants.

modern websites are a cancer that we really quite could do without

>yes, but all that is user hostile stuff that nobody really wants.

The proof is in the pudding. You claim nobody wants these things yet there are billions of people using these kinds of sites.

That vast majority of whom don't understand what's happening. Don't confuse ignorance or apathy with wanting it.

No. My computer having an internet connection is not an automatic invitation for anyone's software to use it.

Just because a lot of software sucks doesn't mean it's acceptable or we should lie down and give up. We should work on improving OS capability/permissions models so that apps can't do this by default.

In the absence of better protections, I absolutely audit which processes make connections from my machine and uninstall those that make unwanted connections that can't easily be uninstalled (with a small number of unfortunate exceptions where the need to use certain software outweighs the desire to maintain a reasonable system).

This doesn't mean no connections ever, it means no conections users don't ask for and no connections that don't provide value to the user. It certainly means no phoning home or stats/crash data connection without explicit opt-in.

It is especially frowned on if the software was packaged by a package manager that handles this for you!

But the upstream didn't package it, Debian forked it and added/changed build scripts to do so. It's on them to remove the update checks if they want to change the distribution mechanism.

True; the easiest solution is probably to have upstream add an option to ./configure to compile it out. FreeBSD, Red Hat, etc, etc. would also appreciate that.

Yes, but there's no requirement they do so. They might (depending on the project) accept such a patch, but catering to forks of their project is rarely any OSS maintainer's top priority. Major distro forks can be important, but if someone built their own update checking mechanism they probably don't care too much about other installation methods.

Well, adding the option would significantly decrease the set of patches that the distributions need to apply, which would decrease erroneous bug reports, etc.

A distribution-provided package doesn't really need to be a fork unless upstream isn't playing nicely with the rest of the OSS ecosystem.

I don't get it either. It feels like two separate things are confused .

1) "Privacy": I.e. the fear of PII being transmitted or used by a third party

2) "Control": I.e. the fear that the system does something that I didn't ask it for.

They are (quite weakly) linked, but they aren't the same things. I'd avoid even discussing them in the same breath for this reason. Saying that checking for updates is a privacy violation just means that everything is lumped together which is a fantastic outcome for software that is actually violating peoples privacy. "Everyone else does it".

I do not think that privacy is restricted to PII. For me, computer privacy is as simple as 'any information about what i do with computer that need not leak outside should not leak outside'.

PII leakages are just considered more severe than general information leakages, so there is a legislation to handle them.

So checking for updates without sending any identifier counts, since it transmits the fact you did in fact run the application, and it's not strictly necessary.

I can see the point but it seems hard to draw the line for every single feature at the precise point of "does a network connection". For some programs there is quite a grayscale of what's "necessary" (i.e. needed) and what isn't.

I agree that in some cases there is a grayscale because what is an important behavior for some users may be unnecessary for others. For example, i could accept that incremental search using Google when text is entered to address bar in a browser could be considered both useful feature and privacy violation depends on user expectations.

But i also think there are some clear lines, like if a tool is not expected to use network at all, it should not use it. If a tool is expected to communicate just with explicitly specified hosts, it should not communicate with third-parties, ...

Checking for updates leaks your IP, which is PII.

yes, it leaks the information that you use the application (at all), at what times and so on, at a (potentially) individual level. But I'm not sure what the remedy is for some applications auto updates might be unexpected or even unwanted, but for other applications it would feel pretty bad to not have them and have them enabled by default. That's the user's expectation - not the expectation of privacy for their IP. I think user expectations should be in focus, but it's not always easy to guess. Saying "put the lid on everything and let the user actively enable anything, check for updates etc" also isn't very user friendly.

I think software updating itself is sort of a windows mentality.

Most other operating systems (linux, macos, ios, etc) update through an os-wide mechanism.

Debian already has apt and that downloads a list of package names and versions from each repo and what is on the system is generally hidden. If the user asks to install a package, then the user has opted-in to download and install that package/dependencies. Also the packages can come from a variety of caches and mirrors.

> I think software updating itself is sort of a windows mentality.

Yes it's definitely a mentality of "the apps are separate from the OS" at least, which is basically every OS except Linux/Unixes with central package managers. Even on a Debian or Ubuntu system, I'd be using dozens of non-packaged applications though (Be they locally compiled from github, or flatpacks or whatever).

> Saying that checking for updates is a privacy violation just means that everything is lumped together

Your IP address is considered PII. Hell with a timestamp you can easily track the behavior of people. When do they work, when are they asleep, which holidays do they observe, when are they on vacation, ... . You can get really creepy with a tiny amount of actual information and some statistical analysis.

Depends how hardcore you are about privacy and the claims the tool makes about privacy. Those who claim to collect none are held to a higher standard than others. Even if it's just version number it does leak usage, location and so on. It can have valid uses, but can also be cleverly abused.

For platforms where the program is sandboxed and permissions have to be declared, I would frown at the software requesting network access just to check for updates. For example, mobile apps and programs in Flatpaks.

If it's undisclosed or it can't be disabled, then yes. It's even better if you have to enable it rather than disable it.

What if it's in an free open source project, and can be disabled? The point is to minimize the issues people open due to running old versions of the software.

I assume you're asking because you do collect it. It depends on your users and what level of privacy you claim. From some it's expected, others would result in uninstall. ToR phoning home on the users' open network will have a different reaction than Firefox, even if it's essentially the same browser.

I don't, yet. Just asking because it'd be quite useful.

I personally don't want my software making any connections unprompted except if that is its primary purpose.

Updates for OSS is also often installed via a package manager so additional checks are less useful and generally unwanted. That leaves non-package distribution (e.g. Windows or portable binaries) - I think best would be to either ask during installation or ask once if the local clock is quite a bit past the release date of the current version.

Of course different people will have different opions on this.

This is Debian we're talking about. If you package something for inclusion in Debian, you're supposed to update it with APT, not some home-baked updater that phones its own mama and displays its own notification.

If you want to push updates faster than Debian stable does, the proper way to do it is to provide a third-party APT repository. Then I can decide to disclose my IP to a mirror of my choice, using a proxy of my choice, that can be configured globally in /etc/apt.

I think it's an even more urgent issue with FOSS. FOSS still has some trust (although it's evaporating), and handling this badly reduces that trust.

If undisclosed, it is outright illegal in Europe, as the IP address can be mapped to an individual's identity in some typical scenarios.

This is a common misconception. IP addresses are only considered PII if you are in the position of being able to decode them to an identity. An anonymous version checking service obviously does not count.

Sure the IP is PII because you are not allowed to publish it as others could relate the IP to the identity.

But as others already said: if you don’t store the IP (eg in logs) it should be fine.

You could store the IPs in logs until the heat death of the universe and it would be fine, as long as you aren't able to translate it to an indentity (or give it to someone who can). The point of my comment is that an IP is only considered PII when possessed by someone who can do the conversion.

Playing devils advocate here, but one interpretation of the law is that if any script that obtains the IP addresses could reverse it to an identity, then you are in violation.

Sure, and "one interpretation" of the sky is that it is purple. Or instead of making random interpretations up, we could look at actual cases like Breyer v. Germany, and see how the laws are interpreted in real life.

And I could interpret your text as Klingon. But that's not reasonable. My interpretation above was reasonable.

An IP address alone may not reveal who had visited a site. However, Internet Service Providers have additional data that can link IP addresses to individual people. Although it's unlikely that the two data sets will ever be matched up, it is possible. So IP addresses must be treated as personal data.

Again, as I have said multiple times in this thread existing EU case law has made it clear IPs are only PII if and ONLY if you are able to do the conversion yourself (or give it to someone who can). Storing IPs in your web server logs is for an anonymous version checker is totally ok (as long as you aren't an ISP or someone who can do the conversion).

You can make up your own interpretations of the law as much as you want, but in real life the interpretation from the CJEU (for US readers like me, the EU's equivalent of the Supreme Court) is the one that matters.

No that is not how the GDPR works.

It would be illegal specifically if you _collected and stored_ the IP address information from the phone home requests to process in some form later.

If you simply process the web request, and don't store the IP address then there it no issue.

If you do end up storing IP address in a log somewhere, then simply having the logs deleted in a documented and reasonable timeframe will be enough.

"Documented and reasonable timeframe" is intentionally vague since business requirements are varied, but if you can justify whatever you come up with, then there is no issue.

Simply do not hold onto user data for longer that what is required for the purposes of the user request. That's it.

It's not "outright illegal", AFAIK. If you can point me to a place that definitely says it is illegal (or not) I'd really appreciate it!

From what I've learned about EU regulations, ANY time you have technology that serves an EU citizen there is the potential for you to be sued over potential violations of the intentionally overreaching and vague privacy laws. The EU is so incredibly hostile to small business and FOSS.

>The EU is so incredibly hostile to small business and FOSS.

It's not EU being hostile, but rather US being incredibly lax(to put it mildly) about privacy issues, so that we even consider these violations a norm.

Oh, so the EU makes vague laws that hurt the small guy because they are mad at the US?

No, the "small guy" should not be entitled to violate privacy and rights of EU citizens (or any people, for that matter), just because US doesn't grant same protections.

The small guy can't afford to abide by these vague and over-reaching regulations, is my point.

It doesn't cost you anything to not collect my PII.

What if you are abusing a service? Can I collect it then?

This is quite a leap from unnecessary phone home request to check version, but alas it already has been answered in depth in other comments.

Not a leap. The conversation jumped to the broader conversation of GDPR and PII a few comments up.

Running a service that might serve an EU citizen quickly escalates to involving lawyers and performing risk analysis in relation to being sued in a court across the ocean.

>Running a service that might serve an EU citizen quickly escalates to involving lawyers and performing risk analysis in relation to being sued in a court across the ocean.

Running any service where you are not sure of legal requirements might require consulting a lawyer first, how is it unique to GDPR? And in order to be on the radar for GDPR violations as a small business you REALLY need to do something seriously wrong.

I actually think I may be mistaken.

I've always believed GDPR was a regulation that crossed borders. Meaning it applies to any EU citizen, no matter where they are located, which is what made this unique (being that it's not my countries laws). But:

> The GDPR applies to: > > a company established outside the EU and is offering goods/services (paid or for free) or is monitoring the behaviour of individuals in the EU.

from https://commission.europa.eu/law/law-topic/data-protection/r...

So now I'm wondering if an IP address reverse-geo lookup to block IPs in the EU is the easy way out for many online services, presuming that this doesn't cause compliance issues for EU users using a VPN.

It sure is a good way to communicate that you don't care about my privacy and should not be getting my money ¯\_(ツ)_/¯

GDPR is a headache and makes doing the right thing harder.

No.

Yes.

Yes.

"Processing shall be lawful only if and to the extent that at least one of the following applies: [..] processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data"

Reasonable abuse protection clearly falls under that, as has been fairly clearly stated even in the GDPR itself: https://gdpr-info.eu/recitals/no-49/

But I don't know what counts as PII because the regulations are so vague.

All of the legal definitions of "PII" leave out a ton that is actually personally-identifying information. Just have personal standards that exceed all of the laws. No problem.

Stop spreading bullshit. GDPR is incredibly easy to comply with if you don't do retarded shit.

Like attempting to protect a service against abuse? Do that and be 100% confident your aren't in violation and post an easy step-by-step tutorial on how to do it.

Using IPs to protect from abuse has been debated to death and is considered legitimate use.

Just some questions off the top of my head, that I, a FOSS developer have, and can not say with absolutely certainty that an EU court won't have problems with.

How long can the IP kept around for? And in what form? If it lands in a database, does it need to be encrypted at rest? Can it just be hashed? Salted, too? Do I need to rotate the salt? This limits the ability to protect the service though. Are the tools in my stack logging something somewhere else I don't know about? Could I get in trouble if it is? Cloudflare forwards IP-derived data to me, like the city of IP may be in, do I have to be concerned with that as well? Do I have to tell users upfront that I use Cloudflare and it derives data? I'm guessing I have to fully understand what CLoudflare does with this data. It eventually hits my Digital Ocean droplet, what does it log?, are there separate logs I can access from them outside my droplet? Certainly they have logs, too, what do I do about that? If I just require all users to explicitly agree to some form of data collection this probably goes away. Oh wait, now I have to manage obvious PII and ensure Right to be Forgotten can be exercised in a timely fashion, I've just made the whole thing more difficult for myself.

There is a cost, and it affect the small honest devs the most.

I'm not saying what GDPR is attempting to do is a bad thing, I'm just saying that it is not easy to comply like everyone keeps saying.

Those questions are not in good faith, and answers are readily available and have been for a long time. e.g https://law.stackexchange.com/a/28609

How can you say the questions aren't in good faith and then link to a popular Stack Exchange question and argument about some of them? Developers do need to ask these questions.

I am saying that you in this particular instance are not asking those questions in good faith.

An IP by itself is not PII.

You have to be sure that you or anyone else in your chain can't link an IP to a specific person without explicit consent (and thus compliant with the rest of the regulation).

You can have cloudflare giving you IP/location pairs as long as cloudflare doesn't know who that person is.

You can keep your own logs of IP/person. You have to keep it safe, and inform somewhere in a policy that you are doing that. If the logs are kept abroad or cloud, then you need consent (and comply with the rest of the regulation).

It's all made to avoid companies tracking using across boundaries, selling data and having all that PII unwarranted for the next "We take your data and security very seriously" blog post about a leak.

It's easier not to keep any PII around. IPs? you can have as many as you want as long it can't be used to identify a person (without consent).

PS: here is a checklist => https://gdpr.eu/checklist/

Debian is quite an opinionated project and they take matters like these very seriously. Pages like these don't exist to judge packages, they're merely there to make people who do care aware of any risks they might not have heard of, and help them exercise control over their machine if they consider these "risks" not to be worth it.

I doubt anyone will really care about version checks, unless that's the only reason your tool needs internet access at all. Maybe if you make it an opt-out rather than an opt-in feature (or don't prompt the user at all), I'd be annoyed by that (but I know others aren't).

They're completely unnecessary in packaged Debian software because the Debian people will provide newer versions of your application for their users, so a flag to opt out would be nice. Using this data in a useful way, like adding a message like "new version available" would be confusing, because there is no new version available when you run the system update tool!

Personally I'd say it should be possible to disable version checks through build flags if you intend to package software through official repositories.

If you intend to do distribution and updates yourself I don't think you should be forced to alter your code if people decide to add your software to their distribution. The burden of removing confusion and making their version stick to their ideals should be on them. It would be nice to cooperate, but I don't think you can be blamed for someone else's redistribution.

that's what apt is for.