On Mar 31, 2009, at 5:36 PM, Dave Cridland wrote:
On Tue Mar 31 16:00:20 2009, Pedro Melo wrote:
1) as much as you have right now: remote servers can do whatever
they want with your presence, you have no control after they leave
your own server (a pessimist would even say that you don't have
any control after they leave your client);
Well, there's trust, and responsibility. If a contact has an
outright evil server, there's little you can do - similarly if your
own server, or even client, is subverted. For things like this, it's
really game over. We generally choose to model a trusted client and
a trusted server, although we assume an untrusted server for content
in the case of e2e encryption.
But then there's responsibility - right now, it's inarguably your
local server which enforces who gets your presence, and a reverse-
roster lookup causes immediate problems there - if people don't get
to see your presence (or worse, do when they shouldn't), you've then
got two places to debug instead of one.
Yes, agreed. The multi-cast solution would change the responsibility
axis of the problem, not the security axis.
2) if subscription state gets out of sync, the protocol will
behave better or worse than the current version :), it really
depends which roster is correct. There was a thread 2 or 3 weeks
back with a tentative solution to keep subscription state in sync
using the initial <presence type="probe" />.
I'm not sure your initial analysis is correct, and it's related to
the above comments I make - if rosters are out of sync now, while
it's tricky to discover, you know where the blame lies instantly in
each case.
And a rough analysis suggests that in the current situation, you'll
either get presence when you *no longer* wanted it, or else you
won't get presence when you want it. With a reverse roster lookup,
it's possible to end up in a situation where you'll get presence
when the sender doesn't want you to, which is substantially worse,
and without any bad actor involved. (I could be wrong here, please
check this.)
if I accept your subscription (my server will move to 'both' or 'to')
but if that <presence type="subscribed"> does not reach you (you keep
'none' or 'to') then the remote fan-out is less revealing. I guess I
could also argue from your side and say that in that case I already
gave you permission to see so in principle I'm disclosing as much as I
wanted.
I do believe that out-of-sync rosters is a separate problem, and it
could be solved with a handshake between servers at presence-probe
time, but maybe thats the topic of another thread.
But let me clarify something: although the bandwidth and
processing savings of a multi-cast approach to presence
distribution should be relevant, I don't believe this is
compatible with a lot of other protocols that we have, so although
I think multi-cast presence is a worthy long-term goal, I don't
think we are ready to address it at this moment.
I'm not even convinced of this.
We have this famous thing about ~87% (the figure varies) of traffic
being presence, and I'm afraid I think these figures skew vastly the
moment compression takes effect, since, by the very nature of the
data we're sending, it compresses really well. In fact, I'm not sure
that it's even worth worrying about as a problem, given how well
this should compress.
My main concern is actually not bandwidth but processing cost. One
stanza, one access and sequential fetch to a index seems to be more
efficient that processing several stanzas.
I basically refuse to consider any solution seriously unless you're
measuring the effects of it post-compression - and I agree that's
hard.
Sure, and given that I actually think of this as an optimization for
overall processing cost, then it will be even more difficult to prove.
I guess I need to hack on some server to prove this hypothesis.
Best regards,
