Re: [Standards] Proposed XMPP Extension: HTTP File Upload
On Fri, Jul 31, 2015 at 1:25 AM, Mickaël Rémond wrote: > I think what we had implemented covers all this: > https://github.com/processone/ejabberd-saas-docs/blob/master/http-filetransfer/http-filetransfer.md > > Here is what you have in mind ? > Anything else missing ? I don't see any mention of headers in your document, except for Content-MD5, (though it does cover the case where you can request a file's GET url from the server). > If you want I can try to propose a patch on HTTP file upload proto XEP based > on some of these ideas, but I would like to be sure this is helpful. I'd like that, but I'm not sure if Daniel would :) I know he really wants to keep it simple. I see generic headers as something that are almost a requirement to make this useable though. Otherwise it only works for the most simple cases (eg. small XMPP servers that want to run their own simple storage). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] XEP-0313 MAM implementation for MUC
Hello, On 31 Jul 2015, at 18:31, Daniel Gultsch wrote: So, I think it may be interesting and more flexible to state that the from attribute will contain the room/nick JID and to add a special tag for real JID. For consistency, we can reuse the same approach we have for presence on non-anonymous room: x tag with xmlns http://jabber.org/protocol/muc#user Yes I had the very same problem when implementing MUC-MAM on the client side. I had very brief discussions with some people at that time but we never got to a point where we could actually implement stuff. Our (or my) conclusions from back then are: The real jid should be included if the mam requester is the original sender of that message or if at the time the message was written the mam requester would have had access to the real jids. (non-anonymous or requester was admin at that time) The last one will quite possible be impossible to achieve since you can not store historic room configurations. So I would suggest to take a more general / easier approach to send the real jid if the muc was non-anonymous back then and still is. (That prevents admins from discovering the real jid retrospectively but thats something we will have to live with I guess) I agree that it would be nice to keep the history of the MUC configuration, but isn't this an overkill requirement ? My point is that MAM MUC is a bit like static chat room page. A bit like: http://chatlogs.jabber.ru/ejabb...@conference.jabber.ru/2015/07/30.html but being marked with proper semantic, and with incremental retrieval. It means as a client developer, you can integrate archive coming from the server almost like standard messages. For that use case, handling the check at the time of access may be reasonable enough: If you are admin and can see JID now, you still can investigate an abuse yesterday for example. So, wouldn't the check being done at time of access to the archive be reasonable enough ? -- Mickaël Rémond http://www.process-one.net
Re: [Standards] XEP-0313 MAM implementation for MUC
Hello, On 31 Jul 2015, at 18:34, Daniel Gultsch wrote: > 2015-07-31 18:31 GMT+02:00 Daniel Gultsch : > >> As for namespaces I would probably reuse XEP-0033: Advanced stanza >> addressing http://xmpp.org/extensions/xep-0033.html >> > > > oh ok forget about this part. It doesn't have a from type Yes, that's what I reused muc#user. -- Mickaël Rémond http://www.process-one.net
Re: [Standards] XEP-0313 MAM implementation for MUC
2015-07-31 18:31 GMT+02:00 Daniel Gultsch : > As for namespaces I would probably reuse XEP-0033: Advanced stanza > addressing http://xmpp.org/extensions/xep-0033.html > oh ok forget about this part. It doesn't have a from type
Re: [Standards] XEP-0313 MAM implementation for MUC
Hi, 2015-07-31 17:49 GMT+02:00 Mickaël Rémond : > > We thus think that we need in some way include the room nick in the > message and only include the real JID if you have the right to access it, > to preserve the anonymous behaviour of the room. XEP-0045 says: "However, > the MUC service MUST NOT reveal the sender's real JID to the recipient at > any time, nor reveal the recipient's real JID to the sender." It is in IQ > section, but this is a good general principle. > > So, I think it may be interesting and more flexible to state that the from > attribute will contain the room/nick JID and to add a special tag for real > JID. For consistency, we can reuse the same approach we have for presence > on non-anonymous room: x tag with xmlns > http://jabber.org/protocol/muc#user > Yes I had the very same problem when implementing MUC-MAM on the client side. I had very brief discussions with some people at that time but we never got to a point where we could actually implement stuff. Our (or my) conclusions from back then are: The real jid should be included if the mam requester is the original sender of that message or if at the time the message was written the mam requester would have had access to the real jids. (non-anonymous or requester was admin at that time) The last one will quite possible be impossible to achieve since you can not store historic room configurations. So I would suggest to take a more general / easier approach to send the real jid if the muc was non-anonymous back then and still is. (That prevents admins from discovering the real jid retrospectively but thats something we will have to live with I guess) As for namespaces I would probably reuse XEP-0033: Advanced stanza addressing http://xmpp.org/extensions/xep-0033.html cheers Daniel P.S: We really need MUC2 so we don't have to bother about these kind of problems any more.
[Standards] XEP-0313 MAM implementation for MUC
Hello, While iterating on our MAM for MUC server-side implementation, we reached an issue on the following part of the XEP. 1. from in MUC archive: "When sending out the archives to a requesting client, the 'to' of the forwarded stanza MUST be empty, and the 'from' MUST be the occupant JID of the sender of the archived message." The original issue is that you cannot display the remote history as you would do with local history because: - On local history, you will have nickname, we are missing it here. - On local history (or during live chat while online) we may not have access to the real jid. We thus think that we need in some way include the room nick in the message and only include the real JID if you have the right to access it, to preserve the anonymous behaviour of the room. XEP-0045 says: "However, the MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender." It is in IQ section, but this is a good general principle. So, I think it may be interesting and more flexible to state that the from attribute will contain the room/nick JID and to add a special tag for real JID. For consistency, we can reuse the same approach we have for presence on non-anonymous room: x tag with xmlns http://jabber.org/protocol/muc#user An example archive message could be: to='jul...@capulet.lit/chamber'> from='co...@chat.shakespeare.lit/secondwitch' type='groupchat'> Thrice and once the hedge-pig whined. Forgive the Shakespeare mashup and inconsistencies :) Another more compact approach, implies putting the real from somewhere else. Example if we include such semantic on the forwarded tag (it would require changing spec for 'urn:xmpp:forward:0', maybe not ok, so just an example): to='jul...@capulet.lit/chamber'> real-from="ha...@shakespeare.lit/pda"> from='co...@chat.shakespeare.lit/secondwitch' type='groupchat'> Thrice and once the hedge-pig whined. 2. Filtering Regarding filtering, the criteria of the with attribute may also need to be clarified. As of now, it seems to be real JID of the sender. That case is clearly interesting for admin user, investigating abuse, but I think this parameter should alternatively (even primarily) accept the room/nick criteria. How does it sounds ? Do you see other way for solving original issue ? Thanks ! -- Mickaël Rémond http://www.process-one.net
[Standards] Source control links
Just wanted to notify that the link for the Git mirror is outdated: http://xmpp.org/about-xmpp/xsf/xsf-source-control/ I think you've migrated to GitHub, right? -- Daniele
Re: [Standards] OpenPGP and XEP-0027
On 31/07/2015 10:27, Daniele Ricci wrote: Hello Goffi, XEP-0027 has serious security concerns, especially regarding reply attacks and key verification (you can read those in the "Security considerations" paragraph of the XEP). It's true that a real replacement hasn't been drafted yet (there are some drafts, but nothing really definitive or practical to use). In my project I use a modified version of XEP-0027, using XEP-0189 for key management (supervised by the server). I took an example from an e2e RFC draft (I really can't remember the number now, sorry), which used Message/CPIM to enforce message metadata inside the encrypted content. That's a bit more secure than plain XEP-0027, still there are many other attack vectors that can be used. I'll probably draft a XEP one day. As for making XEP-0027 obsolete, that XEP is just informative: it's the description of a protocol that was never standardized and as I said it had security issues from the beginning. But at the time, security was a different thing ;-) OK, I understand. That means that OpenPGP use with XMPP is not discarded and we just need a proper and more secure XEP. I would be really interested if you publish a protoXEP one day. Thanks for your answer. Goffi
Re: [Standards] OpenPGP and XEP-0027
Hello Goffi, XEP-0027 has serious security concerns, especially regarding reply attacks and key verification (you can read those in the "Security considerations" paragraph of the XEP). It's true that a real replacement hasn't been drafted yet (there are some drafts, but nothing really definitive or practical to use). In my project I use a modified version of XEP-0027, using XEP-0189 for key management (supervised by the server). I took an example from an e2e RFC draft (I really can't remember the number now, sorry), which used Message/CPIM to enforce message metadata inside the encrypted content. That's a bit more secure than plain XEP-0027, still there are many other attack vectors that can be used. I'll probably draft a XEP one day. As for making XEP-0027 obsolete, that XEP is just informative: it's the description of a protocol that was never standardized and as I said it had security issues from the beginning. But at the time, security was a different thing ;-) On Fri, Jul 31, 2015 at 10:16 AM, Goffi wrote: > G'day, > > I have a few questions about OpenPGP. XEP-0027 has been obsoleted by council > on 26/03/2014, but I can't see no explanation. > > OpenPGP is not the best for instant messaging (and OTR is the de facto > standard), but still it's interesting for normal messages (e.g. with an SMTP > gateway), and signatures, and offline messages, and probably other use > cases. > In addition, it would be nice to have a way to link the public key. > > So why OpenPGP has been obsoleted ? Is is still possible to see it coming > back throught eventually a new more proper XEP ? I don't mean use it as the > main e2e encryption model, but being able to use it with gateways or to > diffuse the public key seems important to me. > > Thanks > Goffi -- Daniele
[Standards] OpenPGP and XEP-0027
G'day, I have a few questions about OpenPGP. XEP-0027 has been obsoleted by council on 26/03/2014, but I can't see no explanation. OpenPGP is not the best for instant messaging (and OTR is the de facto standard), but still it's interesting for normal messages (e.g. with an SMTP gateway), and signatures, and offline messages, and probably other use cases. In addition, it would be nice to have a way to link the public key. So why OpenPGP has been obsoleted ? Is is still possible to see it coming back throught eventually a new more proper XEP ? I don't mean use it as the main e2e encryption model, but being able to use it with gateways or to diffuse the public key seems important to me. Thanks Goffi
