[standards-jig] Discussion on JEP-0016: Server-Based Privacy Rules

Shawn Wilton shawn at black9.net
Sun Jan 20 05:13:39 UTC 2002

I apologize, I've come in to this discussion late and should probably 
say nothing, but this looks just too damn interesting.  

Black Lists:
1.  Great because you specifically say who should NOT be heard from.
2.  Bad because you can "easily circumvent" by getting a new id.
3.  You could block a host by using a RBL.  This has several 
    advantages/disadvantages.  When you do this then you universally 
    block all kinds of people which means you need a way of taking
    people off that black list.  You speak of dhcp renewal.  Well,
    that black list could be set to block these dhcp addresses and 
    in the event this person becomes a particularly large pain in 
    the ass then you just contact their isp.  ISP's don't like
    spammers either.
4.  There's also the option of using a blacklist for one of two
    styles.  You could use it *just* to store the blacklist and let 
    the client do it itself, or you could force the server to do it.
    There has been discussion on the JNG lists of abstracting the
    server a level so that jabber becomes more of a routing protocol
    than an IM protocol (would become more useful).  To be honest
    I was pushing that =D.  However, I bring this up because when
    you force the server to do more work, it's user capacitance is
    reduced.  This should be seriously thought out.  Not to mention
    the fact it makes it much more difficult to do something besides
5.  The major obvious disadavantage here is that you use up the
    bandwidth that it takes to send that message out to a device.
    The question then becomes, how do you prevent this?  Honestly, 
    I don't think that you can prevent this using a blacklist.  If
    you really want to begin thinking about unsolicited messages then
    the solution becomes obvious, you *have* to use a whitelist and
    block by default.  No question about it.  If you don't, then
    you're always going to get that first message and then you're
    just forced to block afterwards.

If I were to choose the blacklisting style, I would say leave it up
to the client.  The server does enough work already.

White Lists:
1.  Nice because it's all blocked by default.
2.  Bad because you have to explicitly add someone to your roster 
    before they can send you a message.  Well, what if I don't want 
    you in my roster but don't mind if you send me messages?
3.  This shouldn't be too difficult to implement since the server 
    already does presence checking.  All you need to do is add in 
    the message checking.  It's simple, if you're not in my roster,
    the message doesn't go through.  You gotta get my permission to
    see me and to message me.
4.  When we stop to think about which packets to pass and not, it
    seems that the only thing that should not be stopped would be 
    presence packets.  Everything else would have to be halted.
    Otherwise we run the risk of new forms of spam/unwanted crap.
    It would really suck if you started getting spam in OOB's.  
5.  Overhead considerations should of course be thought of.  This 
    is certainly going to add overhead, but if we add this now, 
    then it can only get faster and more robust with time.

To me, this is the better choice.  There's no need for a blacklist
when I have to give you permission to send me a packet.  Overhead
considerations aside, this is the better choice.  So I propose 
this style solution be the one persued so we can get to optimizing.

More information about the Standards mailing list