Re:

Rachel Blackman wrote:
> 
> On May 29, 2007, at 1:39 PM, Dave Cridland wrote:
> 
>>>> The resource is opaque, but technically so
is the whole JID.  I 
>>>> don't see the problem with making any part
of it look nice.
>>> My bare jid is my 'address' in xmpp and so not
opaque.
>>
>> No, sorry, it's still opaque. The user portion of
your bare jid does 
>> not mean anything outside the context of your bare
jid, and means 
>> little to anyone outside your domain except as an
opaque string. For 
>> some reason, though, we're all happy to have
usernames that are human 
>> readable, and moreover human identifiable. Perhaps
we should make all 
>> those be hex digits - it might save us from
identity theft, so there's 
>> a solid, security-based reasoning here.
> 
> C'mon, be serious, folks.  (And this is nothing
personal, Dave, but you 
> just happened to be the post I'm replying to here.)
> 
> My JID (or XID, or XMPP End-Point Identifier or
whatever the current 
> Politically Correct term is) is far more important than
a resource.  
> Let's get away from that argument; I'm not going to
hand out 
> 'sparksjabber.org/Trillian' or 'sparksjabber.org/Mobile' or 
> 'sparksjabber.org/Adium' as my JID to folks; I'm going to
just give 
> them 'sparksjabber.org' and be done with it.
> 
> The argument here is not that 'randomly generating
strings for each 
> session is good, so we should do more of it.'  The
argument here is that 
> a number of people have expressed concern that XMPP is
presently 
> vulnerable to 'presence leaking.'
> 
> Specifically, the argument is that the ability to guess
fully-qualified 
> JIDs and probe them will allow you to determine if the
person is online 
> on that resource or not.  Most of us (as has been
noted) do things like 
> 'Office' and 'Home' and 'Mobile' for our resources.  Or
just use the 
> client default resources (Trillian, Adium, etc.).  By
sending various IQ 
> packets to 'common' resources off a target JID, I can
watch for the 
> difference between the server's error response and a
real response (or 
> even a /different/ error response) from the client, and
thus determine 
> that the resource is, indeed, online and has a client
answering rather 
> than the server.
> 
> I don't know that I agree that this is a significant
security issue, but 
> I /do/ agree that if you accept the premise that it
/is/, the 
> human-readable and meaningful resources are a
liability.  The RFCs 
> provide for randomly-generated resources, and we have
-- or can define 
> -- XEPs to attach actual meaning to those resources. 
So it's a fairly 
> simple solution (compared to, say, forcing every server
to rewrite the 
> error messages from clients to match their own ordering
of tags, 
> specific responses, and so on).
> 
> If you disagree that this is a problem and think this
is being regarded 
> as standardsxmpp.org/mountain when we're actually on 
> standardsxmpp.org/molehill, that's great.
> 
> If you agree it's a problem and have an alternate
solution, that's great 
> too!

Well said, Rachel!

For those who are worried about the possibility of presence
leaks 
occurring as you have described, we have a solution: toggle
the "force 
the server to issue me a random resource" option in the
client.

For those who are not worried, as you were.

/psa