XMPP Council - 2017-10-11


  1. jere has joined
  2. pep. has left
  3. Tobias has joined
  4. Tobias has joined
  5. daniel has joined
  6. ralphm has left
  7. moparisthebest has joined
  8. daniel has left
  9. Zash has left
  10. moparisthebest has left
  11. daniel has joined
  12. SamWhited has left
  13. Ge0rG has left
  14. Ge0rG has joined
  15. SamWhited has left
  16. Flow has joined
  17. Flow has left
  18. ralphm has left
  19. daniel has left
  20. daniel has joined
  21. jere has left
  22. jere has joined
  23. ralphm has left
  24. jere has left
  25. ralphm has left
  26. ralphm has left
  27. Flow has joined
  28. ralphm has left
  29. Flow has left
  30. Flow has joined
  31. Flow has left
  32. Flow has joined
  33. Flow has left
  34. ralphm has joined
  35. Flow has joined
  36. Flow has left
  37. Flow has joined
  38. ralphm has left
  39. ralphm has left
  40. ralphm has joined
  41. ralphm has left
  42. ralphm has joined
  43. ralphm has left
  44. Kev has left
  45. Kev has left
  46. ralphm has left
  47. ralphm has left
  48. Flow has left
  49. Flow has joined
  50. ralphm has left
  51. jere has joined
  52. Flow has joined
  53. Flow has joined
  54. ralphm has joined
  55. jere has left
  56. jere has joined
  57. Link Mauve Hi, I’m ill today so I won’t be here, good night. \o_
  58. Tobias get well
  59. ralphm has joined
  60. ralphm has left
  61. moparisthebest has joined
  62. daniel has left
  63. ralphm has left
  64. Flow has left
  65. Flow has joined
  66. ralphm has left
  67. Tobias hi
  68. Tobias 1) Roll call
  69. SamWhited Here
  70. daniel Hi
  71. Tobias Link Mauve is excused as he's ill
  72. Tobias have pinged dave in another channel
  73. Tobias 2) Minute taker
  74. Tobias I can take minutes if there's no other volunteer
  75. daniel Please do. I'm traveling. Will do the minutes when I get back
  76. Tobias alright
  77. Tobias 3) General reminder to vote on things, see pending votes column in trello https://trello.com/b/ww7zWMlI/xmpp-council-agenda
  78. Ge0rG has joined
  79. SamWhited Jingle Encrypted Transports was apparently already published, but it's in that column
  80. SamWhited as was the color one.
  81. daniel Maybe Because the two weeks ran out?
  82. SamWhited Could be, I'm not actually sure which is wrong.
  83. daniel I don't think I voted on either. But I'm fine with it
  84. Tobias yeah
  85. Tobias 4) Vote on advancing XEP-0387: XMPP Compliance Suites 2017
  86. Tobias to Draft that is
  87. Tobias I'm +1
  88. daniel +1
  89. SamWhited As the author I'm +0
  90. Tobias alright. I suppose the rest will vote on list
  91. ralphm has left
  92. dwd has joined
  93. Tobias 5) Consider deprecation of Message Archiving ( https://xmpp.org/extensions/xep-0136.html )
  94. Kev I don't think that's in LC, is it? I don't remember seeing an LC recently, at least.
  95. Kev (compliance)
  96. dwd Mea culpa, meeting was overrunning and I didn't notice the time.
  97. SamWhited oops, yes, that was supposed to be for issuing a LC, not for advancing to draft
  98. daniel I figured as much
  99. Tobias yeah
  100. dwd I was just coming to that conclusion. I'm fine for a last call.
  101. Tobias LC for advancing it to Draft
  102. Tobias SamWhited, why do you want to deprecate XEP-136?
  103. SamWhited RE Message Archiving: we've discussed this before, but I'd like to complain about it again. I was having a conversation with someone the other day that was implementing a server and they said something about having trouble with message archiving. I mentioned that most people seem to use MAM now and that they should probably do that instead and got the usual "but archiving is the recommended one, why would I do MAM?"
  104. daniel I think we should advance mam
  105. daniel Before we deprecate something else
  106. dwd SamWhited, I agree with the sentiment, but let's LC MAM first.
  107. daniel I'm entirely with you on the confusion problem
  108. SamWhited I think we either need to advance MAM and deprecate archiving, or if that's not ready we need to go ahead and deprecate archiving to prevent confusion and just only have an experimental history XEP.
  109. Tobias yeah...I'd prefer advancing MAM first too
  110. SamWhited Since I've heard that "more work on MAM is coming soon" for at least a year, I'm not sure that it's ready to advance, but I would be all for issuing a LC and finding out.
  111. daniel I don't think we should deprecate before there is something else
  112. Kev I don't like deprecating in favour of something with lower advancement, but in this case I think the case is fairly compelling.
  113. SamWhited I disagree, I think we should absolutely deprecate if the community has standardized on something else. Even if that thing is experimental, it can still be the recommendation of this council.
  114. dwd SamWhited, Again, I agree with the sentiment, but I'd want to try pretty hard to nail '313 before deprecating without a replacement.
  115. Kev It's not like there's nothing else, just that the something else isn't Draft.
  116. Kev Whether we continue tweaking MAM or not, we know it's already vastly better than 136.
  117. SamWhited But I do agree that issuign a LC for MAM seems like a reasonable step, maybe I'm wrong about it needing more work.
  118. Ge0rG does the Council want to encourage 136 implementations until MAM is finished?
  119. Kev Ge0rG: Hopefully not :)
  120. daniel Though I admit that the mam situation is a bit problematic. (lots of people use it but it's not really being worked on)
  121. SamWhited I hope not too
  122. daniel But we should fix that situation
  123. Tobias yeah
  124. Ge0rG Kev: in that case deprecating it now might be good?
  125. dwd Ge0rG, I take your point, but I would prefer a push on MAM *first*. If that doesn't work, let's revisit.
  126. SamWhited That is a compromise I can live with. In that case, I would like us to vote on a LC for MAM if possible.
  127. Kev I can probably arrange for a 313 author to request an LC if you want ...
  128. SamWhited This is the second or third time I've run into this specific XEP as a source of confusion, so I'm rather eager to find a solution
  129. SamWhited Or we can just issue one, no?
  130. Kev SamWhited: It was a flippancy, Matt and I are the authors.
  131. dwd Kev, Are you so doing? I think you need to ask an Editor, if you can find one...
  132. daniel has left
  133. daniel has joined
  134. daniel SamWhited: does that work without the author requesting it?
  135. daniel Or is that a good idea without the author requesting it
  136. SamWhited daniel: It seems like a good way to encourage authors to submit the changes they've said they have almost ready for a year or more :)
  137. Kev I don't think Council needs the author to request it, although doing so when the author thinks it isn't ready might be a poor idea.
  138. Kev Anyway, issue the LC. No harm will come, as long as you don't then advance it prematurely :)
  139. daniel Let issue a LC. Maybe that encourages some discussion. Or the author to submit more changes and thus cancel lc
  140. Kev (Or issue the vote for an LC, as clearly I wouldn't tell Council how to vote)
  141. Ge0rG Kev: if 136 is not an alternative to 313, deprecating 136 is independent of pushing forward 313, right?
  142. Tobias sure...fine with issuing a LC
  143. SamWhited Thanks all. +1 to LC from me (obviously)
  144. Kev Ge0rG: I'm not Council, and Council don't want to deprecate 136 until 313 is LCd, so ... path of least resistance.
  145. daniel +1 for the LC
  146. dwd I would be happy to vote on an LC for 313 now. (And will vote for, FWIW).
  147. dwd Oh. So yeah, -1.
  148. dwd Argh.
  149. dwd +1. I meant +1.
  150. Tobias ok..to make it clear in the history let's start fresh
  151. Tobias 6) Vote on issuing a LC on MAM
  152. Tobias +1
  153. dwd +1
  154. SamWhited +1
  155. daniel +1
  156. Tobias thanks
  157. SamWhited I'll add a card; thanks all.
  158. Tobias 7) Deprecate XHTML-IM
  159. daniel Lol
  160. daniel Link Mauve loves that xep
  161. dwd Where did that one spring from?
  162. Tobias SamWhited
  163. Tobias he wants us to discuss this yearly
  164. Tobias :)
  165. dwd Oh. Has it been discussed on the list yearly, too?
  166. daniel I think that needs list discussion
  167. Tobias yeah
  168. daniel Even though I personally hate that xep and would like to deprecate it I think it does have a lot of fans
  169. dwd Yeah. Last time it was discussed on the list was back in December.
  170. SamWhited Okay, back to this
  171. Ge0rG I love XHTML-IM.
  172. daniel Or we should maybe do some 'markup in im' xep
  173. SamWhited Similar to the MAM thing, I was playing around with another web client a few days ago and found, yet again, an implementation of XHTML-IM that simply dumped HTML into the DOM and made it trivial to implement XSS's
  174. dwd daniel, Down. Mark*down*.
  175. daniel Since markup seems to be what cool IMs do theses days
  176. SamWhited I have never found an XHTML-IM implementation that didn't have this issue (or rather, some didn't, but they did have it originally and it had been fixed)
  177. daniel *that *
  178. SamWhited Literally "never", that is not me making a grand statement for the purpose of making a point.
  179. Zash Big warning in <blink> and red letters at the top of the document?
  180. SamWhited I'm sure *someone* has done this right the first time, but it seems that the default is that the spec encourages people to do it wrong. By leaving it as a recommendation I think we are encouraging security issues.
  181. daniel SamWhited: yes I'm personally all in favor for the same arguments. I think we should even do the 'what ever is worse than deprecated'
  182. Ge0rG SamWhited: all modern applications are full of security issues.
  183. daniel But it does need list discussion
  184. SamWhited Even if we're not comfortable deprecating Message Archiving until there is a replacement, I think this is a security problem and therefore should absolutely be obsoleted (not just deprecated) as soon as possible.
  185. daniel Especially if you want to get Link Mauve on board
  186. Tobias yeah, SamWhited, do you mind writing a mail to standard about the plan of deprecating it and we'll see what comes out of that?
  187. daniel He *loves* xhtml
  188. SamWhited Sounds good, I'll write something up for the list.
  189. Tobias ta
  190. SamWhited Thanks for humoring me.
  191. Tobias 7) Date of next
  192. Tobias same time next week
  193. daniel Wfm
  194. Tobias great
  195. SamWhited WFM
  196. Tobias 8) AOB
  197. daniel None from me
  198. dwd Just a heads-up that I'll be writing up Surevine's TOTP approach into a XEP or two shortly.
  199. Tobias TOTP?
  200. SamWhited Excellent!
  201. SamWhited Tobias: time based multi-factor auth (Google Authenticator, Yubico Auth, etc.)
  202. Tobias ahh
  203. Tobias great
  204. Tobias no other AOB
  205. Tobias bangs the gavel
  206. Tobias thanks everybody
  207. SamWhited I can't wait to see that; I'd love to be able to use my yubikey as a second factor in Conversations one of these days
  208. Ge0rG I'd be happy with per-device passwords already.
  209. jonasw I can’t believe people would simply dump an XHTML-IM tree in anything capable of doing something bad with that.
  210. dwd Ge0rG, That has to be included.
  211. jonasw that makes me sad.
  212. dwd Ge0rG, Otherwise you end up having to hit the TOTP device every time you switch networks.
  213. Ge0rG jonasw: people go for convenience first.
  214. jonasw Ge0rG, insert rage here
  215. Ge0rG dwd: right. There needs to be some sensible trade-off here.
  216. daniel has left
  217. daniel has joined
  218. Flow has left
  219. Flow has joined
  220. daniel has left
  221. moparisthebest yubikey might have some value there
  222. moparisthebest but otherwise, all apps are on the phone
  223. moparisthebest so to login to conversations you need your phone anyway, and you are back to 1 factor no?
  224. Ge0rG moparisthebest: the trick is to have a _second_ phone for 2FA!
  225. jere has joined
  226. moparisthebest ah so user friendly Ge0rG :P
  227. dwd moparisthebest, You're right, but the 2FA control is on the account, so this is a generally recurring problem.
  228. Ge0rG we really need some notion of device identity.
  229. dwd moparisthebest, I can recommend a watch for this, BTW. :-)
  230. moparisthebest Ge0rG, you can already see your other online devices right?
  231. Ge0rG moparisthebest: yes and no. Let me write a short mail to standards@.
  232. moparisthebest I'm still undecided on the whole thing, I think it's fine for people that want it, I don't think I'd want it
  233. moparisthebest I'm not positive it's that much better than just long random passwords for most threats
  234. moparisthebest so you've got:
  235. dwd moparisthebest, No, it is.
  236. moparisthebest 1. password leaks, yahoo hacks, etc - long random unique per account password and 2fa protect you the same
  237. moparisthebest 2. NSA is after you - cracking long random password is harder than hacking your phone and stealing your 2fa stuff
  238. moparisthebest 3. Kidnapped - same
  239. moparisthebest what am I missing? I guess if some random hacks your computer and not your phone? in which case 2fa is an advantage
  240. SamWhited The point is that they work together; 1. doesn't actually make sense, it's operating under the assumption that they are two orthogonal things that attempt to solve the same problems. You have to use both together, 2fa is not a replacement for long random unique-per-account passwords.
  241. SamWhited Same with two. The point is that they have to crack a long random password *and* steal your 2fa stuff. Doesn't matter which one is harder for any given actor.
  242. moparisthebest but for #1 it doesn't make it any harder with 2fa
  243. dwd moparisthebest, Yes, it does.
  244. moparisthebest #2 the NSA can just do both, *maybe* it makes it a bit harder, fair
  245. moparisthebest and I mean who are we kidding, the NSA just hacks your server, it doesn't need your credentials, so that was a dumb example on my part :)
  246. SamWhited It does if your bank was storing your password in plain text. Or if it is random, long, and hard to break but your goal is to slow them down even further even if they do break it.
  247. dwd SamWhited, Or if you get phished.
  248. moparisthebest banks are one of the few places I think 2fa makes sense
  249. SamWhited dwd: indeed
  250. moparisthebest too bad none of them implement it :'(
  251. SamWhited It's also almost not worth using the NSA as an example. Most peoples threat model doesn't include a state level adversary.
  252. moparisthebest yep I agree
  253. SamWhited ah yah, I missed your last statement on that.
  254. dwd moparisthebest, There *is* a problem in that many TOTP implementations store the TOTP secret in the clear, and that's bad. It's difficult (especially in XMPP) to do otherwise, though our implementation at least stores it encrypted in the database.
  255. moparisthebest if you do, you should just stay off the internet really :)
  256. moparisthebest I guess in my mind TOTP makes more sense for things you log into, do your business, and log out of
  257. moparisthebest and less for something you plan on staying logged into forever
  258. moparisthebest especially from your phone that doubles as your totp generator
  259. dwd moparisthebest, Sure, which is why any time you'd save your password in the client, you need a way to avoid the TOTP.
  260. moparisthebest that sounds like a good system then dwd :)
  261. dwd moparisthebest, And amazing, we have already implemented most of it. Got to replace the crappy per-client password type thing with a better one I've designed, but it's certainly proved the concept.
  262. dwd moparisthebest, The really painful thing isn't merely using TOTP on the phone, BTW. The really painful thing is signing up to TOTP on the phone.
  263. moparisthebest yea actually that would be a giant pain
  264. moparisthebest back to Ge0rG 's 2 phone thing :)
  265. dwd moparisthebest, But yay, because I don't have a solution there at all.
  266. moparisthebest what about 2 mirrors?
  267. moparisthebest oh, front-facing camera and 1 mirror
  268. moparisthebest problem solved!
  269. dwd moparisthebest, I suspect that trying to open a totp URI on Android might well actually do the right thing.
  270. moparisthebest that's the way, if any totp apps support that
  271. moparisthebest I find redhat's the best https://freeotp.github.io/
  272. Zash has left
  273. ralphm has joined
  274. Lance has joined
  275. Lance has left
  276. Zash has left
  277. jere has left
  278. ralphm has left
  279. ralphm has left
  280. Flow has left
  281. Flow has joined
  282. ralphm has left
  283. Zash has joined
  284. Tobias has joined
  285. ralphm has left
  286. Flow has joined
  287. Flow has joined
  288. Flow has left
  289. Tobias Minutes are out.
  290. Tobias has left
  291. jere has joined
  292. Flow has joined
  293. Flow has left
  294. Ge0rG moparisthebest: https://mail.jabber.org/pipermail/standards/2017-October/033544.html btw
  295. Zash has left
  296. jere has joined
  297. jere has joined
  298. SamWhited has left
  299. Tobias has joined
  300. moparisthebest has joined
  301. Zash has left
  302. peter has joined
  303. Tobias has left
  304. Zash has joined
  305. Zash has left
  306. Zash has left
  307. Zash has left
  308. Zash has left
  309. Zash has left
  310. Zash has left
  311. Zash has left
  312. Zash has left
  313. Zash has left
  314. Zash has left
  315. Zash has left
  316. Zash has left
  317. Zash has left
  318. Zash has left
  319. Zash has left
  320. Zash has left
  321. Zash has left
  322. Zash has left
  323. Zash has left
  324. Zash has left
  325. Zash has left
  326. Zash has left
  327. Zash has left
  328. Zash has left
  329. Zash has left
  330. Zash has left
  331. Zash has left
  332. Zash has left
  333. Zash has left
  334. Zash has left
  335. Zash has left
  336. Zash has left
  337. Zash has left
  338. Zash has left
  339. Zash has left
  340. Zash has left
  341. Zash has left
  342. Zash has left
  343. Zash has left
  344. Zash has left
  345. Zash has joined
  346. Zash has left
  347. Zash has joined
  348. SamWhited has left
  349. pep. Wow deprecate xhtml-im. Didn't see that coming.
  350. SamWhited I try to keep you on your toes :)
  351. pep. People are dumb, sure, help them fix their client. Otherwise you can do whatever other markup you want with it. You want markdown, her xhtml-im! You want rST, use xhtml-im
  352. pep. use* dumb android
  353. Tobias has left
  354. vanitasvitae has left
  355. Tobias has left
  356. daniel has joined
  357. vanitasvitae has left
  358. daniel has left
  359. peter has left
  360. Tobias has joined
  361. Tobias has joined
  362. Zash has left
  363. Zash has left
  364. Zash has joined