XSF logo XMPP Council - 2012-09-19

  1. Neustradamus has left
  2. Neustradamus has joined
  3. Neustradamus has left
  4. Neustradamus has left
  5. Tobias has left
  6. m&m has joined
  7. m&m has left
  8. Tobias has left
  9. Tobias has joined
  10. Tobias has left
  11. Tobias has joined
  12. Zash has joined
  13. Tobias has left
  14. Zash has left
  15. Zash has joined
  16. Tobias has joined
  17. Kev has left
  18. m&m has joined
  19. Kev I'm here with 30mins to spare. Hoorah.
  20. Kev Now to try and make sure I don't get caught up in the next half hour.
  21. ralphm has joined
  22. MattJ has joined
  23. m&m ding!
  24. m&m dong?
  25. Tobias pling
  26. m&m SYN
  27. Tobias FIN
  28. m&m has left
  29. m&m has joined
  30. m&m I take it Kev got distracted in that 30 minutes
  31. Kev Boom.
  32. ralphm :-)
  33. Kev I'm here.
  34. Kev I'm really looking forward to everything settling down.
  35. Kev So...
  36. Kev 1) Roll call
  37. Kev I'm here. Honest.
  38. ralphm Ik ben er!
  39. m&m presente
  40. Tobias so am i
  41. Kev MattJ: ?
  42. MattJ Present
  43. Kev Marvellous
  44. Kev 2) End of CfE on 71.
  45. MattJ I know there is some "experience" in the works, from waqas
  46. MattJ I'll poke him about that
  47. Kev One largeish question here is whether we want to follow through on that W3C feedback we're supposed to be getting.
  48. Tobias and the current feedback has mostly been on how to handle unformatted or other-formatted parts of the message
  49. m&m I agree with stpeter on this one … it won't be realistic to get a formal review from W3C folk
  50. MattJ I think that's fine with me
  51. m&m I remember asking some to look at it informally, and no one squawked
  52. m&m meaning, no one had big problems with the spec
  53. Kev I don't have strong opinions that we need the review - given that it's already just a subset of their work.
  54. Tobias what would be the expected result anyway? we just reduced their basic XHTML, right?
  55. waqas has joined
  56. ralphm Tobias: good point
  57. m&m /nod
  58. Kev ralphm: Why was it a good point when he said it, and not when I said it a minute earlier? :p
  59. Kev So, the next question is whether we feel ready to advance it now.
  60. ralphm Kev: it's personal
  61. Kev Course it is.
  62. ralphm waqas: do you feel we need to wait for your experience?
  63. waqas ralphm: To summarize, I have looked at various XHTML-IM client implementations. The number I couldn't compromise was zero.
  64. waqas This includes popular clients, such as Jappix, Pandion, Candy, etc
  65. ralphm So that's good.
  66. waqas (I was looking at web based clients, or clients embedding a browser control)
  67. waqas I was able to compromise them. That's good? :)
  68. ralphm My only personal experiences are with Adium (which does some horrible tricks with URLs) and Gajim (for which I'd prefer disabling specific styles due to Adium and iChat), but on the whole it looks good.
  69. Tobias waqas, in the sense that you found the issue ;)
  70. Kev I might be inclined to think that advancing a spec that no-one has managed to implement sensibly is ill advised.
  71. Tobias Kev, how can we change the situation?
  72. m&m have these projects been approached regarding the compromises?
  73. MattJ More security notes? :)
  74. Tobias MattJ, yeah...bigger warning signs :P
  75. Kev waqas: Did you let any of the projects know about the vulnerabilities?
  76. waqas I also found lots of other security issues in web clients. Needless to say, I wont be trusting them unless I review the code. The only clients I couldn't compromise were too simple to be of much use.
  77. Kev Were they consistent attacks, or did they each have different issues?
  78. waqas Kev: Not yet. I'll be writing emails.
  79. ralphm waqas: I assume most clients just take some locally available browser-like widget and through the incoming message at it?
  80. m&m without scrubbing
  81. waqas They were different issues. The clients I named went to quite some effort to sanitize the data, but left some cases uncovered.
  82. waqas The style attribute is particularly troublesome. All failed to properly sanitize that.
  83. Tobias MattJ, although it's true that the current security consideration aren't quite little
  84. Kev Should we be disallowing style?
  85. MattJ Tobias, indeed
  86. ralphm I suppose the only thing that can be done is file tickets against the respective projects and provide examples of exploiting messages and their unwanted behavior.
  87. MattJ I think the security notices and examples are our best shot at preventing this
  88. m&m yes
  89. MattJ Obviously notifying existing projects is a given, but it's our job to fix the spec, more importantly (if possible)
  90. Tobias right
  91. MattJ Security issues are the nature of HTML and CSS rendering, as the web has taught us :)
  92. ralphm Kev: I don't believe disallowing style will help one bit, in reality
  93. Kev ralphm: That may well be. I'm just asking the obvious question :)
  94. MattJ Thank $AUTHORS we don't support Javascript
  95. m&m disallowing style is effectively disallowing rich text
  96. ralphm MattJ: but do implementations?
  97. Kev MattJ: Don't go there.
  98. Tobias m&m, right...that'd cut the featureset quite down
  99. Kev m&m: Well, yes, kinda. Depending whether we allowed a separate CSS block or whatever. It depends what the big problems here are.
  100. Tobias don't other technologies like HTML based e-mail have similar problems? but that probably isn't standardized, right?
  101. waqas Kev: My recommendation would be to never use blacklists for anything, always whitelists, including for CSS values.
  102. ralphm I we would want to be thorough, we could provide a reference implementation that does do this properly.
  103. ralphm if
  104. Kev ralphm: If we think we're capable of doing it properly :)
  105. ralphm Kev: well yeah, it would take quite some time and effort, too
  106. Kev The consensus (I think) that I'm hearing is that this isn't ready to go to Final and needs attention for security issues.
  107. Kev And that should probably happen on list, rather than here.
  108. m&m +1
  109. Tobias +1
  110. ralphm Kev: yeah
  111. ralphm Kev: at the very least the word 'whitelist' probably should be in there
  112. ralphm essentially something similar to what the universal feed parser does for RSS/ATom
  113. ralphm Atom
  114. Kev OK.
  115. Kev MattJ: You happy with that too?
  116. MattJ wfm
  117. Kev OK.
  118. Kev 3) Date of next.
  119. Kev I should be here next Wednesday. Others?
  120. waqas I'm a bit concerned about the state of web clients. I tested around half the webclients in the xmpp.org client list. All except one were vulnerable in one way or another.
  121. m&m SBTSBC WFM
  122. ralphm Kev: point of order, did we formally vote just now?
  123. MattJ Next week wfm
  124. Tobias ditto
  125. Kev ralphm: I believe we just agreed to delay voting until later.
  126. ralphm interesting
  127. Kev That is - we didn't decide to move it to deprecated or final, we left it as it was with an intention to vote later once it's been updated.
  128. Kev But what do I know.
  129. Kev 4) Any other business?
  130. ralphm none
  131. m&m nay
  132. Tobias none here for now
  133. MattJ nack
  134. Kev Marvellous.
  135. MattJ I know I've said this before, but in the past week I've been ploughing my spare time into XEP-0313
  136. Kev MattJ: Marvellous :)
  137. MattJ So expect a submission shortly
  138. MattJ There are just a couple of open issues, I'll post those to the list after updating
  139. Tobias !xep 313
  140. Kanchil Tobias: XEP-0313(mam): http://xmpp.org/extensions/xep-0313.html Message Archive Management - Standards Track/Experimental - Updated: 2012-04-18
  141. MattJ m&m, you're also owing a Carbons update for forwarding encapsulation
  142. MattJ but I won't shout at you until I've pushed 313 :)
  143. Kev Anyway ...
  144. Kev I think we're done.
  145. MattJ Yup, thanks
  146. Kev bangs the gavel.
  147. Kev Thanks all.
  148. Tobias thank you
  149. ralphm Arrrr
  150. m&m Avast! Ye be following the code fer this auspicious day!
  151. m&m has left
  152. m&m has joined
  153. Neustradamus has joined
  154. Tobias has left
  155. Tobias has joined
  156. Neustradamus has left
  157. m&m has left
  158. Zash has left