Yann, On Fri, 18 Dec 2009 10:20:21 +0100, Yann Leboulanger <[email protected]> wrote:
[skipped] >>>> I believe current spec does not allow disabling auto-archiving for >>>> particular contact + particular session :-( >>> >>> This is a big issue, and automatic archiving is almost impossible for >>> client that implement E2E (like Gajim) or every client that implements >>> GPG (nearly all jabber clients), or all clients that will implement the >>> XTLS encrupted session in the future!! >> >> In most these cases just putting<item jid='...' save='false'> in prefs >> should be fine: it's unlikely people would constantly switch E2E or GPG >> on >> and off between different sessions with the same client, so just >> disabling >> auto-archiving for them should be OK. However, I agree it's rather >> 'workaround', not a 'solution'. > > Yep, but at the end of the session, should we remove the <item> or not? > If if was there before the session, no we should not, if it wasn't, we > should. And if there was a rule saying save='true' we loose this > preference when we replace it with the save='false' rule. Yes, that's why I agreed it's 'workaround' but not 'solution' ;-) > But a solution could be that when we send a request to removing a > collection being recorded by the server (example 48) The server should > stop recording this session automatically, don't you think it could be > added to the spec? I think that might cover typical use cases, but might lead to problems in some (not really common, though?) scenarios. Suppose client negotiated OTR with some contact (due to E2E, GPG, or whatever reason), so it sent <remove jid='..' open='true'/> to the server and server remembered that it should not record messages for conversations with this contact during current session/conversation/stream (see below for terms discussion) anymore. Now, client during the same session/conversation/stream renegotiates parameters to not use OTR (f.e. they do not discuss anything secret anymore so they do not use E2E/GPG, or whatever else reason) - but client cannot use auto-archiving with this contact anymore because it can only disable it via <remove> command and has no way to enable it back other than closing/reopening session/conversation/stream. >>>> [...] (Or you can just issue >>>> <remove> command at the end of conversation, but it looks like a hacky >>>> way >>>> of doing things) >>> >>> Indeed the last solution is not a good idea at all and is a big security >>> issue. First one is the less annoying workaround, but isn't a good >>> solution I think. >> >> Not really sure why the last solution is bigger security issue than >> passing unencrypted messages via the server in the first place, but that >> probably depends on what you mean by 'security issue' here (no objections >> to "not a good idea" part, though ;-) > > it's a security issue because if the connection or client crashes before > we remove it, we stored a chat that we agreed to not store. But if server is malicious (either due to malicious admin or just because it was compromised or due to any other reason) it does not make any difference if this chat was removed or not - in fact it does not matter if it was stored at all or not because it was possible to intercept it right in the process of chat without resorting to archiving at all. The fact that chat remained stored on server while it should not have been of course lowers security (as it means compromising server after chat was finished would still allow accessing its contents), but the fact that unencrypted messages passed through untrusted server made security level equal to zero from the beginning, so IMHO there's no sense in saying there's any additional 'security issue' here - if anyone cared about security, they should have been using E2E + cryptographic OTR, not the "fake" one provided by XEP-136. >> Yes, I'm all for it - I do not argue that there might be scenarios where >> it can be important, it's just that I haven't encountered them myself, so >> I >> had no real interest in diving deeper here. > > GPG chat are quite common, no? Possibly, but I have yet to see at least one contact in my roster supporting it ;-) >> Just several quick ideas on how it could be implemented (please give your >> ideas also!): >> * Allow having several<auto> elements with additional 'jid' attribute, >> such as<auto jid='[email protected]' save='false'/> to disable >> server-side >> auto-archiving for particular session. > > hmm I'm not sure it's a good solution, because a session is not a jid. I > technically have 2 sessions open with a jid, one that I want to log, and > one not. And those optins should not be saved permanently on server, > because it's a temporary preference. I may want to archive next session > with this jid. Let me clarify some things here to avoid confusion: 1) "Session" was bad term here, sorry about that :-( What you mean by "session" is most likely session in XEP-155 sense, right? What I meant was "stream" (= "XMPP stream between client and server"). Also note that "session" is not the "set of messages between client and contact forming single collection" - that is called "conversation" in XEP-136 and is wider than "session" because it might contain messages which are not part of any formally negotiated session and even lack common <thread> element. 2) <auto> setting in current XEP-136 spec applies to stream, it is not stored permanently, so its value is lost when stream is re-opened, see section 6, after "Otherwise:" words. What you seem to imply here and below is that you'd like to have finer control for auto archiving than at level "stream + contacts" - you'd like to control things at session/conversation + contacts level, did I understand you correctly? While some scenarios certainly could benefit from that, personally for me it looks like complicating things too much: many clients still lack support even for <thread> element (not even speaking of session negotiations), so it's not clear at all how to define and reference different conversations to manage auto-archiving for them. >> * Allow<item> element to have a 'scope' attribute with possible values >> 'global' and 'session', and those with scope='session' should be >> discarded >> as soon as session is closed, while 'global' ones behave exactly like >> they >> do now. > > I think that can cover what clients need: If negociation say to not log > the conversation, we add a rule with the full jid, scope=session and > save=false, but from a server point of view, it will be hard to guess > then a chat session will end. Will it have to check all messages and > check that thread id won't change? See above - I didn't mean here conversations tracking, I meant to use it for stream-wide control. > What about what I proposed earlier: > we use the stanza from example 48: > <iq type='set' id='remove6'> > <remove xmlns='urn:xmpp:archive' [skipped] See above. Besides that, if you want to apply it at conversation level the additional problem is lack of easy way to track conversations and hence lack of clear conditions when recording will be resumed. >> Personally I like the approach with 'scope' attribute more because I was >> going to suggest adding it to spec for<auto> element anyway, so that >> auto-archiving mode could be turned on persistently rather than for >> current >> session only. > > if I set <auto save='true'/> that already mean that autoarchiving is > turned on permanently, no? No, see above. -- Good luck! Alexander
