How is this scenario at all different than any random DoS attack (intentional or unintentional)? Anyone can flood any HTTP endpoint they choose with requests; it's up to the site (in this case the hub) to decide if they're going to accept all those requests or not. Lawsuits are not going to make denial of service attacks go away, nor are they going to stop over-zealous hubs.
The exact same problem exists for SMTP, and is handled just fine. The only response code that suggests that the server wants the sender to back off is 421 which is just "service unavailable"; all modern SMTP servers (i.e., hubs) have facilities to retry and back-off from unavailable hubs. HTTP has a mechanism for signalling over-loadedness, namely 503 Service Unavailable, and a corresponding Retry-After header. Ultimately, though, it's entirely up to the hub to take those responses under advisement. b. 2010/1/11 James Holderness <[email protected]>: > On Jan 8, 5:49 pm, Jeff Lindsay <[email protected]> wrote: >> Think of your callback URL like a webpage ... you can't really control how >> hard it's hit (hence slashdot effect, etc). You can add rate limiting in >> front of it if you're really worried. So a) don't subscribe to publishers >> you don't trust to not flood you, b) deal with it appropriately as HTTP if >> they do and you still want to subscribe to them. >> >> I don't think it's the hub's responsibility. > > I have to disagree. I think this is very much the hub's > responsibility. > > A typical PuSH subscriber could be a web-based feed reader like Google > Reader or Bloglines. The choice of who to subscribe to is made by > users of the service, not the service itself. The service basically > has to trust every feed that a user might want to subscribe to, so (a) > is not really an option. For PuSH to be usable, a subscriber must be > able to rely on the hub not to flood it. > > From a legal point of view I'm kind of curious who would be liable if > a hub flooded a server off the internet (perhaps resulting in loss of > business) as a result of unwanted pings. > > For the sake of argument, assume that the pings were from a feed that > the client *hadn't* subscribed to (i.e. a deliberate attack propagated > through the hub). It seems to me that the hub is responsible for the > loss of business suffered by the subscriber. The hub could in turn try > and sue the attacker (assuming they could be traced), but the initial > liability still lies with the hub IMO. > > Obviously the law will differ from country to country, but if I were > running a hub, and one of my servers took someone's site out by > flooding them with pings, I would hope I had a better defence than > just shrugging and saying "not my responsibility". > > This is not the same as the slashdot effect, which is a legitimate (if > unexpected) flood of connections from multiple sources. > > Regards > James >
