XSF Discussion - 2018-06-11


  1. rtq3 has joined
  2. rtq3 has left
  3. Syndace has left
  4. jere has joined
  5. Syndace has joined
  6. la|r|ma has joined
  7. lskdjf has joined
  8. j.r has joined
  9. Lance has joined
  10. Lance has left
  11. alexis has left
  12. alexis has joined
  13. alexis has left
  14. j.r has joined
  15. alexis has joined
  16. dos has left
  17. jere has joined
  18. ta has left
  19. alexis has left
  20. alexis has joined
  21. alexis has left
  22. alexis has joined
  23. daniel has left
  24. daniel has joined
  25. anjan has left
  26. j.r has joined
  27. dos has joined
  28. j.r has joined
  29. dos has left
  30. j.r has joined
  31. SamWhited has left
  32. tux has left
  33. tux has joined
  34. j.r has joined
  35. rishiraj22 has left
  36. rishiraj22 has joined
  37. anjan has left
  38. alacer has left
  39. alacer has joined
  40. alacer has left
  41. waqas has joined
  42. j.r has joined
  43. j.r has joined
  44. Yagiza has joined
  45. ibikk has joined
  46. moparisthebest has left
  47. SamWhited has left
  48. mimi89999 has left
  49. mimi89999 has left
  50. matlag has left
  51. mimi89999 has joined
  52. lorddavidiii has joined
  53. SaltyBones has left
  54. j.r has joined
  55. lorddavidiii has left
  56. alexis has left
  57. alexis has joined
  58. lorddavidiii has joined
  59. SaltyBones has left
  60. lorddavidiii has left
  61. alexis has joined
  62. lorddavidiii has joined
  63. UsL has left
  64. UsL has joined
  65. SaltyBones has left
  66. alacer has joined
  67. goffi has joined
  68. alacer has left
  69. UsL has joined
  70. j.r has left
  71. j.r has joined
  72. rishiraj22 has left
  73. rishiraj22 has joined
  74. SaltyBones has left
  75. rishiraj22 has left
  76. rishiraj22 has joined
  77. rishiraj22 has left
  78. rishiraj22 has joined
  79. ralphm has left
  80. lnj has joined
  81. alexis has left
  82. alexis has joined
  83. alacer has joined
  84. alexis has left
  85. SaltyBones has left
  86. alexis has joined
  87. Zash has joined
  88. alacer has left
  89. Tobias has joined
  90. blabla has left
  91. igor75 has joined
  92. Guus has left
  93. Guus has left
  94. Ge0rG has left
  95. Wiktor has left
  96. Wiktor has joined
  97. UsL has joined
  98. j.r has joined
  99. andy has joined
  100. SaltyBones has left
  101. Guus has left
  102. Guus has left
  103. Guus has joined
  104. Guus has left
  105. Guus has left
  106. Guus has left
  107. Zash has left
  108. Zash has left
  109. Zash has joined
  110. Guus has left
  111. daniel has left
  112. intosi has left
  113. waqas has left
  114. Tobias has left
  115. Tobias has joined
  116. UsL has left
  117. UsL has joined
  118. jubalh has joined
  119. SaltyBones has left
  120. jubalh has left
  121. jubalh has left
  122. marmistrz has left
  123. jubalh has joined
  124. Dave Cridland has left
  125. Dave Cridland has joined
  126. Ge0rG moparisthebest: the ideas of the GDPR are slowly making it into US state legislation... https://www.schneier.com/blog/archives/2018/06/new_data_privac.html
  127. SaltyBones has left
  128. andy has left
  129. andy has joined
  130. Nekit has joined
  131. cookie has left
  132. rishiraj22 has left
  133. rishiraj22 has joined
  134. valo has joined
  135. anjan has joined
  136. Dave Cridland has left
  137. Dave Cridland has joined
  138. rtq3 has joined
  139. cookie has joined
  140. marmistrz has left
  141. SaltyBones has joined
  142. alexis has left
  143. alexis has joined
  144. rtq3 has left
  145. rtq3 has joined
  146. alexis has left
  147. alexis has joined
  148. ralphm has joined
  149. j.r has joined
  150. Nekit has left
  151. muppeth has left
  152. muppeth has joined
  153. Nekit has joined
  154. Ge0rG has left
  155. Nekit has left
  156. Nekit has joined
  157. jubalh has joined
  158. lumi has joined
  159. alexis has left
  160. alexis has joined
  161. rishiraj22 has left
  162. rishiraj22 has joined
  163. Dave Cridland has left
  164. Dave Cridland has joined
  165. Chobbes has joined
  166. Chobbes has joined
  167. alacer has joined
  168. rtq3 has left
  169. rtq3 has joined
  170. rishiraj22 has left
  171. rishiraj22 has joined
  172. mimi89999 has joined
  173. rishiraj22 has left
  174. rishiraj22 has joined
  175. Valerian has joined
  176. ralphm has left
  177. la|r|ma has joined
  178. SaltyBones has left
  179. daniel has left
  180. jubalh has joined
  181. rishiraj22 has left
  182. rishiraj22 has joined
  183. valo has joined
  184. Ge0rG has left
  185. rishiraj22 has left
  186. rishiraj22 has joined
  187. ralphm has joined
  188. Alex has joined
  189. Andrew Nenakhov has left
  190. Andrew Nenakhov has joined
  191. Andrew Nenakhov has left
  192. Andrew Nenakhov has joined
  193. daniel has left
  194. Andrew Nenakhov has left
  195. Andrew Nenakhov has joined
  196. daniel has left
  197. blabla has left
  198. blabla has joined
  199. Andrew Nenakhov has left
  200. Andrew Nenakhov has joined
  201. lskdjf has joined
  202. UsL US should do article 13 as well. It's awesome. It'll be the best internet.
  203. efrit has joined
  204. rion has left
  205. zak has joined
  206. Ge0rG Damn, 0308 is in Draft.
  207. jonasw what did you want to change?
  208. Valerian has left
  209. Valerian has joined
  210. Valerian has left
  211. Ge0rG jonasw: the biz rules. - allow modifications from other full JIDs of the same user - say that a correction that doesn't qualify shall be displayed like a normal message
  212. Ge0rG jonasw: #2 is what Klaus just adressed on standards@
  213. jonasw > A correction MUST only be allowed when both the original message and correction are received from the same full-JID.
  214. jonasw oh yes, this needs fixing
  215. jonasw whoever thought that was a great idea... possibly due to MUC.
  216. jonasw I think that any message which doesn’t qualify for the business rules is displayed normally is kinda implicit
  217. Valerian has joined
  218. rishiraj22 has left
  219. Kev > whoever thought that was a great idea MUC, mostly, but we can loosen the words for non-MUC.
  220. jonasw yeah
  221. efrit has left
  222. rainslide has joined
  223. rainslide Why not make GDPR support into a plugin?
  224. rishiraj22 has left
  225. vanitasvitae has left
  226. edhelas if only
  227. Ge0rG rainslide: one can not simply module:load legal compliance.
  228. rainslide I don't konw my Chinese forum uses which program, it show me a GDPR just now…
  229. rainslide GDPR can be spreaded though software😂
  230. alexis has left
  231. vanitasvitae <gdpr xmlns='urn:xmpp:legal:gdpr:0' compliant='true'/>
  232. alexis has joined
  233. MattJ "It showed me a GDPR just now" -> "a GDPR" is not a large pop-up
  234. lnj has left
  235. Seve/SouL Hey kid, got GDPR?
  236. edhelas vanitasvitae thanks for the tip! I'll enable it in my client now
  237. Ge0rG GDPR is a software-transmitted disease. A so-called STD.
  238. la|r|ma has joined
  239. daniel has left
  240. alexis has left
  241. alexis has joined
  242. daniel has joined
  243. lskdjf has left
  244. lskdjf has joined
  245. rainslide has left
  246. lskdjf has joined
  247. alexis has left
  248. alexis has joined
  249. alexis has left
  250. alexis has joined
  251. blabla has left
  252. alexis has left
  253. alexis has joined
  254. alexis has left
  255. alexis has joined
  256. pep. I guess for now we're at <gdpr xmlns='urn:xmpp:legal:gdpr:0' compliant='maybe' />
  257. Ge0rG My employer's website redirects you to `about:blank` if you deny the cookie popup. I was ashamed to find that out.
  258. Ge0rG I was even more ashamed when the DPO told me this is by design.
  259. pep. :(
  260. pep. Is it even allowed
  261. Ge0rG He said yes. We are not required to make business with people who don't want to be tracked.
  262. pep. great
  263. Alex has left
  264. lskdjf has left
  265. rtq3 has left
  266. rainslide has joined
  267. Wiktor IANAL but... > More importantly, organizations can't restrict website usability or services based on whether or not consent was granted. Source: http://www.dmnews.com/retail-week/gdpr-cookies-personal-data/article/738977/ > For example, a bank that asks for its customers’ consent to use their payment details for marketing purposes, but denies banking services or increases fees if consent is not granted, would be exerting inappropriate pressure. The GDPR does not absolutely prohibit offering services conditioned on consent to data processing, but per Recital 43, any consent so provided is presumed invalid, and the Working Party notes that “[valid] cases will be highly exceptional.” Source: https://iapp.org/news/a/top-10-operational-responses-to-the-gdpr-part-2-lawful-bases-for-processing/
  268. rishiraj22 has left
  269. rishiraj22 has joined
  270. alexis has left
  271. alexis has joined
  272. pep. Just like facebook's policy is not legal because it forces you into accepting their crap processing or nothing
  273. pep. But then IANAL either
  274. rtq3 has joined
  275. Wiktor yep, let's just prepare a lot of popcorn and see what happens to them :)
  276. rainslide has left
  277. daniel > My employer's website redirects you to `about:blank` if popup. I was ashamed to find that out. Isn't the real scandal that you can redirect to about: pages? That seems dangerous
  278. Ge0rG Wiktor: I agree with you here, but my two coworkers who have undergone GDPR training disagree.
  279. Ge0rG daniel: it's just a regular link
  280. pep. daniel, what's the issue with that
  281. pep. I can redirect you to file:///home/foo/bar, that doesn't mean I can do anything about it
  282. daniel pep.: I can't point my finger at something in particular. But that doesn't _right_
  283. Wiktor I know Ge0rG, I'm just trying to find supporting text for all these issues as I'm curious myself (but fortunately I don't have this problem now).
  284. Ge0rG pep.: you can check the color value of the link via JavaScript to see if you opened it in the past, and whether the file might exist :P
  285. pep. Ge0rG, interesting
  286. pep. Ge0rG, hmm, but I won't be able to do that via redirecting you there right
  287. pep. Ge0rG, hmm, but I won't be able to do that by redirecting you there right
  288. Wiktor Ge0rG: I think this was fixed in 2010: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
  289. rainslide has joined
  290. Ge0rG There are so many things in "the web" that undermine security, we should just bury it all in Lake Karachay
  291. rainslide > He said yes. We are not required to make business with people who don't want to be tracked. And they hire them, sometimes.
  292. alexis has left
  293. Ge0rG Wiktor: yes, but there is a gazillion of other side channels
  294. Wiktor Ge0rG: could you give an example?
  295. pep. daniel, what's interesting is the other way around, https://mathiasbynens.github.io/rel-noopener/
  296. alexis has joined
  297. Ge0rG Wiktor: https://arstechnica.com/information-technology/2018/05/chrome-and-firefox-leaks-let-sites-steal-visitors-facebook-names-profile-pics/
  298. Wiktor ah css mix-blend-mode
  299. Wiktor will probably be fixed just like leaking :active
  300. Ge0rG Wiktor: https://www.bleepingcomputer.com/news/security/css-code-can-be-abused-to-collect-sensitive-user-data/
  301. Ge0rG web security is a huge game of whack-a-mole. And sometimes I'm not sure if we aren't the moles.
  302. alexis has left
  303. Wiktor isn't this true for software in general?
  304. alexis has joined
  305. Wiktor web is just "used software" and complex software so it has more vulnerabilities discovered
  306. Ge0rG Wiktor: software in general is doing okay, but the web is a fractal of insecurity.
  307. Wiktor this is just survivorship bias
  308. Ge0rG Wiktor: the web browser is an attempt to rebuild the desktop operating system, but with the sole intent to load and execute malicious code from third parties.
  309. Ge0rG it doesn't help that all three major web operating system vendors are either in the tracking-users business or paid by this business.
  310. alexis has left
  311. Wiktor > sole intent to load and execute malicious code from third parties [citation needed]
  312. lumi has left
  313. Alex has joined
  314. Valerian has left
  315. alexis has joined
  316. Valerian has joined
  317. Wiktor the code is as malicious as any other piece of software can be
  318. Valerian has left
  319. Valerian has joined
  320. Wiktor do you claim Firefox and Mozilla are in this just because they want you to execute "malicious code from third parties"?
  321. Ge0rG Wiktor: do you remember the time when famil members just downloaded random .scr files from the internet because "that screen saver was so awesome"?
  322. Valerian has left
  323. Ge0rG Wiktor: firefox ships with JavaScript enabled, so yes.
  324. Wiktor yep, that scr could be malicious too
  325. Wiktor little evil johnny castaway
  326. Ge0rG Wiktor: it took a while for users to learn that, the hard way.
  327. Wiktor and now they're learning on the web...
  328. Ge0rG Wiktor: but now, they are doing 90% of their work in a web browser, which is designed and optimized to load and execute malicious JavaScript
  329. Ge0rG Now please tell me that not all JS is malicious.
  330. alacer has left
  331. Wiktor is it?
  332. pep. enables NoScript
  333. pep. Ge0rG, not all JS is malicious!
  334. Nekit has joined
  335. Ge0rG Wiktor: the typical modern web page has 5kb of JS to animate the menus, which depends on 1MB of jquery, and a dozen or two of different tracking services embedded
  336. Zash Not all X!!
  337. Ge0rG And any of those tracking service may do anything to your website.
  338. Wiktor yes, so what? this is just bad design, last time I read ECMAScript spec it didn't require me to put trackers on my page to achieve "malicious JavaScript" badge
  339. Ge0rG Oh, did I mention those pages that allow third-party live bidding platforms to sell code execution rights to shady companies that will redirect you to a "YOU HAVE WON!!!111!" page, delete your back-history and deploy the vibration alert?
  340. rainslide has left
  341. Wiktor your computer allows shady things, do you consider it malicious too?
  342. Ge0rG Wiktor: "this is just bad design" is a statement that applies to the modern web.
  343. pep. Somebody mentioned Intel ME?
  344. Wiktor haha, yes, Intel ME
  345. Ge0rG Wiktor: which brings me directly back to my initial statement, which you just proved :P
  346. pep. And AMD's whatever
  347. Zash Computers are teh wurst
  348. Wiktor bad design on part of the site developer, you cannot claim that if your observed set is composed only out of white swans that black swans do not exist
  349. Ge0rG with I-ME, at least *only Intel* can execute code on my box without me knowing.
  350. pep. Zash, potatoes!
  351. Zash Let's just all become potato farmers
  352. pep. Ge0rG, are you even sure of that
  353. Ge0rG Zash: ITYM Teewurst <https://en.wikipedia.org/wiki/Teewurst>.
  354. Ge0rG pep.: sure of what?
  355. pep. *only Intel*
  356. pep. I mean,
  357. pep. Intel could proxy to third-parties. Just like these websites allows third-parties in
  358. Ge0rG pep.: only Intel and the state actors that coerced them.
  359. pep. Intel could proxy to third-parties. Just like these websites allow third-parties in
  360. pep. :)
  361. pep. Sounds better
  362. Ge0rG pep.: but at least they need to intercept the laptop shipping to me and inject the payload manually
  363. Ge0rG pep.: my laptop doesn't come asking for malware whenever I surf to a news site.
  364. Wiktor Intel ME can be updated though ethernet, even when the computer is powered off (but not plugged off the grid)
  365. rainslide has joined
  366. rishiraj22 has left
  367. rishiraj22 has left
  368. rainslide > isn't this true for software in general? Maybe true for all general stuffs in large scale.
  369. rishiraj22 has joined
  370. vanitasvitae has left
  371. rainslide News next decade: Intel becomes the largest tracker (?)
  372. pep. I bet that's already true to some extent
  373. rishiraj22 has left
  374. rishiraj22 has joined
  375. rtq3 has left
  376. alacer has joined
  377. alacer has left
  378. alacer has joined
  379. alexis has left
  380. vanitasvitae has left
  381. alexis has joined
  382. Andrew Nenakhov has left
  383. Andrew Nenakhov has joined
  384. Andrew Nenakhov has left
  385. Andrew Nenakhov has joined
  386. Valerian has joined
  387. Alex has left
  388. rtq3 has joined
  389. rainslide has left
  390. marmistrz has left
  391. daniel has left
  392. lnj has joined
  393. SaltyBones has left
  394. valo has left
  395. valo has joined
  396. dos has joined
  397. lnj has left
  398. Zash has left
  399. j.r has joined
  400. xnyhps has joined
  401. lnj has joined
  402. xnyhps has joined
  403. link2xt has joined
  404. SamWhited has left
  405. rishiraj22 has left
  406. rishiraj22 has joined
  407. Yagiza has left
  408. Yagiza has joined
  409. lskdjf has left
  410. Guus has left
  411. lskdjf has joined
  412. lskdjf has joined
  413. Zash has left
  414. labdsf has joined
  415. la|r|ma has joined
  416. labdsf I have read the logs about ephemeral messages from http://logs.xmpp.org/xsf/2018-06-07/
  417. labdsf Just in case, I am the author of this protoxep
  418. alexis has left
  419. daniel has left
  420. alexis has joined
  421. daniel has joined
  422. xnyhps has joined
  423. Ge0rG hey labdsf, welcome :)
  424. alacer has left
  425. la|r|ma has joined
  426. la|r|ma has joined
  427. labdsf so far, the main concern is that nested <ephemeral> contents is hard to implement and does not guarantee anything anyway as some clients will store raw XML?
  428. jonasw hi labdsf
  429. jonasw labdsf, yes, that is definitely a conceprn
  430. jonasw labdsf, yes, that is definitely a concern
  431. Ge0rG labdsf: I can't speak for the other Council members; my personal concern is that it is not clear how it is supposed to work in multi-client scenarios.
  432. alexis has joined
  433. alacer has joined
  434. labdsf as for the threat model, it is indeed "stolen device" attack only, nothing more, all parts of the conversation trust each other
  435. Ge0rG labdsf: I already have a hard time removing messages from server-side MAM after 14 days ;)
  436. labdsf Ge0rG, timer setting synchronization part?
  437. labdsf or starting of the timer on the recipient side?
  438. alexis has left
  439. Ge0rG labdsf: starting of the timer. Also, with a <no-store/> hint, the message will only be delivered to clients that are online at the time of transmission
  440. mimi89999 has joined
  441. labdsf it is no-permanent-store in the specification, whatever it means
  442. Ge0rG labdsf: so if my mobile is connected at the time, it will get a copy; if it's not connected, it won't.
  443. labdsf and it is for plaintext only
  444. alexis has joined
  445. labdsf is there any practical difference between no-permanent-store and no-store?
  446. Ge0rG No idea.
  447. Ge0rG MAM only mentions no-store, in https://xmpp.org/extensions/xep-0313.html#hints
  448. Ge0rG labdsf: with the current MAM and XMPP "design", it's not possible to know when all clients have received a given message, so no-permanent-store doesn't make much sense
  449. labdsf according to https://xmpp.org/extensions/xep-0334.html#no-permanent-store , no-permanent-store messages should not be stored in MUC
  450. labdsf MAM*
  451. Holger Yes the idea is "only in the offline spool".
  452. labdsf so if no client is offline, it will be stored for offline delivery
  453. Ge0rG So it still breaks the multi-client use case.
  454. Holger Yes.
  455. Ge0rG MattJ had a nice idea to keep a per-client offline spool, backed by the MAM store. That would break as well.
  456. labdsf it does not break it completely, but we need a better replacement for offline message delivery than MAM for it to work
  457. labdsf so each device can register on the server and have its own message queue
  458. labdsf when all devices got the messages, they are removed
  459. Ge0rG labdsf: yes, that would be great. Except if you drop your device into a beer keg and messages for that device get stored forever.
  460. Holger Ge0rG: I'd burn no-permanent-store with fire, but as you recently told me hints were burnt down altogether anyway.
  461. labdsf Ge0rG, unregister it after 2 weeks of inactivity
  462. Ge0rG labdsf: not a bad idea
  463. Ge0rG But we aren't there yet.
  464. Ge0rG Maybe we can fix it with IM-NG
  465. labdsf Signal actually has this model, it allows you to register the first device with SMS, then register additional devices using already registered one
  466. labdsf device is unregistered after one week
  467. Ge0rG I thought Signal has a single-device model?
  468. labdsf no
  469. labdsf it is WhatsApp that has single-device
  470. Ge0rG We need to establish a device-registration XEP.
  471. labdsf Signal allows you to register the phone with SMS, then register desktop by scanning its QR code, then shutdown the phone and use desktop
  472. Ge0rG Until then, I just use the resource string as a device identifier.
  473. edhelas labdsf afaik, you can't shutdown the phone no
  474. Ge0rG labdsf: and the desktop is a full device, like the phone is?
  475. labdsf yes
  476. edhelas because the phone is just acting a a proxy for the desktop
  477. labdsf edhelas, you are talking about WhatsApp
  478. edhelas ah yeah sorry
  479. vanitasvitae has left
  480. labdsf Signal is different, you can shutdown the phone
  481. Ge0rG What a feature.
  482. labdsf WhatsApp starts displaying the message that your phone has disconnected above the "roster"
  483. labdsf I think we can postpone implementation of plaintext ephemeral messages or at least disable them by default until we have better Signal-like offline message delivery
  484. Zash "Signal-like" means?
  485. labdsf multiple queues, one per device
  486. labdsf messages are removed as soon as you download them
  487. Zash Ugh
  488. labdsf or after one week if you don't
  489. Zash .... isn't that because it doesn't support multiple devices?
  490. Ge0rG labdsf: another point: I can see why you wrapped the <body> into <ephemeral>, but I'm not convinced of this approach. It will interact in non-obvious ways with things like OMEMO
  491. labdsf it does, I just described above
  492. lorddavidiii has left
  493. labdsf Ge0rG, in case of OMEMO you place <encrypted><payload>...</payload>...</encrypted> inside <ephemeral>
  494. edhelas we need to go deeper
  495. Ge0rG labdsf: yes; so you need to parse <ephemeral> for everything that's allowed in a <message>, except with a timer attached.
  496. rtq3 has left
  497. rtq3 has joined
  498. Ge0rG labdsf: what if I send a Read Marker inside <ephemeral>? Will the conversation show up as un-read after the time?
  499. Ge0rG or is there a white-list of tags that are allowed inside of <ephemeral>?
  500. Andrew Nenakhov has left
  501. Andrew Nenakhov has joined
  502. labdsf I expect that <ephemeral> is only used when you explicitly send a message
  503. Ge0rG is a corner case specialist.
  504. xnyhps has joined
  505. marmistrz has joined
  506. Ge0rG I should get that printed onto my business cards, to give people a fair advance warning.
  507. MattJ sends Ge0rG inside an <ephemeral>
  508. Ge0rG MattJ: so what's my TTL, then?
  509. Zash has left
  510. MattJ integer overlow
  511. Ge0rG MattJ: do you have the eyes of a Shinigami?
  512. MattJ integer overflow
  513. Valerian has left
  514. Valerian has joined
  515. Valerian has left
  516. Valerian has joined
  517. rainslide has joined
  518. Kev has left
  519. labdsf As mentioned in https://xmpp.org/extensions/inbox/omemo-media-sharing.html we already have https://xmpp.org/extensions/xep-0373.html that does stanza encryption
  520. labdsf <ephemeral> is no different from <openpgp> except that content is not encrypted
  521. labdsf but then we can have <ephemeral><openpgp><ephemeral>... which will be hard to implement if OpenPGP is a plugin
  522. labdsf various plugins trying to wrap the messages in unspecified order will be a problem
  523. Ge0rG And then all that is wrapped in <forwarded><sent> to your mobile device.
  524. Ge0rG > https://xmpp.org/extensions/inbox/omemo-media-sharing.html Please don't even get me started about `if (message.startsWith("aesgcm://")) { ... }`
  525. Ge0rG and what is an "OMEMO message"?
  526. Ge0rG daniel: what were you smoking?
  527. Zash has left
  528. Zash has left
  529. Ge0rG I mean, I can understand how this results from "we don't need to wrap anything but the <body> into OMEMO".
  530. labdsf in any case, if you *receive* an ephemeral read marker, the conversation becomes read and the marker is not stored in logs
  531. Ge0rG And there is certain merit in producing working code over good specifications; but now might be a good time to rewind and fix this.
  532. jonasw Ge0rG, if this is about encrypting whole stanzas, yeah, let’s do that.
  533. Ge0rG labdsf: but then later the conversation needs to become un-read again when the marker times out, right?
  534. jonasw but I heard it’s not as easy as you’d think
  535. labdsf Ge0rG, no
  536. Ge0rG needs to invent some other interesting corner cases.
  537. labdsf it just becomes read forever
  538. Ge0rG ephemeral Pubsub posts!
  539. MattJ I like the idea of being able to temporarily correct messages
  540. edhelas Ge0rG it already exists, it's called PEP with one item per node :p
  541. MattJ It's called restarting Prosody
  542. Kev MattJ: What about temporarily adding a reference to a message?
  543. Ge0rG MattJ: thanks for making me sad.
  544. edhelas MattJ +1 :D
  545. MattJ Probably making Link Mauve sad, he already implemented persistence :)
  546. Ge0rG in trunk?
  547. MattJ In trunk
  548. Ge0rG I'm running two dozens of half-baked half-broken half-experimental modules on my server, I can't upgrade to trunk!
  549. daniel > And there is certain merit in producing working code over good specifications; but now might be a good time to rewind and fix this. If you read the entire xep the introduction clearly states that
  550. Ge0rG daniel: touché
  551. Guus has left
  552. pep. Ge0rG, I'm sure you can upgrade to trunk and still benefit from another dozen of half-baked half-broken half-experimental modules :P
  553. rion has left
  554. edhelas all our projects are not half-baked half-broken half-experimental in the end ?
  555. Ge0rG pep.: maybe, but I don't want to introduce even more half-baked-ness.
  556. rainslide has left
  557. Guus has left
  558. rtq3 has left
  559. Guus has left
  560. Guus has left
  561. Guus has left
  562. Zash has left
  563. labdsf Ok, so to summarize, I need to 1) add threat model to "security considerations" 2) write "implementation notes" that say plaintext ephemeral messages should be disabled unless the server advertises reliable no-permanent-store offline message delivery mechanism 3) think about moving message contents outside the <ephemeral> if it makes implementation too complicated
  564. Guus has left
  565. labdsf Ge0rG, by the way it does not matter whether you place chat state notification inside <ephemeral> or outside of it as long as <ephemeral> is present in the message
  566. rion has left
  567. jere has joined
  568. rishiraj22 has left
  569. labdsf what is the procedure to update ProtoXEP? Just sumbit a pull request?
  570. daniel has left
  571. daniel has joined
  572. jonasw labdsf, there is not really a procedure. you can submit a PR, yes, I’ll merge the update.
  573. jonasw unfortunately. I would prefer if that happened under Experimental, because there *is no procedure* for anything there.
  574. jonasw I won’t send an update email for example like I’d do for Experimental XEPs
  575. labdsf hmm
  576. Ge0rG jonasw: the XEP was rejected
  577. jonasw but the war on whether we want to "have XEPs in Experimental early and develop there" or "ProtoXEPs must be very promising / very good to accept" is not fought out yet
  578. jonasw Ge0rG, I am aware
  579. jonasw Ge0rG, what are you telling me?
  580. jonasw you saying I should reject the update on that ground?
  581. Ge0rG so it's hanging around in inbox now, and I suppose it could get the PRs applied and the author could kindly ask the editot to resubmit it for a vote
  582. Ge0rG or the Council.
  583. jonasw exactly
  584. daniel has left
  585. jonasw that’s what’s effectively happening whenever things in inbox get updated
  586. daniel has joined
  587. Ge0rG labdsf: so please make a PR to address all Council issues
  588. Ge0rG labdsf: and then let us know
  589. Syndace has joined
  590. daniel has left
  591. daniel has joined
  592. daniel has left
  593. daniel has joined
  594. Guus has left
  595. Guus has left
  596. rishiraj22 has left
  597. Guus has joined
  598. rishiraj22 has left
  599. mikaela has joined
  600. jubalh has left
  601. alacer has left
  602. alacer has joined
  603. Guus has left
  604. Guus has left
  605. Kev > but the war on whether we want to "have XEPs in Experimental early and develop there" or "ProtoXEPs must be very promising / very good to accept" is not fought out yet It is, though.
  606. jonasw it comes up on the list about once a month, doesn’t it?
  607. Kev Usual criteria for Experimental is only "Not obviously wrong", "Confusing as hell" or "duplicating existing stuff for no good reason".
  608. Guus has joined
  609. jonasw soo... if I have a XEP which is very confusing and duplicates everything, I’m in? ;-)
  610. Kev Certainly noting as much as 'must be very good or very promising' has ever been enforced, of which I'm aware.
  611. SamWhited has left
  612. SamWhited has left
  613. Kev Yes, that's exactly what I meant, of course :p
  614. jonasw sorry, I had to take that one after I had a similar negation issue the other day on the same topic:)
  615. j.r has joined
  616. Guus has left
  617. Guus has joined
  618. daniel has left
  619. daniel has joined
  620. rishiraj22 has left
  621. rtq3 has joined
  622. rainslide has joined
  623. rishiraj22 has left
  624. daniel has left
  625. daniel has joined
  626. rainslide has left
  627. rishiraj22 has left
  628. j.r has joined
  629. j.r has joined
  630. remko has joined
  631. la|r|ma has joined
  632. la|r|ma has left
  633. rainslide has joined
  634. jubalh has joined
  635. Nekit has joined
  636. rishiraj22 has left
  637. marmistrz has joined
  638. marmistrz has left
  639. lnj has left
  640. lnj has joined
  641. SaltyBones has left
  642. jubalh has joined
  643. rainslide has left
  644. jubalh has joined
  645. rtq3 has left
  646. marmistrz has left
  647. SaltyBones has left
  648. Guus has left
  649. Guus has left
  650. Guus has joined
  651. UsL has joined
  652. UsL has joined
  653. jere has left
  654. Guus has left
  655. Guus has left
  656. Guus has left
  657. Guus has left
  658. Guus has joined
  659. marmistrz has left
  660. Valerian has left
  661. Valerian has joined
  662. marmistrz has left
  663. Syndace has left
  664. Syndace has joined
  665. j.r has joined
  666. andy has left
  667. jere has joined
  668. Guus has left
  669. Guus has left
  670. j.r has joined
  671. marmistrz has left
  672. Valerian has left
  673. Valerian has joined
  674. andrey.g has left
  675. SaltyBones has left
  676. Valerian has left
  677. Valerian has joined
  678. daniel has left
  679. daniel has joined
  680. mikaela has left
  681. jjrh has left
  682. rishiraj22 has left
  683. rishiraj22 has joined
  684. jubalh has joined
  685. rishiraj22 has left
  686. rishiraj22 has joined
  687. SaltyBones has left
  688. rishiraj22 has left
  689. rishiraj22 has joined
  690. moparisthebest has left
  691. Tobias has joined
  692. Tobias has joined
  693. daniel has left
  694. daniel has joined
  695. j.r has left
  696. daniel has left
  697. daniel has joined
  698. ralphm has left
  699. andrey.g has joined
  700. Tobias has left
  701. Tobias has joined
  702. jjrh has left
  703. j.r has joined
  704. daniel has left
  705. daniel has joined
  706. daniel has left
  707. daniel has joined
  708. mikaela has joined
  709. lskdjf has joined
  710. Wiktor has joined
  711. alexis has left
  712. rtq3 has joined
  713. alexis has joined
  714. Ge0rG has left
  715. marmistrz has joined
  716. alexis has left
  717. Yagiza has left
  718. alexis has joined
  719. alexis has left
  720. alexis has joined
  721. ralphm has joined
  722. j.r has left
  723. j.r has joined
  724. daniel has left
  725. daniel has joined
  726. rtq3 has left
  727. rtq3 has joined
  728. daniel has left
  729. daniel has joined
  730. Yagiza has joined
  731. goffi has left
  732. andy has joined
  733. nyco has left
  734. nyco has joined
  735. tux has joined
  736. marmistrz has left
  737. la|r|ma has left
  738. jonasw has left
  739. jonasw has joined
  740. SaltyBones has left
  741. goffi has joined
  742. vanitasvitae has left
  743. rishiraj22 has left
  744. rishiraj22 has joined
  745. Tobias has joined
  746. marmistrz has left
  747. Lance has joined
  748. mikaela has joined
  749. Lance has joined
  750. Tobias has joined
  751. Valerian has left
  752. jubalh has joined
  753. labdsf has left
  754. labdsf has joined
  755. Guus has left
  756. rishiraj22 has left
  757. labdsf Ge0rG, we cannot use resource string as device identifier, sadly
  758. jonasw labdsf, why?
  759. labdsf Gajim by default has $rand part that is regenerated on each connection
  760. jonasw yeah, gajim needs fixing then :)
  761. Guus has left
  762. Guus has left
  763. labdsf maybe
  764. Andrew Nenakhov has joined
  765. Guus has left
  766. labdsf if all major clients are fixed to use somewhat permanent resources, it may be easy enough to implement offline message queues in prosody
  767. jonasw labdsf, MattJ is working on that, kinda
  768. jonasw regarding fixing clients, please file issues
  769. Guus has left
  770. goffi why a client should have a permanent resource ? I thought it was seen as bad practice at some point. And using resource to identity a client doesn't smells like a good idea.
  771. labdsf goffi, we need to understand why is it a bad practice
  772. goffi if it's needed, a random ID generated once by client and put in some disco sounds better to me.
  773. labdsf my guess is that using non-random is a bad practice, not permanent
  774. labdsf because you may want to use to Gajims, for example
  775. Zash Fixed strings like "Gajim" or "Conversations" or "mobile" are meh.
  776. goffi would be nice to have some input on that, SàT is also using random resource by default (well, actually resource chosed by server).
  777. jonasw goffi, like Zash says, a *predictable* string is bad. a string which identifies a client (of a user) uniquely (but unpredictably) is good
  778. jonasw so gajim-dg6jqVpjVI6, generated once at account setup, is good
  779. jonasw it helps the server re-identify the client right after bind
  780. goffi Zash: I actually find handy to have something like "mobile" when I want to access this device directly, why would is it bad ?
  781. lnj has left
  782. Guus has left
  783. Guus has left
  784. jonasw goffi, you can detect the mobile-ness of a device via disco#info
  785. jonasw parsing the resource string is awful for that
  786. lnj has joined
  787. Zash jonasw: lets me guess it and send stuff directly to your phone. also you'll have a bad time if you ever get a second phone
  788. SaltyBones has left
  789. goffi jonasw: yes, but if I have several mobiles, and I want to retrieve picture from one in particular ?
  790. jonasw goffi, disco#info can have names in it
  791. jonasw allow users to set proper disco#info names
  792. jonasw (and default them to something sensible)
  793. goffi hum, disco#info can be nice indeed
  794. Guus has left
  795. jonasw and the name can even be internationalised!
  796. goffi in resource too
  797. jonasw no
  798. jonasw you can only have one resource
  799. jonasw but you can have many <identity/> items, one for each language
  800. goffi ah ok, I thought you were thinking about non ascii chars.
  801. Guus has left
  802. Syndace has left
  803. Syndace has joined
  804. Guus has left
  805. Guus has left
  806. goffi anyway, a XEP or something official givin advices on resource chosing would be a good think.
  807. jonasw true
  808. jonasw an Informational document would be good
  809. j.r has joined
  810. ta has joined
  811. SaltyBones has left
  812. marmistrz has joined
  813. Neustradamus has left
  814. Guus has left
  815. rishiraj22 has left
  816. alexis has left
  817. alexis has joined
  818. edhelas has left
  819. Ge0rG goffi: I've written out the arguments for a prefixed random-on-account-creation resource string numerous times in the past, including the "human readable for debugging" argument
  820. edhelas has joined
  821. alacer has left
  822. alacer has joined
  823. ralphm has left
  824. waqas has joined
  825. jonasw Ge0rG, copy & paste your arguments into a XEP template?
  826. goffi Ge0rG: where ?
  827. Ge0rG Hm.
  828. alexis has left
  829. Ge0rG has left
  830. Ge0rG I'm using `yaxim.32bithexrnd` since the first user reported an issue with a second device running yaxim, which was ages ago.
  831. alexis has joined
  832. daniel 32 bits?
  833. daniel That seems like a lot
  834. labdsf I would like it to behave like DHCP, server selects a resource for you (or you select random with prefix for the first time), then you request the same resource on reconnection
  835. Ge0rG goffi: on standards@, mostly. The last time in the context of bind2, where the `uuid4/uuid4` resource string scheme was proposed.
  836. jonasw labdsf, you can have that by not specifying a resource on the first connect
  837. jonasw the server has to assign one to you then
  838. SamWhited has left
  839. labdsf jonasw, the problem with Gajim is that it does not remember it
  840. jonasw sure, gajim needs fixing
  841. alacer has left
  842. rishiraj22 has left
  843. labdsf ok, I will file an issue
  844. Ge0rG daniel: maybe. I didn't do the math regarding the birthday collision phenomenon
  845. jonasw 32 bit are just 8 characters of hex. that seems good to me
  846. goffi Ge0rG: would be nice to put in a protoXEP, it's hard to follow every discussions in MUC + mailing list + github issues now, specially for devs like me which are working on their free time.
  847. labdsf 32 bit is what OMEMO uses
  848. jonasw I‘d probably do base64 instead.
  849. labdsf for device id
  850. jonasw goffi, which github issues?
  851. vanitasvitae has left
  852. daniel jonasw, i use 3 bytes in base64. thats short enough that an advanced user (doing debugging or what ever) can still remember it
  853. goffi jonasw: I think discussions happens there sometimes, if not that's good news
  854. legastero has joined
  855. jonasw goffi, not on the xeps repository (not on my watch at least)
  856. jonasw if you spot technical discussion there, feel free to alert me or another editor
  857. rtq3 has left
  858. jonasw because I find that awful, too, and we agreed to remind people to move the discussions to standards@
  859. goffi good then
  860. SaltyBones has joined
  861. Lance has joined
  862. jonasw daniel, right
  863. Ge0rG daniel: I remember being confused by the special characters in a conversations resource. Also, I wonder if there are case insensitive servers out there
  864. rtq3 has joined
  865. jonasw Ge0rG, they’d be in violation of RFC 6122 then
  866. jonasw burn them
  867. daniel Ge0rG: well if there are they should reread the rfc
  868. jonasw Ge0rG, which special characters though? base64 is just a-zA-Z0-9
  869. daniel jonasw: plus two more
  870. jonasw oh right
  871. jonasw (three if you count the padding)
  872. daniel With three bytes you don't have padding
  873. Lance has joined
  874. jonasw true
  875. Ge0rG I'd actually rather use a password generator for the resource
  876. jonasw something like "commissions beer respite"?
  877. Ge0rG Did I say "passphrase"?
  878. legastero has left
  879. legastero has joined
  880. Guus has left
  881. Guus has left
  882. Guus has joined
  883. tux has joined
  884. legastero has joined
  885. jjrh has left
  886. la|r|ma has joined
  887. la|r|ma has joined
  888. la|r|ma has joined
  889. la|r|ma has joined
  890. la|r|ma has joined
  891. jjrh has left
  892. la|r|ma has joined
  893. la|r|ma has joined
  894. marc has joined
  895. la|r|ma has joined
  896. jjrh has left
  897. la|r|ma has joined
  898. la|r|ma has joined
  899. la|r|ma has joined
  900. la|r|ma has joined
  901. SaltyBones has left
  902. labdsf jonasw, you mentioned MattJ is working on something (premanent resources? message queues?), where can I read about it?
  903. mimi89999 has left
  904. Zash Can you read minds?
  905. labdsf I guess it is offline message queues in prosody
  906. anjan has joined
  907. jjrh has left
  908. edhelas has left
  909. Valerian has joined
  910. Andrew Nenakhov has left
  911. Lance has joined
  912. Ge0rG Zash [18:31]: > Can you read minds? Is there an XEP for that?
  913. Lance has joined
  914. Andrew Nenakhov has joined
  915. Guus has left
  916. pep. labdsf, there was some mention of that on this channel iirc, and maybe also on prosody@
  917. MattJ Ge0rG, https://xmpp.org/extensions/xep-0183.html
  918. jjrh has left
  919. MattJ labdsf, there's nothing to read, just reworking the message delivery logic in Prosody. No XEP because no protocol changes (we have all the protocols we already need)
  920. marmistrz has joined
  921. labdsf MattJ: What is the change in delivery logic? Will no-permanent-store offline messages be stored for some time for recently seen resources?
  922. rtq3 has left
  923. Guus has left
  924. MattJ Yes
  925. MattJ Probably no-permanent-store will be ignored for the most part, in preference to delivering the message to all known devices
  926. labdsf I would like to disable MAM completely. As a workaround I have it store messages for a week and in-memory only.
  927. Ge0rG Tedd has a very interesting reading of the LMC rules
  928. MattJ I really dislike the idea of MAM (I don't run it on my own server)
  929. MattJ I wrote the XEP, and intended it to cover multiple use cases, but I should clarify that it's the "store everything forever" thing that people seem to have interpreted it as that I don't like
  930. labdsf MattJ: as I understand it, no-store is "deliver to online clients only", no-permanent-store is "no MAM, store for some time in memory for clients that are likely to reconnect in a few days", store is "store in MAM permanetly until it is removed by some internal logic".
  931. MattJ The stuff I'm working on auto-deletes messages once they have been received by all devices
  932. MattJ Regardless of what hints are in the message
  933. labdsf So you sort of ignore no-store and make it work like no-permanent-store
  934. labdsf And store does not work because MAM is disabled
  935. Ge0rG Funny how everybody involved in xmpp software runs their own custom configuration that's incompatible to the preached best practices and to everybody else's
  936. MattJ Ge0rG, you think I'm preaching that people should have MAM enabled and store everything forever? :)
  937. Guus has left
  938. Guus has left
  939. Guus has joined
  940. Ge0rG MattJ: you wrote the XEP. And MAM support is demanded by at least one modern client.
  941. MattJ labdsf, I'm breaking stanzas into three categories: [deliver to all], [deliver to all online], [deliver to single resource]
  942. Ge0rG I'm running my secondary clients with negative priority to avoid them consuming messages when the primary client is offline.
  943. Ge0rG MattJ: the preaching statement was not related to you personally, just to what the xsf says
  944. MattJ Ge0rG, the XSF preaches? :)
  945. labdsf I would like to have two options: with MAM (Telegram-like, local archive acts like cache and can be pruned anytime) / without MAM (client has to store all messages locally)
  946. Zash birdsite.tld/shitxsfsays
  947. labdsf the fact that MAM became an offline message delivery mechanism is a bug
  948. labdsf especially with OMEMO, when messages are sent with <store/> but cannot be decrypted more than once
  949. labdsf and server stores permanently encrypted messages that nobody can decrypt
  950. Ge0rG labdsf: congratulations, you just discovered the mess that multi device xmpp is.
  951. rtq3 has joined
  952. MattJ labdsf, pretty much agree
  953. MattJ which is why I'm taking a step back and rewriting our code like it's 2018
  954. Ge0rG If I weren't on mobile I'd give you the link to the presentation listing this and many other issues
  955. Ge0rG Per device offline message queues would actually be a reason for me to upgrade prosody to trunk
  956. labdsf Ge0rG, but it seems pretty easy to fix (from the protocol point of view, not sure about implementation), just add semi-permanent resources and store messages for some time
  957. Ge0rG labdsf: Yeah. Except it was a hard fight to convince a small subset of the xmpp community that permanent resources are a good and not a bad thing
  958. Dave Cridland has left
  959. Dave Cridland has joined
  960. labdsf resource is a part of URL, it is there for IoT applications from the start, how non-permanent resource is of any use?
  961. labdsf IoT was not that popular buzzword than, but something like that was considered when resources were added I think
  962. labdsf you connect a device, assign it a resource and then it is available by permanent URL
  963. rtq3 has left
  964. Ge0rG labdsf: don't ask *me* about that
  965. mimi89999 has left
  966. mimi89999 has joined
  967. Dave Cridland has left
  968. lskdjf has left
  969. Dave Cridland has joined
  970. labdsf MattJ, if MAM is enabled, messages are stored even if they have been received by all devices I guess?
  971. rishiraj22 has left
  972. labdsf one reason for MAM to exist is when you want to connect a new device later
  973. MattJ There will be a setting (disabled by default) to control storage of messages for longer periods
  974. labdsf Signal solves this problem by synchronizing messages device-to-device, but that would require an entire new specification
  975. MattJ e.g. "store for at least 7 days"
  976. Dave Cridland has left
  977. MattJ It wouldn't require much more of a specification than one that says clients can optionally enable other clients to speak XEP-0313 to them
  978. Dave Cridland has joined
  979. MattJ Even if it only supported a limited subset (give me everything after id X)
  980. MattJ Probably a trivial operation for most clients
  981. Lance has joined
  982. Lance has joined
  983. marc has left
  984. Holger Is the plan to (re)construct carbons of outgoing messages while delivering per-device offline messages?
  985. Kev has left
  986. rishiraj22 has left
  987. rishiraj22 has joined
  988. alacer has joined
  989. Dave Cridland has left
  990. labdsf https://dev.gajim.org/gajim/gajim/issues/9193
  991. Chobbes has joined
  992. Chobbes has joined
  993. la|r|ma has joined
  994. j.r has joined
  995. rishiraj22 has left
  996. rishiraj22 has joined
  997. pep. "so offline messages will be stored for longer than needed and not delivered to the client." how would they not be delivered to the client?
  998. marc has joined
  999. rishiraj22 has left
  1000. pep. Are we not delivering everything to every clients nowadays
  1001. Ge0rG MattJ: that would make for a nice and secure UX as well. "Conversations on Android asked to obtain your message history. Yes / No"
  1002. rishiraj22 has joined
  1003. rishiraj22 has left
  1004. rishiraj22 has joined
  1005. Holger pep.: No idea but presumably the server would only deliver offline messages when a known resource reconnects.
  1006. Holger Gajim would just fetch them from MAM of course.
  1007. pep. So if I disconnect all my resources and connect with a new one (new client), I'll never receive these only messages? :/
  1008. pep. hmm
  1009. pep. *offline messages
  1010. Holger pep.: Well dunno about the Prosody plans. But otherwise you'd receive the full MAM archive without any paging whenever you log in with a new resource I guess?
  1011. labdsf pep., well, if MAM is not available, and two clients are connected ("Mobile" and "Gajim.foo"), then "Gajim.foo" disconnects, then a message is received, then "Gajim.bar" connects, a message will be stored for "Gajim.foo" and not delivered to "Gajim.bar"
  1012. rion has left
  1013. labdsf "Mobile" will receive the message because it was online
  1014. pep. And if Mobile wasn't connected
  1015. labdsf then "Gajim.bar" will probably receive the message
  1016. pep. I like the certainty of that sentence
  1017. Holger I wonder whether clients that don't implement MAM get deduplication right ...
  1018. labdsf well, according to https://xmpp.org/extensions/xep-0160.html it will be Gajim.bar only
  1019. Zash Does anyone get deduplication right?
  1020. labdsf "the server delivers the message to the resource that has sent that presence"
  1021. labdsf Zash, just remove messages with the same ID, I think Xabber does this
  1022. Holger Yes, shouldn't be hard if you rely on stanza IDs. We ran into the dedup mess because we didn't have them until recently.
  1023. j.r has joined
  1024. marc has left
  1025. Holger While I'm not convinced you're improving the UX with clients that *don't* support carbons and proper dedup of you start sending them incoming messages received by other clients.
  1026. Holger s/of/if/
  1027. SaltyBones has joined
  1028. tux has left
  1029. Valerian has left
  1030. j.r has joined
  1031. rishiraj22 has left
  1032. rishiraj22 has joined
  1033. mimi89999 has left
  1034. ibikk has left
  1035. Lance has joined
  1036. rishiraj22 has left
  1037. rishiraj22 has joined
  1038. rion has joined
  1039. Kev has left
  1040. rtq3 has joined
  1041. rishiraj22 has left
  1042. rishiraj22 has joined
  1043. SamWhited has left
  1044. labdsf has left
  1045. rishiraj22 has left
  1046. labdsf has joined
  1047. rishiraj22 has joined
  1048. Ge0rG labdsf: let me tell you about https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message
  1049. Ge0rG Zash: yaxim does deduplication right, but it doesn't support MAM.
  1050. labdsf has left
  1051. labdsf has joined
  1052. labdsf pep., I have updaet issue https://dev.gajim.org/gajim/gajim/issues/9193 with an expanded example
  1053. Tobias has left
  1054. Tobias has joined
  1055. marc has joined
  1056. Dave Cridland has left
  1057. Dave Cridland has joined
  1058. Dave Cridland has left
  1059. Dave Cridland has joined
  1060. labdsf has left
  1061. Dave Cridland has left
  1062. Dave Cridland has joined
  1063. rishiraj22 has left
  1064. rishiraj22 has joined
  1065. alacer has left
  1066. alacer has joined
  1067. Valerian has joined
  1068. rishiraj22 has left
  1069. rishiraj22 has joined
  1070. rishiraj22 has left
  1071. rishiraj22 has joined
  1072. labdsf has left
  1073. rishiraj22 has left
  1074. rishiraj22 has joined
  1075. Andrew Nenakhov has left
  1076. Andrew Nenakhov has joined
  1077. rishiraj22 has left
  1078. rishiraj22 has joined
  1079. j.r has joined
  1080. rishiraj22 has left
  1081. rishiraj22 has joined
  1082. jjrh has left
  1083. Lance has left
  1084. Lance has joined
  1085. daniel labdsf, resources in Conversations are only semi-stable fwiw
  1086. rtq3 has left
  1087. daniel i support gajim (and other clients) using semi stable (but randomized) resources but i don’t think relying on them is a good idea
  1088. rishiraj22 has left
  1089. rishiraj22 has joined
  1090. Dave Cridland has left
  1091. nyco has left
  1092. Dave Cridland has joined
  1093. rainslide has joined
  1094. nyco has joined
  1095. efrit has joined
  1096. jjrh has left
  1097. ta has left
  1098. rainslide has left
  1099. Andrew Nenakhov I like resources with human-readable parts.
  1100. SamWhited has left
  1101. rion has left
  1102. rishiraj22 has left
  1103. rishiraj22 has joined
  1104. rishiraj22 has left
  1105. rishiraj22 has joined
  1106. rishiraj22 has left
  1107. rishiraj22 has joined
  1108. labdsf has left
  1109. rion has joined
  1110. Yagiza has left
  1111. rishiraj22 has left
  1112. rishiraj22 has joined
  1113. rishiraj22 has left
  1114. rishiraj22 has joined
  1115. Lance has left
  1116. anjan has left
  1117. Lance has joined
  1118. rishiraj22 has left
  1119. rishiraj22 has joined
  1120. anjan has joined
  1121. la|r|ma has joined
  1122. marmistrz has joined
  1123. rishiraj22 has left
  1124. rishiraj22 has joined
  1125. rishiraj22 has left
  1126. labdsf daniel: how can we not rely on stable resources to identify clients?
  1127. rishiraj22 has joined
  1128. labdsf We can make clients advertise that they have stable resource to avoid storing messages for randomized ones
  1129. jonasw MattJ, if you don’t want to mean something "store everything forever", calling it "archive" was probably not smart :)
  1130. labdsf But I think it is easier to just fix major clients
  1131. daniel i’m not even sure a client can guarantee that…
  1132. jonasw daniel, to a local server it can
  1133. Zash It can't. Server has final say in what resource is used.
  1134. daniel what zash said
  1135. daniel even though a client could end the stream if the server doesn’t provide the resource it wants
  1136. daniel but that’s borderline insane
  1137. jonasw what I meant was: if a users server wants to make use of that property for that users clients, having the client advertise it makes sense. because if the server allows, the client can guarantee it.
  1138. jonasw (to the extent that it makes sense, after a disk wipe it obviously can’t)
  1139. labdsf There is no problem, if the server implements offline message queues, it has to provide stable resources
  1140. Tobias has joined
  1141. Tobias has joined
  1142. labdsf No need to think about the case when server does not
  1143. lnj has left
  1144. daniel labdsf, since i missed half the discussion; this is all in an attempt to make self destructible messages work?
  1145. labdsf In attempt to make offline messages work without MAM, unrelated work in prosody
  1146. jonasw Ge0rG, what did you mean by "password generator" for the random resource thing?
  1147. labdsf But that would help make plaintext ephemeral messages usable, which are not in their current state
  1148. rishiraj22 has left
  1149. daniel has left
  1150. Lance has left
  1151. rishiraj22 has joined
  1152. rtq3 has joined
  1153. labdsf OMEMO ephemeral messages are already ok I think, I just need to move the payload out of the <ephemeral> tag
  1154. SamWhited has left
  1155. rion has left
  1156. Ge0rG jonasw: something like https://github.com/pfleidi/yaxim/blob/master/src/org/yaxim/androidclient/util/XMPPHelper.java#L126 but with a-zA-Z0-9 only
  1157. labdsf So the core functionality is advertising ephemeral message support in device bundle and sending OMEMO ephemeral messages
  1158. Ge0rG it doesn't *need* to be exactly N bits of entropy
  1159. jonasw Ge0rG, soo... how’s that different from get_random_bytes(3) | base46?
  1160. jonasw Ge0rG, soo... how’s that different from get_random_bytes(3) | base64?
  1161. jonasw except for / and -
  1162. Ge0rG jonasw: exactly. / and -
  1163. jonasw what’s the isuse with that?
  1164. rishiraj22 has left
  1165. Ge0rG jonasw: because you don't want to have a / in your resource when bind2 strikes
  1166. rishiraj22 has joined
  1167. jonasw why not?
  1168. labdsf That was my proposal before discussion, then it was extented to plaintext and OpenPGP which we have to postpone until no-permanent-store can be supported
  1169. jonasw (and then I can still move to urlsafe…)
  1170. daniel Conversations uses url safe (- and _) by the way
  1171. jonasw Ge0rG, my understanding was that it was supposed to be <server part>/<client part> anyways
  1172. jonasw but whatever, I’ll use urlsafe then
  1173. daniel not because i’m afraid of bind2 but because it looks nice
  1174. rishiraj22 has left
  1175. rishiraj22 has joined
  1176. daniel labdsf, in my experience most clients that implement self destructible messages use omemo anyway
  1177. daniel (and are single device only most of the time)
  1178. Ge0rG daniel: was C using url-safe b64 from start on?
  1179. daniel yes
  1180. Ge0rG daniel: because I could *bet* I've seen a C with a / in the resource.
  1181. daniel (start=when it starting doing the random url part thing)
  1182. Ge0rG jonasw: how much would you bet on nobody ever implemeting resource.split("/")[0] and [1]?
  1183. rishiraj22 has left
  1184. rishiraj22 has joined
  1185. jonasw Ge0rG, https://github.com/jabbercat/jclib/compare/07c2589edf5b7d0a23124ace78477a38e0145f44...46433e394ba6bbc8d5209a93cdd62b34b4af1043
  1186. jonasw Ge0rG, as someone who recently fixed their JID implementation to interpret domain/resource correctly, I say they shall burn in hell
  1187. mrdoctorwho has joined
  1188. Ge0rG jonasw: 👍
  1189. jonasw Ge0rG, as someone who recently fixed their JID implementation to interpret domain/resource/with/slash correctly, I say they shall burn in hell
  1190. rishiraj22 has left
  1191. labdsf daniel: I am in the process of fixing the ProtoXEP to make it clear that everything outside OMEMO should be hidden from the user behind the "i know what I am doing" checkbox, and start writing the code by implementing ephemeral messages for OMEMO in Gajim
  1192. rishiraj22 has joined
  1193. daniel right. i’m just trying to provide you with an fyi on what most implementors are probably looking for
  1194. anjan has left
  1195. Ge0rG jonasw: so you say you are one of these folks who didn't get it right on the first attempt?
  1196. Tobias has joined
  1197. andy has left
  1198. jonasw Ge0rG, yupp. and I shall burn in hell
  1199. rishiraj22 has left
  1200. daniel Ge0rG, is this an argument to actually use / in Conversations and thus making this type of resource more common and thus helping to find those bugs much quicker?
  1201. rishiraj22 has joined
  1202. daniel if those bugs exists it's better to find them
  1203. jonasw daniel, I agree
  1204. daniel speaking of fun with jids. is there some sort of migration path to PRECIS? :-)
  1205. rishiraj22 has left
  1206. rishiraj22 has joined
  1207. jonasw except crying and trying to figure out why anybody would think that PRECIS was a good idea?
  1208. SamWhited PRECIS was a great idea
  1209. alexis has left
  1210. rishiraj22 has left
  1211. rishiraj22 has joined
  1212. jonasw SamWhited, good, can you explain to me how it makes sense to /not/ specify a specific unicode version for a standard which is used for data validation?
  1213. daniel precis is arguably easier to understand and implement than stringprep
  1214. jonasw I’ve been thinking about this for a while now and wasn’t able to figure that out yet
  1215. alexis has joined
  1216. SamWhited Do you want to be stuck on Unicode 3.0 forever? Also yah, I've tried implementing both. PRECIS was *way* easier.
  1217. jonasw this is bound to give inconsistent results, so we can’t ever do strict validation.
  1218. daniel jonasw, it relies on char classes
  1219. daniel and those are standardized by unicode
  1220. jonasw can’t things move between character clasess in different major releases of unicode?
  1221. SamWhited You can do strict validation; it's fine.
  1222. rishiraj22 has left
  1223. rishiraj22 has joined
  1224. SamWhited Yah, they can, so before you upgrade versions of Unicode double check and think about the consequences. Chances are it won't matter, or you'll have to provide an upgrade path just like when upgrading any other dependency ever.
  1225. jonasw SamWhited, uhm... so... instead of having a well-defined unicode version in the standard, now every developer of every XMPP related library needs to consider this?
  1226. jonasw how is this better?
  1227. SamWhited Because the standard can't be upgraded easily, our random libraries can.
  1228. jonasw so you’re saying we can manage to pull off a coordinated effort to lift the network on a new Unicode version whenever a new release comes out?
  1229. SamWhited You don't have to, just be backwards compatible.
  1230. rishiraj22 has left
  1231. rishiraj22 has joined
  1232. SamWhited I think my version supports 9 and 10 correctly and I think marcel added a way to make sure they interop, but I'd have to go look
  1233. daniel how does interop look like though? it has to be valid in both?
  1234. rishiraj22 has left
  1235. rishiraj22 has joined
  1236. daniel or pass through both?
  1237. SamWhited daniel: yah, if it's invalid in one fallback to the other, if it's invalid in both it's invalid.
  1238. jonasw so with enough time and enough interop, you’ll end up with a thing which just accepts everything.
  1239. jonasw and O(n) validation
  1240. SamWhited I suppose it depends on the situation though.
  1241. SamWhited No you really won't, you still have to follow the spec. Unicode charcters aren't changing left and right every day.
  1242. Ge0rG daniel: how is it a good idea to expose a small subset of your users to a weird behavior in the hope to sort it out?
  1243. jonasw O(nm) even, with n being the number of unicode standards you (the network) support and m the length of the string
  1244. SamWhited This is a rare thing that you *might* have to do if something very bad happens.
  1245. SamWhited jonasw: that's fine; it's still pretty fast and that only happens in the failure case and probably very rarely at that. You can probably also just check for any characters you think might cause problems if the performance is a problem.
  1246. jonasw I’m less worried about the practical performance and more about the concept itself.
  1247. rtq3 has left
  1248. rishiraj22 has left
  1249. rishiraj22 has joined
  1250. jonasw and possible attack vectors which come from ambiguous validation
  1251. SamWhited It's not ambiguous, it's very well defined with well defined failure scenarios.
  1252. jonasw ---which I haven’t thought through yet, because I’m avoiding the isuse at the moment.
  1253. Tobias has left
  1254. jonasw SamWhited, where are the failure scenarios defined?
  1255. jonasw i.e. which unicode versions do I have to try for which parts of a JID under which conditions?
  1256. daniel well if you are worried about that then there is probably no way to ever migrate to precis in the first place which means you don't have to worry about that
  1257. rishiraj22 has left
  1258. rishiraj22 has joined
  1259. SamWhited In the XEPs, they talk about this sort of thing extensively.
  1260. jonasw there are PRECIS *XEPs*?
  1261. SamWhited err, RFCs, that is
  1262. jubalh has left
  1263. Tobias has joined
  1264. daniel because the differences between stringprep and precis are more severe than precis with unicode x and precis with unicode y
  1265. jonasw hm, all I found so far was "PRECIS users need to consider the effects of unicode version changes, #notmydepartment" essentially
  1266. jonasw but maybe I have looked at the wrong place
  1267. jonasw daniel, yeah, that too
  1268. Ge0rG And then you are going to end up with users flooded by popup error messages from a client running on an old version of the spec because somebody used a robot face as a MUC nickname
  1269. labdsf has left
  1270. daniel true story
  1271. rtq3 has joined
  1272. Ge0rG Not all of my corner cases were pulled from thin air
  1273. j.r has joined
  1274. j.r has joined
  1275. Tobias has left
  1276. Tobias has joined
  1277. ThibG has left
  1278. ThibG has joined
  1279. rishiraj22 has left
  1280. rishiraj22 has joined
  1281. rishiraj22 has left
  1282. rishiraj22 has joined
  1283. labdsf has left
  1284. jubalh has joined
  1285. labdsf has left
  1286. lorddavidiii has left
  1287. Wiktor has left
  1288. goffi has left
  1289. rtq3 has left
  1290. rion has joined
  1291. Ge0rG has left
  1292. j.r has left
  1293. j.r has joined
  1294. labdsf has left
  1295. rion has left
  1296. rion has joined
  1297. remko has left
  1298. labdsf has left
  1299. Lance has joined
  1300. moparisthebest has joined
  1301. rion has left
  1302. marc has left
  1303. anjan has joined
  1304. Dave Cridland has left
  1305. rion has joined
  1306. rion has left
  1307. rion has joined
  1308. rtq3 has joined
  1309. rainslide has joined
  1310. Valerian has left
  1311. Valerian has joined
  1312. rainslide has left
  1313. marmistrz has left
  1314. zak has left
  1315. zak has left
  1316. rion has left
  1317. SamWhited has left
  1318. anjan has left
  1319. Valerian has left
  1320. Valerian has joined
  1321. Valerian has left
  1322. Valerian has joined
  1323. Andrew Nenakhov has left
  1324. Andrew Nenakhov has joined
  1325. Andrew Nenakhov has left
  1326. Andrew Nenakhov has joined
  1327. Valerian has left
  1328. Valerian has joined
  1329. la|r|ma has joined
  1330. la|r|ma has joined
  1331. la|r|ma has joined
  1332. lumi has joined
  1333. vanitasvitae has left
  1334. SamWhited has left
  1335. vanitasvitae has left
  1336. valo has left
  1337. daniel has left
  1338. anjan has joined
  1339. vanitasvitae has left
  1340. j.r has joined
  1341. Valerian has left
  1342. vanitasvitae has left
  1343. Nekit has joined
  1344. j.r has joined
  1345. Chobbes has left
  1346. Chobbes has joined
  1347. alexis has left
  1348. alexis has joined
  1349. lskdjf has joined
  1350. igor75 has joined
  1351. igor75 has joined
  1352. dos has left
  1353. jjrh has left
  1354. j.r has joined
  1355. SamWhited has left
  1356. matlag has joined
  1357. rtq3 has left
  1358. dos has joined
  1359. rainslide has joined
  1360. j.r has joined
  1361. anjan has left
  1362. rainslide has left
  1363. rtq3 has joined
  1364. UsL has left
  1365. jjrh has left
  1366. UsL has joined
  1367. rtq3 has left
  1368. rtq3 has joined
  1369. Lance has left
  1370. igor75 has left
  1371. muppeth has left
  1372. igor75 has joined
  1373. muppeth has joined
  1374. pep. has left
  1375. rtq3 has left
  1376. vanitasvitae has left
  1377. alexis has left
  1378. alexis has joined
  1379. vanitasvitae has joined
  1380. alexis has left
  1381. alexis has joined
  1382. rainslide has joined
  1383. j.r has joined
  1384. Lance has joined
  1385. alexis has left
  1386. alexis has joined
  1387. nyco has left
  1388. nyco has joined