[standards-jig] Security problems with JEP-115
Matthew A. Miller
linuxwolf at outer-planes.net
Thu Sep 18 14:43:19 UTC 2003
First, I would like you to *fully* explain how this allows one client
(client-A) to disable features of another client (client-B) (and not
simply allow client-B to "mask" capabilities to, or work differently
with, client-A). I just don't see that, so I would greatly appreciate
any detailed insight you can provide.
Second, this JEP does provide a bitmask (of sorts), via the "ext"
attribute. The JEP also outlines a number of rules on how it's applied
and used. Again, if this isn't adequate, detailed insight is greatly
As was previously stated, if you provide a another solution, we'll
consider it; if you provide a better solution, we'll use it! But in
this case, the call of "do nothing" just isn't enough.
Jacek Konieczny wrote:
>On Wed, Sep 17, 2003 at 01:41:22PM -0600, Peter Millard wrote:
>>Jacek Konieczny wrote:
>>>I think the idea of JEP-115 is totally wrong, but I know the intentions
>>When you shoot something down.. it's most constructive to offer some kind of
>IHMO it is better to no nothing, that do something very bad.
>>What do you propose to do?
>I think it would be better if client whould announce real feature list
>in their presence (although I don't like announcing anything that is not
>presence/availability in <presence/> stanza) than some hint which can be
>used to use information from other client. Asking some client for
>features of another client is not good. Of course regular disco reply is
>much to large for announcing in <presence/>, but if it would be reduced
>to some kind of bitmask (values whould have to be registered in JR) then
>the <presence/> packet whould not be much bigger than those proposed by
>Other solution would be not to ask random client, but some entity
>pointent by the <presence/> packet. This could be some jabber entity
>or eg. HTTP URL.
>Standards-JIG mailing list
>Standards-JIG at jabber.org
More information about the Standards