What's the alternative? I'm not sure how a client can query a server for updates without exposing its IP address beyond obfuscation like TOR or perhaps a VPN.

It can just obtain the user's consent; and, if denied, the alternative is to not phone home at all.

That's pretty much the norm in Linux.

One typically gets packages from the distro's repository. And traffic with modern repositories uses HTTPS. So third parties don't see what packages are being used. And unless one configures a developer repository, there's never any traffic to the developer.

Also, IP addresses are considered PII under GDPR.

Edit: Still, if one cares that much about ones IP address, it's prudent to use a VPN service or Tor.

IP addresses are only PII if attached to other information. I can generate a list of IP addresses and store/sell that data and it's all fine because its meaningless without associated data.

The other information is "using Atom".

It's still impossible to link that to an individual unless they sold it to another company that has more info on the address.

Or bought the data.

I'm like 99% sure that datasets are available that link IP addresses to all sorts of PII. And then there are third-party cookies and other trackers.

Yes, and that possibility is enough to make this fall under the GDPR.

> Also, IP addresses are considered PII under GDPR.

Not true. They’re only PII if they can be used to connect something to a person. It’s a minor distinction, but it is one nonetheless.

In this case it would not be PII data if it was just an IP address in a webserver log saying someone checked for an update. It would be PII data if it was linked to your GitHub account.

an alternative updating mechanism that doesn't directly expose IP of the updater?

a dht/blockchain mashup comes to mind, but really it just pushes the IP knowledge to knwoledge of some other intrinsic variable that can be used for fingerprinting.

the issuer of public information (an update) doesn't necessarily need to know who collects the information, it's just architected like that for most internet things.

That’s just not feasible for most projects. Why ship a blockchain along with your product, when you could just go with a GET request? The technical complexity, server space, and additional bloat that would be needed to be added to the app would be a waste, IMO.

>”Would you like to check for updates?”

Or you could maintain the current version number on the Wikipedia page for your app. Your app could then request its wiki page over HTTPS as a check for updates.

Then the only useful logs would be held by Wikipedia. And more broadly, requests to that page would be utterly lost in the noise.

That's not a bad idea, actually.

Ideally the article would contain (in a comment or some hidden field) a signature from the PGP key of the app's developer, covering both the version number and the date of release (to stop replay/rollback attacks).

Alternatively, the app could look at the article history and find the latest edit made by the developer's Wikipedia account, so that malicious edits would be ignored. This assumes the threat model doesn't include rogue Wikipedia admins rewriting history or hijacking accounts.

At the expense of a smaller anonymity set, it might make more sense for the app to query Wikidata instead of Wikipedia: https://www.wikidata.org/wiki/Q16766305

> (to stop replay/rollback attacks)

In my imagining, the content of the Wikipedia article does nothing more than trigger a notification to the user; it would be the user's choice whether to initiate a network connection with the vendor's server for the "real" check and binary download.

Yes, the "real" check would be made against the vendor's server.

I was a little unclear about what I meant by "replay/rollback attacks", though. My concern was that someone editing the Wikipedia page could vandalise it to remove the reference to a newly released app version, meaning the app never checked the vendor's server. They would be rolling back the article to a previous edit, or "replaying" a previous edit that was no longer truthful.

Moreover, an attacker could add a spurious reference to a version that hasn't been released, in order to trigger an app to make unnecessary requests against the vendor's server.

Fortunately, both of these types of vandalism would be ignored by a system which checked the revision history and knew the user name associated with the vendor.

The vendor could also independently monitor their Wikipedia page(s) and deal with the problem through Wikipedia's resolution processes. The benefit here is that the vendor would be the first to know when someone is attempting something nefarious.

That said I suggested Wikipedia mostly as a joke—though I do like the principles of indirection and hiding private material within the most noise.

--

Actually, it occurs to me that an appropriate place for software update notifications could be DNS. Something like a cryptographically signed TXT value with a long TTL. It does have the downside of being a cleartext protocol at the moment, but once that changes, you've got a great distributed, fast and resilient key-value store right there...