XSF Discussion - 2018-02-14

  1. Guus has left
  2. tux has left
  3. tux has joined
  4. Guus has left
  5. la|r|ma has left
  6. Tobias has left
  7. la|r|ma has left
  8. lskdjf has left
  9. Guus has left
  10. moparisthebest has left
  11. ralphm has joined
  12. waqas has left
  13. blabla has left
  14. lskdjf has joined
  15. la|r|ma has joined
  16. lovetox has left
  17. Tobias has joined
  18. lskdjf has left
  19. lskdjf has joined
  20. jjrh has left
  21. Guus has left
  22. jjrh has left
  23. jjrh has left
  24. Guus has left
  25. Tobias has left
  26. jjrh has left
  27. nyco has left
  28. suzyo has joined
  29. la|r|ma has joined
  30. Dave Cridland has left
  31. la|r|ma has left
  32. Tobias has left
  33. tux has left
  34. tux has joined
  35. jere has joined
  36. waqas has joined
  37. waqas has left
  38. la|r|ma has left
  39. Dave Cridland has left
  40. Tobias has left
  41. Dave Cridland has left
  42. Dave Cridland has left
  43. SamWhited has left
  44. rion has joined
  45. @Alacer has left
  46. @Alacer has joined
  47. Tobias has joined
  48. la|r|ma has left
  49. efrit has left
  50. la|r|ma has left
  51. Tobias has left
  52. lskdjf has left
  53. hannes has left
  54. hannes has joined
  55. andy has joined
  56. vanitasvitae has left
  57. Dave Cridland has left
  58. la|r|ma has joined
  59. moparisthebest has left
  60. moparisthebest has left
  61. moparisthebest has joined
  62. lskdjf has joined
  63. Tobias has joined
  64. moparisthebest has left
  65. uc has left
  66. uc has joined
  67. andy has left
  68. Tobias has joined
  69. andy has joined
  70. matlag has left
  71. rion has left
  72. Tobias has joined
  73. suzyo has joined
  74. hannes has left
  75. andy has left
  76. hannes has joined
  77. moparisthebest has joined
  78. moparisthebest has left
  79. moparisthebest has joined
  80. goffi has joined
  81. Dave Cridland has left
  82. Dave Cridland has left
  83. andy has joined
  84. Tobias has joined
  85. suzyo has joined
  86. suzyo has joined
  87. Dave Cridland has left
  88. Dave Cridland has left
  89. nyco has left
  90. jonasw Flow, there was the argument that identities may be localized.
  91. Dave Cridland has left
  92. Dave Cridland has left
  93. SaltyBones has left
  94. Tobias has joined
  95. andy has left
  96. SaltyBones has joined
  97. Dave Cridland has left
  98. Dave Cridland has left
  99. suzyo has left
  100. suzyo has joined
  101. moparisthebest has left
  102. Seve I changed my email address. Does anyone know who should I get in touch with to subscribe myself with my new email address, please?
  103. moparisthebest has joined
  104. daniel has left
  105. jonasw Seve, to all lists but members@, you can manage that yourself
  106. daniel has joined
  107. jonasw I’m not sure if you can change your email address for members@ yourself
  108. jonasw you could try checking the options at https://mail.jabber.org/mailman/options/members/your.old@email.address
  109. Seve Ohh
  110. jonasw (note the email address in the URL)
  111. Seve Sorry!
  112. Seve I forgot to mention that I want to subscribe to members@, yes.
  113. jonasw ha ok
  114. jonasw I don’t know who’s responsible for this, but somebody from iteam will do
  115. andy has joined
  116. jonasw the two I have in mind aren’t here right now though
  117. daniel has left
  118. daniel has joined
  119. andy has left
  120. andy has joined
  121. ralphm has joined
  122. andy has left
  123. Guus has left
  124. andy has joined
  125. Guus has left
  126. remko has joined
  127. andy has left
  128. rion has left
  129. daniel has left
  130. rion has left
  131. Dave Cridland has left
  132. jubalh has joined
  133. tim@boese-ban.de has joined
  134. Tobias has joined
  135. Dave Cridland has left
  136. SaltyBones has left
  137. Dave Cridland has left
  138. Dave Cridland has left
  139. moparisthebest has left
  140. andy has joined
  141. Ge0rG I'd like to propose a new marketing slogan: *XMPP - as popular as the Metric system in the USA*
  142. jonasw :<
  143. Ge0rG jonasw: it could be worse, e.g. "XMPP - as popular as the Measles"
  144. andy has left
  145. jonasw :<
  146. Fabian has joined
  147. Fabian has left
  148. moparisthebest has joined
  149. Alex has joined
  150. Dave Cridland has left
  151. hannes has left
  152. Guus has left
  153. andy has joined
  154. Dave Cridland has left
  155. Fabian has joined
  156. Guus has left
  157. rion has joined
  158. tux has left
  159. tux has joined
  160. andy has left
  161. Steve Kille has left
  162. mimi89999 has joined
  163. Alex has left
  164. Alex has joined
  165. Steve Kille has joined
  166. Fabian has left
  167. jubalh has joined
  168. blabla has joined
  169. andy has joined
  170. andy has left
  171. Dave Cridland has left
  172. tim@boese-ban.de has left
  173. tim@boese-ban.de has joined
  174. Dave Cridland has left
  175. Dave Cridland has left
  176. jubalh has joined
  177. marc has joined
  178. Dave Cridland has left
  179. blabla has joined
  180. Martin has joined
  181. rion has left
  182. rion has joined
  183. rion has left
  184. rion has joined
  185. intosi has joined
  186. rion has left
  187. Kev has joined
  188. Fabian has joined
  189. Dave Cridland has left
  190. Alex has left
  191. mimi89999 has joined
  192. Alex has joined
  193. Fabian has left
  194. jonasw oh my god
  195. jonasw I’m just reading XEP-0013
  196. jonasw why did it seem like a good idea to use disco#info for the number of messages?
  197. Kev -13 is pretty old, we've got a lot of best-practice knowledge that's built up since then.
  198. Bunneh Kev: I'll remember that.
  199. jonasw -13
  200. Bunneh jonasw: pretty old, we've got a lot of best-practice knowledge that's built up since then.
  201. Kev What the smeg?
  202. jonasw hah!
  203. ralphm has joined
  204. Tobias :D
  205. jubalh has left
  206. Fabian has joined
  207. marc has left
  208. Fabian has left
  209. Fabian has joined
  210. jubalh has joined
  211. jubalh has left
  212. jubalh has joined
  213. jubalh has left
  214. Flow jonasw, ok, so why an extra hash for localized identities?
  215. Fabian has left
  216. jonasw Flow, separating them so that entities can profit from their cache for features and forms
  217. jonasw (also, there are precedents for quickly-changing forms)
  218. Neustradamus has left
  219. jonasw (e.g. the number of users in a MUC in its disco#info)
  220. Syndace has joined
  221. SaltyBones What does "localized" in this context mean? "translated"?
  222. jonasw in such a quickly-changing-form-case it would be profitable if entities could opt-out of the forms hash to indicate that it is quickly changing and must always be considered stale.
  223. Flow that sounds like an argument for an extra hash for forms
  224. jonasw yes
  225. jubalh has joined
  226. jonasw question is if separation of identities makes sense, too.
  227. Flow but I still don't see the advantage of an extra hash for localized identities
  228. Flow given that the identities will not frequently change
  229. jonasw I don’t see it either, necessarily
  230. Flow SaltyBones, yep, usually it's about the xml:lang attribute
  231. Flow are there many other popular precedents for quickly changing forms?
  232. jonasw Flow, I don’t know, honestly
  233. jonasw that’s why I *wish* there was more feedback on this on-list
  234. Flow I was going to write yesterday, but then figured that I possibly don't know what it is really about
  235. jonasw so I need to make it clearer?
  236. Flow jonasw, dunno, it appears you also don't know an example where extra hashes for identities, feature and/or forms are beneficial
  237. lumi has joined
  238. jonasw for forms, the MUC case is rather beneficial; the current workaround which is used is that the form wtih the numebr of users is not included when answering disco#info for a caps node
  239. Flow besides when protocols come into play that put dynamic information into e.g. features
  240. jonasw which is bad
  241. jonasw and in many cases, entities might not be interested in the form data, which is almost alwyas supplementary
  242. jonasw thus making them miss the cache because of uninteresting form data is not totally great
  243. jonasw (for example, entities which put OS version into the disco#info data; you’d then build a cache where each release of every operating system on which the client runs is held, which is kind of not very useful to have in the first place)
  244. jonasw I’m not sure there’s a strong argument for separating identities, but separating forms seems appealing to me
  245. jonasw I hoped that zinid would comment on this since he told me about the MUC forms use case.
  246. Flow hmm I see/saw caps mostly as an instrument to discover the caps of a remote "client". I can't even tell from the top of my head if caps works with xep45: Do you get a presence from the MUCs bare JID?
  247. Flow If ecaps2 is missing something, then it is possibly a mechanism for clients to annouce their features even if they are offline (e.g. via PEP)
  248. SaltyBones XEPs should mandate a list of intended use-cases.
  249. Flow SaltyBones, don't they?
  250. jonasw Flow, recent developments make you get a presence from the bare MUC jid on join, yes
  251. jonasw that’s a result of summit
  252. Flow jonasw, is that xep45 change live already?
  253. jonasw it is being developed and evaluated against client implementations
  254. Flow jonasw, ok, i guess it's part of the multi nick sharing initiative
  255. daniel has left
  256. jonasw Flow, no, it’s part of the avatars for MUCs initiative :)
  257. jonasw and knowing the disco#info of a MUC is probably useful
  258. Flow from what I know till now, I don't feel that it is worth separating the hashes. Instead we should consider adding a best practice to xep30 that disco#info results are supposed to be not short-living
  259. jonasw Flow, how are you suggesting to fix the xep45 use-case then?
  260. jonasw also, short-living isn’t the same as high-cardinality, whihc is also an issue
  261. jonasw (as in the OS Version case)
  262. Flow jonasw, the os version case is not xep92?
  263. Flow but yes, you are right, it's not the same, i'm not sure if high-cardinality is an issue and if it needs fixing
  264. marc has joined
  265. moparisthebest has joined
  266. jonasw softwareinfo
  267. Flow same is true for xep45, I possibly could live with an cold caps cache every time an occupant leaves or joins
  268. jonasw hm, we could test that, we have a huge repository of caps data
  269. jonasw I think I’ll do that :)
  270. Flow jonasw, sorry, softwareinfo?
  271. jonasw https://xmpp.org/extensions/xep-0232.html
  272. jonasw that one
  273. jonasw I had to google the namespace myself
  274. pep. has joined
  275. Flow uh, i forgot that we have an update to xep92, would be great if there where a pointer from xep92 to it's possible successor
  276. jonasw Flow, the issue is that caps cache should be persistable; defeating that because we’re spamming the databases with pointless updates/minor differences is kinda sad.
  277. jonasw but sure, I’ll run a test on the capsdb
  278. Flow jonasw, but is it an issue?
  279. jonasw it’s a bit dated, but probably a good source of a first estimate
  280. jonasw Flow, that’s what I’m going to find out
  281. andy has joined
  282. ralphm has joined
  283. Flow hmm not sure if xep232 is really an improvement over xep92
  284. andy has left
  285. marc Ge0rG: how do you implement "pending XMPP URIs"? E.g. you add a contact but don't have an account set up yet and show the corresponding dialog after account setup. IIRC you do this in yaxim
  286. rion has joined
  287. stefandxm has left
  288. Ge0rG marc: I'm keeping the Intent and re-firing its handler after account creation
  289. SaltyBones what does that mean? you can add people who don't have an account??
  290. marc Ge0rG: what if multiple activities are involved before you can re-fire it? Do you pass it to all the activities?
  291. jonasw SaltyBones, XEP-0401
  292. SaltyBones -xep-0401
  293. daniel > Ge0rG: how do you implement "pending XMPP URIs"? E.g. you add a contact but don't have an account set up yet and show the corresponding dialog after account setup. IIRC you do this in yaxim Conversations does that as well
  294. SaltyBones kicks Bunneh.
  295. Ge0rG marc: the only flow allowed is "main activity [optional: prefs activity ->] main activity"
  296. jonasw SaltyBones, -xep 0401
  297. jonasw SaltyBones, {xep 0401}
  298. Bunneh SaltyBones: Easy User Onboarding (Standards Track, Experimental, 2018-01-25) See: https://xmpp.org/extensions/xep-0401.html
  299. SaltyBones pours a bucket of water on Bunneh.
  300. jonasw there we go
  301. marc daniel: really? What version?
  302. daniel Not with the entire uri though. Just the jid. But that could be changed
  303. daniel marc: dunno. Maybe 1.23.0
  304. Ge0rG Bunneh is b0rked
  305. marc Ah okay, because I need the full URI
  306. daniel yeah changing that is probably fairly easy
  307. marc Okay, I'll take a look
  308. SaltyBones marc, did you write this XEP?
  309. SaltyBones Anyway, good stuff.
  310. nyco has left
  311. SaltyBones And of course as always thanks to Ge0rG for all his efforts in this direction!
  312. marc SaltyBones, Ge0rG also did lots of stuff
  313. marc SaltyBones: yes
  314. Ge0rG SaltyBones: 🙇
  315. rion has left
  316. daniel has left
  317. Dave Cridland has left
  318. ralphm has joined
  319. Steve Kille has left
  320. lumi has left
  321. Ge0rG So I've installed kaidan, and it is _very_ basic
  322. Seve it is
  323. blabla has left
  324. marc has left
  325. jubalh has left
  326. daniel seems to be a pattern
  327. Ge0rG The CADT pattern.
  328. Ge0rG Oh, I've installed 0.2.3 from their repo, github has 0.3.2
  329. Seve Well, it is relatively new, so...
  330. Ge0rG https://github.com/KaidanIM/packages/issues/1 :|
  331. Ge0rG Seve: 0.3 was a significant change
  332. rion has joined
  333. Ge0rG also half a year of development between the releases.
  334. jjrh has left
  335. Ge0rG So Kaidan reflects the general status of XMPP very well.
  336. jjrh has left
  337. MattJ 6 months between releases is not long, or what are you saying? :)
  338. nyco has left
  339. Ge0rG MattJ: I'm saying that having 6 months old DEBs on their own repo is really bad.
  340. Ge0rG has joined
  341. Ge0rG has joined
  342. Ge0rG has left
  343. Ge0rG has left
  344. Ge0rG has left
  345. Ge0rG has left
  346. Ge0rG has left
  347. Ge0rG has left
  348. Ge0rG has left
  349. jubalh has joined
  350. jubalh has left
  351. jubalh has joined
  352. jubalh has left
  353. jubalh has joined
  354. marc has joined
  355. Guus has left
  356. Steve Kille has joined
  357. SaltyBones You can deploy QT to iOS?
  358. Dave Cridland has left
  359. Tobias Some Qt pars, yes
  360. Tobias Qt Quick GUIs you can
  361. daniel has left
  362. SaltyBones Does GTK have something similar?
  363. Tobias no clue
  364. stefandxm has joined
  365. suzyo has joined
  366. daniel has left
  367. SaltyBones Tobias, this https://doc.qt.io/qt-5/qtquick-index.html ?
  368. matlag has joined
  369. Tobias yes...that stuff works across desktop and ios/android platforms
  370. SaltyBones huh...nice
  371. jonasw "works"
  372. SaltyBones oh...
  373. jonasw it lacks quite a few things/controls, it is a pain to use with C++ and I think you’ve got to do accessibility quite all by yourself
  374. jonasw but I haven’t looked deeply into the last part
  375. jjrh has left
  376. jjrh has left
  377. Dave Cridland has left
  378. Dave Cridland has left
  379. ralphm has joined
  380. Dave Cridland has left
  381. Dave Cridland has left
  382. Dave Cridland has left
  383. moparisthebest has joined
  384. Dave Cridland has left
  385. stefandxm has left
  386. Dave Cridland has left
  387. Dave Cridland has left
  388. Dave Cridland has left
  389. Dave Cridland has left
  390. Dave Cridland has left
  391. dwd Gosh, Gloox. There's a blast from the past.
  392. Dave Cridland has left
  393. Dave Cridland has left
  394. MattJ Indeed
  395. jubalh has left
  396. Dave Cridland has left
  397. jubalh has joined
  398. Dave Cridland has left
  399. Dave Cridland has left
  400. nyco has left
  401. Dave Cridland has left
  402. la|r|ma has joined
  403. Dave Cridland has left
  404. lskdjf has joined
  405. Dave Cridland has left
  406. vanitasvitae has left
  407. Dave Cridland has left
  408. Dave Cridland has left
  409. Dave Cridland has left
  410. Dave Cridland has left
  411. Dave Cridland has left
  412. jubalh has left
  413. jubalh has joined
  414. jubalh has left
  415. Dave Cridland has left
  416. Dave Cridland has left
  417. Dave Cridland has left
  418. vanitasvitae has left
  419. Dave Cridland has left
  420. Dave Cridland has left
  421. suzyo has joined
  422. marc has left
  423. Alex has joined
  424. marc has joined
  425. vanitasvitae has left
  426. Dave Cridland has left
  427. Dave Cridland has left
  428. jere has joined
  429. jubalh has joined
  430. jubalh has left
  431. marc has left
  432. Ge0rG jonasw: I think the impact from http upload might be comparable to dns rebinding attacks
  433. Dave Cridland has left
  434. jonasw Ge0rG, the local servers thing is a point
  435. jonasw so I’d suggest to add a reference to CWE-918 in the security considerations and write that clients need to treat themselves as HTTP Proxies w.r.t. security considerations
  436. jonasw maybe we can find HTTP documents which elaborate on those
  437. Ge0rG jonasw: with newlines, the attacker can forge any payload to the http post
  438. lskdjf has joined
  439. jonasw daniel, ^
  440. jonasw Ge0rG, but we agreed to reject newlines.
  441. Ge0rG jonasw: I'm not saying it's impossible without newlines
  442. daniel Yes the newline thing doesn't need debating anymore
  443. Dave Cridland has left
  444. Ge0rG daniel: good luck finding out what is "on the LAN"
  445. daniel Ge0rG: any of the reserved IP ranges I mean
  446. Ge0rG Gets you into trouble in enterprise deployments
  447. jonasw Ge0rG, "unless the server is in a LAN"
  448. jonasw that’s by the way similar to the application boundary enforcement NoScript does by default…
  449. jonasw nightmare
  450. Ge0rG jonasw: yay for complex filtering rules!
  451. Dave Cridland has left
  452. jonasw Ge0rG, that wasn’t my idea
  453. jonasw Ge0rG, do you have a better solution, considering that some services will need headers for authn?
  454. jonasw (and authz)
  455. jonasw and we can’t predict the header names reasonably?
  456. daniel By the way the exploiting your plastic router scenario is kinda independent of the header discussion
  457. daniel Those are usually exploited by get parameters anyway
  458. Alex has joined
  459. Ge0rG daniel: indeed. Having PUT instead of POST does us a favor here.
  460. Ge0rG daniel: besides, it's easier to exploit things via POST than via GET, but most browsers block cross-origin-POST
  461. Ge0rG And then, the HTTPS certificate requirement should effectively protect typical LAN routers.
  462. Flow Ge0rG, why is PUT different from POST in this case?
  463. daniel Ge0rG, assuming your $10 router distinguishes between the different methods :-)
  464. Ge0rG but those are all mitigations
  465. Ge0rG daniel: touché
  466. Dave Cridland has left
  467. MattJ "Let's use HTTP because it's simple"
  468. MattJ ducks
  469. Ge0rG Flow: most HTTP appliances use POST for form submission, not PUT
  470. Flow yeah, XMPP is way simpler
  471. jonasw Ge0rG, browsers don’t block cross-origin post unconditionally; I know that you can cross-origin POST with a <form/> for example
  472. Flow ducks
  473. Ge0rG stop it now! I'm just reading Jingle-FT and it's gruesome.
  474. Ge0rG jonasw: good point. Does that make all HTTP POST endpoints exploitable?
  475. jonasw Ge0rG, that’s why we have CSRF tokens
  476. Ge0rG I love those.
  477. Ge0rG Let's add an CSRF token to HTTP-Upload.
  478. Alex has left
  479. Fabian has joined
  480. Flow I whish we had a magic marker which tells us when ge0rg is serious nor not
  481. Ge0rG Flow: I wish I had such a marker myself.
  482. SaltyBones what is the original document you guys are discussing?
  483. Ge0rG SaltyBones: XEP-0363
  484. SaltyBones -{XEP 0363}
  485. Flow -xep363
  486. Ge0rG SaltyBones: also https://mail.jabber.org/pipermail/standards/2017-November/033936.html
  487. Flow hmm
  488. Flow -xep-0363
  489. MattJ -xep 363
  490. Bunneh MattJ: HTTP File Upload (Standards Track, Proposed, 2017-12-03) See: https://xmpp.org/extensions/xep-0363.html
  491. Tobias Ge0rG, what's your issue with Jingle FT?
  492. Dave Cridland has left
  493. Ge0rG Tobias: it's an overengineered horrible mess
  494. Ge0rG Tobias: I can only hope that all of the complexity comes from the domain and not from Jingle-FT itself.
  495. Tobias Ge0rG, in what way? what bit is in there that's not needed to get peer-to-peer file transfer working in all cases
  496. Tobias the complexity likely comes from the problem domain
  497. Tobias WebRTC is similarly complex
  498. Ge0rG Tobias: except WebRTC also has proper NAT traversal and e2ee ;)
  499. Flow I think both Jingle and WebRTC have room for improvement when it comes to reducing the complexity. But I doubt that it's going to happen, because their deployment reached the critical mass
  500. Flow Ge0rG, Jingle has E2EE too (not sure what the current state of the xep is)
  501. jonasw "Experimental"
  502. Ge0rG Flow: "horrrible"
  503. Tobias WebRTC has decent e2ee? I thought it's e2ee was MITM-able
  504. Ge0rG or maybe "abandoned"
  505. stefandxm has joined
  506. la|r|ma has joined
  507. marc has joined
  508. andy has joined
  509. marc It has E2EE if the signaling channel is protected
  510. Ge0rG marc: ITYM if the server is trusted.
  511. SaltyBones Maybe this is controversial but I think 0363 should NOT allow "unlimited other headers" at most it should allow one or two specific ones but imho none would be more appropriate.
  512. jonasw SaltyBones, but there are services which require headers
  513. jonasw integration with those services was the goal of the update which introduced headers
  514. Dave Cridland has left
  515. SaltyBones Why doesn't the server just take the data and the put it wherever it belongs?
  516. Ge0rG HTTP-Upload headers are the XHTML-IM of this year's compliance suite.
  517. Ge0rG SaltyBones: because traffic and scalability
  518. jonasw Ge0rG, you’re exaggerating
  519. Tobias Ge0rG, what's your opinion on XEP-0385?
  520. rion has left
  521. SamWhited For once I disagree about the complexity. The trade off seems justified here, without the headers you can't have auth or signed URLs
  522. marc Ge0rG: not exactly, you could use OMEMO to protect the credentials
  523. rion has joined
  524. jubalh has joined
  525. SaltyBones So, why doesn't the server simply communicate the URL it passed to the client to whoever actually gets the data?
  526. SaltyBones should really stop talking.
  527. Ge0rG SamWhited: I'm only slightly serious, but I'd like to hear your input on how a malicious server could abuse http-upload to wreak havoc
  528. Ge0rG a malicious xmpp server
  529. jubalh has left
  530. Dave Cridland has left
  531. SamWhited I want to make sure that a client can't upload unlimited stuff, but the http server is on another host and knows nothing about the xmpp server. How can I do that without some way for the client to also communicate with the http server? I could maybe shove one or two things in the path, but that's going to get ugly quick
  532. SamWhited mostly I just want to use s3 directly though, which requires auth headers.
  533. Ge0rG SamWhited: so instead you opt for making the client a generic protocol proxy?
  534. stefandxm has left
  535. jonasw (a generic XMPP->HTTP proxy)
  536. SamWhited It's nothing close to that, it has to support http to do a post anyways, so you're just telling it how to structure its request
  537. jonasw SamWhited, this is exactly what proxying is
  538. Dave Cridland has left
  539. jonasw I was flabbergasted when Ge0rG said that first, but I think he’s right.
  540. Martin has left
  541. jonasw in the end what the client is here is a proxy supporting PUT with arbitrary headers to an arbitrary HTTP(S) host with an arbitrary URL
  542. jonasw the only thing the server can’t control is Content-* and the body
  543. SamWhited this sounds dangerously close to a semantic argument, so sure, it's a simple proxy without the complex body bits. that seems fine.
  544. Ge0rG SamWhited: I'd argue that we have a whitelist of HTTP headers that the module is allowed to override/set.
  545. SaltyBones SamWhited, isn't that impossible? The client has to request a slot from the XMPP server and must include the filesize and the receiving host must validate that filesize. They have to communicate, right?
  546. Ge0rG SaltyBones: they don't *have to*, the HTTP server can be independent
  547. jonasw SamWhited, SaltyBones, mod_http_upload_external for prosody essentially includes an HMAC of the content size and file name into the PUT URL query which is verified by the peer.
  548. jonasw but other, already existing things require HTTP headers to dot hat
  549. jonasw but other, already existing things require HTTP headers to do that
  550. SamWhited Ge0rG: what benefit would a white list provide?
  551. Ge0rG SamWhited: we would severely limit what a malicious server can do via the client-proxy.
  552. SamWhited SaltyBones: upload servers often need things at point of upload, eg a bearer token.
  553. SamWhited Ge0rG: I see, that seems fair.
  554. Ge0rG SamWhited: have a look at http://blog.portswigger.net/2017/07/cracking-lens-targeting-https-hidden.html#host for how to abuse an HTTP proxy to access non-HTTP protocols
  555. Ge0rG Seems like nobody is reading my emails :>
  556. SamWhited I'm reasonably sure this isn't actually a problem here, but I'd be interested in trying to come up with a POC. Will read that when I get to my desk
  557. Dave Cridland has left
  558. Ge0rG SamWhited: tl;dr: if you can inject raw multi-line text into requests to custom ports, you can own many text-based protocols.
  559. SamWhited oh, well yah, headers have to be sanitized
  560. Ge0rG I'm pretty sure that SMTP looks sufficiently close to HTTP to be able to send an email just by passing a long list of custom headers ;)
  561. jonasw I’m not so sure
  562. jonasw or does SMTP use colons everywhere?
  563. Ge0rG jonasw: MAIL FROM: foo RCPT TO: bar
  564. jonasw ew
  565. jonasw but can you add spaces to HTTP header names?
  566. Ge0rG jonasw: it depends™
  567. daniel Ge0rG: but you can't pass a data and a dot
  568. daniel As mentioned earlier
  569. SamWhited it also uses mime like headers, yah. But that's an easy fix.
  570. SamWhited That being said, I agree it's going to be a problem.
  571. SamWhited Actually, no I don't. I need to be at my desk to test this, but I'd be suprised if most http libraries allowed invalid requests that way.
  572. jubalh has joined
  573. jere has left
  574. jere has joined
  575. SamWhited The attack vector here relies on the users server or a component being malicios too, but part of xmpps security model is that you have to trust your server, so it botheers me less, though if we can mitigate it without too much trouble that seems fine.
  576. SamWhited /thinking-out-loud
  577. SamWhited spling is herd
  578. Ge0rG SamWhited: I tend to agree with what you say, but having such a reverse proxy in a corporate network will surely ring some compliance bells.
  579. SamWhited I doubt it, but I'lk ask our compliance person when I get to the office
  580. andy has left
  581. SaltyBones Who are these people who want to put their http upload data on a different machine but cannot be bothered to give it an interface which can check urls with HMACs and why should we care about them? :p
  582. Ge0rG SamWhited: I'm also not sure that all http libraries properly sanitize headers.
  583. Ge0rG SaltyBones: amazon cloud was called out
  584. SamWhited We didn't use it at HipChat for this reason if you need a real world example.
  585. SamWhited Also S3 gives you 5 gigs of free storage or something, but the bandwidth to proxy it is not free.
  586. Dave Cridland has left
  587. SamWhited Well, in all fairness I'm not sure that it would fit HipChats use case anyways, but it was immediately discounted because there was no control over requests
  588. SaltyBones and they wanted total control or would some kind of "provide this token" have been sufficient?
  589. jonasw SaltyBones, headers, obviously, because the server had full control over the URL all the time
  590. SamWhited We needed the ability to set auth headers, I think. Can't remember if we needed other stuff for signing or not, seems like that didn't end up making it to the final thing.
  591. Ge0rG SamWhited: so can we agree on a whitelist of "Authorization" and "Cookie"?
  592. Ge0rG and _maybe_ "X-*"
  593. jonasw Ge0rG, also, what is the issue we’re seeing here by the way?
  594. jonasw the only real issue is with network boundaries, isn’t it?
  595. Dave Cridland has left
  596. jonasw and the possibility for the malicious XMPP server to disguise itself behind the HTTP upload-ing clients
  597. jonasw otherwise the XMPP server could carry out the attacks themselves
  598. jonasw and with much more precision
  599. Ge0rG jonasw: yes.
  600. jubalh has joined
  601. SamWhited maybe… if it's not actually a problem a white list seems like it will just be ignored by half of clients and end up causing interoperability problems. We should try to prove that it is, or is not, a problem first in my mind.
  602. jonasw so if there is stuff which breaks from unauthenticated plaintext being sent, I’d be inclined to argue that the stuff which breaks is at fault
  603. jubalh has left
  604. jonasw +1 SamWhited
  605. SamWhited I still think trusting the server is okay too.
  606. jonasw that too
  607. jonasw (even though the server might be in an entirely different trust domain than the network the client is on)
  608. Ge0rG SamWhited: if we make it a closed whitelist, we can just provide according xmpp elements for each header name
  609. Ge0rG SamWhited: so that clients can't make dumb errors.
  610. jonasw Ge0rG, for all X-* headers? ;-)
  611. jonasw (blanket-allowing X-* is a bad idea though, IMO)
  612. Ge0rG jonasw: this is why I wrote "closed" :P
  613. Guus has left
  614. Ge0rG jonasw: yes, blanket-allowing X-* is bad. But less bad than blanket-allowing *.
  615. MattJ A whitelist makes the feature next to pointless, if the point was to allow arbitrary 3rd-party upload protocols
  616. jonasw that
  617. SamWhited Agreed.
  618. jonasw Ge0rG, I’d argue that an overly-open whitelist is worse than "*"
  619. Ge0rG A blacklist is worthless as well, due to the complexities and lack of standardization of HTTP.
  620. SamWhited Also agree.
  621. MattJ If we're really worried, we can solve it by just ("just") having the client enforce the same same-origin policies a browser would
  622. jonasw MattJ, you mean "none"?
  623. Ge0rG MattJ: awesome idea. because same-origin works so well on HTTP already?
  624. jonasw POST/PUT can be sent cross-domain
  625. MattJ Ge0rG, imagine a world without it
  626. MattJ jonasw, since when?
  627. jonasw MattJ, at least with <form/>
  628. Dave Cridland has left
  629. Ge0rG MattJ: a world without cross-origin scripting? It would be great!
  630. MattJ jonasw, ah, but you can't send custom headers that way, at least
  631. Ge0rG so we need to disable custom headers in 0363. QED.
  632. jonasw MattJ, true
  633. MattJ for not-same-origin?
  634. jonasw not-same-origin will ~always be the case with s3, won’t it?
  635. MattJ CNAME
  636. jonasw does that work?
  637. jonasw with Host header etc.?
  638. Fabian has left
  639. jonasw .oO(CNAME and set Host header. bazinga)
  640. MattJ Yes, you can serve any domain from S3 with the right configuration and DNS records
  641. Ge0rG the problem with CNAME will be one of HTTPS certificate validation
  642. MattJ Amazon handles this for you, not an issue
  643. jonasw MattJ, amazon maybe, but $non-amazon-cloud-provider object storage?
  644. jonasw do we want to pin people to amazon with that rule?
  645. SaltyBones I'm in no way an expert on the matter but https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy clearly says "Cross-origin writes are typically allowed" and https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest has a function "XMLHttpRequest.setRequestHeader()"
  646. MattJ You're not pinning them to Amazon - any provider can use Let's Encrypt for example, if you point a CNAME at them
  647. la|r|ma has joined
  648. jonasw MattJ, yes, but I bet not many do
  649. MattJ jonasw, this is not a protocol problem
  650. jonasw MattJ, yes, but .....
  651. MattJ Delegating to a third-party is something people (rightly) want to do. It can be done.
  652. jonasw do we need to make it harder for people?
  653. SaltyBones So it seems to me, like what we are trying to prevent, can be accomplished with JS in a w ebsite...
  654. MattJ They don't have to do this, it's optional
  655. SamWhited hmm, this seems sensible at first glance. It does limit what you can do with the upload, but it does seem desirable from a security standpoint and the drawbacks aren't that severe. It moves the place you define trust to DNS, which is how xmpp does things anyways.
  656. Dave Cridland has left
  657. daniel but same origin doesn't protect you if your own server is bad
  658. jonasw hmm
  659. daniel they could just point a cname to 192.168. something
  660. SamWhited you have to trust your own server anyways
  661. jonasw SamWhited, in that case the whole discussion is moot and we can just allow arbitrary headers!
  662. jonasw daniel, +1
  663. daniel SamWhited, the entire debate is about not trusting your server
  664. Guus has left
  665. SaltyBones Can somebody tell me why what we are trying to prevent is NOT something that JS on websites can do?
  666. SaltyBones In other words, something that is "somebody elses problem".
  667. Ge0rG daniel: pointing a cname to 192.168.x.x won't give you a valid certificate.
  668. Ge0rG SaltyBones: modern browsers will use CORS to prevent cross-origin POST/PUT
  669. Ge0rG SaltyBones: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS > Additionally, for HTTP request methods that can cause side-effects on server's data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method
  670. Dave Cridland has left
  671. Dave Cridland has left
  672. SaltyBones Ge0rG, CORS is a way so circumvent the SOP and the SOP is what I quoted above as not protecting you against cross origin writes...where is the error?
  673. jonasw SaltyBones, because you read "typically" as "always"?
  674. SaltyBones jonasw, but this is enforced in the browser not per site, right?
  675. jonasw SaltyBones, https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests > In particular, a request is preflighted if any of the following conditions is true: > * If the request uses any of the following methods: > * PUT
  676. MattJ It's enforced in the browser. In our discussion, the XMPP client is in the place of the browser
  677. jonasw I think that is pretty clear
  678. jonasw so SaltyBones, if e.g. your plastic router instructs the browser to reject cross-origin POST requests, it would be safe with modern browsers.
  679. jonasw but it would not be safe against HTTP-Upload
  680. Ge0rG MattJ: so we need to mandate the XMPP client do an HTTP OPTIONS call to the server and to check CORS
  681. uc has joined
  682. jonasw Ge0rG, noooooooooooooooooo
  683. MattJ > 13:19:49 MattJ> "Let's use HTTP because it's simple"
  684. Ge0rG I'll -1 the XEP until this is mandated, or until I'm kicked out of Council.
  685. MattJ -1's Ge0rG
  686. jonasw -1's HTTP
  687. jonasw I think that’s the right course of action anyways.
  688. MattJ first performs an OPTIONS request to verify he's allowed to -1 Ge0rG
  689. Ge0rG MattJ: you are not.
  690. Guus has left
  691. intosi 303 Pull the other one
  692. Dave Cridland has left
  693. jonasw Ge0rG, what about my "if a thing breaks by unauthenticated plaintext, it is that things fault"?
  694. Dave Cridland has left
  695. Alex has joined
  696. Ge0rG jonasw: talk to a BigCorp CSO and explain that to them, and how their "trusted core network consisting of the datacenter and the office network" must be fixed yesterday.
  697. Alex has left
  698. jonasw SamWhited, my feeling is that "trust your serevr" is not applicable here, because this is a different level of privilegue. I trust my XMPP server to handle my IM, but I wouldn’t trust it with remote code execution on my client. Likewise, I’m not sure I’d trust it with "arbitrary" network access.
  699. Dave Cridland has left
  700. jonasw Ge0rG, why the hell would you allow people to run XMPP clients in your trusted core network?
  701. valo has joined
  702. jonasw or any not thoroughly audited software for that matter
  703. jonasw if it’s so crucial to your operations and there’s no additional layer of authentication except being in that network.
  704. Ge0rG jonasw: because Gajim portable and Direct-TLS on :443
  705. jonasw don’t allow removable drives?
  706. Ge0rG don't allow The Internet?
  707. jonasw on the same note, why would you allow people to accsss the intenet at all from that network. you’re doing it very wrong in that case.
  708. jonasw yeah
  709. SamWhited You're alreadytrusting that by virtue of connecting to a thing in an srv record.
  710. jonasw SamWhited, but it can’t control what contents I send there, except for its domain name
  711. jonasw and even that it can’t really controll
  712. jonasw while HTTP Upload does let it control a substantial part of the content I send
  713. SamWhited fair
  714. jonasw so, strawman proposal: what about we make a disco#info form or something which tells the client which headers will be used by a given upload service. They can then decide whether to use that service at all (before showing in the UI that an upload would be possible, thus improving UX in the "no, that’s not okay" use case). And then clients can keep their own whitelist, while we recommend a whitelist in the XEP which contains Authentication, Cookie, Cookie2 (maybe?), and whatever S3 needs
  715. Dave Cridland has left
  716. Ge0rG jonasw: please don't.
  717. jonasw mention the trade-offs clearly in the security considerations, too
  718. jonasw Ge0rG, why not?
  719. Ge0rG jonasw: the client can't decide that, and the user even less so.
  720. jonasw how can we decide what the client can’t decide?
  721. Ge0rG jonasw: the client can't decide anything.
  722. daniel has left
  723. Guus has left
  724. Flow Ge0rG, it's hard to follow your arguments when you don't provide an explaination
  725. Dave Cridland has left
  726. jonasw I’m fine with allowing any header then, I think. Most havoc can be wreaked (on the web side, which is why we have CORS etc.) due to cookies
  727. jonasw and existing sessions
  728. jonasw which isn’t applicable here
  729. Ge0rG Flow: which argument do you want explained?
  730. Flow Ge0rG, why can't the client decide which headers to use or not?
  731. Ge0rG Flow: because client developers are already incapable to securely implement IQs, Carbons and XHTML-IM. I'm a full-time IT security consultant and I have a hard time figuring out which HTTP headers might have malicious side-effects.
  732. andy has joined
  733. Dave Cridland has left
  734. Ge0rG Flow: a client doesn't know if it runs in a "secure network" of some sort
  735. Flow got it, thanks
  736. Ge0rG has left
  737. Ge0rG has left
  738. daniel Ge0rG, could you name one header that can cause bad side effects? (something that couldn't be done with the URL)
  739. daniel (assuming the headers are stripped of \n which I already agreed to)
  740. Ge0rG daniel: sending a mismatching `Host` header will confuse middleboxes.
  741. jubalh has joined
  742. Dave Cridland has left
  743. Guus has left
  744. Ge0rG a `Connection` header might at least confuse the server, causing a small DoS
  745. daniel a middle box that mitm https?
  746. Seve/SouL has joined
  747. Ge0rG daniel: yes, that's a common setup at BigCorps
  748. daniel has left
  749. Ge0rG We could also require an Origin header to be set to the HTTP-Upload component name, cf. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Origin
  750. Ge0rG But this is less strong than any enforced filtering
  751. Dave Cridland has left
  752. jonasw Ge0rG, that concurs with my argument "do not let the server override any header you’re setting yourself"
  753. pep. Let me jump in an propose a jingle-ft component on the server to counter http-upload :-°
  754. jonasw both Connection and Host would typically be set by the client (one due to how the lib works, one from the URL)
  755. pep. is waiting for the stick
  756. jonasw pep., do it
  757. Ge0rG jonasw: "typically"
  758. daniel > Ge0rG, that concurs with my argument "do not let the server override any header you’re setting yourself" that by the way i'm fine with and i'm actually implemting this in Conversations right now
  759. Ge0rG jonasw: do you know from memory which HTTP headers are set by your favorite http client library? And which of those can't be overridden?
  760. pep. jonasw, I wish I had the knowledge and time for it, but yeah I've heard ideas here and there about this already
  761. Dave Cridland has left
  762. Ge0rG jonasw, daniel: so what you are doing is the blacklist approach.
  763. daniel in that case yes
  764. daniel although it is not a fixed blacklist
  765. Ge0rG has left
  766. Ge0rG has left
  767. SaltyBones Proposal: We ditch alls this in favor of something that ONLY supports what amazon s3 does
  768. SaltyBones Which hopefully should be easy to tighten...
  769. SaltyBones This gives people the option to 1. Use S3 2. Use their XMPP server 3. Emulate one of two API
  770. intosi has left
  771. intosi has joined
  772. Dave Cridland has left
  773. MattJ Except that I wanted to experiment with using Dropbox/NextCloud/etc. as upload services
  774. MattJ and neither mimic S3
  775. andy has left
  776. stefandxm has joined
  777. daniel MattJ, maybe do your expirments and see what headers they require? probably most of them will just use authorize anyway?
  778. daniel in which case instead of allowing header we could just allow authorize or something
  779. SamWhited I really want to try Joyents blob file storage with the Content-MD5 header.
  780. SamWhited Also allowing the server to set the durability-level header which indicates the number of backups in different regions that are required.
  781. moparisthebest has joined
  782. Ge0rG SamWhited: that sounds like a _very special_ special case.
  783. daniel SamWhited, that sounds a bit dangerous to give the client control over that?
  784. MattJ daniel, I don't know about Dropbox, but NextCloud is either basic auth (if you don't mind sharing credentials with your server) or cookies
  785. SamWhited Not especially; they could cost me a tiny bit more money by having the max replication factor all the time, or not have backups of their own files
  786. SamWhited But yah, fair enough, that's a special case.
  787. daniel MattJ, then maybe authorize and cookie
  788. Holger FWIW, being able to set an X-ejabberd-something header would be very useful for me.
  789. Ge0rG has joined
  790. Ge0rG daniel: I could live with `Authorization` and `Cookie` being the only whitelisted headers.
  791. Holger (Or without the "X-", IIRC today's youth dislikes that?)
  792. Ge0rG Holger: what for?
  793. Holger Ge0rG: Mapping the HTTP request to a virtual host (configuration).
  794. MattJ Dropbox is also Authorization it seems
  795. daniel the thing is that i wasn't the one who wanted headers in there in the first place
  796. Ge0rG Holger: you are doing it wrong.
  797. Dave Cridland has left
  798. daniel so it's hard for me to argue for either one side
  799. Holger Ge0rG: How to do it right?
  800. Ge0rG Holger: use the Host header to route to virtual hosts? :P
  801. Holger No.
  802. Holger Or well.
  803. Dave Cridland has left
  804. Ge0rG has joined
  805. Dave Cridland is just thinking this is definitely more complex than the Security Considerations of the XEP makes out.
  806. Dave Cridland has left
  807. Dave Cridland has left
  808. Dave Cridland has left
  809. daniel I mean if we white list only cookie and auth you could set a cookie Holger
  810. Ge0rG Holger: on your own infrastructure you could also `PUT https://yourserver.com/yourxmppdomain/random/random.jpg`
  811. jubalh has left
  812. daniel If you don't want to use the vhost
  813. Holger Ge0rG: That works if you have an 1:1 mapping between HTTP 'Host' and virtual hosts of course, but admins will spam your tracker if you impose such restrictions.
  814. daniel Or what Ge0rG said
  815. Holger Yes I suggest such things in the docs.
  816. Guus has left
  817. Holger Still tracker spam :-)
  818. SamWhited I'm not sure the whitelist really works; as soon as we do that most signing schemes break. Eg. Joyents requires Host, Amazon's requires that you specify headers to sign up front, I think and has a handful that it always requires.
  819. Holger daniel: Yes I could probably abuse Auth/Cookie headers.
  820. Dave Cridland has left
  821. SamWhited And if we're really worried about invalid headers from a malicious server, having any headers at all is a problem (though as I said, I'm not convinced we should be worried about that)
  822. Holger I'm just saying that I doubt we'll come up with all possible use cases in here.
  823. daniel > I'm not sure the whitelist really works; as soon as we do that most signing schemes break. Eg. Joyents requires Host, Amazon's requires that you specify headers to sign up front, I think and has a handful that it always requires. Can you find out what exactly it requires?
  824. SamWhited Yah, just a moment, I hate looking at the S3 docs (which are terrible) so I was being lazy and looked up Joyents instead.
  825. Holger So the idea now is to cope with a few services that are popular today and just hope for the best that the next one will use the same headers?
  826. Alex has joined
  827. SamWhited a bunch of x-amz- headers, otherwise I'm having trouble finding info.
  828. SamWhited But what Holger said.
  829. suzyo has joined
  830. Ge0rG So it's ["Cookie", "Authorization", "X-*"]
  831. Holger ...
  832. Dave Cridland has left
  833. SamWhited I'm still not sure what problem we think we're solving with this.
  834. SamWhited Amazon also does Host and User-Agent at least, I think
  835. SamWhited Although User-Agent makes no sense to me, so maybe this is wrong
  836. daniel SamWhited, the user agent has to be set to something specific?
  837. SamWhited I'm reading this page, and being confused: https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
  838. SaltyBones SamWhited, the problem we are trying to solve is that we are currently giving the server the possibility to trigger arbitrary HTTP requests from the client.
  839. daniel oh signed
  840. daniel i get it
  841. SamWhited SaltyBones: that is not a problem description. Why is that bad?
  842. SamWhited I know we've been through this, but I'm just not sure that it's actually a problem and am trying to figure out if it would really cause any security issue.
  843. SaltyBones SamWhited, I'm not convinced that it is but Ge0rG's link does suggest otherwise.
  844. Ge0rG SamWhited: that signature needs to contain the content md5. I can't see how you can make a client generate that header.
  845. Dave Cridland [[ 20 minutes until Council, BTW ]]
  846. SamWhited Does it? I know I've made amazon work before, but yah that doesn't seem like it can be supported easily without additional modifications
  847. SamWhited SaltyBones: his link was about malicious invalid headers, right? (I lost it, sorry, no search in any of my clients) This doesn't solve that (again, if it's actually a problem in our case)
  848. stefandxm has left
  849. Ge0rG SamWhited: the signature also depends on YourSecretAccessKeyID, which I'm sure you don't want to leak to the client.
  850. MattJ https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationQueryStringAuth
  851. andy has joined
  852. Ge0rG SamWhited: so either the xmpp server needs to have the MD5 in advance or you are doomed.
  853. SamWhited Ge0rG: that's fine, you can generate one per request
  854. intosi has left
  855. SamWhited But yah, MD5 is a problem. It might not always be required though, because I know I've made this work before
  856. intosi has joined
  857. Dave Cridland has left
  858. Guus has left
  859. suzyo has joined
  860. Dave Cridland has left
  861. lskdjf has joined
  862. waqas has joined
  863. pep. has left
  864. tux has left
  865. MattJ SamWhited, I think it's optional, in that I think if you don't provide the header you just put an empty string in the string-to-sign
  866. Dave Cridland By the way, if anyone wants to take some minutes for the Council meeting (in a few minutes from now), that'd be tremendously useful.
  867. Dave Cridland has left
  868. Ge0rG has left
  869. blabla has left
  870. andy has left
  871. vanitasvitae has left
  872. MattJ SamWhited, and at this point... it looks like S3 allows putting everything into the query string? :)
  873. vanitasvitae has joined
  874. Ge0rG has left
  875. Ge0rG has left
  876. Ge0rG has left
  877. Ge0rG has left
  878. Ge0rG has left
  879. Ge0rG has left
  880. Ge0rG has left
  881. Ge0rG has left
  882. SamWhited That's useful, I didn't realize that. I would prefer not to put auth in the query string either way though.
  883. Ge0rG has left
  884. Ge0rG has joined
  885. Ge0rG has left
  886. SaltyBones Why?
  887. Ge0rG has left
  888. jubalh has joined
  889. Ge0rG has left
  890. SamWhited Because it's generally accepted best practice that you don't. Things log URLs and it's acceptable to do so, they don't generally log headers (because that's generally where you put things you don't want logged like this)
  891. tux has joined
  892. Dave Cridland has left
  893. Dave Cridland [[ Council time over in council@muc.xmpp.org ]]
  894. goffi pep.: I have a server side jingle-ft component
  895. pep. goffi, !
  896. pep. Is it in a working state
  897. goffi I'm currently working on it, but it's already working yes
  898. pep. Also, there's no XEP for that right? Or how much is it covered by the current XEP?
  899. goffi the XEP is jingle FT
  900. goffi instead of sending to an other client, I send to the component
  901. goffi nothing else to do
  902. tux has joined
  903. Dave Cridland has left
  904. SaltyBones and then the server offers it via httpupload or again jingle?
  905. pep. Sure but then you can do things with your component you can't do with clients
  906. pep. You can use your component to proxy the transfer, to retry when the other contact is back online etc.
  907. pep. Or just serve the file
  908. SaltyBones I'm not complaining just trying to figure out what's happening. :)
  909. goffi SaltyBones: I'm on this part currently, implementing XEP-0329, but I'm not happy with it, I plan to write a feedback on standard@ about that
  910. pep. SaltyBones, jingle
  911. pep. I hope
  912. pep. I don't see the point of http-upload here
  913. pep. It's not unfeasible though, the component could serve via http as well
  914. goffi I'm saying that since HTTP upload is on the table. The only interest is has, is that it's easy to implement when jingle is not yet implemented in a library
  915. goffi but once you have jingle, it's more easy to do this way.
  916. Dave Cridland has left
  917. andy has joined
  918. goffi and with namespace delegation, you can even send fileto your bare jid, you don't even need to find the component. I've not done it yet, but it's in my TODO
  919. jjrh has left
  920. Dave Cridland has left
  921. blabla has left
  922. blabla has left
  923. blabla has joined
  924. jubalh has left
  925. Ge0rG has left
  926. Dave Cridland has left
  927. jubalh has joined
  928. jubalh has left
  929. Dave Cridland has left
  930. Guus has left
  931. Guus has left
  932. Dave Cridland has left
  933. efrit has joined
  934. jjrh has left
  935. jjrh has left
  936. jubalh has joined
  937. Dave Cridland has left
  938. Dave Cridland has left
  939. lumi has joined
  940. la|r|ma has joined
  941. Kev has left
  942. Dave Cridland has left
  943. jubalh has left
  944. blabla has left
  945. SaltyBones has left
  946. rion has left
  947. Dave Cridland has left
  948. jjrh has left
  949. blabla has left
  950. Dave Cridland has left
  951. tim@boese-ban.de has left
  952. Dave Cridland has left
  953. andy has left
  954. Dave Cridland has left
  955. Ge0rG has left
  956. Dave Cridland has left
  957. tux has joined
  958. blabla has left
  959. Guus has left
  960. efrit has left
  961. efrit has joined
  962. Guus has left
  963. Guus has left
  964. stefandxm has joined
  965. lskdjf has joined
  966. Dave Cridland has left
  967. lovetox has joined
  968. Guus has left
  969. pep. has left
  970. Dave Cridland has left
  971. Kev has joined
  972. jubalh has joined
  973. Dave Cridland has left
  974. stefandxm has left
  975. Dave Cridland has left
  976. andy has joined
  977. Dave Cridland has left
  978. SaltyBones message-id question: why can't we use a counter
  979. SaltyBones I have heard: 1. State keeping is impossible, 2. Attacks based on guessing the id but I'm not convinced that either is a real thing.
  980. la|r|ma has left
  981. Dave Cridland has left
  982. SamWhited State keeping is very difficult if you have a cluster. Your counter has to be centralized and atomic, which rather defeats the purpose of having a cluster.
  983. SaltyBones can I PM you for discussion? I don't want to spam this channel all the time :)
  984. SamWhited Message me directly please (sam@samwhited.com); none of my clients handle PMs well.
  985. SamWhited Though this is probably good discussion and I don't think you'd be spamming this channel :)
  986. Dave Cridland has left
  987. jere has left
  988. jere has joined
  989. Dave Cridland has left
  990. andy has left
  991. Dave Cridland has left
  992. pep. has left
  993. @Alacer has left
  994. waqas has left
  995. @Alacer has joined
  996. @Alacer has left
  997. @Alacer has joined
  998. Dave Cridland has left
  999. Kev has left
  1000. jere has joined
  1001. jere has joined
  1002. Steve Kille has left
  1003. Dave Cridland has left
  1004. Dave Cridland has left
  1005. jjrh has left
  1006. blabla has joined
  1007. Dave Cridland has left
  1008. Steve Kille has joined
  1009. Tobias has joined
  1010. andy has joined
  1011. Dave Cridland has left
  1012. jonasw yeah
  1013. jonasw I’d prefer such discussions here too
  1014. jonasw most of the time they’re insightful
  1015. Dave Cridland has left
  1016. waqas has joined
  1017. intosi has left
  1018. andy has left
  1019. Dave Cridland has left
  1020. jubalh has joined
  1021. moparisthebest SaltyBones, state keeping client side is impossible too
  1022. andy has joined
  1023. moparisthebest see: vm snapshots
  1024. moparisthebest (server side also)
  1025. Dave Cridland has left
  1026. Dave Cridland has left
  1027. andy has left
  1028. Dave Cridland has left
  1029. jjrh has left
  1030. andy has joined
  1031. Guus has left
  1032. jjrh has left
  1033. Dave Cridland has left
  1034. lskdjf has left
  1035. andy has left
  1036. la|r|ma has left
  1037. andy has joined
  1038. Dave Cridland has left
  1039. rion has joined
  1040. Guus has left
  1041. Dave Cridland has left
  1042. jjrh has left
  1043. jjrh has left
  1044. Seve/SouL has left
  1045. Seve/SouL has joined
  1046. Seve/SouL has left
  1047. Seve/SouL has joined
  1048. ralphm has joined
  1049. Dave Cridland has left
  1050. jjrh has left
  1051. stefandxm has joined
  1052. Dave Cridland has left
  1053. Syndace has left
  1054. Syndace has joined
  1055. rion has left
  1056. rion has joined
  1057. Dave Cridland has left
  1058. efrit has left
  1059. jere has joined
  1060. Dave Cridland has left
  1061. Guus has left
  1062. Dave Cridland has left
  1063. lskdjf has joined
  1064. Dave Cridland has left
  1065. efrit has joined
  1066. lumi has joined
  1067. lskdjf has joined
  1068. rion has left
  1069. Dave Cridland has left
  1070. Dave Cridland has left
  1071. stefandxm has left
  1072. Dave Cridland has left
  1073. Dave Cridland has left
  1074. Guus has left
  1075. Dave Cridland has left
  1076. Guus has left
  1077. Dave Cridland has left
  1078. Dave Cridland has left
  1079. Dave Cridland has left
  1080. Guus has left
  1081. Dave Cridland has left
  1082. Ge0rG We could also discuss why MUC-PMs are still broken in some clients :>
  1083. SamWhited They're just broken in general whichever model you take for them. There are tradeoffs both ways.
  1084. Dave Cridland has left
  1085. Ge0rG They are broken in poezio, but it seems that once you explain to a reasonable developer how to implement them, they magically start working.
  1086. Ge0rG At least it's a problem that's easier to solve than MUC reflection matching
  1087. efrit has left
  1088. efrit has joined
  1089. Guus Ge0rG: are they more broken than UI's not being aware to check if PMs are permitted in the room?
  1090. nyco has left
  1091. Dave Cridland has left
  1092. SamWhited Guus: you either have what Conversations / Mcabber do where they're mixed in with room traffic and you constantly accidentally send things you meant to be a PM to the room, or they're separate conversations in which case they look like 1:1's except a lot of stuff you'd expect to work just doesn't because they're actually MUCs.
  1093. SamWhited Also if they're mixed in with the room it's just hard to follow a conversation by PMs if there's also room chatter going on.
  1094. Dave Cridland has left
  1095. Dave Cridland has left
  1096. Ge0rG Guus: that should be solved by properly augmenting outgoing messages with their error bounces
  1097. Ge0rG SamWhited: I think that daniel's take at integrating PMs into the MUC is a conscious effort to make them unusable ;)
  1098. Ge0rG Besides of not working when you are not in the room, and most clients getting MUC-PM Carbons wrong, my experience is that they work just like normal messages, except you don't know the actual JID of the receiver.
  1099. SamWhited Ge0rG: as opposed to having them being separate conversations? That's almost as unusable, just for different reasons. Especially since if the person changes their nickname it immediately breaks everything and makes the world a confusing place.
  1100. daniel > Besides of not working when you are not in the room, or the recipient. but yes not working messages. pretty minor
  1101. Ge0rG SamWhited: a smart client would probably implement nick change tracking, but that doesn't work well for history.
  1102. Holger has left
  1103. Ge0rG SamWhited: but as opposed to nickname wars from the IRC days, people have pretty constant nicknames today.
  1104. daniel it's almost perfect. expect. you know. messages don't work if the recipient drives through a tunnel
  1105. SamWhited Right; MUC PMs in general are just a bad experience, no matter how you slice it.
  1106. Dave Cridland has left
  1107. Ge0rG I don't know. My experience with them has been better than with some MUCs, and even better than with direct messages in some corner cases
  1108. daniel and yes. making the UX bad in Conversations and 'hiding' it behind a long press is an attempt to guide people to send regular messages
  1109. Ge0rG daniel: except people botch it all the time and send private things in public by accident
  1110. blabla has left
  1111. Ge0rG daniel: it's okay to hide them, but please don't make them easy to mis-use
  1112. andy has left
  1113. Dave Cridland has left
  1114. Dave Cridland has left
  1115. Holger has left
  1116. Holger has left
  1117. Neustradamus has left
  1118. Neustradamus has joined
  1119. marc has left
  1120. marc has joined
  1121. Ge0rG I think that with always on clients and some self-presence checking code they can be made to work pretty well. Bonus points if you keep outgoing PMs stored until the nickname comes back online
  1122. daniel Lol sure. But why?
  1123. Dave Cridland has left
  1124. jonasw Ge0rG, so I can steal that nicknames PMs?
  1125. jonasw sweet
  1126. daniel The serve no purpose besides annoying me when people think that I help them faster if they pm me
  1127. Ge0rG jonasw: how do you know that I'm me?
  1128. jonasw Ge0rG, I could’ve established that during the conversation.
  1129. blabla has joined
  1130. Ge0rG (besides of the obvious one, me being the only person who cares about PMs)
  1131. daniel > Bonus points if you keep outgoing PMs stored until the nickname comes back online Until you are both online at the same time
  1132. Ge0rG jonasw: I could have left the conversation and been replaced by Mallory at any moment in time during our dialog
  1133. Dave Cridland has left
  1134. Ge0rG daniel: you can't see their presence if you are offline 😛
  1135. daniel Pretty cool feature these PMs
  1136. jonasw Ge0rG, not with a client which reasonably checks identity
  1137. jonasw i.e. either uses the real JID if available or assumes the worst :>
  1138. Ge0rG daniel: so you are annoyed because your client is popular? Note taken.
  1139. daniel And I could even have four conversations with four different Ge0rGs in four different mucs
  1140. daniel And I wouldn't even know if it's the same Ge0rG
  1141. daniel Pretty fucking awesome
  1142. daniel Plus the regular conversation with the real Ge0rG if have
  1143. jonasw I like what pidgin does (yes, really)
  1144. Ge0rG jonasw: daniel: now you are arguing against anonymous MUCs
  1145. jonasw if it knows the real JID, it’ll just make a conversation with that
  1146. daniel jonasw: execute code remotely?
  1147. jonasw completely circumventing the MUC. and your privacy if real JIDs are only visible to mods, I guess.
  1148. jonasw daniel, hah.
  1149. Ge0rG jonasw [21:11]: > I like what pidgin does (yes, really) Who are you and what have you done to jonasw?
  1150. Dave Cridland has left
  1151. Holger > now you are arguing against anonymous MUCs Go go go!
  1152. Holger Once we ditched anon MUCs, there's clearly no point anymore in keeping MUC PMs, is there?
  1153. jonasw we might need to solve the SPIM issue first.
  1154. jonasw or also ditch public MUCs in general. and even then I’m not convinced that this is a good idea.
  1155. Zash Solve you say?
  1156. daniel maybe we need a small protocol where you can ask someone for their real jid . or give them your real jid. sort of like an invite to chat 1:1. and the other person can accept or decline
  1157. jonasw Zash, yes.
  1158. Ge0rG Holger: tell that to the people who created MIX proxy JIDs.
  1159. Holger jonasw: Yes my suggestion is ditching public MUCs.
  1160. jonasw Holger, hm.
  1161. daniel so clients could render that as Ge0rG (georg@domain.tld) wants to talk to. is that cool?
  1162. jonasw Holger, what IM system would you propose as support channel for, say, prosody, then?
  1163. Dave Cridland has left
  1164. Holger jonasw: Or keep them the half-broken way we have them now. That's good enough for the few of us who use them.
  1165. Holger jonasw: IRC.
  1166. jonasw ugh
  1167. Holger Ok, Matrix :-)
  1168. jonasw Holger, okay, if we agree on that, we could "just" solve that with UX
  1169. SamWhited Maybe we ditch anonymous mucs, and then if you need to be anonymous your server could issue you with some sort of temporary JID that you could use. Some sort of "burner" jid, maybe. (actually, there were reasons this wasn't ideal, but I forget what they were every time this conversation happens)
  1170. Ge0rG SamWhited: didn't you even write a strawman xep for that?
  1171. Ge0rG BTW, was MIX even mentioned at the summit?
  1172. Seve Heh..
  1173. Holger Or just register an anon JID manually if you need that.
  1174. SamWhited -xep 0383
  1175. Bunneh SamWhited: Burner JIDs (Standards Track, Deferred, 2017-01-28) See: https://xmpp.org/extensions/xep-0383.html
  1176. Holger Like email users do.
  1177. Ge0rG Or has everybody sane finally reached the conclusion that MIX is dead?
  1178. Dave Cridland has left
  1179. jonasw Holger, right, because our multi-account story does work so well ;)
  1180. SamWhited -xep 0389
  1181. Bunneh SamWhited: Extensible In-Band Registration (Standards Track, Experimental, 2017-03-16) See: https://xmpp.org/extensions/xep-0389.html
  1182. Holger jonasw: Rather than investing time in fixing PMs we should fix that multi-account story!
  1183. Ge0rG SamWhited: the only problem with burner JIDs is that they are free and nobody can block them
  1184. andy has joined
  1185. jonasw Holger, I tend to agree
  1186. Ge0rG So all we need to do is a PoW attached to creating them!
  1187. jonasw I’ll... just ... stop following that discussion at this point.
  1188. SamWhited Ge0rG: yah, there needs to be some better policy or access control around them, but there didn't seem to be enough interest for that to be developed.
  1189. Ge0rG Do I hear blockchain m
  1190. Guus has left
  1191. SamWhited But it's no different than people running their own server that they could add tons of JIDs on really, and public servers can certainly rate limit since it requires authentication to get a burner JID
  1192. SamWhited Servers could even say that burner JIDs aren't allowed to federate, so they could only be used for MUCs on that server (in which case you could also allow them with SASL-ANONYMOUS)
  1193. Dave Cridland has left
  1194. Ge0rG SamWhited: now this is a really useful idea. I'm running a non federated anonymous server for support MUC purposes on my domain.
  1195. SamWhited Ge0rG: yah, I do the same, that could be a burner JID service as well and just don't allow burner JIDs to send to stuff on other domains to prevent spam.
  1196. jonasw daniel, IIRC, when zinid announced that he was working on the MUC bare-presence thing, you asked whether it’d include disco#info caps. Why did you ask for that? Which part of a MUCs disco#info do you need?
  1197. Ge0rG SamWhited: I'd say your last proposal is sufficient to kick all that proxy JID stuff from MIX.
  1198. Dave Cridland has left
  1199. SamWhited Ge0rG: there was some reason that it wasn't that I think I ended up being convinced by, but I can't remember what it was.
  1200. efrit has left
  1201. SamWhited But I would love it if we just ignored anonymous MUC and that was handled out of band, by my proposal or something else.
  1202. SamWhited Anonymous identities are useful for more than just chat rooms, so it doesn't make much sense to me that it should be part of the groupchat spec and only useable there.
  1203. daniel jonasw: mhhh I guess I don't really *need* it. I think I always query the muc anyway to get a response and avoid server not found et al. But I do work with the non anonymous, members only feature
  1204. efrit has joined
  1205. daniel And the form field that tells me if users are allowed to write pms and set the subject
  1206. jonasw daniel, okay, so you essentially need the Form :/
  1207. daniel Which currently doesn't provide the information I need anyway on ejabberd...
  1208. Ge0rG daniel: you should write an xep (or a new section for 45) on how to properly create a private MUC
  1209. goffi has left
  1210. daniel jonasw: yes. I'm aware of ejabberd putting in the member count though... Which makes that difficult...
  1211. Dave Cridland has left
  1212. Dave Cridland has left
  1213. jonasw daniel, so that use-case wouldn’t profit from splitting the caps hash into identities+features and forms
  1214. jonasw pity
  1215. daniel Other than that a lot of my conferences are configured the same. And having a caps hash would actually minimize the traffic a bit
  1216. jonasw daniel, but only if the occupant count isn’t in there
  1217. daniel Yes
  1218. jonasw and if it isn’t, it probably doesn’t matter a lot if we split the hashes because MUCs generally don’t have a very diverse feature set I assume
  1219. Ge0rG I'm displaying the occupant count in MUC invitations... 🤔
  1220. andy has left
  1221. jjrh Is there not a way to set a MUC to show everyones full JID?
  1222. daniel jjrh: yes
  1223. jonasw "yes there is a way%
  1224. jonasw "yes there is a way"
  1225. remko has left
  1226. Guus has left
  1227. Ge0rG https://upload.yax.im/upload/7Cr3yYVohs6RrCxg/1518640458381643013676.jpg
  1228. Dave Cridland has left
  1229. Holger has left
  1230. jjrh Because this issue is more of a annoyance in 'trusted' places - aka internal chat where there is no reason I shouldn't know you're JID and when I click your name in group chat (as a lazy way to send a PM vs going to my roster) it should do the right thing.
  1231. daniel jonasw: fwiw the split of what muc puts into features and the form is pretty weird and confusing anyway
  1232. Dave Cridland has left
  1233. Dave Cridland has left
  1234. Dave Cridland has left
  1235. daniel And the naming of the features as well
  1236. Dave Cridland has left
  1237. Dave Cridland has left
  1238. Dave Cridland has left
  1239. moparisthebest I quite like that burner jid thing
  1240. moparisthebest what were the downsides again SamWhited ? (or whoever)
  1241. Dave Cridland has left
  1242. SamWhited I wish someone would remind me, but I do remember being convinced that it wouldn't work for MIX ¯\_(ツ)_/¯
  1243. Alex has left
  1244. jjrh beh i'm dumb, I didn't know showing jids was a option in room configuration that probably solves /my/ issue at least.
  1245. Dave Cridland has left
  1246. Dave Cridland has left
  1247. stefandxm has joined
  1248. jjrh has left
  1249. Dave Cridland has left
  1250. Dave Cridland has left
  1251. moparisthebest SamWhited, oh, because burner JIDs aren't shared across devices?
  1252. moparisthebest which basically means multi-device can't work
  1253. moparisthebest so what if you essentially just solved the alias problem while you are at it?
  1254. Dave Cridland has left
  1255. moparisthebest a XEP that gives 'burner JIDs', except rather than being extra logins, the server just delivers all messages to that JID to your account, and you can also send things as that JID, same connection
  1256. moparisthebest it would be a bit complicated, but would solve the alias problem *and* the anonymous muc/mix/future mux/whatever problem
  1257. Dave Cridland has left
  1258. jonasw if multi-device doesn’t work, I’d be pretty unhappy wtih that
  1259. Syndace has left
  1260. Syndace has joined
  1261. Dave Cridland has left
  1262. stefandxm has left
  1263. efrit has left
  1264. Dave Cridland has left
  1265. Dave Cridland has left
  1266. Dave Cridland has left
  1267. daniel has left
  1268. daniel has left
  1269. daniel has left
  1270. Dave Cridland has left
  1271. daniel has joined
  1272. Dave Cridland has left
  1273. bra has left
  1274. Dave Cridland has left
  1275. Syndace has left
  1276. Syndace has joined
  1277. andy has joined
  1278. Dave Cridland has left
  1279. intosi has joined
  1280. Dave Cridland has left
  1281. jubalh has joined
  1282. daniel has left
  1283. Dave Cridland has left
  1284. SamWhited yah, that's probably it; multidevice seems like a must. I actually had it that way originally before someone reminded me that SASL provides an authorization identity; mixing the two streams felt *really* dangerous to me though.
  1285. andy has left
  1286. SamWhited The server could always issue the same burner JID to all of your devices though.
  1287. Dave Cridland has left
  1288. daniel has joined
  1289. Alex has left
  1290. Alex has joined
  1291. Dave Cridland has left
  1292. valo has left
  1293. valo has joined
  1294. Dave Cridland has left
  1295. daniel has left
  1296. daniel has joined
  1297. Dave Cridland has left
  1298. Tobias has left
  1299. moparisthebest has joined
  1300. SamWhited has left
  1301. jubalh has left
  1302. Dave Cridland has left
  1303. Dave Cridland has left
  1304. Ge0rG Burner could work as a jabber transport as well.
  1305. SamWhited Ge0rG: I didn't understand that?
  1306. suzyo has joined
  1307. Dave Cridland has left
  1308. Tobias has joined
  1309. stefandxm has joined
  1310. andy has joined
  1311. Dave Cridland has left
  1312. Ge0rG SamWhited: implement it as an xmpp 2 xmpp transport...
  1313. Ge0rG Would give us roster control and the ability to unsubscribe and obtain a new identity
  1314. SamWhited I don't think a second JID would help you with that, you still need the client and server to speak the protocol. I suspect I'm missing something though
  1315. SamWhited oh, not 'xmpp2 to xmpp transport'
  1316. SamWhited I am still not sure how it helps or what use an xmpp to xmpp transport is though
  1317. lskdjf has joined
  1318. SamWhited Different identities in your roster I'll grant, although merging rosters is weird UI wise
  1319. andy has left
  1320. Dave Cridland has left
  1321. SaltyBones I postulate that all of this is caused by people wanting to use the same software for private chats and anonymous public chats. There is surprisingly little overlap in terms of both functionality and UI.
  1322. SamWhited I tend to agree
  1323. SaltyBones Also, people don't understand how any of this works anyway. If we completey drop anonymous JIDs it will be strictly better because nobody even understand what the benefits are or when they apply so they cannot make use of them. :p
  1324. blabla has joined
  1325. Zash More or less public chats are what we use XMPP for ourselves. Don't underestimate that use case.
  1326. SaltyBones Zash, what do you mean by more or less public chats?
  1327. Zash SaltyBones: This very room for example.
  1328. SaltyBones This room could have JIDs of everybody and nobody would care...
  1329. Zash I would, I'm not entirely comfortable with random people being able to contact me out of band just becasue I join a room.
  1330. Zash Not that my JID is secret
  1331. SaltyBones That's imho a matter of spam handling
  1332. blabla has left
  1333. Dave Cridland has left
  1334. Zash I don't mean because of spam
  1335. SaltyBones has left
  1336. Dave Cridland has left
  1337. SamWhited I can see anonymity being useful, I just don't think it makes sense to lump it in with grouochat.
  1338. SamWhited groupchat, even.
  1339. Zash In the prosody support room, the intention is for people to ask the room, so that someone who has time and will can reply and help. Sometimes they instead go directly to PM someone, which can create some amount of stress over not being able to shift the work to others.
  1340. jjrh While I set everyone to who may discover JID's, clicking someones name still creates a message in the context of the MUC instead of a direct message. This is with Gajim but i'm guessing this is a issue with other clients.
  1341. Tobias has joined
  1342. SaltyBones Zash: so you re saying it is already as bad as if there were no anonymous IDs? ;)
  1343. Dave Cridland has left
  1344. Dave Cridland has left
  1345. jjrh Zash, it's not just stress - chances are the answer is probably useful to others. :)
  1346. Zash That too
  1347. jjrh MUC message threads in a smart UI would be really cool on high volume channels where multiple questions/discussions are going on at the same time.
  1348. Zash There was a client that did that, IIRC. Vacuum-IM perhaps?
  1349. Zash There was one (mabye the same) that did #hashtags that let you filter on that as well.
  1350. had-hoc has joined
  1351. had-hoc has joined
  1352. nyco has left
  1353. SaltyBones has left
  1354. SaltyBones has joined
  1355. Dave Cridland has left
  1356. mathieui has joined
  1357. had-hoc has joined
  1358. Dave Cridland has left
  1359. Guus has left
  1360. Dave Cridland has left
  1361. Dave Cridland has left
  1362. Dave Cridland has left
  1363. Dave Cridland has left
  1364. Dave Cridland has left
  1365. efrit has joined
  1366. Dave Cridland has left
  1367. Guus has left
  1368. mathieui has joined
  1369. lovetox has left
  1370. efrit has left
  1371. efrit has joined
  1372. waqas has left