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