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