On 06/04/2008 10:47 AM, Tim Julien wrote: > Peter Saint-Andre wrote: >> On 06/03/2008 2:14 PM, Maiku wrote: >>> In XEP-0176, Jingle using the ICE-UDP transport method, it says for >>> the initiator to send out the transport candidates either as soon as >>> getting the ACK from the session-initiate message or just as soon as >>> sending the session-initiate message, but I can't seem to find any >>> place that mentions where the responder's client would wait for the >>> responder to actually click to accept the session. Where would this >>> happen? Would the responder wait to send transport-info packets until >>> the user actually accepts? If not, wouldn't that be a security issue, >>> sending out your IP address to anyone who tries to start a session >>> with you? >> >> Maiku and I chatted about this via IM just now. I think it would make >> sense for the client to have a configuration setting such as "it's OK to >> share my personally identifying information (such as my network >> location) with people who can see my presence" [yeah yeah yeah that's >> long, shorten it as necessary!]. So if you share presence, your client >> will ack the session-initiate, return a ringing message, and start >> sending candidates. If you don't share presence, you would ack and send >> ringing but not share candidates until the user accepts the negotiation. >> >> Thoughts? > > One meta point that I think will help me understand (and Paul Witty, I > think) is: > > When you say "The user accepts the session", do you mean: > 1) user clicks an "accept" button b/c the phone is ringing.
Maiku meant (1) -- he's trying to figure out how to design the UI in Pidgin. > 2) the session-accept message is sent. > 3) both 1) and 2) > > That question aside, a few thoughts. > > Could we have a compromise where if someone is in your roster we assume > a certain amount of trust, and go ahead and exchange transport-info > before the call is accepted. Right, that's what I'm suggesting -- if you share presence with someone via presence subscription (which gets reflected in the rosteR), you probably think it's ok to share IP addresses with that person for the purpose of call setup. > And in the case where an incoming call is > from someone not in your roster, you delay sending transport-info until > the user has clicked accept. Where "clicked accept" means (1) from above. However I would not necessarily restrict sending transport candidates to situations where you have a presence subscription. For instance in XMPP you can exchange messages with someone even if you don't have a presence subscription. So you and I might have a message chat like that. And then as we chat away, one of us says "hey let's upgrade this message chat to voice chat". You know my full JID and I know your full JID because we've been chatting, so if you send me a voice chat request my client might automatically start sending candidates to you because we have a live message chat going. And I think that might be fine! Now, I happen to think it is a best practice to share directed presence (in the absence of a presence subscription) when you have a message chat with someone who's not in your roster, so in XEP-0176 we could say that it's OK to share candidates (and therefore IP addresses) before clicking the big "accept this call" button with someone you share presence with either through a formal subscription or through dynamic sharing of directed presence. > This would cut down on options / config. > It feels like this option won't be understood by your average user, plus > it seems like the only benefit is to slightly optimize transport > negotiation. Is it really worth the cost in spec. complexity, > implementation complexity, and user mind-share to configure the option? > I would say no, and if it really is a security concern, lets just err > on the side of being more secure and pick one way of doing it. Tying this to presence sharing (formal or dynamic) seems OK to me. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
