[pubsubhubbub] PSHB thoughts...

[James M Snell]

Posted some thoughts here: http://www.snellspace.com/wp/2010/05/pubsubhubbub-thoughts

DeWitt requested that I also post here to make sure it was seen.
Hopefully the comments are useful.

- James

[Julien Genestoux]

James, 

The "fat" ping from a publisher is definitely doable. Superfeedr does that with some of its publishers, but we need ways to enforce that nobody is actually trying to forge the relationship. It's doable, but on a per publisher basis, so I think the protocol is right to define a way that _always_ work.

For the rest of the post, I'm not so competent, so I won't comment :D

Cheers!

[Bob Wyman]

Right. As Julien says, the silliness with light-pings to the hub followed by polling for updates on the feed is only there in order to make it harder for people to spoof the system. There are a variety of alternatives to this approach, but a light-ping and fetch method it is certainly the simplest to implement and thus probably always needs to be supported even if more complex approaches are used.

Personally, I hope that we'll one day be able to see support for fat-pings using something like the signed entries that Salmon produces. (Actually, I would prefer if people would just use the DSig stuff that is defined in Atom, but the reality is that that approach simply seems too hard for many developers and I've given up on trying to convince anyone to use it. There are all sorts of problems with getting certificates, the canonicalization is hard, many elements are confusing, etc... The intent of Salmon's Magic Signatures is to make signing stuff as simple as conceivably possible without loosing too much of what a signature is supposed to do for you. I think it succeeds and I think Magic Sigs, with just a few minor extensions and support from WebFinger, will be able to handle the vast majority of signature needs -- although not all.)

If "signed" fat-pings are too complex, there are all sorts of mechanisms by which publishers and the hub could pass secrets back and forth to convince each other that they knew who they were talking to...

There should be no question that a fat-ping approach would have real benefits. Heck, in various forums, a number of us have been working on fat-ping proposals of one kind or another for something like seven or eight years now... (Do you remember "FeedMesh?") Eventually, we'll figure it out.

bob wyman

[James Snell]

On Thu, May 20, 2010 at 11:14 PM, Bob Wyman <b...@wyman.us> wrote:
> Right. As Julien says, the silliness with light-pings to the hub followed by
> polling for updates on the feed is only there in order to make it harder for
> people to spoof the system. There are a variety of alternatives to this
> approach, but a light-ping and fetch method it is certainly the simplest to
> implement and thus probably always needs to be supported even if more
> complex approaches are used.

Agreed. Definitely not advocating that light-pings not be included.

> Personally, I hope that we'll one day be able to see support for fat-pings
> using something like the signed entries that Salmon produces. (Actually, I
> would prefer if people would just use the DSig stuff that is defined in
> Atom, but the reality is that that approach simply seems too hard for many
> developers and I've given up on trying to convince anyone to use it. There
> are all sorts of problems with getting certificates, the canonicalization is
> hard, many elements are confusing, etc... The intent of Salmon's Magic
> Signatures is to make signing stuff as simple as conceivably possible
> without loosing too much of what a signature is supposed to do for you. I
> think it succeeds and I think Magic Sigs, with just a few minor extensions
> and support from WebFinger, will be able to handle the vast majority of
> signature needs -- although not all.)

Having implemented dsig and encryption support for Atom in Abdera, I
don't buy the argument that it's too complicated. The tooling support
for XML-DSig's isn't great, but any solution that adequately secures
Atom docs is going to suffer from many of the same fundamental issues.
Sure, we might be able to simplify the problem in various ways, but in
so doing we end up building a less secure system. That said... the
ability to digitally sign HTTP requests/responses independently of
Atom could likely make this a whole lot easier as it would move those
details out of the data format and keep us from having to muck around
with the XML at all.

