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