[Security] "Terms of use"

Peter Saint-Andre stpeter at stpeter.im
Sun Apr 5 19:38:08 CDT 2009

On 1/15/09 4:01 PM, mbecker wrote:
> Hello everyone!

Hi! Sorry about the slow reply.

> I came across XEP-0161: Abuse Reporting and I see a problem when it
> comes to terms like "generates large amounts of traffic" or
> "inappropriate use".

I don't know if we will use XEP-0161. At the XMPP Summit in February, we
talked about the need for server-to-server reporting of problems on the
network, rather than the user-generated reports from XEP-0161 (which I
agree are open to abuse).

> One idea would be to add an extension "Terms of use" where entities
> could exchange machine-readable information about what is acceptable use
> and what is meant by "too much traffic".
> Example:
> <acceptable use 
> appliesto="s2s|client|component" 
> usefortestingallowed="true|false" 
> messagemaxkbytes="integer" 
> stanzasmaxperminute="integer" 
> filtering="true|false"
> forwardtoclientenforcement="none|drop|warn|score"
> receivefromclientenforcement="none|drop|warn|score" 
> />

Interesting. I think the server would advertise this during stream
negotiation (as a stream feature).

> This approach would serve on serveral frontlines:
> 1. A server could enforce limitations for all clients connected in a
> "harsh" way since the rules are public. (Or not: Scoring a users
> traffic-behaviour could allow exceptions from rules.)
> 2. Servers could check the policies of their s2s-counterparts and
> generate warnings for their clients or act in another way
> appropriately.
> 3. Clients could take such a policy and protect their users from
> violating policies "by accident". (As in: "War and Peace? Sure, let me
> paste this...")
> 5. (Some) Abuse reports as in XEP-0161 can be checked against hard
> facts.

Those are all good reasons to pursue an approach like this. Perhaps we
can build it into the s2s problem-reporting spec (because in that spec
we will define what the problems are). I have notes about this from our
meetings in Brussels but haven't yet found the time to write up an
initial draft. Soon, I hope.

Thanks for the ideas!


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20090405/1470c200/attachment.bin 

More information about the Security mailing list