> If "signed" fat-pings are too complex, there are all sorts of mechanisms by
> which publishers and the hub could pass secrets back and forth to convince
> each other that they knew who they were talking to...
> There should be no question that a fat-ping approach would have real
> benefits. Heck, in various forums, a number of us have been working on
> fat-ping proposals of one kind or another for something like seven or eight
> years now... (Do you remember "FeedMesh?") Eventually, we'll figure it out.
> bob wyman

Oh yeah, definitely not a new idea, lol, but one that qualifies for
It's-About-Friggen-Time-We-Make-This-Work.

- James

> On Fri, May 21, 2010 at 1:36 AM, Julien Genestoux
> <julien.g...@gmail.com> wrote:
>>
>> James,
>> The "fat" ping from a publisher is definitely doable. Superfeedr does that
>> with some of its publishers, but we need ways to enforce that nobody is
>> actually trying to forge the relationship. It's doable, but on a per
>> publisher basis, so I think the protocol is right to define a way that
>> _always_ work.
>> For the rest of the post, I'm not so competent, so I won't comment :D
>> Cheers!
>> On Thu, May 20, 2010 at 8:20 PM, James M Snell <jas...@gmail.com> wrote:
>>>
>>> Posted some thoughts here:
>>> http://www.snellspace.com/wp/2010/05/pubsubhubbub-thoughts
>>>
>>> DeWitt requested that I also post here to make sure it was seen.
>>> Hopefully the comments are useful.
>>>
>>> - James
>>
>
>

--
- James Snell
http://www.snellspace.com
jas...@gmail.com

[Bob Wyman]

On Fri, May 21, 2010 at 1:14 PM, James Snell <jas...@gmail.com> wrote:

On Thu, May 20, 2010 at 11:14 PM, Bob Wyman <b...@wyman.us> wrote:
> Right. As Julien says, the silliness with light-pings to the hub followed by
> polling for updates on the feed is only there in order to make it harder for
> people to spoof the system. There are a variety of alternatives to this
> approach, but a light-ping and fetch method it is certainly the simplest to
> implement and thus probably always needs to be supported even if more
> complex approaches are used.

Agreed. Definitely not advocating that light-pings not be included.

> Personally, I hope that we'll one day be able to see support for fat-pings
> using something like the signed entries that Salmon produces. (Actually, I
> would prefer if people would just use the DSig stuff that is defined in
> Atom, but the reality is that that approach simply seems too hard for many
> developers and I've given up on trying to convince anyone to use it. There
> are all sorts of problems with getting certificates, the canonicalization is
> hard, many elements are confusing, etc... The intent of Salmon's Magic
> Signatures is to make signing stuff as simple as conceivably possible
> without loosing too much of what a signature is supposed to do for you. I
> think it succeeds and I think Magic Sigs, with just a few minor extensions
> and support from WebFinger, will be able to handle the vast majority of
> signature needs -- although not all.)

Having implemented dsig and encryption support for Atom in Abdera, I 
don't buy the argument that it's too complicated. 

I agree that it DSig *isn't* all that hard. The problem is that it *seems* to be hard to people who aren't familiar with it. This is a question of perception, not reality. Unfortunately, it also reminds us of what every good marketer knows: "Reality is rarely relevant, it is perception that counts...)

 

The tooling support
for XML-DSig's isn't great, but any solution that adequately secures
Atom docs is going to suffer from many of the same fundamental issues.
Sure, we might be able to simplify the problem in various ways, but in
so doing we end up building a less secure system. That said... the
ability to digitally sign HTTP requests/responses independently of
Atom could likely make this a whole lot easier as it would move those
details out of the data format and keep us from having to muck around
with the XML at all.

Of course we must remember that digitally signed HTTP requests will only give us point-to-point assurance of integrity. The value of signed objects is that they can be passed through an arbitrarily long chain of potentially untrusted intermediaries and you can still trust the data that you receive. Certainly, signed HTTP request have a useful role to play -- but they are only a limited scope solution for the problems we have in fully distributed systems.