The draft spec doesn't account for a change in policy. How would a publisher pull access for a subscriber that seemed harmless at the point of subscription but turned out to be malicious later? Depending on the subscription renewal policy there would be at least a considerable time span where a subscriber would still receive notifications. Is this time span neglectable?
In my mind the core of the problem is that fat pings aren't good when you need to worry who's subscribing. I am currently using pubsubhubbub for protected feeds. I took the liberty in my implementation to support a 'light ping' that forces the subscriber to fetch the feed from the original source - authenticated, over a secure connection. This allows me to distinguish between subscribers and - if necessary - disallow access on a granular level. A very useful feature for feeds of paid content or in my case - feeds of user credentials in a federated system of sites. Correct me if we're talking about *completely* different things here. Alex On Wed, Jan 20, 2010 at 9:02 AM, Pádraic Brady <[email protected]> wrote: > Hi Julien, > > Having thought about I had a few conclusions. Being an implementor (loves me > code ;)), it would certainly be simple to do so no complaints there. I was > curious how you saw this operating in a synchronous mode of subscription - > the more indirect requests needed, the longer we're keeping Subscribers > waiting. I'm particularly sensitive to us engaging in transactions which > will start hitting bottlenecks like PHP's maximum execution time limit (let > alone whatever the locally set HTTP timeout is). I nearly always favour > async mode (where possible) but most Subscribers I suspect won't want the > added complexity and will prefer synchronous. > > The privacy issues I really don't see. Use of any technology is always > subject to the client exposing something of their identity. The exposure of > certain details like their callback URL doesn't seem to be much of an issue. > By definition it's already publicly exposed so what else is there to keep > private? We're not looking for Joe Doe's name, address and credit card > details ;). Why don't we apply this same principle to Hubs? Aren't > Subscribers handing them private information in this case already?? > > At the end of the day, I really think this has a huge amount of potential > with is underplayed by its very modest intent. I think that's the main weak > spot of the proposal - it's very specific ;). Then again, its specific > nature is what makes it simple to grasp and implement. For myself, I would > definitely like to see Publishers being able to get some kind of feedback in > real-time in this vein. It may not be foolproof but on a personal note, I > already have some funky programming tampering with my feeds so certain IPs > get a feed full of copyright infringement messages instead of my actual > content. Surely a modest blogger like me can't be the only one plagued by > content stealing. > > There is absolutely no reason why we should be linking the nature of feeds > to the nature of Pubsubhubbub - they may be marginally related but both > offer two very different distribution methods that merely share a common > distributable format. It seems quite acceptable that Publishers have the > right to impose additional restrictions. They can already do it to some > extent with feeds, but real-time data and interactions with a Hub offers a > far richer environment to work within. > > Paddy > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative > > > ________________________________ > From: Julien Genestoux <[email protected]> > To: Pubsubhubbub <[email protected]> > Sent: Wed, January 20, 2010 10:28:46 AM > Subject: [pubsubhubbub] Publisher Callback Extension to PubSubHubbub > > Hey, > We (superfeedr) have been in talks with a lot of publishers and several of > them where concerned about the "blindness" for publishers in the > PubSubHubbub protocol. > Sorry for linking from the Superfeedr blog > (http://blog.superfeedr.com/Extension/PubSubHubbub/Spec/publisher-callback-extension/), > but if you're looking for more insight on why we're proposing this, you can > find it there. > We published the Extension proposal to the wiki > : http://code.google.com/p/pubsubhubbub/wiki/AcceptingSubscriptionForPublishers?ts=1263982978&updated=AcceptingSubscriptionForPublishers > I'd love to have everybody's opinion. Bob added a few comments and I'd like > to insist on the fact that this doesn't solve any copyright issue. It just > makes it a little easier for publishers to know about who subscribed to > their content. > I'd love to know what you guys think :). Please help me complete that! > Cheers > > > -- > Julien Genestoux, > > http://twitter.com/julien51 > http://superfeedr.com > > +1 (415) 830 6574 > +33 (0)9 70 44 76 29 > Sent from Milan, MI, Italy
