[serf]

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.

[gen3]

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.

[egdod]

>”Would you like to check for updates?”

[sjwright]

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.

[dane-pgp]

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

[sjwright]

> (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.

[dane-pgp]

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.

[sjwright]

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...