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