if 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
moparisthebest
yikes, can anyone read that without cringing? :P
Zash
Not even gonna try
Ge0rG
is it my copy&paste-fu, or is that link a 404?
Ge0rG
oh, it's the former.
moparisthebest
you know you want to read it Zash haha
Alexhas joined
Ge0rG
moparisthebest: I wonder if the icon is supposed to represent a trojan horse or my little pony.
edhelas
Ge0rG, both
Ge0rG
This is the Total Data Protection! /:=O
ralphmhas left
artyhas left
dwd
That one is so hyperbolic.
Lancehas joined
soulhas left
soulhas joined
ralphmhas left
Zashhas joined
mark.erdhas joined
edhelas
XMPP Compliance Suites 2016 <3
edhelas
would be really nice to have the validation system to promote the apps that are compatibles
SamWhited
Just 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
SamWhited
Probably going to add stream compression, EXI, and push notifications at least at various levels.
edhelas
For Movim it's a bit weird actually, because I'm not really a web client, but not a "IM" client as well
SamWhited
Is movim that social networking thing?
Zash
SamWhited: Don't we consider stream compression horribly insecure nowdays?
edhelas
SamWhited, yup
edhelas
basically it's a "webmail" but for XMPP
SamWhited
Zash: probably, I don't buy it though as long as you do a full flush on stanza boundaries
SamWhited
I don't buy that it's a problem, that is.
SamWhited
I guess that will probably come up when the discussion about moving it forward happens though, so good to start thinking about.
Zash
Well it's gone from the next Prosody fwiw
Holger
SamWhited: I don't know whether or not it's a problem, but it doesn't sound essential for interop/UX to me.
SamWhited
Holger: It helps a lot on mobile when you have a X000 person roster.
Holger
You have too many friends.
Zash
SamWhited: Even with various CSI optimizations?
Link Mauve
edhelas, Movim definitely is both a web client and an IM client.
SamWhited
Coworkers, but yah, we (Atlassian) aren't even one of our (HipChat's) bigger groups.
soulhas left
soulhas joined
SamWhited
Zash: Not sure about that; wish I could convince them to let me deploy my implementation.
edhelas
Link Mauve, yeah but all the XMPP part is done server side, with a stable and good Internet connection
SamWhited
edhelas: Does Movim not make an XMPP connection to the server?
edhelas
Holger, I have ~300 contacts in my roster, some clients really have issues to process it :p
edhelas
SamWhited, it does but server side, basically you have
edhelas
User Browser <- HTML + Websocket -> Web Server <- Pure XMPP TCP/TLS -> XMPP Server
Holger
edhelas: I guess compression won't help those clients though :-)
SamWhited
edhelas: 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 Mauve
315 here, and my main client is really slow at processing their presence. ^^'
SamWhited
Unless your HTML+Websocket connection isn't XMPP? I'm still confused.
Holger
Everyone has more friends than me.
edhelas
no it's pure "web" websocket, there is no XMPP at all browser side
edhelas
as I said, Movim is a "webmail" for XMPP
SamWhited
Oh yah, wouldn't apply then I guess
dwd
FWIW, compression is fine and perfectly safe in some cases; but they're oddball ones.
edhelas
ok :p
edhelas
Link 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 :)
edhelas
the roster is actually read in one time and saved in one request in the DB
SamWhited
As it should be. If you ever find yourself writing "for whatever { dbcall }" you're probably doing it wrong.
SamWhited
Build the query, then execute, or you're going to have scaling problems later :)
Link Mauve
edhelas, I expect your parsing to be way less heavy than slixmpp’s. :)
Link Mauve
Also, 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
Flow
I still consider stream compression essential for mobile connections
Flow
Also 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
Flow
Happy to be proven otherwhise and told if this still would be a security issue
Fabianhas joined
dwdhas left
SamWhited
What Flow said ⤴
edhelashas left
Flow
s/not only stanza boundary/not on stanza boundaries/
Flow
the idea is that you can keep the compression dict state as long as you are sending stanzas to the same entity
Link Mauve
I’d be interested in having that in Prosody.
Link Mauve
Especially for s2s, since broadcasting a stanza to many people is very slow on ADSL.
Link Mauve
And very often you send many stanzas to the same server in a row.
Link Mauve
Even better, many similar stanzas.
dwdhas left
dwdhas left
edhelashas joined
Guushas left
goffihas left
dwdhas left
xnyhps
Compressing single stanzas could allow attackers to discover your real JID to others in semi-anonymous rooms if they can observe the encrypted stanza size.
xnyhps
s/to others/
xnyhps
But that's very little payoff for how much access you need.
Fabianhas left
Flow
xnyhps: So no big worries with having compression this way from your side?
intosihas left
intosihas joined
xnyhps
You 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
Flow
well we coud register a new compression algo like 'zlib-secure'
Flowhas left
mark.erdhas joined
xnyhps
I 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
xnyhps
With any relatively modern ciphersuite there's at least 41 bytes of overhead per record, the maximum would be ~85 bytes with AES-CBC + SHA384.
SamWhited
Agree 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)
SamWhited
I'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
Tobias
stpeter, what are the plans for https://github.com/stpeter/xmppdotnet/ ? expanding the team that processes those PRs?