[standards-jig] Discussion on JEP-0016: Server-Based Privacy Rules
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.
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
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.
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