On Fri, Feb 19, 2010 at 11:10 AM, ara.t.howard <[email protected]> wrote: > doesn't running on port 80 accepting a > super simple unsigned data format open me up to > getting unwanted messages? No, not really. Have you read the PSHB specification? Your server might experience some attempts to send unwanted messages, however, the PSHB protocol provides for "secret" tokens to be shared between hubs and subscribers. Thus, it is difficult to spoof a hub (although not impossible.) The ability to spoof will be made even harder once Salmon<http://www.salmon-protocol.org/>'s "magic signatures<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>" become broadly used (and they will be because they are so fantastically simple to implement!).
> computing is full of stories like this, where protocols > only tangentially address these issues and they > all are eventually exploited. You use these words to question my claim that a recipient-controlled routing system is less subject to spam... Well, I encourage you to carefully reconsider your position... By switching from "sender-controlled" to "recipient-controlled" routing, we're making a very fundamental change in the way messages flow through the network. This is the sort of architectural change that is directly, not "tangentially," addressing these issues. The result is a system that is fundamentally more difficult to spam. Consider that "spam" is usually defined as "unsolicited messages." However, in a recipient-controlled routing system, all messages are, in fact, "solicited." Recipients chose either whose messages to receive or describe the characteristics of messages that they wish to receive. No other messages will arrive unless either a sender has changed characteristics (e.g. been taken over by a hacker) or there is a bug in the implementation. This is *very* different from a sender-controlled system in which *all* messages are essentially unsolicited as far as the code is concerned. In a sender-controlled system, what you build on the recipient side is mechanisms to determine if a message is "acceptable" after the fact of receiving it. In a recipient-controlled system, the recipient need only describe what messages are desired -- if unwanted messages arrive, it is because the recipient's specification of what is desirable is flawed -- not simply because someone decided to send a message.. In a recipient-controlled system, if a sender ever changes characteristics and becomes undesirable, the recipient is free to simply stop asking for that sender's messages. Similarly, if a recipients interests change, they can instantly change the set of messages that will be delivered. This is not "tangentially" addressing the issue. This is making a fundamental architectural change in the nature of the relationship between senders and receivers. > - the spam thing is a red herring, no actual > security is built into the system. Re-read my comment above and re-read the specifications of PSHB and related protocols. In this claim, you are simply wrong. A recipient-controlled routing system is *inherently* more resistant to spam than a sender-controlled system is. > i wouldn't wish xmpp integration on anyone. Beware... This sort of cheap, toss-off comment makes it look like you might not be as familiar with the issues as you probably would like people to believe... On Fri, Feb 19, 2010 at 11:10 AM, ara.t.howard <[email protected]>wrote: > On Fri, Feb 19, 2010 at 01:52, Bob Wyman <[email protected]> wrote: > > finally a serious answer! > > > > > SMTP and PSHB implement fundamentally different message routing patterns. > > SMTP defines a method of implementing "sender controlled" message routing > > while PSHB defines a method of "recipient controlled" message routing. > > In a sender-controlled system, whether a message reaches a particular > node > > in the network is determined exclusively by message routing information > > attached to the message by the sender of the message. This implies, of > > course, that the sender of the message must know each of the eventual > > recipients of each message or at least proxies for those recipients (a > > "proxy" in this case would include things like mailing-list inboxes that > > then do further sender-controlled distribution of the message.) On the > other > > hand, in such a sender-controlled system, the potential recipients of > > messages have no means of discovering the set of all senders who might > send > > them messages. > > is this really true at a deep level? i mean, if need to postback data > via http, doesn't the process of dns discovery and network rounding > itself *exactly* suffer from all of the above flaws? doesn't running > on port 80 accepting a super simple unsigned data format open me up to > getting unwanted messages? we all put form verification tokens in our > html for this very reason... > > > > Also, recipients have no means of controlling the rate, flow, > > or content of messages received. > > hrm. i understand this somewhat - but this is also true of anyone > running a program on any open port, esp 80, as those of us who have > tried to lock down gov't web servers know. this seems more relative > than absolute but it definitely a possible major distinguisher. > > > > PubSubHubbub (PSHB) as a "PubSub" or publish/subscribe system implements > a > > recipient-controlled method of message routing. > > again - i think this is only true if you ignore DNS. this is not > trivial - you are probably aware of the security issues surrounding > OpenID as a result of depending on the this same system. this may > seem academic but i bring it up because it has a little bit of a > 'security through obscurity' smell to it - we all know if spammers > can, they will... > > > In such a system, the > > publisher only controls whether or not a message is available for > routing, > > not which endpoints or even if any endpoints actually receive the > message. > > In a PSHB system, who receives a message is determined exclusively by the > > recipients themselves. Publishers of messages have no means to determine > who > > the recipients are. (Note: This isolation of publishers from subscribers > is > > one of the key reasons that PubSub systems, in general, are much less > > subject to "spam" than sender-controlled systems. > > this really does seem dubious to me. i think we can be absolutely > certain that you need to be able to replace "less subject" to > "impossible to be subject to" (or close to) for people not to find a > work around just as soon as everyone on the internet is having their > news delivered to their readers via RSS. computing is full of stories > like this, where protocols only tangentially address these issues and > they all are eventually exploited. > > > > > If you're looking for protocols that should be considered as alternatives > to > > PSHB, you'd probably do better to look at NNTP (Network News Transfer > > Protocol) rather than SMTP. > > <snip> > > fair enough. i hadn't thought of NNTP actually... more food for thought. > > > > A better protocol than NNTP would be XMPP. This is particularly the case > if > > you were to implement the XEP-0060 Publish Subscribe protocol extension > to > > XMPP. This would give you a true "push" protocol with subscription > > management and everything else you need. However, you would discover > that a > > simple implementation of XEP-0060 would give you pretty much what you > have > > with PSHB today. You'd also discover that it was massively harder to get > > anyone to support what you had done since XMPP relies on continuous > > connections between servers and doesn't layer on top of HTTP they > virtually > > all other "modern" protocols do. > > <snip> > > indeed. i wouldn't wish xmpp integration on anyone. > > > I have personal experience implementing and using all of the protocols > defined > > here and frankly, I'm quite happy to see that PSHB has been able to do in > a > > very short period of time something that many of us in this business have > > been trying to get done for a very, very long time. > > cool. thanks very much spelling out your thoughts like that, it's the > best attempt anyone has bothered to make yet. > > here is where my mind is currently sitting: > > > - the spam thing is a red herring, no actual security is built into > the system. without being baked it my belief is that it will > immediately become a target for spammers to do the direct delivery > component and lack of sender verification methods. i realize it will > be much harder to spam, but it's far from impossible. > > - simplicity is potentially an edge, on paper, over existing > systems. but incompleteness of features and the barrage of features > being discussed which are re-inventions leave that an open question > which only time will answer. > > > thanks again for the detailed answer, really appreciate that! > > cheers. > > -- > -a > -- > be kind whenever possible... it is always possible - h.h. the 14th dalai > lama >
