moparisthebestif only we could make XMPP use this new cipher "We created a cipher that is 6,000,000 times stronger than current data security, as proven by algorithmic mathematics." https://www.kickstarter.com/projects/datagatekeeper/datagatekeeper-the-first-impenetrable-anti-hacking
stpeterhas joined
moparisthebestyikes, can anyone read that without cringing? :P
ZashNot even gonna try
Ge0rGis it my copy&paste-fu, or is that link a 404?
Ge0rGoh, it's the former.
moparisthebestyou know you want to read it Zash haha
Alexhas joined
Ge0rGmoparisthebest: I wonder if the icon is supposed to represent a trojan horse or my little pony.
edhelasGe0rG, both
Ge0rGThis is the Total Data Protection! /:=O
ralphmhas left
artyhas left
dwdThat one is so hyperbolic.
Lancehas joined
soulhas left
soulhas joined
ralphmhas left
Zashhas joined
mark.erdhas joined
edhelasXMPP Compliance Suites 2016 <3
edhelaswould be really nice to have the validation system to promote the apps that are compatibles
SamWhitedJust updated to add a mobile compliance suite as well; suggestions for what should go in it are welcome: https://github.com/xsf/xeps/pull/185
mark.erdhas left
SamWhitedProbably going to add stream compression, EXI, and push notifications at least at various levels.
edhelasFor Movim it's a bit weird actually, because I'm not really a web client, but not a "IM" client as well
SamWhitedIs movim that social networking thing?
ZashSamWhited: Don't we consider stream compression horribly insecure nowdays?
edhelasSamWhited, yup
edhelasbasically it's a "webmail" but for XMPP
SamWhitedZash: probably, I don't buy it though as long as you do a full flush on stanza boundaries
SamWhitedI don't buy that it's a problem, that is.
SamWhitedI guess that will probably come up when the discussion about moving it forward happens though, so good to start thinking about.
ZashWell it's gone from the next Prosody fwiw
HolgerSamWhited: I don't know whether or not it's a problem, but it doesn't sound essential for interop/UX to me.
SamWhitedHolger: It helps a lot on mobile when you have a X000 person roster.
HolgerYou have too many friends.
ZashSamWhited: Even with various CSI optimizations?
Link Mauveedhelas, Movim definitely is both a web client and an IM client.
SamWhitedCoworkers, but yah, we (Atlassian) aren't even one of our (HipChat's) bigger groups.
soulhas left
soulhas joined
SamWhitedZash: Not sure about that; wish I could convince them to let me deploy my implementation.
edhelasLink Mauve, yeah but all the XMPP part is done server side, with a stable and good Internet connection
SamWhitededhelas: Does Movim not make an XMPP connection to the server?
edhelasHolger, I have ~300 contacts in my roster, some clients really have issues to process it :p
edhelasSamWhited, it does but server side, basically you have
edhelasUser Browser <- HTML + Websocket -> Web Server <- Pure XMPP TCP/TLS -> XMPP Server
Holgeredhelas: I guess compression won't help those clients though :-)
SamWhitededhelas: Yah, if it makes an XMPP connection to the server, I'd say that means it fits in the web compliance category (in the sense that you'll need either BOSH or websockets to connect, and you'll have to implement the XMPP subprotocol of one or the other presumably)
Link Mauve315 here, and my main client is really slow at processing their presence. ^^'
SamWhitedUnless your HTML+Websocket connection isn't XMPP? I'm still confused.
HolgerEveryone has more friends than me.
edhelasno it's pure "web" websocket, there is no XMPP at all browser side
edhelasas I said, Movim is a "webmail" for XMPP
SamWhitedOh yah, wouldn't apply then I guess
dwdFWIW, compression is fine and perfectly safe in some cases; but they're oddball ones.
edhelasok :p
edhelasLink Mauve, roster + presence processing need to be really well doneif you have a huge roster. It took me some time to have nice performance on Movim, now it process the ~500 stanza of the login in less than 1sec. All in pure PHP :)
edhelasthe roster is actually read in one time and saved in one request in the DB
SamWhitedAs it should be. If you ever find yourself writing "for whatever { dbcall }" you're probably doing it wrong.
SamWhitedBuild the query, then execute, or you're going to have scaling problems later :)
Link Mauveedhelas, I expect your parsing to be way less heavy than slixmpp’s. :)
Link MauveAlso, Python is slow.
mathieui:D
daurnimatorhas left
Sonnyhas left
miklhas left
Sonnyhas left
Alexhas joined
stpeterhas joined
Neustradamushas joined
stpeterhas joined
Alexhas joined
Neustradamushas joined
xnyhpshas left
Zashhas left
FlowI still consider stream compression essential for mobile connections
FlowAlso I've been working on Smack droping the compression dict state, not only stanza boundary, but on channel change. Where "channel change" means that the recipient bare jid has changed. I believe that this is the best trade-off between security and efficiency
Guushas left
FlowHappy to be proven otherwhise and told if this still would be a security issue
Fabianhas joined
dwdhas left
SamWhitedWhat Flow said ⤴
edhelashas left
Flows/not only stanza boundary/not on stanza boundaries/
Flowthe idea is that you can keep the compression dict state as long as you are sending stanzas to the same entity
Link MauveI’d be interested in having that in Prosody.
Link MauveEspecially for s2s, since broadcasting a stanza to many people is very slow on ADSL.
Link MauveAnd very often you send many stanzas to the same server in a row.
Link MauveEven better, many similar stanzas.
dwdhas left
dwdhas left
edhelashas joined
Guushas left
goffihas left
dwdhas left
xnyhpsCompressing single stanzas could allow attackers to discover your real JID to others in semi-anonymous rooms if they can observe the encrypted stanza size.
xnyhpss/to others/
xnyhpsBut that's very little payoff for how much access you need.
Fabianhas left
Flowxnyhps: So no big worries with having compression this way from your side?
intosihas left
intosihas joined
xnyhpsYou can't easily detect if the server is doing the same, so I still think it's a bad idea.
waqashas left
dwdhas left
intosihas left
intosihas joined
Flowwell we coud register a new compression algo like 'zlib-secure'
Flowhas left
mark.erdhas joined
xnyhpsI still think you can win a lot more (and actually reduce processing time and information leakage) by making sure stanzas that are sent simultaneously get into the same TLS record.
dwdhas left
xnyhpsWith any relatively modern ciphersuite there's at least 41 bytes of overhead per record, the maximum would be ~85 bytes with AES-CBC + SHA384.
SamWhitedAgree about sticking stanzas in the same TLS record, but I very much doubt you can convince most clients (or servers, for that matter) to try and optimize at that level. Would love to be proven wrong though (hint, hint, client/server developers)
SamWhitedI'm not sure a zlib-secure algo is needed; just require it in the spec in general and if you implement that version of the spec assume it's being done.
SamWhited(if it's not being done, that's a bug but it could equally not actually be happening if they advertised zlib-secure or something)
narcodehas left
mark.erdhas left
waqashas joined
Tobiashas joined
Ge0rGhas left
Ge0rGhas left
Sonnyhas left
dwdhas left
Tobiashas left
dwdhas joined
Ge0rGhas joined
mark.erdhas joined
Ge0rGhas joined
Zashhas left
mark.erdhas left
Alexhas left
Alexhas joined
Sonnyhas left
Alexhas left
xnyhpshas left
Sonnyhas left
Sonnyhas left
Sonnyhas left
waqashas left
waqashas joined
Lancehas joined
kalkinhas joined
google-is-lordhas joined
lloydhas left
Sonnyhas left
kalkinhas joined
kalkinhas left
kalkinhas joined
edhelashas left
artyhas joined
google-is-lordhas joined
mhterreshas left
Ge0rGhas left
intosi has joined
Neustradamushas left
Neustradamushas joined
Sonnyhas left
Sonnyhas left
lloydhas joined
ralphmhas left
moparisthebesthas left
Tobiasstpeter, what are the plans for https://github.com/stpeter/xmppdotnet/ ? expanding the team that processes those PRs?
XSF Discussion - 2016-05-18