XSF Discussion - 2016-05-18


  1. Tobias has left

  2. stpeter has left

  3. arty has left

  4. arty has joined

  5. Kev has left

  6. Tobias has joined

  7. Kev has left

  8. google-is-lord has joined

  9. intosi has joined

  10. Guus has left

  11. Sonny has left

  12. Sonny has joined

  13. Sonny has left

  14. Sonny has joined

  15. Sonny has left

  16. rnx has left

  17. google-is-lord has joined

  18. rnx has joined

  19. waqas has left

  20. intosi has left

  21. rnx has left

  22. ralphm has left

  23. google-is-lord has joined

  24. Lance has joined

  25. Tobias has left

  26. Tobias has left

  27. dwd has left

  28. dwd has left

  29. dwd has left

  30. dwd has left

  31. Lance has joined

  32. Lance has joined

  33. Zash has left

  34. Lance has joined

  35. intosi has joined

  36. dwd has left

  37. dwd has left

  38. xnyhps has left

  39. Fabian has joined

  40. Guus has left

  41. bjc has left

  42. bjc has joined

  43. daurnimator has joined

  44. google-is-lord has joined

  45. Guus has left

  46. Fabian has left

  47. narcode has left

  48. Guus has left

  49. xnyhps has left

  50. arty has left

  51. mikl has joined

  52. Flow has joined

  53. dwd has left

  54. dwd has left

  55. Ashley Ward has joined

  56. ralphm has left

  57. daurnimator has left

  58. arty has joined

  59. intosi has left

  60. goffi has joined

  61. georg has joined

  62. georg has left

  63. georg has joined

  64. intosi has joined

  65. xnyhps has left

  66. intosi has left

  67. google-is-lord has joined

  68. xnyhps has left

  69. xnyhps has left

  70. mikl has left

  71. mikl has joined

  72. georg has left

  73. xnyhps has left

  74. lloyd has left

  75. lloyd has joined

  76. xnyhps has left

  77. Kev has left

  78. Kev has left

  79. boothj5 has joined

  80. Tobias has left

  81. Tobias has left

  82. Tobias has left

  83. Tobias has left

  84. Kev has joined

  85. intosi has joined

  86. rnx has joined

  87. Kev has left

  88. Kev has left

  89. Kev has joined

  90. Kev has left

  91. Kev has left

  92. Kev has joined

  93. Kev has left

  94. Kev has left

  95. daurnimator has joined

  96. Kev has joined

  97. Tobias has joined

  98. boothj5 has left

  99. xnyhps has left

  100. Tobias has joined

  101. Tobias has joined

  102. Kev has left

  103. Kev has left

  104. Kev has joined

  105. intosi has joined

  106. Kev has left

  107. Kev has left

  108. Kev has joined

  109. Kev has left

  110. xnyhps has left

  111. Sonny has joined

  112. winfried has joined

  113. Kev has joined

  114. Kev has left

  115. intosi has left

  116. Tobias has left

  117. Kev has joined

  118. Kev has left

  119. Kev has joined

  120. mhterres has joined

  121. dwd has left

  122. bjc has left

  123. mikl has left

  124. mikl has joined

  125. Kev has left

  126. Sonny has left

  127. Sonny has joined

  128. Ashley Ward has left

  129. Kev has left

  130. Alex has joined

  131. Ashley Ward has joined

  132. mhterres has left

  133. narcode has joined

  134. edhelas has joined

  135. google-is-lord has joined

  136. Zash has left

  137. Zash has joined

  138. mhterres has joined

  139. Alex has left

  140. ralphm has left

  141. Ashley Ward has left

  142. intosi has joined

  143. bjc has joined

  144. Lance has joined

  145. waqas has joined

  146. Sonny has left

  147. Sonny has left

  148. Guus has left

  149. Sonny has left

  150. intosi has left

  151. Sonny has left

  152. moparisthebest

    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

  153. stpeter has joined

  154. moparisthebest

    yikes, can anyone read that without cringing? :P

  155. Zash

    Not even gonna try

  156. Ge0rG

    is it my copy&paste-fu, or is that link a 404?

  157. Ge0rG

    oh, it's the former.

  158. moparisthebest

    you know you want to read it Zash haha

  159. Alex has joined

  160. Ge0rG

    moparisthebest: I wonder if the icon is supposed to represent a trojan horse or my little pony.

  161. edhelas

    Ge0rG, both

  162. Ge0rG

    This is the Total Data Protection! /:=O

  163. ralphm has left

  164. arty has left

  165. dwd

    That one is so hyperbolic.

  166. Lance has joined

  167. soul has left

  168. soul has joined

  169. ralphm has left

  170. Zash has joined

  171. mark.erd has joined

  172. edhelas

    XMPP Compliance Suites 2016 <3

  173. edhelas

    would be really nice to have the validation system to promote the apps that are compatibles

  174. 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

  175. mark.erd has left

  176. SamWhited

    Probably going to add stream compression, EXI, and push notifications at least at various levels.

  177. edhelas

    For Movim it's a bit weird actually, because I'm not really a web client, but not a "IM" client as well

  178. SamWhited

    Is movim that social networking thing?

  179. Zash

    SamWhited: Don't we consider stream compression horribly insecure nowdays?

  180. edhelas

    SamWhited, yup

  181. edhelas

    basically it's a "webmail" but for XMPP

  182. SamWhited

    Zash: probably, I don't buy it though as long as you do a full flush on stanza boundaries

  183. SamWhited

    I don't buy that it's a problem, that is.

  184. SamWhited

    I guess that will probably come up when the discussion about moving it forward happens though, so good to start thinking about.

  185. Zash

    Well it's gone from the next Prosody fwiw

  186. Holger

    SamWhited: I don't know whether or not it's a problem, but it doesn't sound essential for interop/UX to me.

  187. SamWhited

    Holger: It helps a lot on mobile when you have a X000 person roster.

  188. Holger

    You have too many friends.

  189. Zash

    SamWhited: Even with various CSI optimizations?

  190. Link Mauve

    edhelas, Movim definitely is both a web client and an IM client.

  191. SamWhited

    Coworkers, but yah, we (Atlassian) aren't even one of our (HipChat's) bigger groups.

  192. soul has left

  193. soul has joined

  194. SamWhited

    Zash: Not sure about that; wish I could convince them to let me deploy my implementation.

  195. edhelas

    Link Mauve, yeah but all the XMPP part is done server side, with a stable and good Internet connection

  196. SamWhited

    edhelas: Does Movim not make an XMPP connection to the server?

  197. edhelas

    Holger, I have ~300 contacts in my roster, some clients really have issues to process it :p

  198. edhelas

    SamWhited, it does but server side, basically you have

  199. edhelas

    User Browser <- HTML + Websocket -> Web Server <- Pure XMPP TCP/TLS -> XMPP Server

  200. Holger

    edhelas: I guess compression won't help those clients though :-)

  201. 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)

  202. Link Mauve

    315 here, and my main client is really slow at processing their presence. ^^'

  203. SamWhited

    Unless your HTML+Websocket connection isn't XMPP? I'm still confused.

  204. Holger

    Everyone has more friends than me.

  205. edhelas

    no it's pure "web" websocket, there is no XMPP at all browser side

  206. edhelas

    as I said, Movim is a "webmail" for XMPP

  207. SamWhited

    Oh yah, wouldn't apply then I guess

  208. dwd

    FWIW, compression is fine and perfectly safe in some cases; but they're oddball ones.

  209. edhelas

    ok :p

  210. 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 :)

  211. edhelas

    the roster is actually read in one time and saved in one request in the DB

  212. SamWhited

    As it should be. If you ever find yourself writing "for whatever { dbcall }" you're probably doing it wrong.

  213. SamWhited

    Build the query, then execute, or you're going to have scaling problems later :)

  214. Link Mauve

    edhelas, I expect your parsing to be way less heavy than slixmpp’s. :)

  215. Link Mauve

    Also, Python is slow.

  216. mathieui

    :D

  217. daurnimator has left

  218. Sonny has left

  219. mikl has left

  220. Sonny has left

  221. Alex has joined

  222. stpeter has joined

  223. Neustradamus has joined

  224. stpeter has joined

  225. Alex has joined

  226. Neustradamus has joined

  227. xnyhps has left

  228. Zash has left

  229. Flow

    I still consider stream compression essential for mobile connections

  230. 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

  231. Guus has left

  232. Flow

    Happy to be proven otherwhise and told if this still would be a security issue

  233. Fabian has joined

  234. dwd has left

  235. SamWhited

    What Flow said ⤴

  236. edhelas has left

  237. Flow

    s/not only stanza boundary/not on stanza boundaries/

  238. Flow

    the idea is that you can keep the compression dict state as long as you are sending stanzas to the same entity

  239. Link Mauve

    I’d be interested in having that in Prosody.

  240. Link Mauve

    Especially for s2s, since broadcasting a stanza to many people is very slow on ADSL.

  241. Link Mauve

    And very often you send many stanzas to the same server in a row.

  242. Link Mauve

    Even better, many similar stanzas.

  243. dwd has left

  244. dwd has left

  245. edhelas has joined

  246. Guus has left

  247. goffi has left

  248. dwd has left

  249. 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.

  250. xnyhps

    s/to others/

  251. xnyhps

    But that's very little payoff for how much access you need.

  252. Fabian has left

  253. Flow

    xnyhps: So no big worries with having compression this way from your side?

  254. intosi has left

  255. intosi has joined

  256. xnyhps

    You can't easily detect if the server is doing the same, so I still think it's a bad idea.

  257. waqas has left

  258. dwd has left

  259. intosi has left

  260. intosi has joined

  261. Flow

    well we coud register a new compression algo like 'zlib-secure'

  262. Flow has left

  263. mark.erd has joined

  264. 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.

  265. dwd has left

  266. 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.

  267. 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)

  268. 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.

  269. 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)

  270. narcode has left

  271. mark.erd has left

  272. waqas has joined

  273. Tobias has joined

  274. Ge0rG has left

  275. Ge0rG has left

  276. Sonny has left

  277. dwd has left

  278. Tobias has left

  279. dwd has joined

  280. Ge0rG has joined

  281. mark.erd has joined

  282. Ge0rG has joined

  283. Zash has left

  284. mark.erd has left

  285. Alex has left

  286. Alex has joined

  287. Sonny has left

  288. Alex has left

  289. xnyhps has left

  290. Sonny has left

  291. Sonny has left

  292. Sonny has left

  293. waqas has left

  294. waqas has joined

  295. Lance has joined

  296. kalkin has joined

  297. google-is-lord has joined

  298. lloyd has left

  299. Sonny has left

  300. kalkin has joined

  301. kalkin has left

  302. kalkin has joined

  303. edhelas has left

  304. arty has joined

  305. google-is-lord has joined

  306. mhterres has left

  307. Ge0rG has left

  308. intosi has joined

  309. Neustradamus has left

  310. Neustradamus has joined

  311. Sonny has left

  312. Sonny has left

  313. lloyd has joined

  314. ralphm has left

  315. moparisthebest has left

  316. Tobias

    stpeter, what are the plans for https://github.com/stpeter/xmppdotnet/ ? expanding the team that processes those PRs?

  317. intosi has joined

  318. Ashley Ward has joined

  319. Sonny has left

  320. Lance has joined

  321. stpeter has left

  322. moparisthebest has joined

  323. intosi has joined

  324. moparisthebest has joined

  325. dwd has joined

  326. Ashley Ward has left

  327. dwd has left

  328. dwd has joined

  329. dwd has left

  330. dwd has joined

  331. Tobias has left

  332. kalkin has left

  333. kalkin has joined

  334. andrey.utkin has left

  335. andrey.utkin has left

  336. Holger has left

  337. Holger has joined

  338. andrey.utkin has joined

  339. Sonny has left

  340. intosi has joined

  341. dwd has left

  342. bjc has left

  343. dwd has joined

  344. dwd has left

  345. Sonny has left

  346. Sonny has joined

  347. intosi has joined

  348. google-is-lord has joined

  349. Kev has left

  350. stpeter has left