traffic analysis: http://en.wikipedia.org/wiki... on private resources because you will know how often and when they update. The spec should point out the potential risk. - Adewale Oshineye

I've given this issue a lot of thought because it affects OurDoings. The risk is negligible. I don't have time for an extensive comment now, but hopefully can fill in details later. - Bruce Lewis from fftogo

Briefly, if you don't already have access to the resource, the resource token won't lead you to it. If you know enough about the resource to do traffic analysis, you might be able to figure out what token goes with said resource, but you won't have any more info than when you started, i.e. you'll know when the resource updates. You already had that knowledge or you couldn't do traffic analysis. - Bruce Lewis

Given a private resource at example.net/1 (perhaps discovered through the Referer header) all I can tell is that there's something there. Given an Update Document that points to example.net/1 (perhaps because the publisher has decided not to use opaque tokens because all the urls are password protected) it becomes possible to tell when this private resource is being updated. Moreover it becomes possible to build up a history of when all the private resources for a particular publisher were updated. With a small dataset this isn't a significant risk but with larger datasets it becomes possible to start correlating it with other information and then the risk increases. All I really want is a line in the spec pointing out that adopting SUP slightly increases the risk to the privacy of a publisher's users. The risk is small but potential adopters still ought to be warned. Of course this assumes that potential adopters will actually read the spec. - Adewale Oshineye

If people know your URLs and you use a hash of your URLs as the token, then yes you're telling the world when each was updated, no traffic analysis necessary. Seems obvious to me, but you're probably right that implementors should be warned somewhere. (I take back what I said about having thought a lot about this; I used opaque tokens and didn't think about the risk of non-opaque tokens.) - Bruce Lewis

Would adding this paragraph to the Security section of the spec help: "SUP does not require that a site MUST encrypt its resource tokens. The resource tokens may be rendered opaque through strong encryption, hashing or they may be non-opaque. In a scenario where a SUP document is being used to indicate that private or password protected resources have been updated and the resource tokens are insufficiently opaque (e.g. the urls of the resources are used as resource tokens or the resource tokens are rendered opaque with an algorithm that can be reversed in order to identify the underlying resource) then an attacker can build up a detailed profile of when these documents were updated. This profile can then be correlated with other data sources in order to compromise the security of the private or password resources. This is one way adoption of SUP can weaken a site's security." - Adewale Oshineye

@Ade - the SUP draft RFC has been updated to include that text: http://simpleupdateprotocol.go.... Thanks! - DeWitt Clinton

Regarding traffic analysis: you can place fake updates in the SUP feed. Consumers won't be able to tell the difference between a real update and a fake one. - Benjamin Golub

That will only work if you do something very clever to generate realistic looking fake updates without causing consumers to hammer your server looking for updates that don't exist. - Adewale Oshineye