On Mon, Oct 8, 2012 at 4:59 PM, Bob Wyman <[email protected]> wrote: > Do you have a specific proposal for improving the current protocol or > empirical evidence that the existing design is inadequate? > > bob wyman
My initial scenario was something like an attacker POSTing a publish to multiple hubs, and then counting on the asynchronous content fetch to happen in a small window of time on the target. This was based on pure thinking and no experience though. However, If I read strictly the current spec, I can see under the "New Content Notification" [0] that : > The topic URL of the topic that has been updated. This field may be repeated > to indicate multiple topics that have been updated. and there is no word about removing duplicates, so a strict implementation would fetch new content once for each dupe. I admit this is rather far-fetched (even the reference implementation does a set(topic_list) so duplicates are removed) and different implementations would be smart and remove duplicates, but it isn't strictly written. All things considered, I don't see the above-mentioned scenario would be a threat, so please excuse the noise I have generated. Keep up the good work ! [0] https://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#rfc.section.7.1 -- Matthieu RAKOTOJAONA
