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


  24. m&m


  25. Tobias


  26. m&m


  27. Tobias


  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


  32. ralphm


  33. Kev

    I'm here.

  34. Kev

    I'm really looking forward to everything settling down.

  35. Kev


  36. Kev

    1) Roll call

  37. Kev

    I'm here. Honest.

  38. ralphm

    Ik ben er!

  39. m&m


  40. Tobias

    so am i

  41. Kev

    MattJ: ?

  42. MattJ


  43. Kev


  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


  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


  89. MattJ

    Obviously notifying existing projects is a given, but it's our job to fix the spec, more importantly (if possible)

  90. Tobias


  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


  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


  109. Tobias


  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


  114. Kev


  115. Kev

    MattJ: You happy with that too?

  116. MattJ


  117. Kev


  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


  122. ralphm

    Kev: point of order, did we formally vote just now?

  123. MattJ

    Next week wfm

  124. Tobias


  125. Kev

    ralphm: I believe we just agreed to delay voting until later.

  126. ralphm


  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


  131. m&m


  132. Tobias

    none here for now

  133. MattJ


  134. Kev


  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


  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