XSF Discussion - 2022-05-25

  1. restive_monk has joined
  2. Calvin has joined
  3. neshtaxmpp has left
  4. adiaholic has joined
  5. neshtaxmpp has joined
  6. adiaholic has left
  7. adiaholic has joined
  8. sbach has left
  9. adiaholic has left
  10. pjn has left
  11. sbach has joined
  12. gooya has left
  13. gooya has joined
  14. neshtaxmpp has left
  15. Kev has left
  16. Kev has joined
  17. stp has left
  18. gooya has left
  19. adiaholic has joined
  20. floretta has left
  21. floretta has joined
  22. sbach has left
  23. jgart has joined
  24. adiaholic has left
  25. sbach has joined
  26. Kev has left
  27. Kev has joined
  28. Kev has left
  29. adiaholic has joined
  30. Kev has joined
  31. adiaholic has left
  32. restive_monk has left
  33. Kev has left
  34. atomicwatch has joined
  35. restive_monk has joined
  36. neshtaxmpp has joined
  37. adiaholic has joined
  38. jgart has left
  39. pjn has joined
  40. adiaholic has left
  41. Calvin has left
  42. Kev has joined
  43. pablo has joined
  44. antranigv has left
  45. sbach has left
  46. sbach has joined
  47. Titi has left
  48. antranigv has joined
  49. Titi has joined
  50. Kev has left
  51. adiaholic has joined
  52. pablo has left
  53. sbach has left
  54. sbach has joined
  55. restive_monk has left
  56. adiaholic has left
  57. pablo has joined
  58. neshtaxmpp has left
  59. menel has joined
  60. adiaholic has joined
  61. pablo has left
  62. adiaholic has left
  63. restive_monk has joined
  64. menel has left
  65. Kev has joined
  66. adiaholic has joined
  67. Kev has left
  68. Steve Kille has left
  69. Steve Kille has joined
  70. karoshi has joined
  71. adiaholic has left
  72. harry837374884 has left
  73. floretta has left
  74. Kev has joined
  75. floretta has joined
  76. adiaholic has joined
  77. harry837374884 has joined
  78. sbach has left
  79. sbach has joined
  80. Seve has left
  81. antranigv has left
  82. adiaholic has left
  83. Kev has left
  84. վարյա has left
  85. վարյա has joined
  86. karoshi has left
  87. Kev has joined
  88. antranigv has joined
  89. menel has joined
  90. adiaholic has joined
  91. վարյա has left
  92. վարյա has joined
  93. Yagiza has joined
  94. atomicwatch has left
  95. xnamed has left
  96. konstantinos has joined
  97. xnamed has joined
  98. neshtaxmpp has joined
  99. Kev has left
  100. nikhilmwarrier has joined
  101. Tobias has joined
  102. Tobias has left
  103. Tobias has joined
  104. Half-Shot has left
  105. Matthew has left
  106. homebeach has left
  107. uhoreg has left
  108. Half-Shot has joined
  109. Matthew has joined
  110. homebeach has joined
  111. uhoreg has joined
  112. Seve has joined
  113. xnamed has left
  114. sbach has left
  115. sbach has joined
  116. վարյա has left
  117. վարյա has joined
  118. karoshi has joined
  119. thndrbvr has left
  120. Sam has left
  121. Kev has joined
  122. xnamed has joined
  123. millesimus has left
  124. floretta has left
  125. millesimus has joined
  126. floretta has joined
  127. harry837374884 has left
  128. restive_monk has left
  129. Kev has left
  130. adiaholic has left
  131. restive_monk has joined
  132. adiaholic has joined
  133. karoshi has left
  134. atomicwatch has joined
  135. adiaholic has left
  136. adiaholic has joined
  137. eevvoor has left
  138. david has joined
  139. david has left
  140. yushyin has left
  141. Kev has joined
  142. restive_monk has left
  143. adiaholic has left
  144. nikhilmwarrier has left
  145. yushyin has joined
  146. sbach has left
  147. sbach has joined
  148. adiaholic has joined
  149. neshtaxmpp has left
  150. neshtaxmpp has joined
  151. goffi has joined
  152. adiaholic has left
  153. Kev has left
  154. jgart has joined
  155. millesimus has left
  156. millesimus has joined
  157. rebeld22 has left
  158. yushyin has left
  159. yushyin has joined
  160. Sam has joined
  161. jcbrand has left
  162. adiaholic has joined
  163. antranigv has left
  164. thndrbvr has joined
  165. msavoritias has joined
  166. antranigv has joined
  167. jcbrand has joined
  168. karoshi has joined
  169. thilo.molitor has left
  170. david has joined
  171. david has left
  172. jgart has left
  173. Kev has joined
  174. sbach has left
  175. sbach has joined
  176. Sam has left
  177. yushyin has left
  178. harry837374884 has joined
  179. djorz has joined
  180. antranigv has left
  181. antranigv has joined
  182. yushyin has joined
  183. yushyin has left
  184. yushyin has joined
  185. pjn has left
  186. david has joined
  187. david has left
  188. neshtaxmpp has left
  189. TheCoffeMaker has left
  190. konstantinos has left
  191. rion has left
  192. debacle has joined
  193. antranigv has left
  194. Paganini has left
  195. TheCoffeMaker has joined
  196. thilo.molitor has joined
  197. floretta has left
  198. floretta has joined
  199. վարյա has left
  200. վարյա has joined
  201. Kev has left
  202. sbach has left
  203. antranigv has joined
  204. marc has joined
  205. sbach has joined
  206. pjn has joined
  207. վարյա has left
  208. վարյա has joined
  209. djorz has left
  210. menel has left
  211. Kev has joined
  212. Kev has left
  213. nuron has left
  214. nuron has joined
  215. harry837374884 has left
  216. sbach has left
  217. վարյա has left
  218. վարյա has joined
  219. Kev has joined
  220. sbach has joined
  221. lskdjf has joined
  222. goffi has left
  223. millesimus has left
  224. վարյա has left
  225. վարյա has joined
  226. david has joined
  227. david has left
  228. sbach has left
  229. millesimus has joined
  230. goffi has joined
  231. david has joined
  232. david has left
  233. konstantinos has joined
  234. lovetox has left
  235. sbach has joined
  236. floretta has left
  237. floretta has joined
  238. stp has joined
  239. david has joined
  240. david has left
  241. SteveF has joined
  242. Tim R has joined
  243. lovetox has joined
  244. Yagiza has left
  245. sbach has left
  246. վարյա has left
  247. վարյա has joined
  248. վարյա has left
  249. վարյա has joined
  250. Sam has joined
  251. marc has left
  252. stp has left
  253. debacle has left
  254. goffi hi, what's the status of https://xmpp.org/extensions/xep-0424.html ? It's in last-call which is supposed to be ended since 2022-01-04…
  255. goffi ping jcbrand ^
  256. bean has joined
  257. Dele Olajide has joined
  258. sbach has joined
  259. Sam has left
  260. millesimus has left
  261. antranigv has left
  262. antranigv has joined
  263. Zash https://logs.xmpp.org/council/2022-01-05?p=h#2022-01-05-fa0ce69fd8b2d0be
  264. menel has joined
  265. david has joined
  266. david has left
  267. goffi Zash: Thanks. The XEP should not be updated to remove the last-call notice then?
  268. antranigv has left
  269. antranigv has joined
  270. վարյա has left
  271. վարյա has joined
  272. Zash Maybe, ask the editor?
  273. menel has left
  274. rion has joined
  275. Dele Olajide has left
  276. Dele Olajide has joined
  277. goffi right, I've let a note on editor@
  278. adiaholic has left
  279. goffi jcbrand: any plan to update this XEP? I'm asking because I'm about to implement it.
  280. antranigv has left
  281. antranigv has joined
  282. Thilo Molitor has left
  283. adiaholic has joined
  284. Thilo Molitor has joined
  285. antranigv has left
  286. david has joined
  287. david has left
  288. antranigv has joined
  289. վարյա has left
  290. վարյա has joined
  291. debacle has joined
  292. վարյա has left
  293. վարյա has joined
  294. david has joined
  295. david has left
  296. վարյա has left
  297. վարյա has joined
  298. sbach has left
  299. Yagiza has joined
  300. floretta has left
  301. marc has joined
  302. sbach has joined
  303. floretta has joined
  304. sbach has left
  305. վարյա has left
  306. վարյա has joined
  307. sbach has joined
  308. Yagiza has left
  309. harry837374884 has joined
  310. վարյա has left
  311. վարյա has joined
  312. debacle has left
  313. debacle has joined
  314. Yagiza has joined
  315. jcbrand goffi: AFAIK people didn't like the `<apply-to>` wrapper. It's already implemented in Converse and Gajim AFAIK. I've been meaning to study people's feedback and make adjustments but haven't found the time. Mainly because IMO it works well and I have many other things on my plate.
  316. jcbrand Probably one could get rid of `<apply-to>` and just have `<retract>` like we have for `<correction>` and then it might get accepted, unless there's something I forgot.
  317. goffi jcbrand: I see, thanks. Well I'll implement in current state, and will adapt when necessary.
  318. pjn has left
  319. millesimus has joined
  320. neshtaxmpp has joined
  321. adiaholic has left
  322. adiaholic has joined
  323. david has joined
  324. david has left
  325. adiaholic has left
  326. Dele Olajide has left
  327. Dele Olajide has joined
  328. adiaholic has joined
  329. Steve Kille has left
  330. Steve Kille has joined
  331. sbach has left
  332. marc has left
  333. sbach has joined
  334. stp has joined
  335. Wojtek has joined
  336. eab has left
  337. eab has joined
  338. Dele Olajide has left
  339. Dele Olajide has joined
  340. gooya has joined
  341. neshtaxmpp has left
  342. neshtaxmpp has joined
  343. eab has left
  344. eab has joined
  345. eab has left
  346. marc has joined
  347. eab has joined
  348. eab has left
  349. eab has joined
  350. adiaholic has left
  351. adiaholic has joined
  352. eab has left
  353. eab has joined
  354. eab has left
  355. վարյա has left
  356. eab has joined
  357. վարյա has joined
  358. eab has left
  359. eab has joined
  360. adiaholic has left
  361. eab has left
  362. eab has joined
  363. eab has left
  364. eab has joined
  365. stp has left
  366. eab has left
  367. eab has joined
  368. eab has left
  369. eab has joined
  370. nikhilmwarrier has joined
  371. վարյա has left
  372. վարյա has joined
  373. eab has left
  374. eab has joined
  375. eab has left
  376. eab has joined
  377. jinxd has joined
  378. eab has left
  379. eab has joined
  380. sbach has left
  381. sbach has joined
  382. sbach has left
  383. sbach has joined
  384. վարյա has left
  385. pjn has joined
  386. Sam has joined
  387. stp has joined
  388. sbach has left
  389. վարյա has joined
  390. jinxd has left
  391. harry837374884 has left
  392. sbach has joined
  393. antranigv has left
  394. Andrzej has joined
  395. neshtaxmpp has left
  396. neshtaxmpp has joined
  397. pjn has left
  398. Andrzej jcbrand, XEP-0424 is also implemented in SiskinIM and BeagleIM, and it works as expected
  399. emus has joined
  400. Mikaela has left
  401. rubi has left
  402. rubi has joined
  403. jcbrand Ah cool, good to know
  404. anamulhaque has joined
  405. sbach has left
  406. flow how do implementations behave is someone smuggels in an message with an origin-id that is identical the origin-id of a previous message that got retracted?
  407. flow how do implementations behave is someone smuggels in a message with an origin-id that is identical the origin-id of a previous message that got retracted?
  408. Zash abolish origin-id!
  409. Ge0rG halt and catch fire
  410. antranigv has joined
  411. Andrzej in our case, we are accepting those, but during lookup we are looking for the newest message with matching origin-id
  412. flow Andrzej, so I can un-retract a message by injecting a newer message with a duplicate origin-id?
  413. Andrzej no, it would result in a new message
  414. Andrzej only further references would be related to the new message
  415. Ge0rG how do you treat LMC on a retracted message?
  416. Ge0rG semantically, a message with the same origin-id should be treated as a duplicate of the original message, except when they have different stanza-ids. So I suppose it is safe to ignore everything with a seen-before origin-id.
  417. Ge0rG The other part of the question is about "operator precedence" of message-modifying messages. Does LMC beat retraction? Does moderator retraction beat LMC?
  418. jcbrand Depends on what is received first? In any case, LMC on a retracted message is moot, since the message has been retracted
  419. Ge0rG jcbrand: what about: I send something obscene, the message is retracted by mods, I edit it to remove the obscenity?
  420. sbach has joined
  421. jcbrand It's already retracted, so your correction can no longer be applied
  422. jcbrand TBH, I'm not sure how much I've tested such edge cases, but that's what I would expect
  423. jcbrand i.e. retraction has precedence over corrections
  424. jcbrand should perhaps be mentioned in the XEP
  425. Andrzej I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to edit it
  426. harry837374884 has joined
  427. Andrzej I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to correct it
  428. jcbrand No, but a cilent that doesn't support retractions could allow it
  429. flow I am still very skeptical to reference previous messages by origin-id, as opposed to using stanza-id, i.e. the securely combined values of the stanza-id 'by' and 'id' attribute
  430. pjn has joined
  431. Ge0rG You could race a retraction and an edit from different clients. Or just use an XML console
  432. jcbrand flow you don't always have the stanza-id. For example when you want to retract a message you just sent
  433. Ge0rG flow: let's just get rid of origin-id then, okay?
  434. Ge0rG jcbrand: that's a point I've tried to make for a while. I suppose you need to keep a list of in-flight messages and delay updates that reference them until they've been MAMed
  435. flow jcbrand, surely you can wait till you observe the messsage reflection containing the stanza-id. you want to wait for it anyways before you show it as received by the channel
  436. jcbrand 1:1 messages don't get reflected
  437. Ge0rG jcbrand: that's another wart on the design of MAM
  438. anamulhaque has left
  439. jcbrand It's been a while, but I'm pretty sure Converse prioritizes stanza-id over oriring-id
  440. flow jcbrand, yeah, what Ge0rG said. but you could always query your local MAM to get the stanza-id of the message
  441. Ge0rG would be great to receive a carbon shell on each sent message that was put into MAM
  442. Ge0rG flow: that's like the worst design idea ever
  443. flow surely not ideal
  444. jcbrand Yeah, I'm not doing that
  445. konstantinos has left
  446. flow in any case, I believe it is possible to use stanza-id in the MUC(/MIX) case, and the XEPs should reflect that
  447. flow as I wrote a while ago to standards@, using origin-id is prone to id-impersonating issues
  448. վարյա has left
  449. վարյա has joined
  450. jcbrand origin-id should be matched with the `from` attribute
  451. jcbrand That's kind of obvious, no?
  452. Ge0rG flow: let's just get rid of origin-id then, okay?
  453. flow jcbrand, it isn't and afaik it's nowhere specified
  454. Ge0rG needs to put that on a key binding.
  455. jcbrand If you match origin-id with `from` there's no impersonation risk
  456. vanitasvitae has left
  457. flow probably, but this should be explicitly spelled out then. I fear a lot of implementations treat origin-id as being magical by itself, when there is no authoritiy that authenticates those IDs
  458. jcbrand It's mentioned in the security considerations of XEP-424 https://xmpp.org/extensions/xep-0424.html#security
  459. *IM* has left
  460. flow that could be enough, since it appears to limit retractions to be send only by the "owner" of the retracted message. But I always have the 'fastening' case in mind, where anyone can react with a +1 on somebody else's message, and it's IMHO also based on origin-id
  461. jcbrand Retracting someone else's message is XEP-425
  462. flow which kinda makes it susceptible to the kind of attacks where I replace the message you just +1'ed with a different message…
  463. jcbrand yes, that sounds broken
  464. jcbrand `origin-id` works when the person doing the modification is the sender of the original message
  465. jcbrand `origin-id` works when the person doing the modification is always the sender of the original message
  466. jcbrand which is the case with retractions
  467. flow true, I am less concerned now, aftter discussing this
  468. flow true, I am less concerned now, after discussing this
  469. vanitasvitae has joined
  470. flow although, I believe the buisness rules and security considerations of xep425 could be better stated (but isn't that always the case?)
  471. *IM* has joined
  472. adiaholic has joined
  473. jcbrand Is there something specific that you're missing?
  474. sbach has left
  475. flow mostly discussion of the threats to motivate the buisness rules
  476. adiaholic has left
  477. Sam has left
  478. xecks has left
  479. xecks has joined
  480. Sam has joined
  481. Thilo Molitor has left
  482. sbach has joined
  483. Thilo Molitor has joined
  484. chipmnk has left
  485. chipmnk has joined
  486. adiaholic has joined
  487. vanitasvitae has left
  488. vanitasvitae has joined
  489. MattJ Remind me why we're still using origin-id?
  490. nikhilmwarrier has left
  491. adiaholic has left
  492. adiaholic has joined
  493. Wojtek has left
  494. sbach has left
  495. papatutuwawa has joined
  496. david has joined
  497. david has left
  498. vanitasvitae has left
  499. vanitasvitae has joined
  500. jcbrand because you don't get reflection for 1:1 chats
  501. adiaholic has left
  502. adiaholic has joined
  503. Zash Okay, but why origin-id when there's the stanza@id ?
  504. sbach has joined
  505. jcbrand because you don't have that without reflection
  506. Zash huh? but, _you_ set that?
  507. nikhilmwarrier has joined
  508. jcbrand do you set your own stanza-ids when you send messages?
  509. Zash `<message id="THIS"/>`
  510. jcbrand oh sorry, that id
  511. jcbrand because they have no guarantee of being unique
  512. Zash ... when _you_ yourself set them?
  513. Zash and then later refer to your own messages (in the context of XEP-0424)
  514. jcbrand I see what you're getting at, but I don't see how this is better than using origin-id, particularly because clients (devs) have been conditioned to not trust the id to be unique
  515. MattJ Right, is it wrong to question that conditioning?
  516. MattJ Devs are also complaining about how many ids we have
  517. MattJ And yes, it is getting a bit silly
  518. jcbrand Converse in any case makes the origin-id and the id the same, like Conversations
  519. MattJ The number of times I've had "oh no, when I said 'the id of the stanza I meant...' conversations with devs"
  520. Zash Every message needs at least 5 ids and 3 timestamps!
  521. neshtaxmpp has left
  522. neshtaxmpp has joined
  523. jcbrand Obviously unique ids would have been ideal, but my impression was that that ship has sailed
  524. MattJ The number of times I've had "oh no, when I said 'the id of the stanza' I meant..." conversations with devs
  525. MattJ I don't think it has, but people continue to push the ship further out, and I like to speak up when I see that happening. I and a number of other people really think that origin-id should be deprecated.
  526. MattJ Not used in more and more specs
  527. jcbrand meh 🙂
  528. jcbrand I really don't see the harm here
  529. Wojtek has joined
  530. Zash ```xml <message id='fa137ce375c641e5808cbcff88770973' type='groupchat' xml:lang='en' from='xsf@muc.xmpp.org/MattJ'> <origin-id id='fa137ce375c641e5808cbcff88770973' xmlns='urn:xmpp:sid:0'/> <body>And yes, it is getting a bit silly</body> <active xmlns='http://jabber.org/protocol/chatstates'/> <occupant-id id='Im3knKDDFlUHyEv8Cj9d/Vx/KnTelRKocoOQSB3SncM=' xmlns='urn:xmpp:occupant-id:0'/> <stanza-id id='2022-05-25-c7615d7b398f5235' xmlns='urn:xmpp:sid:0' by='xsf@muc.xmpp.org'/> <delay xmlns='urn:xmpp:delay' stamp='2022-05-25T12:31:52Z' from='xsf@muc.xmpp.org'/> </message> ``` Count the number of IDs!
  531. jcbrand It's more explicit than relying on an idea where there is no guarantee of uniqueness
  532. Kev If we assume that stanza@id is stable now, origin-id gives us nothing, does it?
  533. emus has left
  534. MattJ There's also no guarantee that either 'id' or 'origin-id' even exist, so you still have to handle that case either way
  535. jcbrand it's not stable, there are still clients that don't have unique stanza@id
  536. lovetox has left
  537. Zash Kev, in-message promise that the id is unique?
  538. Mikaela has joined
  539. Zash So it could just be `<origin-id/>` without the id
  540. jcbrand MattJ: XEP-424 mandates origin-id, so it must be there
  541. Kev Ah, uniqueness between clients and sessions, right.
  542. MattJ jcbrand, right, so why can't it just mandate that @id is unique?
  543. mdosch How to know whether it's unique when you just create a random string?
  544. MattJ Same thing
  545. emus has joined
  546. jcbrand I guess it can, but since that was already mandated for origin-id, it seemed simpler to just use that.
  547. Zash `<message id="uuid"><{I-promise}id-is-unique/></>`
  548. MattJ Zash, but even then you have to deal with the absence of that (e.g. if you have a legacy client on your account)
  549. MattJ Same as if you "mandate" origin-id
  550. jcbrand To me, it seems like more dev overhead. Now you have to know that there are some cases where stanza@id is unique and others where you can't rely on it being unique
  551. jcbrand better to just say it's not unique
  552. Kev That's just the same as origin-id, though, where it might be missing.
  553. Kev Isn't it?
  554. jcbrand I don't see how it's the same
  555. MattJ It's not more dev overhead, it's exactly the same but with additional useless syntax
  556. jcbrand explicit is better than implicit
  557. jcbrand implicit = more overhead
  558. MattJ So state explicitly in the XEP that any client supporting MUST use unique @id attributes
  559. jcbrand it's not the same IMO
  560. MattJ and that removes a needless dependency on a XEP that many of us want to deprecate
  561. jcbrand it's not explicit in the stanza in that case
  562. jcbrand why do you want to deprecate it?
  563. Half-Shot has left
  564. homebeach has left
  565. Matthew has left
  566. uhoreg has left
  567. Half-Shot has joined
  568. Matthew has joined
  569. homebeach has joined
  570. uhoreg has joined
  571. MattJ Because it's additional overhead, duplicated information and confusing
  572. jcbrand so having stanza@id sometimes being unique and sometimes not is not confusing?
  573. MattJ No, it should always be unique in any modern client, and we should push for that
  574. jcbrand yes but people us non-modern clients as well
  575. MattJ But adding additional syntax doesn't really help, because you still have to deal with the case where it is not unique or missing
  576. jcbrand > you still have to deal with the case where it is not unique I don't agree, IMO you can assume that origin-id together with `from` is always unique
  577. MattJ But origin-id is not always there
  578. jcbrand if it's missing, then that's also explicit
  579. jcbrand I'll have to go check, but IIRC I rely on origin-id quite a bit in Converse to dedupe messages
  580. jonas’ jcbrand, what about an attacker? :)
  581. jcbrand And I think a web-client has to care much more about deduping than other clients
  582. jonas’ someone maliciously setting origin-id to equal values
  583. jcbrand jonas’ If you match `from` and origin-id then attack doesn't work
  584. jonas’ depends on the attack I suppose
  585. jcbrand jonas’ In any case, that would apply to stanza@id also
  586. jonas’ exactly
  587. jonas’ making origin-id useless
  588. jonas’ there is no gain here, you need to be equipped to deal with duplicate or missing IDs, because clients can be legacy or malicious/buggy
  589. jonas’ and it shouldn't break your client
  590. jcbrand I never said that I'm pro origin-id to prevent attacks that can happen with stanza@id
  591. jonas’ that's not what I said either
  592. jcbrand The gain here is that you can safely assume that origin-id (with `from`) is unique
  593. jonas’ I just said that there is absolutely zero gain with origin-id
  594. jonas’ no, you can't
  595. jcbrand Yes you can
  596. jonas’ no, it's remote data. You can never assume any property like uniqueness about it.
  597. MattJ Yeah, you can assume it is, but it might be wrong. But that's a whole other level :)
  598. jonas’ you can work on the basis that it probably is, but you absolutely need to gracefully handle cases where it isn't. and then there is zero (0) gain of using origin-id over @id
  599. jonas’ fair
  600. jonas’ words!
  601. jcbrand I don't agree
  602. jonas’ I finally get proper pressure values from my sensors now, so I'll tune out and bring my sensor network back up again.
  603. MattJ You don't agree? I could modify my client today to send <origin-id id='hello world'/> on every message
  604. jcbrand and then that's your problem?
  605. jcbrand you're not following the spec
  606. MattJ That depends what you're using it for
  607. jonas’ jcbrand, if that's just MattJs problem, then why not use message@id? :)
  608. jcbrand sigh
  609. MattJ Sure I'm not following the spec, but if you're relying on every entity to follow spec behaviour, that could cause problems for you
  610. jcbrand because message@id is not guaranteed to be unique, so if he did that with message@id it would still be spec compliant
  611. MattJ It really depends what you're using it for
  612. jcbrand to some extent
  613. MattJ It wouldn't be compliant in any XEP-0424 client
  614. jcbrand sure, so you're retractions don't work
  615. Guus Failed to connect, CredSSP required by server
  616. jcbrand sure, so your retractions don't work
  617. MattJ Correct
  618. vanitasvitae has left
  619. jcbrand actually, if you had duplicate message@id your retractions will still work if you have unique origin-id
  620. jcbrand that's the whole point
  621. jcbrand In any case, I mentioned deduping, to which no-one responded
  622. MattJ That doesn't make much sense, why would I have duplicate @id and unique origin-id?
  623. jcbrand it's not just about you, it's about the fact that other clients don't have unique message@id
  624. MattJ Yes, definitely not denying that some clients might not send a unique @id, or not send any @id at all
  625. Kev Forget all about stanza@id except on id, and only use origin-id. Best of all worlds ;D
  626. MattJ But you also can't deny that such clients also don't send origin-id
  627. Kev Forget all about stanza@id except on iq, and only use origin-id. Best of all worlds ;D
  628. MattJ or that some clients send unique @id and no origin-id
  629. jcbrand I don't deny, to me this isn't only about XEP-424
  630. MattJ Kev, and then error tracking becomes horrible
  631. Kev Note the ;D :)
  632. MattJ Someone might take you seriously :P
  633. jcbrand It's about the fact that I use origin-id to dedupe
  634. jcbrand regardless of XEP-424
  635. Kev > Someone might take you seriously :P Not in my experience.
  636. MattJ jcbrand, I understand that. And your mention of that wasn't ignored... all these arguments apply to de-dupe as well
  637. jcbrand And personally I'm not that interested in making even more complicated deduping rules because people want to remove origin-id and then have message@id be guaranteed unique in some cases but not in others
  638. MattJ Note that it's not just about removing origin-id, it's not like it's universally sent today
  639. jonas’ ok, can someone please load a module on this MUC server which sets origin-id to hello world for all messages? kthxbai
  640. MattJ So the point is that your de-dupe today is breaking with clients that don't send unique @id
  641. MattJ (I assume)
  642. MattJ It won't break if they send unique @id, I assume
  643. jcbrand jonas’ Converse gives priority to stanza-id
  644. MattJ The presence of origin-id has no effect on the outcome
  645. jonas’ I've got an idea
  646. jcbrand MattJ: It has an effect in the sense that I can't know if someone's client sends a unique @id or not
  647. jcbrand except for certain edge cases like when a retraction is included
  648. jonas’ modify '359 to say: If the `id` attribute of `<origin-id/>` is empty, it MUST be assumed to be equal to the `id` attribute on the containing stanza.
  649. jonas’ modify '359 to say: If the `id` attribute of `<origin-id/>` is empty, it MUST be assumed to be equal to the `id` attribute on the containing stanza and the sending entity MUST adhere to the same rules for that ID as it would have for `<origin-id/>`.
  650. MattJ 😣
  651. vanitasvitae has joined
  652. MattJ That helps with the "too many ids" confusion, but it's still... meh. Now we have to send this tag in every message for the rest of eternity?
  653. jonas’ nah, we'll wait until most people have forgotten that it exists and just use @id directly and then drop it ;)
  654. Zash XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error
  655. jcbrand I have to leave
  656. MattJ jcbrand, you said origin-id tells you if the stanza id is unique. What do you do with this information?
  657. Zash Time to dig up the idea of IDs being based on a (stream-id, stanza-counter) tuple?
  658. MattJ Okay, later :)
  659. jcbrand MattJ use it to dedupe
  660. Daniel > XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error Unique and sequential UUIDv6
  661. MattJ and if it's not unique, no de-dupe happens?
  662. jcbrand I have other heuristics
  663. MattJ *if it may not be unique
  664. jcbrand but nothing as nice as having a unique id
  665. Zash Daniel, the time+random one? mmmmmmmmmmmmm
  666. Zash I just wish it was more compact
  667. jcbrand ok, bye, I'll be back later
  668. Kev Amusingly I've been looking at stuff recently where guaranteed-unique IDs are a problem and I need to get rid of them :D
  669. MattJ See you!
  670. vanitasvitae has left
  671. *IM* has left
  672. lovetox has joined
  673. sbach has left
  674. adiaholic has left
  675. adiaholic has joined
  676. vanitasvitae has joined
  677. konstantinos has joined
  678. sbach has joined
  679. menel has joined
  680. Andrzej has left
  681. marc has left
  682. msavoritias has left
  683. sbach has left
  684. rebeld22 has joined
  685. Paganini has joined
  686. msavoritias has joined
  687. sbach has joined
  688. lovetox has left
  689. konstantinos has left
  690. andrey.g has joined
  691. millesimus has left
  692. millesimus has joined
  693. msavoritias has left
  694. adiaholic has left
  695. andrey.g has left
  696. msavoritias has joined
  697. msavoritias has left
  698. Andrzej has joined
  699. msavoritias has joined
  700. adiaholic has joined
  701. lovetox has joined
  702. konstantinos has joined
  703. menel has left
  704. neshtaxmpp has left
  705. neshtaxmpp has joined
  706. msavoritias has left
  707. msavoritias has joined
  708. *IM* has joined
  709. sbach has left
  710. sbach has joined
  711. konstantinos has left
  712. xnamed has left
  713. xnamed has joined
  714. marc has joined
  715. Mikaela has left
  716. Mikaela has joined
  717. millesimus has left
  718. coleman has left
  719. millesimus has joined
  720. *IM* has left
  721. sbach has left
  722. thndrbvr has left
  723. menel has joined
  724. *IM* has joined
  725. Seve https://thehackernews.com/2022/05/new-zoom-flaws-could-let-attackers-hack.html?m=1
  726. moparisthebest Seve, sorry we already discussed that yesterday :D
  727. Seve Guessed so.. haha
  728. Zash Do you want to know more? https://logs.xmpp.org/xsf/2022-05-24?p=h#2022-05-24-7f462f13fbf0be1b
  729. *IM* has left
  730. moparisthebest it's a (unpatched) gloox bug, maintainer hasn't responded yet, 2 expat bugs, and an (unpatched, but may be mitigated by the expat fixes) ejabberd bug
  731. Andrzej has left
  732. moparisthebest and, a (presumably novel) general XMPP attack we now need to watch out for
  733. jonas’ what general xmpp attack?
  734. sbach has joined
  735. Zash HACK
  736. moparisthebest 'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1
  737. jonas’ ah
  738. jonas’ I see I should've shouted louder when that happened in aioxmpp :)
  739. *IM* has joined
  740. moparisthebest crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes"
  741. Kev Interestingly, if servers cared about validating things in jabber:(client|server), this wouldn't happen. normative schemas anyone? :)
  742. Kev > crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes" I struggle to produce an argument against it.
  743. jonas’ please no normative schemas
  744. moparisthebest then servers+clients could read X more bytes, parse it to exactly 1 stanza, and if it parsed to more, hack, throw it away, stream error
  745. jonas’ moparisthebest, that requires to know the length ahead-of-time when sending
  746. moparisthebest right, which since we all agree on stanza size limits you must know anyway
  747. Kev It would make XML parsing in general quite a lot easier for clients and servers.
  748. jonas’ well you could also just try ;)
  749. jonas’ (and see if your peer kills you for it)
  750. Kev (Or, at least, in I think all the implementations I've worked with it would have reduced some complexity)
  751. moparisthebest the only argument for streaming stanzas of unknown-length is malicious https://www.moparisthebest.com/eatxmempp-cve-2021-32918/
  752. msavoritias has left
  753. jonas’ moparisthebest, no, I think arguments can be had which are not malicious, but likely not in federated networks
  754. jonas’ (because generic XMPP software will suffer from stuff like eatxmempp indeed)
  755. moparisthebest then I don't care, they can use XMPP 1.0, or likely their own variant like whatsapp does
  756. sbach has left
  757. adiaholic has left
  758. adiaholic has joined
  759. konstantinos has joined
  760. msavoritias has joined
  761. msavoritias has left
  762. msavoritias has joined
  763. adiaholic has left
  764. sbach has joined
  765. APach has joined
  766. rumin-miller has joined
  767. adiaholic has joined
  768. rumin-miller has left
  769. krauq has left
  770. krauq has joined
  771. raghavgururajan has joined
  772. adiaholic has left
  773. neshtaxmpp has left
  774. neshtaxmpp has joined
  775. konstantinos has left
  776. xnamed has left
  777. nikhilmwarrier has left
  778. adiaholic has joined
  779. konstantinos has joined
  780. nuron has left
  781. nuron has joined
  782. stp has left
  783. junaid has left
  784. junaid has joined
  785. Andrzej has joined
  786. stp has joined
  787. djorz has joined
  788. msavoritias has left
  789. nikhilmwarrier has joined
  790. floretta has left
  791. Ingolf has left
  792. floretta has joined
  793. sbach has left
  794. papatutuwawa has left
  795. sbach has joined
  796. Tim R has left
  797. msavoritias has joined
  798. harry837374884 has left
  799. Ingolf has joined
  800. gooya has left
  801. nikhilmwarrier has left
  802. Dele Olajide has left
  803. Dele Olajide has joined
  804. wladmis has left
  805. wladmis has joined
  806. gooya has joined
  807. xnamed has joined
  808. harry837374884 has joined
  809. Steve Kille has left
  810. emus I saw that has been a hot discussion. But could someone volunteer to summarize the issue with Zoom for me? On a rather general level, as I lag most knowledge :-/ (no troll)
  811. Steve Kille has joined
  812. Steve Kille has left
  813. Steve Kille has joined
  814. nikhilmwarrier has joined
  815. krauq has left
  816. moparisthebest > it's a (unpatched) gloox bug, maintainer hasn't responded yet, 2 expat bugs, and an (unpatched, but may be mitigated by the expat fixes) ejabberd bug > and, a (presumably novel) general XMPP attack we now need to watch out for > 'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1 emus I *think* that's a fair summary ^
  817. moparisthebest the reason this was catastrophic in zoom is the second stanza smuggled in told the client to download a binary and execute it, don't think any XMPP things on the public federated network do anything that stupid
  818. konstantinos has left
  819. emus So, it was not know, but also no practice out there in the wild XMPP?
  820. Kev has left
  821. Tim R has joined
  822. emus but thanks for responding!
  823. moparisthebest not really known before, but apparantly jonas’ experienced similar in aioxmpp just didn't spread it around :D
  824. moparisthebest you could pull off the same hack right now on a user of Renga if they were connected to a server without a patched expat
  825. moparisthebest "hi this is your admin" - from admin@yourserver
  826. qy can zoom federate?
  827. moparisthebest seriously doubt it
  828. emus moparisthebest: thanks
  829. raghavgururajan has left
  830. adiaholic has left
  831. stp has left
  832. krauq has joined
  833. adiaholic has joined
  834. neshtaxmpp has left
  835. neshtaxmpp has joined
  836. bung has joined
  837. debacle has left
  838. sbach has left
  839. Tobias has left
  840. Tobias has joined
  841. Tobias has left
  842. Tobias has joined
  843. adiaholic has left
  844. sbach has joined
  845. Kev has joined
  846. Sam has left
  847. nikhilmwarrier has left
  848. stp has joined
  849. Sam has joined
  850. TheCoffeMaker jonas’, ping sent u a message regarding a ping account for observe.jabber.network
  851. Tobias has left
  852. Tobias has joined
  853. jonas’ TheCoffeMaker, ah yes, I meant to reply to that
  854. Fishbowler has left
  855. Fishbowler has joined
  856. TheCoffeMaker jonas’, no problem!
  857. adiaholic has joined
  858. debacle has joined
  859. papatutuwawa has joined
  860. Tobias has left
  861. Tobias has joined
  862. Tobias has left
  863. Tobias has joined
  864. floretta has left
  865. Tobias has left
  866. Tobias has joined
  867. jinxd has joined
  868. Kev has left
  869. Tobias has left
  870. Tobias has joined
  871. adiaholic has left
  872. adiaholic has joined
  873. adiaholic has left
  874. debacle has left
  875. Tobias has left
  876. Tobias has joined
  877. adiaholic has joined
  878. bean has left
  879. sbach has left
  880. david has joined
  881. david has left
  882. rubi has left
  883. rubi has joined
  884. Tobias has left
  885. Tobias has joined
  886. *IM* has left
  887. Tobias has left
  888. Tobias has joined
  889. coleman has joined
  890. debacle has joined
  891. Tobias has left
  892. Tobias has joined
  893. sbach has joined
  894. konstantinos has joined
  895. SteveF has left
  896. Tobias has left
  897. Tobias has joined
  898. david has joined
  899. david has left
  900. rubi has left
  901. rubi has joined
  902. Tobias has left
  903. Tobias has joined
  904. sbach has left
  905. stp has left
  906. *IM* has joined
  907. stp has joined
  908. Kev has joined
  909. chipmnk has left
  910. chipmnk has joined
  911. floretta has joined
  912. Tobias has left
  913. Tobias has joined
  914. sbach has joined
  915. Wojtek has left
  916. adiaholic has left
  917. Tobias has left
  918. Tobias has joined
  919. Tobias has left
  920. Tobias has joined
  921. Tobias has left
  922. Tobias has joined
  923. adiaholic has joined
  924. Kev has left
  925. Ingolf has left
  926. adiaholic has left
  927. Ingolf has joined
  928. neshtaxmpp has left
  929. neshtaxmpp has joined
  930. *IM* has left
  931. adiaholic has joined
  932. bung has left
  933. krauq has left
  934. Andrzej has left
  935. adiaholic has left
  936. krauq has joined
  937. daags has left
  938. daags has joined
  939. bung has joined
  940. adiaholic has joined
  941. Alex has left
  942. Kev has joined
  943. Alex has joined
  944. floretta has left
  945. sbach has left
  946. Andrzej has joined
  947. adiaholic has left
  948. sbach has joined
  949. Sam has left
  950. Sam has joined
  951. Tim R has left
  952. Kev has left
  953. sbach has left
  954. Half-Shot has left
  955. homebeach has left
  956. Matthew has left
  957. uhoreg has left
  958. Half-Shot has joined
  959. Matthew has joined
  960. homebeach has joined
  961. uhoreg has joined
  962. floretta has joined
  963. wgreenhouse has left
  964. wgreenhouse has joined
  965. harry837374884 has left
  966. sbach has joined
  967. southerntofu has joined
  968. Andrzej has left
  969. thndrbvr has joined
  970. *IM* has joined
  971. adiaholic has joined
  972. adiaholic has left
  973. Andrzej has joined
  974. Sam has left
  975. Andrzej has left
  976. Sam has joined
  977. xecks has left
  978. antranigv has left
  979. antranigv has joined
  980. Kev has joined
  981. sbach has left
  982. adiaholic has joined
  983. Yagiza has left
  984. pablo has joined
  985. antranigv has left
  986. sbach has joined
  987. վարյա has left
  988. վարյա has joined
  989. mh has left
  990. Kev has left
  991. adiaholic has left
  992. Sam has left
  993. millesimus has left
  994. adiaholic has joined
  995. floretta has left
  996. adiaholic has left
  997. bung has left
  998. Sam has joined
  999. millesimus has joined
  1000. floretta has joined
  1001. edhelas has left
  1002. edhelas has joined
  1003. millesimus has left
  1004. stp has left
  1005. millesimus has joined
  1006. mh has joined
  1007. floretta has left
  1008. stp has joined
  1009. Kev has joined
  1010. floretta has joined
  1011. pjn has left
  1012. jinxd has left
  1013. sbach has left
  1014. Tim R has joined
  1015. Tim R has left
  1016. Tim R has joined
  1017. Kev has left
  1018. sbach has joined
  1019. kujiu has left
  1020. floretta has left
  1021. kujiu has joined
  1022. pjn has joined
  1023. floretta has joined
  1024. msavoritias has left
  1025. millesimus has left
  1026. chipmnk has left
  1027. chipmnk has joined
  1028. jinxd has joined
  1029. millesimus has joined
  1030. adiaholic has joined
  1031. Dele Olajide has left
  1032. adiaholic has left
  1033. Sam has left
  1034. xecks has joined
  1035. Sam has joined
  1036. adiaholic has joined
  1037. krauq has left
  1038. krauq has joined
  1039. jinxd has left
  1040. Kev has joined
  1041. Sam has left
  1042. adiaholic has left
  1043. Sam has joined
  1044. bung has joined
  1045. Tobias has left
  1046. karoshi has left
  1047. adiaholic has joined
  1048. sbach has left
  1049. Kev has left
  1050. Tim R has left
  1051. adiaholic has left
  1052. krauq has left
  1053. adiaholic has joined
  1054. marc0s has left
  1055. Half-Shot has left
  1056. Matthew has left
  1057. uhoreg has left
  1058. homebeach has left
  1059. Half-Shot has joined
  1060. Matthew has joined
  1061. homebeach has joined
  1062. uhoreg has joined
  1063. marc0s has joined
  1064. sbach has joined
  1065. krauq has joined
  1066. menel has left
  1067. debacle has left
  1068. adiaholic has left
  1069. papatutuwawa has left
  1070. adiaholic has joined
  1071. Ingolf has left
  1072. adiaholic has left
  1073. bung has left
  1074. bung has joined
  1075. phoebos has joined
  1076. phoebos has left
  1077. floretta has left
  1078. Ingolf has joined
  1079. pjn has left
  1080. adiaholic has joined
  1081. konstantinos has left
  1082. stp has left
  1083. RayTutu has joined
  1084. adiaholic has left
  1085. floretta has joined
  1086. Kev has joined
  1087. millesimus has left
  1088. pjn has joined
  1089. adiaholic has joined
  1090. goffi has left
  1091. marc has left
  1092. marc has joined
  1093. adiaholic has left
  1094. Kev has left
  1095. adiaholic has joined
  1096. Mx2 has left
  1097. marc has left
  1098. marc has joined
  1099. sbach has left
  1100. adiaholic has left
  1101. Mx2 has joined
  1102. sbach has joined
  1103. lskdjf has left
  1104. վարյա has left
  1105. Kev has joined
  1106. neshtaxmpp has left
  1107. վարյա has joined
  1108. neshtaxmpp has joined
  1109. nuron has left
  1110. neshtaxmpp has left
  1111. floretta has left
  1112. floretta has joined
  1113. neshtaxmpp has joined
  1114. adiaholic has joined
  1115. Friendly Resident Cynic has left
  1116. Friendly Resident Cynic has joined
  1117. neshtaxmpp has left
  1118. Kev has left
  1119. millesimus has joined
  1120. neshtaxmpp has joined
  1121. adiaholic has left
  1122. neshtaxmpp has left
  1123. emus has left
  1124. adiaholic has joined
  1125. neshtaxmpp has joined