XSF Discussion - 2019-07-18

  1. lnj has joined
  2. wojtek has left
  3. Chobbes has joined
  4. vanitasvitae has left
  5. vanitasvitae has joined
  6. waqas has joined
  7. Lance has joined
  8. Lance has left
  9. Lance has joined
  10. mimi89999 has left
  11. mimi89999 has joined
  12. ziggys has left
  13. mimi89999 has left
  14. mimi89999 has joined
  15. mimi89999 has left
  16. mimi89999 has joined
  17. alacer has joined
  18. mimi89999 has left
  19. mimi89999 has joined
  20. remko has joined
  21. ziggys has joined
  22. mimi89999 has left
  23. mimi89999 has joined
  24. debacle has left
  25. remko has left
  26. ziggys has left
  27. ziggys has joined
  28. ziggys has left
  29. ziggys has joined
  30. Douglas Terabyte has left
  31. Douglas Terabyte has joined
  32. remko has joined
  33. Chobbes has left
  34. Lance has left
  35. Lance has joined
  36. neshtaxmpp has joined
  37. remko has left
  38. ziggys has left
  39. lnj has left
  40. pdurbin has joined
  41. pdurbin has left
  42. pdurbin has joined
  43. lskdjf has left
  44. adityaborikar has left
  45. adityaborikar has joined
  46. adityaborikar has left
  47. adityaborikar has joined
  48. adityaborikar has left
  49. adityaborikar has joined
  50. karoshi has joined
  51. pdurbin has left
  52. pdurbin has joined
  53. adityaborikar has left
  54. adityaborikar has joined
  55. Nekit has joined
  56. adityaborikar has left
  57. adityaborikar has joined
  58. adityaborikar has left
  59. adityaborikar has joined
  60. david has left
  61. lee has left
  62. lee has joined
  63. wurstsalat has joined
  64. adityaborikar has left
  65. valo has left
  66. valo has joined
  67. goffi has joined
  68. goffi has left
  69. goffi has joined
  70. goffi has left
  71. goffi has joined
  72. david has joined
  73. adityaborikar has joined
  74. adityaborikar has left
  75. adityaborikar has joined
  76. remko has joined
  77. igoose has left
  78. igoose has joined
  79. moparisthebest has left
  80. moparisthebest has joined
  81. COM8 has joined
  82. alacer has left
  83. alacer has joined
  84. adityaborikar has left
  85. Mikaela has joined
  86. COM8 has left
  87. adityaborikar has joined
  88. Syndace has left
  89. Syndace has joined
  90. sezuan has joined
  91. adityaborikar has left
  92. adityaborikar has joined
  93. vanitasvitae has left
  94. vanitasvitae has joined
  95. Guus has left
  96. Guus has joined
  97. waqas has left
  98. waqas has joined
  99. valo has left
  100. valo has joined
  101. mimi89999 has left
  102. igoose has left
  103. mimi89999 has joined
  104. Yagiza has joined
  105. valo has left
  106. waqas has left
  107. igoose has joined
  108. Lance has left
  109. Lance has joined
  110. Kev has joined
  111. valo has joined
  112. Lance has left
  113. Lance has joined
  114. rion has left
  115. rion has joined
  116. adityaborikar has left
  117. adityaborikar has joined
  118. patrick has left
  119. valo has left
  120. alacer has left
  121. debacle has joined
  122. alacer has joined
  123. valo has joined
  124. larma has left
  125. larma has joined
  126. pdurbin has left
  127. Lance has left
  128. rion I'm planning to provide some improvements to SIMS xep. And I think this recent unique MUC occupant id xep would be useful here. Is it going to be published any soon?
  129. jonas’ rion, I expect it to be accepted
  130. jonas’ but that’s just me ;)
  131. jonas’ still lacks two council votes because the respective members weren’t available for the meeting yesterday
  132. jonas’ which means it’ll probably be dealt with next wednesday
  133. igoose has left
  134. Zash What kind of improvements?
  135. Ge0rG The biggest issue I have with the occupant-id thing is that IT'S NOT ANONYMOUS!
  136. ralphm Anonymity is in the eye of the beholder?
  137. Ge0rG it's effectively adding a pseudonym for each bare JID in a MUC.
  138. jonas’ my sarcasmometer isn’t sure about what you’re doing
  139. Ge0rG I'm not saying it's bad or wrong, just that the name doesn't fit.
  140. jonas’ my sarcasmometer isn’t sure about what you’re saying
  141. ralphm Ah, right.
  142. jonas’ Ge0rG, you didn’t mention that yesterday
  143. jonas’ but then again, MUC is pseudonymous in itself, it won’t get better than that?
  144. ralphm It would be better if that were more explicit.
  145. Ge0rG jonas’: it's a different kind of pseudonymous
  146. ralphm Anonymity for occupants v.s. admins, right?
  147. Ge0rG one could hash (muc-jid, nickname, bare-user-jid) together to allow nick changes to become identity changes.
  148. Ge0rG jonas’: I didn't mention it because it was not critical for what the XEP is supposed to do
  149. pep. Ge0rG, I think one of the goal is not to include nick in there
  150. pep. Ge0rG, I think one of the goals is not to include nick in there
  151. pep. But yeah that could be made explicit
  152. Ge0rG I still think that making it a proxy-JID on top of the MUC service domain would be a Good Thing™, and then just stuff it into messages and presence.
  153. jonas’ Ge0rG, ITYM making MIX?
  154. ralphm This
  155. pep. Ge0rG, I also have something like that in mind
  156. pep. But it's not incompatible
  157. jonas’ are you going to re-invent MIX in worse on top MUC?
  158. ralphm I think doing MIX is a much better use of time than attempting to bolt things onto MUC even further.
  159. pep. worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fix 4 things into 3 (is that the one?)
  160. pep. worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fit 4 things into 3 (is that the one?)
  161. Ge0rG pep.: yeah, it's the one
  162. jonas’ pep., you’ll end up in the same situation with MUC, plus the additional issues from the different participant model
  163. ralphm Of course a MIX service could still expose a MUC interface/facade.
  164. Ge0rG ralphm: I'm fighting hard to keep that a thing, yes.
  165. Ge0rG I agree that proxy-JID is one of the uglier things of MIX.
  166. jonas’ pep., the protoxep wants the occupant-id to be stable across rejoins. putting it on the domain then requires to make it reversible (so a simple HMAC won’t do, you eithre need to encrypt it symmetrically (not feasible) or store the mapping (ew))
  167. Ge0rG now that I think about it. Advertising those proxy JIDs inside of MUC will add a bunch of problems indeed, like clients trying to PM those JIDs
  168. Ge0rG it was a dumb idea, nevermind.
  169. igoose has joined
  170. jonas’ Ge0rG, excellent, problem solved ;)
  171. ralphm Yay
  172. Ge0rG I just hate UUIDs for their uglyness.
  173. pep. jonas’, putting what on the domain
  174. Zash Where are there UUIDs?
  175. pep. Is that a remake of yesterday's discussion in programming@
  176. Ge0rG I suggest HMAC(server_secret, muc-JID + user-bare-JID)
  177. Ge0rG Zash: "UUID" is a placeholder for "long, random-looking hexadecimal string"
  178. ralphm Also, who cares. It is not something the user should ever see.
  179. pep. Ge0rG, HMAC(real_bare_jid, room_secret) is what I use in the module atm
  180. ralphm Someone should use emoji for hex digits
  181. Ge0rG pep.: that requires persisting the room_secret, whereas with a server_secret + room-JID you reduce the storage reqs
  182. pep. jonas’, see I said somebody would care about that :P
  183. Ge0rG ralphm: did you just say "usability nightmare"?
  184. pep. I just didn't know how to do that with prosody's API, but I don't really mind :)
  185. Zash Ge0rG room destruction and recreation would produce the same IDs then, which seems undesirable
  186. pep. ^this
  187. pep. ^ this
  188. Ge0rG Zash: is it really?
  189. alacer has left
  190. alacer has joined
  191. Ge0rG okay, you could also rotate the room_secret on jid visibility changes.
  192. Ge0rG (as if anybody would do those in practice)
  193. pep. what does that mean
  194. jonas’ Ge0rG, I prefer a room secret managed by the server, because it fixes destroy/re-create use cases
  195. jonas’ Ge0rG, plus it avoids having to have the secret configurable / have a server/domain-wide secret which needs to be managed somehow
  196. Ge0rG jonas’: what's the threat model in those cases?
  197. jonas’ Ge0rG, take a destroyed room, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon
  198. Ge0rG I create a MUC, invite everybody there, store the occupant-id mappings, close down the MUC and let somebody else recreate it?
  199. jonas’ Ge0rG, take a destroyed room, re-create it becoming owner, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon
  200. Ge0rG full-anon has been removed, hasn't it?
  201. jonas’ Ge0rG, I call "occupant-id anon" "full anon"
  202. jonas’ when we assume the path towards where the owner cannot see the real JID anymore, instead operating on the occupant-id
  203. Ge0rG jonas’: your naming convention needs more thought
  204. jonas’ Ge0rG, sorry
  205. Ge0rG I might have mentioned it before, but none of this is actually anon.
  206. jonas’ yes
  207. jonas’ full-pseudonymous then ;)
  208. pep. That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners)
  209. valo has left
  210. valo has joined
  211. jonas’ Ge0rG, admittedly, I’m a bit thinking ahead here, but I think it’s valuable to do that
  212. Ge0rG pep.: we can hardly manage affiliation management in our clients with the existing protocol.
  213. Syndace has left
  214. pep. Fix your client?
  215. Ge0rG jonas’: what's the additional attack surface compared to "make a full-pseudo room full of people non-anon"
  216. winfried has left
  217. winfried has joined
  218. jonas’ Ge0rG, you need to be owner to do that
  219. Ge0rG jonas’: yes, like in your proposed scenario
  220. pep. tbh if we were to start using occupant-id for more things, I'd prefer that to be a component setting and not a room setting that the owner can change
  221. Ge0rG pep.: what to be a component setting?
  222. rion The problem I see in SIMS is jingle transfer with references like this <reference xmlns='urn:xmpp:reference:0' type='data' uri='xmpp:romeo@montague.lit/resource?jingle-ft' /> While they look quite simple to handle this "resource" part makes it very temporary. While it can be intended to have a temporary share it doesn't look quite reliable anyway. So a client to download a file should try all possible resources and expect the jingle session will be rejected immediately if the resource doesn't have this file. I'm not sure how it can't be enhanced, but probably there is a way (likely something with carbons). As far as I understand Jingle session publishing suffers from the same problem. We have to send <start> request to specific resource, but which one?
  223. rion And with MUCs things are even more complicated.
  224. pep. Ge0rG, "use occupant-id for things", as said above (using it for MUC operations instead of real-jids)
  225. alacer has left
  226. alacer has joined
  227. Ge0rG pep.: so you want to be able to enforce occupant-id-stamping on all MUCs of your service?
  228. Kev > pep. 10:42 That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners) That would be broken, wouldn't it? You would need someone to join the room first before you could ever ban them.
  229. Kev And you wouldn't be able to ban other than single users.
  230. tom what if someone is set on harassing a muc
  231. tom and start creating a whole bunch of free accounts on a host
  232. Ge0rG tom: they'll just register new accounts via IBR
  233. Ge0rG ...on different hosts
  234. tom and you can't preactively ban
  235. Ge0rG there's that script that will register thousands of IBR accounts on hundreds of servers for you.
  236. tom how can we metigate that?
  237. Ge0rG we can hope that the abusers won't find out
  238. tom so is this like an open resolvers on the internet type situation?
  239. Kev More or less, yes.
  240. tom oh no.
  241. tom nevermind
  242. APach has left
  243. Nekit has left
  244. frainz has left
  245. APach has joined
  246. frainz has joined
  247. lskdjf has joined
  248. Nekit has joined
  249. alacer has left
  250. pep. Kev, you can use mod_firewall for that. Or you can ask the server operator.
  251. pep. (well in both cases it's up to the server operator)
  252. pep. I'm not saying banning a real-jid wouldn't be possible anymore, I just don't feel the need to expose them
  253. Kev I don't understand the motivation, though. Suggesting mod_firewall, or other things the server operator needs to do, seems to be moving away from a functional standard mechanism, and that's kinda what we do.
  254. pep. handling spam is not really well spec'd tbh
  255. pep. And I don't think it's ever possible to do
  256. Kev I don't think banning people is necessarily about spam.
  257. pep. And that feature wouldn't go away
  258. pep. And this feature wouldn't go away
  259. frainz has left
  260. Syndace has joined
  261. frainz has joined
  262. Ge0rG we have blocking, but it doesn't work for MUCs
  263. Zash Technical solutions to social problems?
  264. igoose has left
  265. alacer has joined
  266. pdurbin has joined
  267. adityaborikar has left
  268. adityaborikar has joined
  269. igoose has joined
  270. ralphm So much this
  271. ralphm Unless you get really radical, technology usually doesn't solve social problems. Merely mitigates, or permanently removes the opponent from the equation. The latter is where Geneva is often mentioned.
  272. Ge0rG Let's give up and farm potatoes.
  273. ralphm You've never been in the Netherlands?
  274. Ge0rG ralphm: It'd be interesting to have a way to accomplish that... over the Internet.
  275. Ge0rG OTOH, there are underground groups with pre-made lists-of-opponents-to-be-removed, so I'm less prepared than they are, and their lists have all the wrong people on them.
  276. Ge0rG And without being able to properly execute, I shouldn't utter this kind of wish.
  277. ralphm ...
  278. pdurbin has left
  279. pep. Is there an xmpp logo in svg somewhere?
  280. pep. Ah on the main page
  281. adityaborikar has left
  282. pdurbin has joined
  283. adityaborikar has joined
  284. igoose has left
  285. pdurbin has left
  286. igoose has joined
  287. Zash has left
  288. krauq has left
  289. krauq has joined
  290. matlag has left
  291. matlag has joined
  292. kokonoe has left
  293. valo has left
  294. kokonoe has joined
  295. COM8 has joined
  296. COM8 has left
  297. lnj has joined
  298. flow has left
  299. valo has joined
  300. adityaborikar has left
  301. patrick has joined
  302. Chobbes has joined
  303. flow has joined
  304. eevvoor has joined
  305. alacer has left
  306. andrey.g has left
  307. ziggys has joined
  308. Zash has joined
  309. Chobbes has left
  310. Chobbes has joined
  311. adityaborikar has joined
  312. Chobbes has left
  313. Chobbes has joined
  314. Chobbes has left
  315. andrey.g has joined
  316. nyco Board meeting -10 min
  317. MattJ o/
  318. nyco time+1
  319. nyco where's the gavel?
  320. ralphm bangs gavel
  321. ralphm 0. Welcome
  322. ralphm Who do we have?
  323. Seve says hi.
  324. MattJ Hey
  325. nyco bonjour
  326. ralphm Hi!
  327. Guus I'm on a very unreliable network
  328. ralphm :-D
  329. ralphm 1. Minute taker
  330. Guus I might drop at any time, for any period
  331. nyco if nobody wants it, I'll do it
  332. ralphm 2. Badges
  333. ralphm Poll results yet?
  334. nyco not sent yet, was waiting for more feedback: are we ok to go?
  335. nyco https://forms.gle/nY76DLaD6Ttyn8AV9 latest iteration, DO NOT VOTE YET
  336. ralphm I think so
  337. nyco if no red light today, I'll send it to members@ after I send the minutes
  338. edhelas has left
  339. MattJ sgtm
  340. edhelas has joined
  341. ralphm But I'm a bit confused. You didn't really add more questions per dwd's suggestion?
  342. nyco yes, I did, second page
  343. ralphm Oh!
  344. nyco first page is the choice + comment
  345. ralphm Yes, I see it now
  346. ralphm Looks good to me
  347. dwd LGTM2.
  348. nyco ok, thx all
  349. Seve Nice!
  350. ralphm Thanks, nyco!
  351. dwd So disappointed it's "badges" and not "badgers" though.
  352. ralphm :-D
  353. ralphm 3. Messenger Regulation
  354. ralphm I'm sure it's holiday season, so nothing to report here?
  355. lee has left
  356. ralphm Ge0rG
  357. Ge0rG ralphm: I still haven't written that promised mail to members@
  358. Ge0rG the contact person was very much interested in e2ee btw.
  359. Ge0rG also promised to come back to me in the timeframe of two months, which isn't over yet.
  360. Ge0rG our task of determining what exactly we expect is still open
  361. Ge0rG or rather what we want
  362. ralphm I think the first goal is give them the executive summary of what XMPP is
  363. Ge0rG maybe one of the XSF sposors would stand up to sponsor some heavy lobbying? ;)
  364. Ge0rG ralphm: that I did.
  365. Ge0rG ralphm: we have been listed as one of the stakeholders in the process.
  366. ralphm Good
  367. waqas has joined
  368. edhelas has left
  369. Ge0rG so what is our desired outcome? put XMPP into law? put "standardized protocol" into law?
  370. nyco well what other protocol qualifies?
  371. nyco no one sane recommands SIP/SIMPLE
  372. nyco Matrix is in its infancy
  373. Ge0rG nyco: matrix has been accelerating their standardization efforts
  374. Ge0rG nyco: the only difference between matrix and xmpp, for an outside observer, is some rfc numbers
  375. nyco Telegram protocol is quite not open nor standard, although openly documented, only one server implem
  376. ralphm The thing I find most important in general was summarized perfectly by Google (https://developers.google.com/talk/open_communications): Freedom of Client, Service, Platform.
  377. Nekit has left
  378. Nekit has joined
  379. Ge0rG ralphm: from when is that? 2004?
  380. nyco Matrix has only one server implem, thus does not qualify as an open standard
  381. ralphm Ge0rG: slightly later
  382. Ge0rG nyco: I think you are mixing up things there.
  383. ralphm Ge0rG: But it is indeed timeless
  384. nyco to be honest, we can push open standards protocols, but only one qualifies
  385. Ge0rG nyco: this is a classic approach, to make the requirements appear generic but be sufficiently specific so that only your proposal matches.
  386. Ge0rG still, Microsoft Open Office XML is the mandatory reference here.
  387. nyco athough I am biaised, you gotta be honest: what other protocol qualifies? none
  388. Ge0rG I'm sure that if pushed by legal regulations, Facebook, Google and the others will all come up with their own "open" "standard"
  389. Ge0rG ...overnight
  390. nyco Note: have to leave exactly at 16:00
  391. pep. nyco, personally I wouldn't want to put a protocol name in the legislation
  392. nyco pep. this, I agree
  393. ralphm Ge0rG: indeed, the things we have going for us: standardized at IETF, many implementation, not a single entity in control
  394. MattJ I think we can all agree on that
  395. ralphm ss
  396. pep. Ge0rG, that will happen and I don't think there's anything you can do about this
  397. Ge0rG pep.: it's possible to make law that leaves the specific protocols open for a later decree.
  398. nyco the RGI name protocols (Référentiel Général d'Interopérabilité) in France
  399. Ge0rG pep.: we might have to create wording that, in the presence of malicious actors, can't be gamed too much
  400. ralphm Even if you'd mandate 'XMPP', what does that mean?
  401. pep. RFC3920!
  402. nyco we must then clearly define what an open standard is, and then different actors will push their agendas
  403. ralphm I think what you'd want is interop in features, retaining the freedoms I (Google) listed.
  404. nyco https://en.wikipedia.org/wiki/Open_standard
  405. Zash Exactly what Google deployed in 2006, no more, no less
  406. ralphm This will be fluid over time.
  407. ralphm Zash: with various notes, to be honest
  408. Ge0rG so how do we move forward now?
  409. nyco (time -5 min for me to leave)
  410. Alex has left
  411. ralphm Does it make sense to try to push what I wrote above, and showing how XMPP would get us there?
  412. Ge0rG we also should prepare an answer for E2EE over bridges.
  413. MattJ I think so
  414. pep. Ge0rG, "it doesn't work"? :/
  415. ralphm FWIW, full interop is never going to happen. There will always be features only certain implementations support. Establishing a baseline is not easy, but maybe our compliance suites could be a guide.
  416. pep. The best example of E2EE over bridges we have is OTR..
  417. Ge0rG which reminds me of things I need to put onto next Council's agenda.
  418. Chobbes has joined
  419. edhelas has joined
  420. Ge0rG pep.: OTR is also the worst example.
  421. ralphm Ge0rG: bridges between XMPP and other networks (e.g. Matrix)?
  422. pep. Ge0rG, agreed
  423. nyco and IRC
  424. Ge0rG ralphm: if you mandate open access to facebook, whatsapp etc over xmpp, it will be some kind of bridge as well
  425. nyco on their side
  426. Ge0rG even if the bridging part is hidden from us
  427. ralphm I'd also note that although both XMPP and Matrix have federation features, making it a single federation is hard.
  428. nyco gotta go, sorry, I'm off
  429. ralphm nyco: thanks@
  430. Ge0rG do we want to mandate OMEMO in all IM clients? Or rather wait for / influence MLS?
  431. Lance has joined
  432. ralphm Ge0rG: well, I assume that Facebook, WhatsApp would expose their services as an XMPP server.
  433. ralphm I.e. the interop would be XMPP s2s
  434. Ge0rG ralphm: this is not an answer to E2EE
  435. ralphm Indeed, you'd need to agreed on protocol agnostic E2EE. I don't know if that's possible.
  436. igoose has left
  437. Ge0rG ralphm: either that, or all providers need to implement a protocol-specific E2EE algo in all their clients
  438. Ge0rG which is not impossible, if properly agreed upon by all parties
  439. ralphm Why couldn't you specify an E2EE mechanism like how SASL is defined?
  440. Ge0rG ralphm: please explain
  441. ralphm I.e. you can do SASL over IMAP, XMPP, and others.
  442. ziggys has left
  443. ralphm The interactions are defined, the wire protocol framing is a specialization
  444. ralphm Where things get hard is encrypting more than just text.
  445. ralphm If whatever you encrypt needs to be distributedly extensible, you need to agree to, basically, XMPP stanzas.
  446. valo has left
  447. igoose has joined
  448. ralphm I think we can continue this discussion, but I'd also close the formal part of this meeting.
  449. ralphm 5. Date of Next
  450. ralphm +1W
  451. ralphm 6. Close.
  452. ralphm KTXBYE
  453. MattJ Thanks!
  454. ralphm bangs gavel
  455. Seve Thank you :)
  456. ralphm Ge0rG: is it clear what I meant?
  457. Alex has joined
  458. valo has joined
  459. Ge0rG ralphm: yes, thanks.
  460. eevvoor has left
  461. ralphm I suppose you could also define a JSON format that can then be encrypted, but if you want distributed extensibility, you need namespaces, etc., and you are basically replacing angle brackets with curly ones.
  462. Ge0rG I wonder if OMEMO isn't already 90% there
  463. ralphm I think DE is also a selling point to reluctant corps
  464. Guus I love this WiFi. Good meeting! Ttyl
  465. pep. Ge0rG, but not really appealing. I'm not sure I want to get stuck with only encrypted body in the legislation
  466. Ge0rG if only somebody had told the XEP authors.
  467. pep. And if you want more, as ralphm says, you have to have the same transport on the other side basically
  468. pep. Ge0rG, well OMEMO or not that's what you're saying, and that's effectively the only thing that can go over bridges (body-only)
  469. ralphm Guus: :-/
  470. Ge0rG pep.: OMEMO is what's there in XMPP land. There is also MLS of which I have no clue.
  471. ralphm pep.: same transport (XMPP s2s) would be ideal. For E2EE you need a common format to encrypt.
  472. Ge0rG pep.: and I'm sure we can easily embed XML or JSON or whatever inside OMEMO payloads
  473. pep. Ge0rG, and then you'd need clients to put encrypted json in body? :(
  474. ralphm pep.: and if you want Distributed Extensibility within that encrypted payload, then you might as well mandate XML Stanzas
  475. Ge0rG pep.: into the new OMEMO element.
  476. Ge0rG ralphm: at which point we arrive at Stanza Encryption
  477. pep. Ge0rG, I'm not sure I follow
  478. pep. You're not talking about stanza encryption yet?
  479. Ge0rG no idea what we are talking about
  480. ralphm We were talking about how E2EE might work across networks.
  481. ralphm E.g. Facebook, WhatsApp, 'normal' XMPP clients
  482. ralphm And I tried to list requisites, given that I assume both we and Facebook would want to be able to encrypt more than just plain text.
  483. Ge0rG I'm not sure how much the second part of that assumption holds.
  484. pep. At least we do, I'm not sure about Facebook
  485. pep. But that'S something to consider
  486. ralphm Well, have you seen Facebook Templated messages?
  487. pep. no, what are they?
  488. Ge0rG pep.: https://developers.facebook.com/docs/messenger-platform/send-messages/templates/
  489. ralphm Or using another example: Slack, which has a lot of rich stuff in messages.
  490. Ge0rG still has that tab open
  491. Zash Buttons?
  492. Ge0rG Zash: Buttons++
  493. ralphm If I was a company working on this, and I wanted to offer E2EE, I'd definitely want/need to include this
  494. Ge0rG now we are speaking of a baseline feature set
  495. Ge0rG this will be hard to agree upon.
  496. pep. Right. "What do we want to have in the legislation"
  497. Ge0rG because facebook needs templates, instagram needs galleries and whatsoever.
  498. ralphm (also caroussels, maps, link cards (url, picture, title, description), flight infor)
  499. MattJ Nobody said open standards were easy
  500. alacer has joined
  501. ralphm Ge0rG: that's why I mentioned distributed extensibility. If each vendor has the ability to add their own stuff, you are not limiting a feature set.
  502. ralphm Of course whether other clients can interpret all the things is another matter.
  503. Ge0rG ralphm: I think you just invented the XSF
  504. ralphm But you'd definitely need to have a baseline (probably plain text)
  505. ralphm Not even the XSF needs to be a single controlling entity.
  506. ralphm At VEON, we clearly defined all rich messaging in a way that it could have a fallback body with plain text.
  507. Ge0rG I wish XEP authors would consider that.
  508. ralphm Aren't you on the Council?
  509. Ge0rG Each rich messaging XEP should: - mandate a legacy body format - mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it
  510. ralphm Make it one of your review checkboxes.
  511. Ge0rG ralphm: you'd be surprised, it already is
  512. ralphm I'd hoped so. It was definitely on mine.
  513. Ge0rG unfortunately I'm not aware of any XEP that follows this simple pattern
  514. Nekit has left
  515. Ge0rG not even EME
  516. Ge0rG > When a message is marked with an encryption tag and can not be decrypted, the body can safely be ignored and a localized message displayed instead. This is close, but not quite there.
  517. Nekit has joined
  518. ralphm No?
  519. ralphm XHTML-IM?
  520. ralphm References, and thus SIMS, also assume this.
  521. Zash So when are we un-deprecating XHTML-IM again?
  522. ralphm No, I'm saying that the way it was designed, it assumes that if you don't support it, you can still use the body.
  523. ralphm Without loss of information ideally.
  524. ralphm Also, XEP-0060, section 12.7 (and other places).
  525. Ge0rG ralphm: indeed, XHTML-IM is explicit in that regard. I'm not sure I would count References as it's only an annotation to <body>, not a replacement.
  526. waqas has left
  527. ralphm Sure, but the idea here is entirely that the common format is plain text, and that richer stuff points to it.
  528. ralphm (sure, you can also use References with actually referencing begin/end, but that'd mean you lose information)
  529. ralphm without
  530. Ge0rG I'm looking at XEPs that contain a fallback <body> for non-supporting clients, and that should mandate that the <body> will be superseded
  531. Ge0rG OOB as currently used is the best anti-pattern example to that.
  532. Ge0rG the new reactions proto-proto-XEP fails miserably as well
  533. Ge0rG and then there are things like MUC invitations (direct or mediated)
  534. adityaborikar has left
  535. adityaborikar has joined
  536. ralphm I haven't read that yet, but reactions should be annotations. A body might be tricky. I'm not sure how to refer to a previous message in plain text in a way that a user could understand.
  537. waqas has joined
  538. Ge0rG ralphm: https://github.com/jabbercat/jabbercat/issues/80#issue-304305375
  539. ralphm In case a body cannot convey a certain extension, maybe it could say something to that effect.
  540. Ge0rG I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo
  541. ralphm 'You are invited to a chat room, but your client doesn't support this mechanism. [link-to-faq-page].
  542. ralphm See, literally the same thing.
  543. debacle has left
  544. ralphm (oh, and a closing ')
  545. Ge0rG ralphm: technically, an OMEMO client could insert actual text into the <body> of an OMEMO message, and it would remain unnoticed by OMEMO clients.
  546. pdurbin has joined
  547. Ge0rG https://xmpp.org/extensions/xep-0384.html doesn't mandate that the <body> must be throw-away content
  548. Ge0rG > If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message.
  549. ralphm Given that it is not Final, there's some room still :-D
  550. Ge0rG So I could troll OMEMO-enabled clients by adding a broken <encrypted xmlns='eu.siacs.conversations.axolotl'> element into all my messages.
  551. debacle has joined
  552. Lance has left
  553. ralphm There are so many ways to troll clients. Again, social problems.
  554. Ge0rG ralphm: I'm pretty sure that XEP won't move forward in the current state ;)
  555. Ge0rG when designing the receiving side of things, I need to make a deliberate decision on throwing away the <body>
  556. Ge0rG I suppose I'm way too deep in nitpicking mode.
  557. adityaborikar has left
  558. adityaborikar has joined
  559. ralphm :-)
  560. ralphm :-)
  561. pdurbin has left
  562. ziggys has joined
  563. lnj has left
  564. lnj has joined
  565. adityaborikar has left
  566. adityaborikar has joined
  567. Lance has joined
  568. curen has left
  569. nyco minutes sent
  570. nyco poll sent
  571. Ge0rG can I vote now? :D
  572. Lance MattJ: hats ping
  573. nyco Ge0rG only once! :)
  574. Ge0rG only once per split identity.
  575. nyco ah, this...
  576. nyco if these people are many contributors, then yes
  577. Ge0rG nyco: you forgot to add the "would you use it?" to the poll.
  578. nyco second page
  579. nyco 2) If you run an XMPP project, would you use those badges? (website, repo, doc, flyer, poster, etc.)
  580. Ge0rG 👍
  581. sezuan has left
  582. eevvoor has joined
  583. adityaborikar has left
  584. adityaborikar has joined
  585. UsL has left
  586. goffi has left
  587. UsL has joined
  588. lovetox has joined
  589. Chobbes has left
  590. Chobbes has joined
  591. Chobbes has left
  592. Chobbes has joined
  593. igoose has left
  594. igoose has joined
  595. debacle has left
  596. valo has left
  597. valo has joined
  598. igoose has left
  599. UsL has left
  600. pdurbin has joined
  601. igoose has joined
  602. waqas has left
  603. pdurbin has left
  604. jjrh has left
  605. Nekit has left
  606. moparisthebest jonas’: > The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).
  607. david has left
  608. david has joined
  609. moparisthebest eh, I know what 6120 says but I can't agree with that here
  610. moparisthebest it's trivial for an evil attacker to insert a DNS record that tells a client/server not to fallback
  611. moparisthebest I see no harm in falling back anyway if you are doing TLS, does anyone?
  612. moparisthebest (sorry for ENOCONTEXT referencing https://github.com/xsf/xeps/pull/796/files )
  613. Nekit has joined
  614. moparisthebest the other bit, trying regular _xmpp-client/_xmpp-server seems fine though
  615. UsL has joined
  616. rion about improving SIMS... I believe Jingle Session Publishing xep should take some features from Jingle Message Initiation then it will fit well to SIMS. Like.. 1. I'm sending SIMS with published Jingle session 2. a party discovers details of the published Jingle session and if it's compatible sends a *message* (not iq) with <start> 3. the message is carbonned and my other resources not having the file from SIMS just ignore the message (or maybe just record it happened) 4. my resource which has the file sends <starting> via message to a party resource so other my resources know I'm sending a file and also know where from 5. a party initiates jingle session with file request to specific resource (where <starting> came from)
  617. ralphm moparisthebest: I wrote this elsewhere before, but I disagree, too. See also RFC 2782. We should totally have a fallback, so the service name should be registered with IANA with a port number.
  618. ralphm Elsewhere being the mailing list
  619. moparisthebest yep I see that in the email chain now ralphm
  620. ralphm rion: could you send a mail on this, with maybe some example protocol exchange?
  621. moparisthebest I vaguely recall conversations daniel talking about falling back to 443, clearly we can't register that with IANA though
  622. ralphm rion: It is a bit hard to wrap my head around it.
  623. moparisthebest I actually don't mind either way if the XEP recommends to fallback and/or a port, I just strongly disagree with "MUST NOT fallback"
  624. neshtaxmpp has left
  625. rion ralphm: yep. a little bit later. need to finish some regular work stuff first :)
  626. ralphm moparisthebest: I think that's not a great idea. However, one could use port 443 as an SRV target port.
  627. ralphm rion: 👍
  628. ralphm moparisthebest: right, I think we should prevent doing something special. I'd like to use existing generic SRV handlers.
  629. UsL has left
  630. moparisthebest especially when it's only downsides, basically just allowing a network MITM to keep you disconnected when there is a chance you could connect
  631. jonas’ moparisthebest, an evil attacker can also insert a broken A/AAAA record
  632. jonas’ if you assume that DNS can be meddled with, all bets are off
  633. moparisthebest right, should probably fallback then too
  634. jonas’ fall back to what?
  635. moparisthebest everything you can
  636. jonas’ there is nothing to fall back if your attacker spoofs A/AAAA
  637. jonas’ you just end up with broken TLS, hopefully
  638. moparisthebest ah sorry I read that as 'broken SRV record' but yea
  639. ralphm jonas’: I don't think it is useful to think about spoofing DNS in this context.
  640. jonas’ ralphm, indeed
  641. ralphm But following the RFC on SRV records seems sensible.
  642. moparisthebest I think it is though, you can't get around everything an evil mitm could do of course, but maybe you can get around some of them, and there is no reason to give up early
  643. Zash ralphm: So does that mean the "fetch both _xmpp and _xmpps SRV and merge the results" is undesirable?
  644. ralphm Yes
  645. Zash I tend to agree
  646. moparisthebest that is optional though
  647. jonas’ moparisthebest, initiating connections the domain owner clearly did not intend you to do is probably not a good idea
  648. jonas’ and this is what you’re doing in this case
  649. jonas’ the endpoint you end up connecting to may easily be a hacked webserver for the same domain
  650. jonas’ it may be in an entirely different trust domain. just don’t do things the domain owner asked you specifically not to do by placing SRV records.
  651. moparisthebest you have no guarantees that the SRV record came from the domain owner though
  652. moparisthebest unless DNSSEC, I'm fine with a MUST NOT if you've validated it with DNSSEC
  653. jonas’ 17:29:06 ralphm> jonas’: I don't think it is useful to think about spoofing DNS in this context.
  654. jonas’ moparisthebest, ^
  655. jonas’ if the attacker can spoof the SRV record, they can also spoof the A/AAAA you want to fall back to. it’s pointless.
  656. moparisthebest and I disagree with that :)
  657. jonas’ what you propose does not help against an active DNS attacker, and it makes the situation worse in a non-attacked situation.
  658. moparisthebest because some attacker might just spoof the SRV record and not A/AAAA, or you might be getting A/AAAA over tor because that only supports them and not SRV
  659. jonas’ (or in a situation where the attacker has control over a specific machine (A/AAAA), but not over DNS)
  660. moparisthebest or a million other reasons
  661. goffi has joined
  662. jonas’ moparisthebest, if you’re connecting via a transport which does not support SRV, then obviously XEP-0386 does not apply to you
  663. Zash Don't worry, be happy. Make sure you validate the TLS certificate.
  664. moparisthebest if domain owner is running a public web server that will be hurt by attempting a funky connection to it, they need to fix that
  665. jonas’ and neither does the SRV RFC or the parts about SRV in RFC 6120
  666. jonas’ moparisthebest, it may not be *hurt*, but it may easily log things to plaintext logs which you (as the client/user) wouldn’t want to have there. think pipelining authentication because you "know" the domain already.
  667. igoose has left
  668. moparisthebest SRV RFC is more generic, it doesn't know we have a foolproof way of validating the port we connect to by guessing
  669. Zash validating ... by guessing
  670. moparisthebest we guess the port
  671. Nekit has left
  672. jonas’ what?
  673. moparisthebest we have a foolproof way of validating whether it was correct or not, TLS certs
  674. jonas’ no, that’s not foolproof
  675. jonas’ the webserver or whatever on the A/AAAA record *will* have a TLS cert for *exactly* the domain
  676. Nekit has joined
  677. jonas’ so you’re on the wrong port, but still connected and TLS says everything’s green
  678. moparisthebest right, and that's fine
  679. jonas’ no it’s not
  680. Zash 400 WHAT ARE THESE ANGLE BRACKETS Connection: gtfo
  681. Zash I still think guessing is stupid
  682. jonas’ guessing is stupid and dangerous
  683. moparisthebest it absolutely is, again running a public port on the internet means you are willing to accept whatever garbage anyone throws at you
  684. moparisthebest and not only accept, but be happy about it
  685. jonas’ moparisthebest, yes, and I might log that "garbage" including your SASL PLAIN password into some plaintext files for someone to investigate
  686. neshtaxmpp has joined
  687. jonas’ which is probably very much not what you want
  688. jonas’ or alternatively, the webserver may run in a different trust domain and may be owned by an attacker
  689. moparisthebest the domain owner is the one that made a decision to give them a cert valid for xmpp, and to run an xmpp and https service on the same domain
  690. moparisthebest so the owner already decided all that was fine
  691. jonas’ not really
  692. jonas’ they have told you via SRV that you should very much should not connect to that webserver machine for XMPP
  693. jonas’ anything you do beyond that is your fault
  694. moparisthebest again without DNSSEC you can't know that, you can only guess
  695. jonas’ okay, the discussion has just become a pointless loop
  696. moparisthebest bottom line, as a user, I want to connect by any means possible, I certainly don't want to not connect because a network is poorly configured either intentionally or accidentally
  697. moparisthebest if I understand correctly, you are saying a domain/server operator might not want certain connections, and while I agree, that's tough shit
  698. Nekit has left
  699. moparisthebest you open a public port on the internet you have to be willing to accept anything anyhow at any time, period
  700. Nekit has joined
  701. jjrh has joined
  702. Zash so we have the two classic camps "fail early and hard on errors" and "just make it work at an ycost"
  703. Zash XML vs HTML
  704. Zash etc
  705. moparisthebest I dislike being compared to HTML but otherwise sure :D
  706. Nekit has left
  707. goffi has left
  708. igoose has joined
  709. ralphm If you want to prevent connections, you can publish an SRV record with . as target
  710. Zash Ask Ge0rG how common it still is for devices to not support SRV resolution
  711. ralphm Well, if that's true, they are not able to have functional compliant XMPP implementations.
  712. Zash I imagine the fault would most likely be in DNS resolvers in cheap routers or something
  713. larma has left
  714. Holger Or Tor.
  715. ralphm But wait, how does that prevent a client device from doing SRV? Or do you mean routers blocking SRV requests?
  716. Zash Blocking or otherwise failing for unknown reasons
  717. moparisthebest because a client generally gets their DNS server from DHCP which tells it to use crap router
  718. Holger WiFi routers having a built-in caching DNS server that's borked.
  719. ralphm Well, I'm not sure if I want to be in the business of catering for such brokenness.
  720. jonas’ there’s also some firewall appliances which filter SRV away
  721. Zash And fallback combined with SRV not being critical for the web or email means nobody notices or fixes them.
  722. moparisthebest of course DoX fixes this if you have a hard-coded ip+port for your resolver :D
  723. Holger On the public servers I'm involved with, we'd loose >10% of the users by not redirecting 5222 from the A/AAAA target.
  724. goffi has joined
  725. Zash Holger: Sounds like what Ge0rG has said about yax.im
  726. ralphm Holger: wow. Are those corporate users?
  727. ralphm Also, how can you tell.
  728. Holger ralphm: I don't think so; as I said, from what I've seen it's mostly crap end-user routers and Tor.
  729. ralphm Tor is not on my radar
  730. ralphm But how can you tell that users cannot use SRV?
  731. Holger ralphm: I just check the percentage of the connections that are redirected from the A/AAAA target.
  732. ralphm Oh, you publish a different host in SRV?
  733. Holger ralphm: Yes.
  734. ralphm I kinda want users to complain to their ISPs.
  735. Holger ralphm: Not sure about the Tor/crap-router ratio. But it's definitely not just Tor.
  736. karoshi has left
  737. Holger ralphm: Well they'd have to complain to their router manufacturers. At least in the cases I tracked down.
  738. Holger (Which was like two or three.)
  739. Holger A popular thing in France was/is affected, for example.
  740. moparisthebest also just as a data point I have what I'd call a "crap corporate network" and SRV is wide open, but it'll only allow HTTP on 80 and TLS on 443, it checks that it's actually TLS too
  741. larma has joined
  742. goffi has left
  743. goffi has joined
  744. moparisthebest and yea it'd be great if people complained to ISP/router manufacturers, in practice though it's just "XMPP sucks I can't even connect"
  745. Lance has left
  746. Seve has left
  747. Vaulor has left
  748. goffi has left
  749. UsL has joined
  750. ralphm Holger: in most cases people get routers from their ISP. If not, they have themselves to blame for broken behavior.
  751. waqas has joined
  752. Holger True that.
  753. Holger Of course neither will stop them from concluding what moparisthebest said. XMPP fails, everything else just works.
  754. Zash Can't have nice things
  755. ralphm And corporate users, well, should complain to corporate IT. There's no end to stupidity in that area.
  756. Zash ENTERPRISE
  757. moparisthebest > Star Trek Fan Accidentally Accepts Job Writing "Enterprise Software"
  758. ralphm When we worked on Jingle/WebRTC we had some issues with blocked UDP traffic in our office.
  759. moparisthebest ralphm, don't worry QUIC should fix that for you in a bit :)
  760. ralphm Thus wasting valuable bandwidth for calls between two people in the office.
  761. ralphm moparisthebest: I think QUIC has a lot going for it, but no.
  762. moparisthebest Zash, I think it's more like "can only have nice things if HTTP wants them first" :D
  763. Zash :(
  764. ralphm moparisthebest: not in this case, I mean. I definitely would like to see XMPP-over-QUIC.
  765. neshtaxmpp has left
  766. wojtek has joined
  767. ralphm And indeed if QUIC would work in the corporate environment, then calls would too, since you can use the same port for TURN/STUN.
  768. moparisthebest I mainly meant users will complain if websites quit working, so as websites migrate to http3/udp and break, networks should be fixing that
  769. Lance has joined
  770. debacle has joined
  771. ralphm I think websites will fallback to plain http for a long time
  772. rion QUIC+WebRTC ? I though wg abandoned this idea because all the id remapping crap for compatibility with STUN and absence of signalling ideas.
  773. rion thought*
  774. ralphm Sure, but I believe even without changes, it can still be done.
  775. ralphm Especially with XMPP, as hey, we have signaling.
  776. ralphm The conflict is with TURN mostly
  777. wojtek has left
  778. eevvoor has left
  779. frainz has left
  780. frainz has joined
  781. ralphm I am a bit surprised one of the arguments is that TURN is rarely used with WebRTC, though. TURN was considered a significant requirement when we were building calls in the VEON app.
  782. Lance has left
  783. ralphm But that's not on websites, so who cares? Right, fippo?
  784. frainz has left
  785. igoose has left
  786. frainz has joined
  787. adityaborikar has left
  788. pdurbin has joined
  789. frainz has left
  790. frainz has joined
  791. igoose has joined
  792. igoose has left
  793. pdurbin has left
  794. frainz has left
  795. frainz has joined
  796. frainz has left
  797. frainz has joined
  798. Steve Kille has left
  799. rion If web browsers could use our signaling out of the box that would be quite interesting.
  800. ralphm Hah, well! If I'm right, the webrtc library has roots in libjingle.
  801. ralphm Of course with all the XMPP now removed.
  802. Zash ralphm: I have heard that as well
  803. ralphm Maybe we could say XMPP caused WebRTC to happen.
  804. neshtaxmpp has joined
  805. igoose has joined
  806. UsL has left
  807. frainz has left
  808. frainz has joined
  809. Lance has joined
  810. frainz has left
  811. frainz has joined
  812. tom Shouldn't IPv6 fix these issues as well?
  813. frainz has left
  814. tom because with IPv6, if setup properly every computer on then network get's it's own unique publicly routable IPv6 address
  815. tom sometimes every device gets a whole range to itself
  816. jonas’ > because with IPv6, if setup properly
  817. jonas’ that’s the catch ;)
  818. tom well
  819. jonas’ but yes, IPv6 will (hopefully) make mayn things easier
  820. jonas’ but yes, IPv6 will (hopefully) make many things easier
  821. tom most corporate enviroments are going to setup PFsense or OpenWRT
  822. tom which sets up most of ipv6 for you ounce you give it an upstream
  823. frainz has joined
  824. igoose has left
  825. tom we aren't in the dark ages of proprietary router firmware ruling majority anymore, least not for professional space
  826. tom too many routers got turned into zombies
  827. jonas’ ironically, the gateway thing provided by my ISP handles IPv6 just fine
  828. jonas’ it even supports prefix delegation via DHCPv6
  829. ralphm I think your view on the activities or competence of corporate IT departments is extremely optimistic.
  830. tom maybe that's just my area
  832. frainz has left
  833. tom the only place I've really seen something not PacketFilter of NetFilter based is where it's probably not possible to route/firewall without ASICs
  834. jonas’ ralphm, that, too
  835. tom like routing 400+gbps
  836. tom where we'd use a switch fabric backplane
  837. tom otherwise everything in the office areas flowed threw a PFsense box.
  838. tom the 1U unit they sell
  839. ralphm You might have been lucky.
  840. frainz has joined
  841. Seve has joined
  842. ralphm I've seen IT departments being understaffed, underfunded, outsourced, and misused for setting up teleconferences.
  843. goffi has joined
  844. frainz has left
  845. frainz has joined
  846. Yagiza has left
  847. moparisthebest tom, can you tell my corporate IT dept, they use all the proprietary blackboxes, riverbed, telari, cisco, and palo alto
  848. moparisthebest and those are just the ones I know about
  849. Vaulor has joined
  850. zach has left
  851. zach has joined
  852. Nekit has joined
  853. Steve Kille has joined
  854. Steve Kille has left
  855. igoose has joined
  856. zach has left
  857. zach has joined
  858. remko has left
  859. frainz has left
  860. frainz has joined
  861. ziggys has left
  862. lovetox_ has joined
  863. lovetox_ has left
  864. frainz has left
  865. frainz has joined
  866. lskdjf has left
  867. lskdjf has joined
  868. igoose has left
  869. goffi has left
  870. lumi has joined
  871. igoose has joined
  872. pep. "Ge0rG> Each rich messaging XEP should: - mandate a legacy body format - mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it", I don't want to start a discussion right now (sleep!) but I also don't want to forget about it, so I'll say for now that I'm not sure I like this, and we can come back to it later :)
  873. ralphm Dude. I want to sleep.
  874. waqas has left
  875. Ge0rG pep.: I'm going to write that to standards in the context of reactions
  876. pep. Ok
  877. pep. I'll reply to that
  878. ralphm https://upload.ik.nu/upload/oQfV7r-1Xd5r9hYF/9XML-6JsSvqz0agHghjWlg.png
  879. pep. https://www.xkcd.com/386/
  880. ralphm Yes
  881. moparisthebest has left
  882. moparisthebest has joined
  883. Nekit has left
  884. waqas has joined
  885. karoshi has joined
  886. lovetox has left
  887. UsL has joined
  888. mimi89999 has left
  889. mimi89999 has joined
  890. Chobbes has left
  891. moparisthebest has left
  892. adityaborikar has joined
  893. andrey.g has left
  894. Mikaela has left
  895. ziggys has joined
  896. ziggys has left
  897. ziggys has joined
  898. debacle has left
  899. krauq has left
  900. krauq has joined
  901. UsL has left
  902. lumi has left
  903. moparisthebest has joined
  904. lumi has joined
  905. lnj has left
  906. karoshi has left