XSF Discussion - 2017-10-13

  1. Guus has joined
  2. Guus has left
  3. Guus has joined
  4. intosi has joined
  5. Guus has left
  6. Guus has joined
  7. Guus has left
  8. Guus has joined
  9. Guus has left
  10. Guus has joined
  11. daniel has left
  12. Guus has left
  13. dwd has left
  14. Zash has left
  15. Zash has joined
  16. jere has left
  17. jere has joined
  18. nyco has left
  19. Zash has left
  20. jjrh has left
  21. Zash has joined
  22. efrit has joined
  23. intosi has joined
  24. jjrh has left
  25. intosi has joined
  26. Guus has joined
  27. jjrh has left
  28. jjrh has left
  29. moparisthebest has joined
  30. moparisthebest What if we replace xhtml-im with bbcode!!!
  31. jjrh has left
  32. moparisthebest has left
  33. moparisthebest has joined
  34. moparisthebest Think of all the php implementations at our disposal
  35. andrey.g has joined
  36. matlag has left
  37. jjrh has left
  38. jjrh has left
  39. jjrh has left
  40. emxp has joined
  41. Guus has left
  42. alacer has joined
  43. lskdjf has joined
  44. jjrh has left
  45. Valerian has joined
  46. mimi89999 has joined
  47. jjrh has left
  48. jjrh has left
  49. jjrh has left
  50. Guus has joined
  51. Guus has left
  52. jjrh has left
  53. alacer has joined
  54. Guus has joined
  55. jjrh has left
  56. jjrh has left
  57. lskdjf has joined
  58. alacer has left
  59. intosi has left
  60. Syndace has joined
  61. jjrh has left
  62. alacer has joined
  63. Ge0rG has left
  64. daniel has joined
  65. Guus has left
  66. Guus has joined
  67. jjrh has left
  68. jjrh has left
  69. SamWhited has left
  70. jjrh has left
  71. alacer has left
  72. alacer has joined
  73. vanitasvitae has joined
  74. la|r|ma has joined
  75. lskdjf has joined
  76. Guus has left
  77. Guus has joined
  78. lskdjf has left
  79. jjrh has left
  80. alacer has left
  81. lskdjf has joined
  82. Zash has left
  83. lskdjf has joined
  84. uc has joined
  85. efrit has left
  86. alacer has joined
  87. tux has left
  88. tux has joined
  89. daniel has left
  90. Valerian has left
  91. SamWhited has left
  92. mimi89999 has joined
  93. alacer has left
  94. uc has joined
  95. la|r|ma has left
  96. la|r|ma has joined
  97. Valerian has joined
  98. lskdjf has joined
  99. Zash has joined
  100. alacer has joined
  101. jere has left
  102. goffi has joined
  103. Valerian has left
  104. alacer has left
  105. alacer has joined
  106. Guus has left
  107. Flow has joined
  108. alacer has joined
  109. alacer has joined
  110. Flow has left
  111. Tobias has joined
  112. uc has joined
  113. emxp has joined
  114. dwd has left
  115. dwd has left
  116. la|r|ma has left
  117. la|r|ma has joined
  118. uc has joined
  119. dwd has left
  120. Flow has joined
  121. SamWhited has left
  122. ralphm has left
  123. uc has joined
  124. Flow has joined
  125. Flow has joined
  126. dwd has left
  127. alacer has joined
  128. sonny has joined
  129. jonasw moparisthebest, loool
  130. Zash I do wonder if we should revive the <font> tag as replacement for the style attr
  131. jonasw I don’t believe in font styling, but people seem to think differently
  132. alacer has joined
  133. jonasw it’s the number one reason I block inbound formatting
  134. Zash Way easier to sanitize <font color="name | #hexhex">
  135. jonasw if we start to go down the route to revive parts of deprecated HTML, we can go down Sams route of inventing our own markup all the way
  136. Zash jonasw: People want stickers!!
  137. jonasw people don’t know what’s good for them!
  138. Zash People want the silliest things!
  139. sonny has joined
  140. Zash Do we give it to them or do they go elsewhere?
  141. Zash Nice things, none shall have them!
  142. Flow has joined
  143. Zash Only shiny, silly things
  144. edhelas stickers are possible with XMPP
  145. jonasw SIMS + a repository of stickers yes
  146. Zash Sure they are, since literally forever
  147. edhelas non, with Bits Of Binary as well
  148. Zash Peoples reasons for XMPP suckage don't need match reality
  149. jonasw edhelas, do stickers fit into BOB?
  150. Zash Make them fit
  151. jonasw Zash, they sure match the reality of actual implementations :)
  152. edhelas well 20kb-30kb is enough for most of them
  153. jonasw 30kB * 4 / 3 = 40kiB stanza
  154. Zash That's well within the 10M stanza limit, even if base64'd
  155. edhelas also BOB use some hash, so they are transfered only once
  156. jonasw there’s a 10MiB stanza limit? :)
  157. Zash In Prosody, IIRC inspired by some recommendation for minimal limit somewhere
  158. edhelas Movim implement stickers using BOB :)
  159. edhelas https://github.com/movim/movim/tree/master/app/widgets/Stickers/stickers
  160. jonasw 7.5 MiB data limit -- that’s well sufficient for avatars
  161. edhelas jonasw at one moment people will ask for high-def-animated-with-sound stickers
  162. jonasw I recall that people said that PEP avatars are not feasible due to (among others) stanza size limit?
  163. Flow has left
  164. Zash Here we go. Why can't I have my browser plugin that lets me link directly to sections?
  165. Kev has joined
  166. Zash https://xmpp.org/rfcs/rfc6120.html#security-dos > A deployed server's maximum stanza size MUST NOT be smaller than 10000 bytes
  167. Zash Wait that's ~10k
  168. jonasw :D
  169. Steve Kille has joined
  170. zinid and there is no way to check what limit is applied on the server :)
  171. zinid we need a XEP
  172. Zash Path MTU discovery!
  173. Zash Now with eXtensibility! :D
  174. Zash MattJ: How did we end up with 10M then?
  175. dwd has left
  176. emxp has joined
  177. Zash I suppose you could survey peoples vCards and multiply the maximum size by some number out of a hat and call it a day.
  178. jonasw Zash, it’s not impossible that I complained a few years ago when my fiancees avatar wouldn’t upload and that made pidgin fail to connect or something. I remotely recall there to be such a problem.
  179. Zash jonasw: Not the thing where data goes into a buffer that the network stack isn't paying attention to?
  180. jonasw back in the days of google code
  181. jonasw not sure, I think it was some limit thing
  182. Zash Hm
  183. dwd has left
  184. dwd has left
  185. uc has joined
  186. goffi has left
  187. dwd has left
  188. dwd has left
  189. Flow has joined
  190. dwd has left
  191. vanitasvitae has joined
  192. dwd has left
  193. winfried has joined
  194. Zash Hey, how do browsers deal with namespaces?
  195. Zash Like, if I stupidly insert some random XML tree into my DOM, and there's like a <p xmlns="not xhtml" onclick="evil();"> in there, what happens?
  196. jonasw Zash, horribly
  197. jonasw they don’t care a lot
  198. jonasw and as always, it depends
  199. Zash So a thing that sanitizes the xhtml-im namespace but lets anything else thorugh would be useless?
  200. jonasw I can imagine that this kind of stuff works because it is hared between XML and SVG handling
  201. jonasw maybe
  202. jonasw I wouldn’t rely on it
  203. jonasw there are funny bugs in browsers with prefixes, too
  204. moparisthebest has joined
  205. uc has left
  206. dwd has left
  207. ralphm has joined
  208. winfried has joined
  209. tux has joined
  210. la|r|ma has joined
  211. stefandxm has left
  212. ralphm has left
  213. lskdjf has joined
  214. stefandxm has joined
  215. Ge0rG has left
  216. Ge0rG has left
  217. Steve Kille has left
  218. nyco has left
  219. jubalh has joined
  220. ralphm has left
  221. Steve Kille has joined
  222. tux has joined
  223. ThurahT has left
  224. ThurahT has joined
  225. jonasw Kev, +1 to your XHTML-IM mail
  226. jonasw you brought to the point what I tried to convey in a few paragraphs of prose elsewhere.
  227. Kev I don't have the attention span to write TL;DR mails :)
  228. Ge0rG Ha, I tried to make the same point yesterday.
  229. Ge0rG Let's see if different framings are going to convince the public
  230. jonasw itym the council.
  231. zinid guys, what is the agreement on pubsub in push?
  232. goffi has joined
  233. Kev I don't think the move towards something markdownish is actually stupid, FWIW, and I think it's much much easier to sanitise something that you can write your own parser/serialiser for, than XHTML-IM. So I don't think this is a bad direction. It is much easier for diligent devs to get it right. I'm just not sure I buy the argument that it's going to suddenly make anyone who wants to dump things into a DOM unsanitised safe.
  234. Ge0rG I like markdown, but it's impossible to write a parser for that.
  235. jonasw I agree with Ge0rG
  236. jonasw writing your own markdown parser is a mess, and will yield 1000 different implementations
  237. jonasw (this holds for all text-based markups, I’m afraid)
  238. Ge0rG It's even less possible to sanitize markdown.
  239. Kev Well, we can go with a binary markup if you want, and then base64 it to get it into the stream, but I don't think it helps :p
  240. Kev preempts Dave suggesting ASN.1 encoding of markup.
  241. Guus has joined
  242. Ge0rG Kev: it's already impossible to write correct markdown _text_, which is rendered in the same way everywhere. How are you going to write a parser?
  243. jonasw Kev, I sense buffer overflows there.
  244. Zash This is the appropriate reaction: https://pics.zash.se/4c840479.jpeg
  245. jonasw using an XML-based markup makes much more sense to me.
  246. Steve Kille has left
  247. Kev Ge0rG: That isn't the hard part. Tedious, but not hard, we just need to spec it. And by 'we', I mean that dwd has volunteered, so yay.
  248. zinid where to vote for asn.1? :)
  249. Ge0rG BER or DER?
  250. jonasw hasn’t BER failed?
  251. Zash Is server-side cleaning of xhtml-im sane, or would that just let broken clients be broken and then get hacked by evil servers?
  252. Zash XER
  253. Ge0rG Zash: yes.
  254. Kev Abstract Syntax Notation 71.
  255. jonasw from what I’ve heard, the general sentiment is that clients need to trust the server anyways to some extent...
  256. Zash Yes, trust the server, the server is good.
  257. jonasw but I guess it’d break e2ee
  258. Zash E2EE is just marketing fluff, did't we establish that?
  259. zinid jonasw: +1, I can't understand what's the point in building client-server architecture where there is no trust to server?
  260. jonasw Zash, I won’t get into that argument.
  261. zinid better off using p2p directly
  262. jonasw I’m torn on the e2ee thing. I don’t want certain stuff I discuss with people plaintext on my server in some MAM.
  263. jonasw zinid, p2p doesn’t scale
  264. Zash p2p doesn't scale *on mobile*
  265. zinid jonasw: I wouldn't say that, there are some research going on
  266. Ge0rG I really don't get why people hate ASN.1
  267. zinid Ge0rG: because it generates lots of boilerplate code for mainstream languages such as C++ or Java
  268. zinid for example, in Erlang it's great
  269. jonasw not rather because ~every ASN.1 parser is broken somehow?
  270. Steve Kille has left
  271. zinid jonasw: but we have PKIX working?
  272. Steve Kille has joined
  273. jonasw sure, take a look how secure the PKIX libraries are
  274. Ge0rG Every browser contains an ASN.1 decoder. We could leverage that and replace JSON, once and for all.
  275. Zash Ge0rG: Call it "binary JSON with schemas and namespaces"
  276. Zash Make a fancy website on whatever is the hip TLD today.
  277. Ge0rG Zash: yeah, marketing is crucial.
  278. Ge0rG .io?
  279. zinid jonasw: I think that's the problem of the language you're using
  280. jonasw zinid, excellent, let’s ignore issues because they only occur in a single language.
  281. jonasw then we can stay with XHTML-IM, because javascript/DOM is the actual issue.
  282. zinid jonasw: well, we ignore? and what do we have as a result?
  283. zinid ASN.1 was a standard and now there are tons of implementation with 0 interop
  284. edhelas the XHTML-IM problem can be extended to Pubsub as well, with the usage of Atom
  285. dwd Kev, I volunteered to document a "snippets" design, which - I think - covers most of the use cases outside of *bold* /italic/ _underline_ and `preformat`.
  286. Ge0rG maybe we need a subset of ASN.1 that is easy to understand and to implement. Let's call it ASN.0. Or maybe ASNdown.
  287. zinid Ge0rG: I would rather use protobuff, frankly
  288. zinid but it's not a standard
  289. dwd zinid, FWIW, I've not come across any of these incompatible ASN.1 implementations, and I've used many of them.
  290. Kev dwd: I had completely misunderstood, I thought you'd volunteered to write the thing that's like markdown spec, sorry.
  291. dwd zinid, After all, when I worked at Isode, M-Link had about 6 in the code.
  292. edhelas but I'd say, maybe we can just add modules on servers to checkup the content of messages when they detect the xhtml-im namespace
  293. edhelas it's basically applying a schema and check if it fits
  294. dwd Kev, I can probably do that too. But I have a pair of XEPs and a I-D in my pipeline, and adding another one is pushing things enough. (Oh, and I'm trying to shepherd Ash through updateing '314 *and* writing another).
  295. zinid dwd: well I'm not talking about incompatible implementations, I think jonasw said that :)
  296. dwd edhelas, Really? So I can strip tables then?
  297. jonasw zinid, nope, I did not mention incompatibilities.
  298. dwd zinid, Then I misunderstood: [09:47:59] ‎zinid‎: ASN.1 was a standard and now there are tons of implementation with 0 interop
  299. zinid dwd: I mean there are now: thrift, protobuff, several json serializers, etc
  300. Ge0rG but those are all not ASN.1?
  301. zinid yes, but they do the same
  302. zinid encode/decode lang structures into/from wire format
  303. Ge0rG It's funny how SQL injection is still a thing in 2017. And XSS.
  304. Guus has left
  305. Guus has joined
  306. Kev When I keep talking about markdownish, to be clear, I'm talking about something that is clearly and comprehensively specced, presumably by us. I am not suggesting it's ok to say "use markdown", and then just have everyone pick their own, subtly incompatible, library.
  307. uc has joined
  308. dwd has left
  309. Ge0rG Kev: I'm not sure that makes a difference. If it is sufficiently similar to markdown, people will just plug their own markdown library in and end up wth full HTML support.
  310. Alex has joined
  311. Kev Ge0rG: I'd really like the discussion to move away from "People will do what's easy, not what the spec says", and instead try to work out how to have a spec that a reasonable person is likely to implement without significant issue. XHTML-IM, as it stands right now, is not the latter thing.
  312. la|r|ma has joined
  313. jonasw Kev, I’d like your opinion on a (possibly audited) JS reference implementation of a sanitiser.
  314. Kev I think it's a different question to whether XHTML-IM is sane. I don't think "It's near impossible to get right, but we've already done it, so use our implementation (or port it)" is the right thing to do.
  315. Kev If we get to the stage that we *do* have a sane spec, then a reference implementation could be helpful, but at that point is also probably not as necessary.
  316. jonasw I think that XHTML-IM is easy to get right, once we drop @style.
  317. jonasw (you’re gonna have the problem of sanitizing URLs in any markup which supports URLs)
  318. Ge0rG Kev: I'm not sure that it's actually possible for a reasonable person to implement a secure web application.
  319. zinid I'm lost, what is required to be sanitized? URLs?
  320. Ge0rG Kev: and I think that XHTML-IM is mostly a strawman here.
  321. zinid xhtml-im doesn't define scripting, so there should no be XSS, no? (I'm not a web developer)
  322. Ge0rG zinid: the problem is that it's insanely hard to sanitize user-controlled strings in a web application. And even more so if those strings contain HTML markup.
  323. Ge0rG zinid: change your nickname to `<script src=.../>` and there is a good chance some client will actually load and execute that.
  324. zinid I know about web application, but this is mostly due to script execution
  325. winfried has joined
  326. zinid yes, your example is also about scripting :)
  327. Ge0rG zinid: yes, but there are so many ways to include scripts.
  328. Ge0rG and developers need to know and filter them all.
  329. zinid but xmpp client should not execute scripts?
  330. Ge0rG zinid: should not, no. but if the client is running in the browser, the browser well might do
  331. zinid ah
  332. jonasw zinid, the fact that XHTML-IM doesn’t define scripting does not prevent (a) maliciuos entities to include <script>...</script> and (b) stupid clients to embed the XHTML from the message unsanitised into the browsers DOM
  333. zinid jonasw: yes, got it
  334. zinid but don't we have the same problem with markdown? how is markdown processed? web clients can pretty much insert <script/> from markdown into DOM as well
  335. zinid and the same for raw messages (i.e. <body/>)
  336. Ge0rG zinid: that's a very valid point, made multiple times by now.
  337. zinid ah, ok
  338. zinid sorry, TL;DR :D
  339. Ge0rG yeah, that is a common problem :>
  340. dwd has left
  341. uc has joined
  342. pep. Ge0rG> Kev: I'm not sure that it's actually possible for a reasonable person to implement a secure web application. < +1
  343. tux has joined
  344. pep. "Markdown is not HTML so people will have to write their own parser" what? (*me just read the ml thread*)
  345. pep. Or rather, people can't drop that into innerHTML. Don't worry they'll find ways
  346. Ge0rG I mean: I'm a professional IT security specialist, and I don't know all the ways that you can inject code into a web app from user input.
  347. pep. I'm not even sure how to contribute to that thread. People hear "We need to deprecate XHTML-IM" and already it's "I know $NEW_FANCY_MARKUP that we can use". We're just going in circles.
  348. pep. Kev> Ge0rG: I'd really like the discussion to move away from "People will do what's easy, not what the spec says" < That's exactly what's happening at the moment with XHTML-IM.
  349. pep. And that's what sam is ranting about
  350. pep. If it their implementation were compliant there would be no such issue. (Or we could fix the XEP to answer these issues)
  351. Syndace Can you deprecate a XEP, modify it and then make it draft again?
  352. pep. If it their implementation was compliant there would be no such issue. (Or we could fix the XEP to answer these issues)
  353. pep. Under a different name/number? dunno. That would be silly anyway
  354. pep. Might as well reinstate the original XEP
  355. Syndace No under same name and number
  356. mathieui Syndace, https://xmpp.org/extensions/xep-0001.html#approval-std
  357. Syndace Okay thanks
  358. pep. Anybody can post to standards@ right?
  359. Steve Kille has left
  360. mimi89999 has joined
  361. jubalh has joined
  362. uc has joined
  363. jonasw pep., must be subscribed, but subscription is open
  364. pep. I get the emails, so I did that iirc
  365. jonasw your mail got through
  366. jonasw the list has some delay, in the order of a few minutes
  367. pep. Yeah I saw it/them come back :)
  368. pep. Yeah I saw it/them go through :)
  369. pep. Why do my first emails have to be hate mails :(
  370. jonasw it’s not hate, it’s constructive discussion (for now)
  371. Kev Uhm.
  372. pep. https://www.mail-archive.com/standards@xmpp.org/msg17919.html I like goffi's position here
  373. Kev Wasn't the first of those mails "We have to consider people who ignore the spec" and the second mail "Changing the spec will fix it"?
  374. Kev I think as long as your position involves the "stupid people" argument, there is no way to find a solution to injecting markup, but there is certainly no way for xhtml-im markup.
  375. pep. I'm not of the opinion that changing the spec would fix the issue. It might help a bit
  376. Kev Jonas said we should change the spec, you said you strongly agree...
  377. jonasw sure, because @style is hard to validate right. everything else can be done.
  378. pep. Well, that would help yes.
  379. jonasw (even @style can be done, but I don’t think we should be asking people to do that)
  380. pep. Kev, also look at my second sentence. "the issue is not here"
  381. Kev jonasw: Yes, and that's fine if you agree with my premise that we should be catering to people who want to do the right thing, not to people who ignore the spec and inject HTML directly. If you want to go along with my premise there, then changing the sanitisation rules can help. But if you're on the premise that people will ignore the spec, no amount of changing the spec will help with that.
  382. jonasw Kev, I still believe that a working reference implementation will help against people ignoring the spec.
  383. jonasw (and a reference implementation would benefit from getting rid of @style, which is my argument there)
  384. Syndace I don't even think in a open source environment you have to care about stupid people. If you stumple across an implementation that allows for XSS you open an issue and point them to the reference sanitizer and everything is fine.
  385. Syndace If someone writes new client code for fun that only he and his friends use then whatever
  386. jonasw I prefer to try to prevent security issues before they happen.
  387. Syndace Yeah sure
  388. Kev jonasw: I think you're agreeing with my argument, and disagreeing with pep's, that we should be making this easy for people who want to do the right thing.
  389. jonasw yes, we definitely agree on that.
  390. jonasw I don’t agree that inventing our own markup will help with that.
  391. pep. Kev, but the issue at hand is people not doing things right, am I wrong?
  392. jonasw it will just open another can of worms, be it security issues or interop issues.
  393. jonasw (or probably a mix of both)
  394. Alex server plugins could strip out java script and other malicious tags
  395. jonasw Alex, that has been proposed, and Zash even drafted an implementation of that for prosody.
  396. jonasw I don’t feel that clients should rely on that in any way.
  397. Kev Alex: I'm not convinced by that argument, really.
  398. jonasw (but it’d be an interesting tool to detect malicious parties)
  399. Alex I have done this before, the XHTML XEP lists the allowed tags, any other tag I ignored in the parser
  400. pep. Kev, if it's to make things more straightforward for people who follow the spec, I'm all in, and I agree with jonasw. But that's not how I read SamWhited's email.
  401. jonasw I also firmly believe that obsoleting XHTML-IM without a replacement which has deployment will achieve nothing, except closing a door for us on fixing things there. See Private XML support.
  402. Alex jonasw: agreed on that
  403. Alex we really need modern markup to compete with Slack and others these days
  404. jonasw I will implement XHTML-IM in my client over the next weeks, no matter the XEP status.
  405. jonasw simply to gain interoperability
  406. Alex othereise its a step backwards
  407. jonasw and I assume that others will do the same
  408. jonasw and if they don’t then we’ll end up with a bunch of incompatible tacked-on markups
  409. jonasw e.g. clients (not people!) putting markdown in <body/>
  410. jonasw (we already have that to some extent with clients interpreting *foo* and /bar/ and such)
  411. pep. I see *foo*, _bar_ etc. as historical, coming from IRC. Not sure where IRC got that first though
  412. jonasw pep., agreed
  413. jonasw even though there are clients which interpret ">", which I haven’t seen used much in IRC except in the last few years.
  414. pep. Right, they're all implementing their own markup, using <body>, which is meh
  415. jonasw much meh
  416. pep. I often rage against Conversations translating ">" at the beginning of a message. It breaks stuff like "><", and messages with a single ">" don't make sense anymore (got this case on prosody@ the other day)
  417. pep. I often rage against Conversations converting ">" at the beginning of a message. It breaks stuff like "><", and messages with a single ">" don't make sense anymore (got this case on prosody@ the other day)
  418. Holger >< works though.
  419. dwd has left
  420. zinid Alex: > we really need modern markup to compete with Slack and others these days Do we really want to compete? I just doubt that this is the goal of XSF
  421. pep. Ah it works now indeed. I haven'T checked in a while
  422. dwd zinid, I think we should be competitive with things like Slack, yes.
  423. Alex zinid: I see many people switching to Slack these days. There is no reason why you can do the same with XMPP. But we lack of modern client and features these days
  424. pep. Alex, I think we have most tools to start implementing. I would rather wait and see if UAs ask for more
  425. jonasw has left
  426. pep. Maybe push them to implement such things if you really want
  427. zinid dwd: only like Slack? really, what userbase do XSF target? because from what I see currently it's producing specs for nerds (like e2ee)
  428. dwd zinid, Well, not only like Slack. And I don't entirely disagree with your assertions there.
  429. dwd zinid, ALthough not all nerds focus on the threat model that OMEMO does.
  430. pep. zinid, I think most nerds have their own servers, and e2ee is possibly of less important there
  431. pep. But I don't disagree with your assertions either :)
  432. zinid I just think maybe it's better to define the target userbase?
  433. zinid I mean if this is nerds, then I'm fine and we should go in this direction
  434. zinid I don't think we can produce a protocol for every person on the planet
  435. dwd zinid, Scalability would be an issue, for sure.
  436. Zash has left
  437. Alex the strenght of XMPP was the we always covered a huge variety of use cases an users
  438. pep. zinid, protocol maybe, but for the end-users I don't think the protocol really matters anyway.
  439. zinid dwd: yes, but if we try to resolve scalability issues we will end up with SIP :)
  440. pep. Or rather, for *most end-users, non-tech that is
  441. zinid there is sip p2p rfc already
  442. dwd zinid, Oh, I do hope not.
  443. zinid dwd: well, if you strip shit from sip, it's usable and can be used as building block
  444. Zash zinid: the one that also works for xmpp?
  445. jubalh has joined
  446. zinid hehe, ok, I didn't want to go into SIP vs XMPP debate :)
  447. dwd zinid, That's not a debate, it's a bloodbath. ;-)
  448. dwd zinid, But anyway, I think we have a set of existing target communities, and I agree that defining these would be of benefit to us as protocol designers - however you implied there can only be one, which I think I take issue with.
  449. jere has joined
  450. Alex the target communities also changed over the last 10+ years. I like this discussion of defining it
  451. zinid dwd: well, their can be several, but I don't think "regular user" class intersects a lot with "nerds" class (intersection is a very basic functionality)
  452. zinid I mean, take a look: 1) a girl spending most of the time in instagram and so on 2) a nerd who lives with console
  453. zinid how can we target both?
  454. dwd zinid, I think the amount of intersection between the sets is actually something we'd need to find out. I suspect it's not nearly as small as you might think.
  455. zinid maybe, would be great to understand though at least for making the priorities
  456. Alex extensions, give teh nerd a console client without XHTML, and the girl a client where she can like messages, have hundreds of emoticons and share images and glyphys
  457. zinid Alex: sounds great in theory, but does it work in practice?
  458. Zash Jack of all trades
  459. Alex yes it does, I am doing XMPP stuff for close to 15 years now, and have customers which do all that with XMPP with great sucess
  460. Zash It does show that a bunch of us are more or less doing stuff for ourselves. Nothing wrong with that.
  461. Holger Zash: Nothing wrong with targetting ourselves if we clarify that. Then I can give up trying to sell XMPP to others and then having to explain why stuff breaks.
  462. Zash Optimally we'd get instagramming teens into software and standards development
  463. zinid nothing wrong of course, the problem I have is that we constantly speak about how to fight with Slack without even defining the target
  464. Zash And if the target is everything then it's a lot of work
  465. zinid yes, 300+ XEPs for sure :)
  466. zinid yet another 300 I mean :)
  467. Alex I think case studies and small tutorials on our webpages would help
  468. Zash Only? Gotta break that initial zero ;)
  469. Holger I think it's a vicious circle. XMPP's niche is mostly nerds, so there's few other users complaining about our stuff, so we concentrate on the nerd stuff because that's more fun to implement.
  470. Zash Holger: Typical in most FOSS circles
  471. Alex you wanna build something liek Slack, hey this iw what you need, extensions A+B+C+D you wanna build a military grade client, then this is what you need, extensions X+Y+Z
  472. Zash Alex: Sounds good
  473. zinid Holger: +1
  474. Holger Zash: Yes but elsewhere there target audience is more obvious.
  475. Holger s/there/the
  476. dwd Alex, In my experience, the Military and similar markets actually want something Slack-like anyway.
  477. Holger Zash: If you build a tiling window manager, you won't break stuff for non-geeks.
  478. Alex you wanna build something like whats app do that you wanna build machine 2 amchien communications do this you need build a system for realtime stick exchange do this you wanna build the next Uber (geoLoc) to that
  479. dwd Alex, I mean, they want labelling, sure, but don't think they don't care about emoji support.
  480. Holger And a large part of FOSS projects is building server/infrastructure stuff ...
  481. Ge0rG Alex: that sounds like a compliance suite.
  482. zinid Alex: ok, let me rephrase maybe: who will write the XEPs for Slack audience? Hell, does anyone even know what Slack audience want? :)
  483. Alex I suck at typing today, so need a client which supports XEP-0308 :-)
  484. dwd zinid, I've used Slack, and I can tell you that Slack themselves don't have a clue.
  485. Ge0rG there is a commercial market for corporate (or government) slack-like things self-hosted with data retention, archival, LDAP integration and other enterprisey requirements.
  486. zinid we can start doing this, but we will eventually end up working on JET and OMEMO :D
  487. zinid dwd: yes, maybe :)
  488. Ge0rG zinid: we don't need to target the nerd audience. They will come to us voluntarily.
  489. zinid Ge0rG: but we do this
  490. zinid JET and OMEMO for whom?
  491. zinid a girl from instagram never heard about e2e
  492. Alex Ge0rG: yes, we had a compliance suite before at the XSF for servers and client, but somehow died
  493. Ge0rG IMO, there are two target groups we should focus on, five years ago: - Slack-like on-premise / hosted services with a good web and mobile UX - slightly nerdy normal users (see Conversations' success)
  494. Ge0rG Alex: the current one is defining "mobile" and "IM" use cases. I'm pretty sure that "Slack" would make a good "Multimedia Chat" one or somesuch
  495. Ge0rG Alex: actually, there is not much specification missing to pull off a Slack-like thing, it's only a lack of dev power to make a proper web client and a one-button easy-deployment server.
  496. Ge0rG okay, web client _and_ mobile client
  497. Ge0rG Give me a dozen competent developers, a year and a time machine so I can start in 2012, and I can pull it off.
  498. dwd Ge0rG, Actually, Openfire has the latter, for sure. You can install webchat clients just by push-button after Openfire itself is installed.
  499. Ge0rG dwd: will Openfire come with AD/LDAP integration and all the Enterprisey checklist features?
  500. dwd Ge0rG, It has had AD integration for a decade or something.
  501. Ge0rG And will it scale to (tens) thousands of users?
  502. dwd Ge0rG, It doesn't scale as well as some servers. Chokes around 20k users or so, I think, until you do clustering.
  503. edhelas what about ejabberd ?
  504. dwd edhelas, I think that has LDAP integration, I don't know about Active Directory SSO (ie, GSSAPI).
  505. zinid edhelas: https://blog.process-one.net/ejabberd-massive-scalability-1node-2-million-concurrent-users/
  506. Ge0rG dwd: is it possible to buy an Openfire appliance / virtual machine with around-the-clock tech support?
  507. zinid :)
  508. Ge0rG dwd: but we are getting off-topic here.
  509. Ge0rG There is a German startup, selling enterprise mobile messaging <https://www.teamwire.eu/> - they provide cloud-hosted and on-premise solutions, and ask something like 3€/month/user for a WhatsApp-like experience. And they don't even have federation.
  510. Alex zinid: there is hosted.im if you need that
  511. Ge0rG But they have a sustainable business for something like five years now.
  512. dwd Ge0rG, Sure. We do have a dearth of clients running on Apple-favloured systems.
  513. Ge0rG The problem is: nobody will buy an XMPP-based IM solution if the UI isn't Slack-like
  514. zinid Alex: me? :) now, thanks, I have my own domain
  515. Ge0rG dwd: business clients running openfire on Apple? Or XMPP clients running on macOS?
  516. Ge0rG or iOS?
  517. edhelas Ge0rG what is "slack like" for you ?
  518. zinid damn, last time I checked slack I didn't understand what its buzz is about
  519. dwd Ge0rG, Yes.
  520. Ge0rG edhelas: easy to use private messages, channels, markup, some integration with websites / web services
  521. dwd zinid, It introduces millenials to IRC.
  522. Ge0rG edhelas: synchronization across all devices. proper push notifications
  523. valo has joined
  524. dwd zinid, That is, pretty much, it. It's IRC with emojis and working file sharing.
  525. Ge0rG I actually like Slack. It's easy to use.
  526. zinid dwd: then what is a problem to build slack-like using existing XEPs? am I missing something?
  527. Ge0rG zinid: lack of developers
  528. dwd zinid, No, we're not missing much to build something Slack-like, but federating and with security.
  529. edhelas I already have a couple of Movim users that deployed it in their business on top of a XMPP server
  530. edhelas you add some bots to integrate with github/jira and you're good no ?
  531. dwd I do think that our absolute neutrality does handicap us from showcasing good clients, which in turn reduces the appeal of the platform as a whole.
  532. zinid Ge0rG: that's true
  533. zinid dwd: so the problem is nobody wants to use XMPP for their apps, ok, we go in circles now :)
  534. dwd zinid, Well, sorta. I think people look at the first client or two they see and assume that the UX they encounter is due to restrictions in XMPP.
  535. Alex GitHubs Gitter is another example, also getting quite popular these days
  536. Ge0rG dwd [13:46]: > I do think that our absolute neutrality does handicap us from showcasing good clients, which in turn reduces the appeal of the platform as a whole. Very sad, and very true.
  537. edhelas I was thinking of creating a page that showcase those "good clients" actually
  538. edhelas if it's a project that is not officially pushed by the XSF, it could work no ?
  539. zinid what good clients? I still use Tkabber...
  540. zinid conversations maybe
  541. dwd zinid, Nerd. :-P
  542. edhelas zinid Dino looks very promissing
  543. zinid dwd: but what to use? swift lacks of features, dino is crashing, gajim is buggy (tracebacks are the friends)
  544. dwd zinid, I wonder if - and I know this sounds silly - the XSF should have an awards thing for Best XMPP Client for XYZ Platform, etc? Would that help highlight and motivate?
  545. zinid dwd: no, Durov puts 1M$/month in telegram for instance, I think other major IM players do the same
  546. zinid so if the price will be 1M$ then maybe :)
  547. zinid s/price/award
  548. jubalh has left
  549. jubalh has joined
  550. jubalh has left
  551. jubalh has joined
  552. Ge0rG You don't need that much for developing a client or two
  553. mimi89999 has joined
  554. zinid Ge0rG: yes, I understand the most of the money goes into adv, but still there is a lot of guys working on a client
  555. jonasw dwd, awards are not so cool
  556. jonasw the issue with awards is that only one wins
  557. jonasw or let me put it this way: it would require well thought out terms for people to participate
  558. jonasw also I’m afraid it might just re-enforce already well-funded (in which way ever) clients
  559. lumi has joined
  560. Ge0rG dwd: we really need to revive the Jabber Software Foundation
  561. Alex putting good software projects under an umbrella like Apache does could help
  562. Alex Ge0rG: same idea :-)
  563. pep. edhelas, arguably there is no good clients, it's all shapes of bad :)
  564. Alex Pandion was this client for windows in the early days of Jabber/XMPP
  565. Zash has left
  566. dwd has left
  567. zinid Ge0rG: what will JSF do?
  568. pep. marketing? promotion of clients? and the XSF do standards? (wild guess)
  569. zinid marketing = $$$
  570. dwd has left
  571. Alex $$$ could be raised easily, when there is good software
  572. Zash Alex: wrong, when there is good marketing
  573. zinid Alex: no
  574. Alex Zash: both
  575. Kev OK. I have a strong position on XSF Neutrality, because I don't see a way to do things fairly. So perhaps it'd help to persuade people like me that the XSF can do this stuff if someone came up with a concrete proposal of how the XSF could do recommended clients/servers etc., and do it fairly.
  576. zinid Alex: tons of Conversations user don't even pay for it
  577. jubalh has left
  578. Alex zinid: its not easy, but doable
  579. jubalh has joined
  580. valo has joined
  581. dwd has left
  582. dwd has left
  583. dwd has left
  584. edhelas has left
  585. nyco has left
  586. edhelas has joined
  587. matlag has left
  588. jonasw has left
  589. winfried has joined
  590. dwd has left
  591. emxp has left
  592. jubalh has left
  593. dwd has left
  594. stefandxm has left
  595. stefandxm has joined
  596. jere has left
  597. jere has joined
  598. Guus has left
  599. intosi has joined
  600. jere has left
  601. jere has joined
  602. Guus has joined
  603. alacer has joined
  604. winfried has joined
  605. Alex has left
  606. SamWhited Catching up… fwiw, I don't have a "position" that we should do markdown that likes like plain text in <body>. I have a position that we should deprecate XHTML-IM and then we should take the time top write a good replacement considering the pros and cons of both approaches. Tentatively I suspect that doing it in the body makes sense, but I'm not pushing for that.
  607. alacer has left
  608. SamWhited Similarly, this started because I've tried an XHTML-IM impl that was broken … again. So it's hardly a strawman for "other xss'". If I thought other xss' were caused by a poor spec, I would probably try to obsolete that too.
  609. alacer has joined
  610. SamWhited Alex: we have a council vote to advance them next week! https://xmpp.org/extensions/xep-0387.html
  611. SamWhited Or already did and it's waiting on list votes, I forget.
  612. jonasw SamWhited, good luck trying to obsolete .innerHTML and others :)
  613. Kev I think Council just approved an LC on 387, and so vote to advance should be the week after, shouldn't it?
  614. SamWhited jonasw: exactly, that's why I'm focusing on xhtml-im instead :)
  615. jonasw I think the LC needs to be announced properly on the ML first
  616. jonasw some editor should do that *cough*
  617. SamWhited Ah yah, that sounds tight
  618. SamWhited Right, even
  619. jonasw I can see if I can get around to do that this weekend
  620. Kev Oh, right. The two weeks don't start until that's announced.
  621. Zash SamWhited: How is "The Web" handling that? Because it's not just XMPP clients having that problem, right?
  622. emxp has joined
  623. SamWhited Zash: by not sending raw html around and trusting that developers can implement a white list properly or will do so at all.
  624. jonasw Zash, have you looked at the web? it’s injections everywhere.
  625. Zash I looked at the web recently. It said "It is inherently impossible to make a secure web thing."
  626. dwd has left
  627. SamWhited I assumed we were talking about transmitting formatting over instant messages, but yes, generally it's injections everywhere. I just still fail to see what other problems that aren't xhtml-im have to do with xhtml-im.
  628. dwd has left
  629. Zash I'm thinking, what are other standards orgs or such doing about equivalent injection issues?
  630. Zash I'm assuming here that there's some overlap between xhtml-im and web apps
  631. SamWhited Ah, yah… good idea, someone else must do this.
  632. Zash More like "has someone done something already that we can steal?"
  633. pep. SamWhited, for me deprecating xhtml-im is just delaying the same kind of issues with another more or less similar XEP. You're complaining about a range of UAs that are either 1. not following the XEP, 2. Not doing their job correctly. I don't think you can't fix 1., and if you see 2. please report it. If you do and and still get no reply, then I don't think we can't do anything either.
  634. pep. Replacing XHTML-IM won't fix this
  635. Zash The XMPP thing to do is to turn it into XML on the wire. But people will fail at that, whatever we do.
  636. SamWhited pep.: it won't fix that, you're right. I am not arguing that a new thing will make developers never have any security issues ever again.
  637. pep. Right
  638. SamWhited I am arguing that I have never seen an xhtmlim impl that worked the first time and that it is especially easy to get wrong. We *can* make something where the default naive implementation does not commonly lead to badness.
  639. SamWhited This is the best you can do in any security issue.
  640. dwd has left
  641. mathieui SamWhited, would bringing up the poezio xhtmlim impl be trollong?
  642. mathieui SamWhited, would bringing up the poezio xhtmlim impl be trolling?
  643. pep. goffi also has an implementation iirc
  644. jonasw doesn’t movim have XHTML-IM support?
  645. pep. no
  646. SamWhited mathieui: sorry, I didn't include it here because phone, but yes, on the emails I think I specifically said "web based"
  647. SamWhited :)
  648. jonasw I thought they talked about that (at least partial support, I think they strip @style, but maybe I’m confusing things)
  649. mathieui that makes sense, np
  650. pep. SamWhited, libervia is a web client.
  651. mathieui and everything that brings in a webview in a client application too
  652. pep. jonasw, no, edhelas doesn't want xhtml-im for some reason
  653. SamWhited Right, "things that actually have a javascript engine"
  654. SamWhited Getting of the bus… may be slow to respond.
  655. pep. SamWhited, also please don't merge markup in <body> :(
  656. SamWhited Off… I hate phones.
  657. jonasw who doesn’t
  658. Flow has joined
  659. winfried has joined
  660. lovetox has joined
  661. SamWhited I give up. Why does everyone think I want to push an alternative format? I will probably volunteer to write one if xhtml-im gets deprecated, but I am not pushing for markdown or whatever in body. I haven't done any research yet.
  662. jonasw I personally do not think that, but we are going to need an alternative, and the alternatives all look bad.
  663. Flow has joined
  664. Ge0rG We won't improve our situation by deprecating XHTML-IM without an alternative, and I still don't believe we will be able to come up with an idiot-proof alternative.
  665. Kev And if we're not striving for idiot-proof, we should assess whether XHTML-IM can be suitably improved.
  666. Zash If you do, the universe will spawn a better idiot.
  667. Zash Having an official safe JS reference implementation does sound somewhat promising tho.
  668. Zash And and a bigger better security considerations section
  669. Kev And blacklisting style.
  670. Flow has joined
  671. Zash What about the teends that crave colorful messages?
  672. Alex has joined
  673. Zash Bunch of predefined classes?
  674. Kev If we allow style, I'm not at all sure how even a reasonably diligent implementor avoids issues.
  675. Zash Instead of <span style="color:red">, there would be <span class="fg-red">
  676. jonasw classes seem like not a good idea either
  677. jonasw hm
  678. jonasw it needs sanitization at least
  679. jonasw to avoid that some attacker abusse your clients classes
  680. Zash Do they?
  681. Zash Hrm
  682. jonasw but they’re much easier to sanitise than @style
  683. jonasw (split by " ", make a set, check that only things starting with xhtml-im- are in there or so)
  684. jonasw alternatively (but Sam will shoot me for that), xhtml-im:color="..."
  685. Zash howaboutno
  686. jonasw why not?
  687. jonasw (hm, still needs sanitisation to prevent injection attacks)
  688. jonasw so using @class and defining a set of classes seems most safe for now
  689. mathieui shoots jonasw
  690. Ge0rG we should only allow one value for color, which is an integer between `0` and `359` on the XEP-0392 color wheel.
  691. stefandxm has left
  692. SamWhited Amusingly, I just sent a short reply to one of Kev's messages that included the example: *&lt;script&gt;alert(123)&lt;script;&gt;* and FastMail rendered that as bold.
  693. Zash Why not hold a public poll where people can suggest names for them
  694. Zash SamWhited: /nick <script>alert("everyhing is broken");</script>
  695. Zash Especially my typing
  696. Ge0rG what happens if you add unquoted HTML to the <body> text?
  697. lumi has left
  698. Zash What happens when you encrypt unquoted HTML in OTR?
  699. jonasw Ge0rG, you mean, like, <body><b>foo</b></body>?
  700. Zash Interesting how <b> isn't in xhtml-im
  701. lumi has joined
  702. jonasw s/b/strong/
  703. pep. Zash, jonasw, reference implementation, and tests also maybe
  704. pep. Although I'd like to have more than just JS, because it's not just a web issue and it's not just an xhtml-im issue
  705. pep. Basically we need a reference client? :)
  706. mathieui 16:20:06 Zash> What happens when you encrypt unquoted HTML in OTR? → let’s not talk about OTR
  707. Zash jonasw: IIRC <b> was added back into html because nobody cares about semantics
  708. efrit has joined
  709. Zash And nobody is going to fix all the web that uses it
  710. Ge0rG jonasw: yeah
  711. alacer has joined
  712. alacer has joined
  713. jonasw Ge0rG: depends; web clients might joyfully let themselves being XSSed
  714. jonasw has left
  715. mathieui but they do even without xhtml-im
  716. jere has left
  717. jere has joined
  718. SamWhited > but they do even without xhtml-im I still can't figure out what the argument is there. Other XSS's aren't related to XHTML-IM… what point are people trying to make when they say that "there are other XSS's too"? If it's obvious to everyone else I apologize, but I'm honestly asking. There is some implied ending to that statement that I don't understand.
  719. Syndace has left
  720. pep. That XHTML-IM is not the issue, there's a deeper issue
  721. SamWhited Yes, XSS is a deeper issue, but you can't fix XSS on the web. You can not recommend a spec that actively encourages them though.
  722. SamWhited Is that what people are suggesting though? XSS is the underlying issue so there's no point in trying to prevent a subset of them?
  723. alacer has joined
  724. alacer has joined
  725. pep. You can try and improve XEPs all you want, that won't prevent clients from having bugs. I agree XHTML-IM could be improved to try and make people aware of it, but in the end it's mostly reporting bugs to clients
  726. SamWhited You won't prevent it, but you can certainly make it less likely that those bugs are catastrophic security issues.
  727. jonasw has left
  728. pep. Do you have specific examples of these issues btw? And I suppose you also reported them
  729. jonasw has left
  730. SamWhited Yes, I reported them. I won't go into the most recent one because it's not fixed yet as far as I know, but literally *every* XHTML-IM impl I've tried that was tied to an environment where JavaScript could be executed was either vulnerable at first, or had been vulnerable in the past (there was a CVE or issue about it or something)
  731. SamWhited HipChat for instance tried to do things right, but had a handful of bugs in their whitelisting (and I'm sure you could easily find more).
  732. SamWhited With XHTML-IM almost *any* simple bug leads to a security issue. We can absolutely write a spec where not every single simple logic issue allows a script to be executed.
  733. Guus has left
  734. sonny has joined
  735. sonny has left
  736. sonny has joined
  737. sonny has left
  738. sonny has joined
  739. sonny has left
  740. sonny has joined
  741. tux has joined
  742. stefandxm has joined
  743. dwd SamWhited, Quite. The problem with XHTML-IM is that the obvious implementation is the most dangerous one, and insatead you more or less have to add an HTML protocol break in to make it safe.
  744. dwd SamWhited, In fact, edhelas suggested doing so in the server (and I thought of doing so in Metre), but the problem there is that XHTML-IM is often silently extended anyway.
  745. SamWhited dwd: Indeed. HipChat in theory does things right on the client (whitelist of elements and attributes, don't stick things straight into the DOM), *and* it has server side filtering. Despite that I've found at least two injections in that implementation (both of which are fixed now).
  746. jonasw what’s an "HTML protocol break"?
  747. sonny has joined
  748. alacer has joined
  749. tux has left
  750. jubalh has joined
  751. Kev has left
  752. Zash jonasw: <bold> mebbe
  753. Zash Or markdown
  754. Valerian has joined
  755. dwd jonasw, A protocol break is a security programming technique where you extract out the information into a different, fixed, form and then reconstitute it entirely from scratch. Means that, in our case, a bit of Javascript has no place in the intermediate form so cannot pass through.
  756. Zash dwd: And is that even possible while still being XML?
  757. dwd Zash, No, you wouldn't do it with XML, you'd do it with something else. Real protocol breaks would break up all the XMPP traffic into an intermediate form (JSON, maybe) and ship it across a wire to the other side, which then puts it back together. Obviously that's a little overkill for XHTML-IM.
  758. jonasw You’re saying we can’t use XML for markup, at all.
  759. alacer has joined
  760. Zash jonasw: Yes. But we should, but we can't. Nice things and unavailability
  761. jonasw That’s depressing.
  762. waqas has joined
  763. pep. Who ever thought web clients would be a good thing :x
  764. efrit has left
  765. SamWhited What is the advantage to doing an XML based markup? I'm not convinced that we can't do it, but I do think a non-XML based thing (which I'm assuming means "in the <body>") has a few nice advantages (single source of truth, better fallback behavior, etc.)
  766. dwd jonasw, No, I'm not. Just that you can't copy it direct to output without very havey mangling.
  767. dwd jonasw, And the level of safety we're talking about in the mangling negates the advantage of it being XML in the first place, IMO.
  768. jere has joined
  769. alacer has joined
  770. intosi has joined
  771. Zash dwd: people will find a way to lazily search and replace that lets trough evil stuff
  772. dwd jonasw, I mean, two XMPP servers talking across a heavily secured boundary have all their traffic mangled out, and then back into, XML. It's not the XML itself that's the problem, it's that you cannot do a direct copy and guarantee safety.
  773. jonasw SamWhited, whatever we do, not in <body/>.
  774. waqas I agree with everything SamWhited said. Not a single client that I reviewed has gotten xhtml-im secure.
  775. SamWhited jonasw: what is the advantage of not doing it in the <body/>
  776. jonasw dwd, so, I like your HTML protocol break argument. Indeed, based on that argumentation, I think a something-not-XML-based-but-still-structural representation of the semantics of XHTML-IM would make sense.
  777. Zash <body type='html'>&lt;script....
  778. SamWhited thanks waqas; you're running for council next term right?
  779. jonasw SamWhited, doing it in the body ties us to poor plaintext-ish markups like Markdown, Creole or reStructuredText. Those are not extensible, the implementations often vary or are poor in other ways and such.
  780. waqas As part of my research I'd written a library that implements XHTML-IM protcol break: https://github.com/zeen/xhtml-im.js — it makes an XML DOM to an HTML DOM with a strict whitelist of elements, attributes and possible attribute values.
  781. Zash The xep talks about rtf. Do that
  782. stefandxm has left
  783. jonasw waqas: :-O
  784. waqas I need to npm-ify it, to make it easier to use and add docs.
  785. jonasw waqas, that sounds like the reference implementation I wanted to see in XEP-0071 which everybody can use.
  786. SamWhited Ooh nifty, that's nice to have, thanks
  787. Zash So, let's pay for an audit?
  788. SamWhited actually I forgot, I think you sent this to me and challenged me to break it a while back and I never did.
  789. SamWhited never tried, I mean.
  790. jonasw waqas, except that I think it also gets the "replace invalid tags with their children thing" wrong
  791. jonasw (i.e. doesn’t implement it)
  792. Zash jonasw: let's kill that plz
  793. waqas It discards anything invalid first and foremost
  794. waqas i.e., it avoids all positives, but may have false-positives for certain attribute values
  795. waqas And the unknown element case
  796. jonasw Zash, I think it’s a nice-to-have for extensibility.
  797. jonasw (but I see how it’s hard to implement in anything which isn’t XSLT)
  798. dwd has left
  799. Zash jonasw: you can extend the <message>, it's probably safer
  800. jonasw Zash, how’d you extend <message/> with HTML-<video/> elements?
  801. SamWhited jonasw: why is a plain text protocol not extensible? If I want to add /italics/ later, what is stopping me?
  802. SamWhited for that matter, why are "plaintext-ish markups" poor?
  803. dwd SamWhited, It still amuses me that the word italics in your message is rendered in italics for me.
  804. jonasw SamWhited, that clients which don’t know that /italics/ is italics won’t escape it
  805. SamWhited See, there we go, it works already!
  806. Zash Let's talk about /etc/foobar/
  807. SamWhited jonasw: Right, and we have a lovely fallback behavior, they still see the exact same message it just looks like someone added /emphasis/ in a different way
  808. waqas Extensibility is a secondary concern, that we should be thoughtful about. Security is the primary concern. I'm not sure the 'include the children' approach is always correct in HTML.
  809. pep. Zash, :D
  810. jonasw so my /path/to/some/file will render italics on your new client supporting italics even though it shouldn’t
  811. dwd Zash, Not italics.
  812. SamWhited Zash: Yah, I don't know about the specifics of using /, just an example.
  813. jonasw SamWhited, it’ll work for anything
  814. Syndace has left
  815. pep. +1
  816. SamWhited *sigh* so pick a different character, it was an example.
  817. dwd So /this is italics/ but yet /etc/passwd is not.
  818. dwd has left
  819. jonasw SamWhited, I challenge you, which one which doesn’t look super odd when seen without support?
  820. dwd I mean, right now, in Gajim, this is the actual case.
  821. waqas dwd: Machine learning!
  822. jonasw dwd, what if I want to have only a part of a word in italics?
  823. SamWhited jonasw: That doesn't look odd to me, _emphasis_, /emphasis/, and *emphasis* all look relatively nice.
  824. dwd has left
  825. SamWhited we're diving into specifics that don't matter though. The question is "why isn't it extensible" which you argued was a problem. Implementation details are not relavant at this point.
  826. dwd SamWhited, And they all worked in Gajim. They show the markup, mind, as well as the effect. But they work.
  827. Flow has joined
  828. jonasw SamWhited, but that’s exactly why it isn’t extensible.
  829. SamWhited dwd: Oh that's interesting, I've noticed a few web things (not IM) that keep showing the markup and the effect recently and liked it, I wanted to try it in an IM client. Didn't realize gajim already did it.
  830. jonasw You are re-defining things which previously were normal characters as meta-characters when extending it.
  831. jonasw That simply breaks, always.
  832. jonasw anyways, I gotta go for now.
  833. jonasw has left
  834. SamWhited jonasw: ahh, I see. That's fair.
  835. SamWhited I still think it doesn't matter as far as deprecating XHTML-IM, mind. The security concern comes first like waqas said.
  836. SamWhited But it's a fair argument if we're discussing alternatives.
  837. Steve Kille has left
  838. SamWhited A fair argument that I would love to consider in parallel to deprecating XHTML-IM ;)
  839. pep. So you're going to deprecate XHTML-IM, to then try and find a replacement, that is possibly just XHTML-IM 2.0.
  840. Zash XHTML-IM 2.0, now 200% more security considerations
  841. pep. :)
  842. SamWhited pep. yes. I certainly hope we don't come up with something that's just as bad, but we *know* XHTML-IM causes problems, it has been for years, so let's stop recommending new implementations of it. Keep in mind that people will still implement it for compatibility, and all existing implementations won't go away. It just means we don't advertise it as the way to do things.
  843. jonasw SamWhited, thanks for seeing my point, that has driven me crazy ;-)
  844. pep. So that doesn't find things at all, deprecating it. Fixing the XEP might be a better option?
  845. Guus has left
  846. pep. So that doesn't fix things at all, deprecating it. Fixing the XEP might be a better option?
  847. SamWhited pep. we can't fix it without a rewrite, the basic idea is fundamentally broken.
  848. pep. If there is anything to fix
  849. jonasw SamWhited, given the arguments from dwd about protocol breaks and such, I agree that we should do other things. at this point, I’m in favour of something like some simple JSON-based markup or so.
  850. SamWhited At least, I don't think we can, if you have a proposal I'd love to be proven wrong.
  851. jonasw but I’m out of the discussion for now, I’ll write a list to standards@
  852. SamWhited jonasw: thanks, I look forward to reading it.
  853. Flow has joined
  854. pep. SamWhited, no I don't see how what you want to fix can be fixed, and I don't know if we have to worry about this to then come up with something as bad
  855. SamWhited I don't think we'll come up with something as bad. I'm reasonably sure most of us understand the problem.
  856. dwd Zash, Incidentally, `/etc/passwd` works in most IM-based Markdown variants as an escape pattern that also switches to monospaced "code" layout. But not in Gajim.
  857. pep. dwd, that doesn't change jonasw's point
  858. pep. And I agree with him
  859. pep. If you want to do something else please don't use <body>
  860. Zash dwd: Markdown is a html superset. You are doomed.
  861. dwd pep., Oh, I'm somewhat open either way, there.
  862. SamWhited I wonder if there's a middle ground, body and a hint about the type of markdown being supported. <body>this is *bold*!</body><formatting version="0.2"/>
  863. alacer has joined
  864. dwd Zash, I'm not proposing using *full* markdown. That would indeed be insane - nobody needs headers and things in IM messages.
  865. pep. SamWhited, so you'd include all different versions?
  866. SamWhited pep. you'd just give a hint about what the version of the spec was, then the client could implement all or nothing depending on if it understands the version attribute. I'm not sure this is a good idea mind, just spit balling.
  867. mimi89999 has left
  868. Zash dwd: markdown libs are going to pass through html by default
  869. Zash Same problem
  870. Zash SamWhited: I have this vague feeling that I've seen that proposal before
  871. SamWhited Like dwd, I'm rather open to either thing though. I do have a vague sense that doing it in body fixes a lot of little problems, but it has the downside that jonasw pointed out. I'm not sure which is the best tradeoff.
  872. dwd Zash, Well, I'm not actually sure most of them do, anymore. And in any case, there are loads of cut-down ones. But I'm merely hinting at a direction rather than wanting to compare it with XHTML-IM. It is, as SamWhited says, more a matter of agreeing we need to deprecate XHTML-IM and wondering what the functionality might be replaced with.
  873. pep. SamWhited, right. I don't think this fixes the issue. If the client doesn't handle *foo*, it'll leave the markup here, which is meh, and for each new version you'll just be defining more and more new meta-characters that weren't before. I'm not sure that addresses our issue
  874. pep. (As you just said ^)
  875. Valerian has left
  876. SamWhited I'm pretty okay with leaving the markup there; it may not be ideal, but it's a better fallback behavior than XHTML-IM right now (where the message just doesn't show up if you don't also include a plaintext body, eg. most HipChat extensions)
  877. pep. Well then HipChat is not compliant?
  878. pep. They should follow the XEP
  879. dwd pep., Do you seriously think that anyone using any Internet-based communications medium for the past two decades would be surprised to see *bold* things expressed as such?
  880. pep. dwd, not us no, but I'm pretty sure you don't want to target only us nerds with this
  881. SamWhited I'm pretty sure that everybody would understand *emphasis*.
  882. dwd pep., No, not just us. Any Twitter user, for example. Probably any Facebook user too.
  883. pep. Also, you will never be able to have any breaking change
  884. Zash Should it be about styling or semantics ? ?
  885. pep. I'd prefer it to be semantics
  886. pep. But I suppose Slack or Facebook users don't care
  887. mimi89999 has left
  888. SamWhited That's an interesting distinction. I think a replacement should just deal with text styling. If you want an image you have sims or something, and the client can decide if and how it wants to display that (maybe with an information XEP about displaying media in clients for guidance).
  889. SamWhited and the XML-based SIMS or OOB or whatever gives the client the semantic meaning of whatever the non-text resource is.
  890. Ge0rG has left
  891. Ge0rG has left
  892. Zash has left
  893. Valerian has joined
  894. alacer has joined
  895. mimi89999 has left
  896. uc has left
  897. uc has left
  898. mimi89999 has left
  899. mimi89999 has joined
  900. uc has joined
  901. intosi has joined
  902. ralphm has left
  903. mimi89999 has left
  904. uc has left
  905. mimi89999 has left
  906. mimi89999 has joined
  907. uc has joined
  908. Zash Someone mentioned push and publish-options being invalid?
  909. Zash https://xmpp.org/extensions/xep-0223.html#example-1 has the same issue?
  910. zinid Zash: yes, #persist_items is not registered within XEP-0060
  911. zinid only #access_model is registered
  912. Kev has left
  913. stefandxm has joined
  914. Zash https://xmpp.org/extensions/xep-0222.html#example-5
  915. sonny has joined
  916. zinid ah, right :)
  917. zinid even more
  918. Zash Maybe one should do a `grep publish-options xeps/xep-????.xml`
  919. zinid sure, PRs are welcome, I'm told
  920. zinid but it seems like we just copy attributes from #node_config to #publish-options
  921. zinid what's the point? why not using #node_config data form directly?
  922. Zash It seems like at the time, people thought that was what it was
  923. Zash Like how you can create+configure a node in a single step, but this would be publish+configure (and maybe autocreate)
  924. Zash Seems like it'd be weird if you have many clients disagreeing on the options
  925. dwd has left
  926. valo has joined
  927. Flow has left
  928. stefandxm has left
  929. dwd has left
  930. emxp has joined
  931. Zash Oh look at what fun issue I'm having. My xep-0071.epub had unescaped HTML like <body/> passed through, breaking things.
  932. zinid irony :D
  933. Ge0rG has left
  934. Ge0rG has left
  935. mathieui Zash, nice
  936. Zash > The root element for including XHTML content within XMPP stanzas is > > .
  937. Zash Good job pandoc
  938. Zash > The raw HTML is passed through unchanged in HTML, [bunch of formats], EPUB, Markdown, [even more]
  939. Zash Maybe I should just generate JSON. That'll solve all problems.
  940. Zash {"blocks":[{"t":"Plain","c":[{"t":"Str","c":"The"},{"t":"Space"},{"t":"Str","c":"root"},{"t":"Space"},{"t":"Str","c":"element"},{"t":"Space"},{"t":"Str","c":"for"},{"t":"Space"},{"t":"Str","c":"including"},{"t":"Space"},{"t":"Str","c":"XHTML"},{"t":"Space"},{"t":"Str","c":"content"},{"t":"Space"},{"t":"Str","c":"within"},{"t":"Space"},{"t":"Str","c":"XMPP"},{"t":"Space"},{"t":"Str","c":"stanzas"},{"t":"Space"},{"t":"Str","c":"is"}]},{"t":"RawBlock","c":["html","<html/>"]},{"t":"Para","c":[{"t":"Str","c":"."}]}],"pandoc-api-version":[1,17,0,4],"meta":{}}
  941. Flow has joined
  942. winfried has joined
  943. Ge0rG has joined
  944. mimi89999 has left
  945. Steve Kille has joined
  946. dwd Zash, Just looks like smiley faces to me.
  947. Zash dwd: Please don't use JSON as a markup language. Altho maybe that's the reason it's the only choice.
  948. Steve Kille has left
  949. Steve Kille has joined
  950. dwd Zash, I wasn't going to suggest JSON at all.
  951. dwd has left
  952. uc has joined
  953. Guus has left
  954. Flow has left
  955. dwd has left
  956. Guus has left
  957. dwd has left
  958. efrit has joined
  959. Steve Kille has left
  960. dwd has left
  961. Steve Kille has joined
  962. Alex has left
  963. Alex has joined
  964. Alex has left
  965. ralphm has left
  966. Alex has joined
  967. Alex has left
  968. stefandxm has joined
  969. Alex has joined
  970. Alex has left
  971. Zash Forget about XHTML-IM and markdown, let's do this https://www.oasis-open.org/committees/download.php/60/HM.Primary-Base-Spec-1.0.html
  972. jubalh has joined
  973. Steve Kille has left
  974. edhelas has left
  975. edhelas has joined
  976. SamWhited Embedded SVG, but the version of the spec that didn't end up making it through where it had functionality to open sockets.
  977. SamWhited Done.
  978. Valerian has left
  979. Valerian has joined
  980. alacer has joined
  981. efrit has left
  982. stefandxm has left
  983. Valerian has left
  984. Valerian has joined
  985. stefandxm has joined
  986. jubalh has joined
  987. Tobias has joined
  988. dwd has left
  989. Steve Kille has joined
  990. dwd has left
  991. jubalh has left
  992. emxp has joined
  993. Flow has joined
  994. valo has joined
  995. jubalh has joined
  996. valo has joined
  997. Flow has left
  998. Steve Kille has left
  999. dwd has left
  1000. dwd has left
  1001. dwd has left
  1002. emxp has joined
  1003. SamWhited has left
  1004. dwd has left
  1005. alacer has left
  1006. alacer has joined
  1007. ralphm has joined
  1008. emxp has joined
  1009. Syndace has left
  1010. alacer has left
  1011. alacer has joined
  1012. Valerian has left
  1013. valo has joined
  1014. alacer has left
  1015. Steve Kille has joined
  1016. jubalh has joined
  1017. goffi has left
  1018. alacer has joined
  1019. Steve Kille has left
  1020. uc has joined
  1021. ralphm has left
  1022. zinid has left
  1023. Syndace I really don't get why all examples of XEP-0030: Service Discovery error responses contain the query element mirrored from the request. To me it is as confusing as it looks useless. If a client does not support disco at all it won't know that it has to mirror the query element anyway, so why is it mirrored in all examples and do I really have to mirror it in my implementation? I did not find a MUST or REQUIRED about this in the specification. Do people mirror it? Do people rely on it to exist in error stanzas?
  1024. Zash Syndace: I believe that's technically allowed by the specifications, but rarely used.
  1025. zinid It's useful for debugging sometimes
  1026. Syndace Zash: So, I can ignore it as being historical? Is there any reason it might be helpfull that I'm missing?
  1027. Syndace zinid, okay I can see that, it's easier than matching ids of outgoing and incoming iqs.
  1028. zinid I mean when you dump xml on server: you see what exactly your server is replying to with error
  1029. zinid Syndace: but there is no requirement in the RFC
  1030. Syndace Okay got it, thanks :)
  1031. Valerian has joined
  1032. jubalh has joined
  1033. alacer has joined
  1034. jubalh has joined
  1035. Flow has joined
  1036. dwd has left
  1037. edhelas has left
  1038. alacer has joined
  1039. Alex has joined
  1040. dwd has left
  1041. edhelas has left
  1042. edhelas has joined
  1043. edhelas has left
  1044. edhelas has joined
  1045. edhelas has left
  1046. edhelas has joined
  1047. Kev has left
  1048. edhelas has left
  1049. edhelas has joined
  1050. edhelas has left
  1051. edhelas has joined
  1052. edhelas has left
  1053. edhelas has joined
  1054. Ge0rG has left
  1055. alacer has joined
  1056. alacer has joined
  1057. Syndace has left
  1058. Flow has joined
  1059. Ge0rG has left
  1060. alacer has left
  1061. daniel has joined
  1062. Ge0rG has left
  1063. alacer has joined
  1064. lovetox has left
  1065. waqas has left
  1066. daniel has left
  1067. emxp has left
  1068. emxp has joined
  1069. Ge0rG has left
  1070. jubalh has left
  1071. winfried has joined
  1072. Ge0rG has left
  1073. emxp has left
  1074. emxp has joined
  1075. efrit has joined
  1076. Syndace has left
  1077. daniel has joined
  1078. SamWhited has left
  1079. daniel has left
  1080. daniel has joined
  1081. Valerian has left
  1082. Valerian has joined
  1083. alacer has joined
  1084. Ge0rG has left
  1085. alacer has joined
  1086. Alex has left
  1087. Tobias has left
  1088. Tobias has joined
  1089. Guus has left
  1090. Zash has left
  1091. sonny has joined
  1092. Valerian has left
  1093. emxp has joined
  1094. Ge0rG has left
  1095. emxp has joined
  1096. Syndace has joined
  1097. jere has joined
  1098. jere has joined
  1099. dwd has left
  1100. Syndace has joined
  1101. Ge0rG has left
  1102. Valerian has joined
  1103. Ge0rG has left
  1104. daniel has left
  1105. alacer has joined
  1106. alacer has joined