On 04/02/2011, at 14:34, Evgeniy Khramtsov wrote: > 04.02.2011 02:02, Ben Schumacher wrote: >> On 1/30/11 8:26 PM, Evgeniy Khramtsov wrote: >>> What I really don't like in this XEP is that it contradicts the idea of >>> "keep clients simple". I think we can do the same using server-side >>> redirects (we have such error type already defined in the core RFC). In >>> that case a client just need to set a redirect and his/her contacts should >>> process presence redirects correctly. Also, redirects can be used for >>> temporary migration and not only for account removal. >> >> Attempting to "keep clients simple" shouldn't come before all other >> considerations. In this case I believe that using a redirect so greatly >> complicates the security model (not to mention the server implementation) >> that it's necessary to have some work on both sides. There is a widely held >> belief among protocol snobs that the email system's flexibility in this >> regard leads to a lot of the exploits that have made it so ripe for abuse. >> >> Being able to balance the work between the server and the client for XEP-283 >> means a user still has the ability to maintain their subscriptions while >> changing their username but is flexible and scalable enough to work in a >> globally federated environment and still gives the individual the >> opportunity to review any action before it is taken. > > Blah-blah-blah. Could you please be more specific? Especially for "using a > redirect so greatly complicates the security model".
Okay, say I have a friend Alfred, with JID [email protected]. Alfred gets his own domain, alfredrocks.net, & decides that he wants to change his JID to [email protected]. If the changeover is implemented by way of redirection at the server, everything is fine until some other Alfred who I don't know jumps in & grabs [email protected]. First, what if it turns out I know the second Alfred as well? My server already redirects [email protected] to [email protected] for the client, so what's it gonna tell my client when the actual [email protected] wants to talk? Second, what if I export my contacts client-side, start a new account, & import the contacts to this new account, sending out subscription requests? Suddenly I've lost my Alfred & subscribed to the other dude instead, & there's no way my client can tell me otherwise. The client needs to know if the JID changes.
smime.p7s
Description: S/MIME cryptographic signature
