XMPP Council - 2018-05-30


  1. moparisthebest has joined
  2. Lance has joined
  3. Lance has joined
  4. Dave has left
  5. moparisthebest has left
  6. Tobias has left
  7. Tobias has joined
  8. Zash has joined
  9. Dave has left
  10. ralphm has left
  11. SamWhited has left
  12. guus.der.kinderen has left
  13. guus.der.kinderen has left
  14. Lance has joined
  15. Lance has joined
  16. Tobias has joined
  17. guus.der.kinderen has left
  18. guus.der.kinderen has left
  19. guus.der.kinderen has joined
  20. guus.der.kinderen has left
  21. Tobias has joined
  22. ralphm has joined
  23. Kev has joined
  24. guus.der.kinderen has left
  25. daniel I want to put http upload on today's agenda. There has been some criticism on the use of normative language which I believe I have addressed now. Before that there was also some criticism on handling headers. This has also been resolved. So I would either like a vote on advancing it since it's technically still in last call or alternatively a vote on restarting last call
  26. daniel What ever people feel is more appropriate
  27. Kev has left
  28. Dave has left
  29. Dave has left
  30. Dave has left
  31. Dave has left
  32. Kev has joined
  33. Dave has left
  34. ralphm has left
  35. pep. has joined
  36. Dave has left
  37. Dave has left
  38. ralphm has joined
  39. pep. has left
  40. pep. has left
  41. daniel has left
  42. Dave has left
  43. Dave has left
  44. pep. has left
  45. pep. has left
  46. pep. has joined
  47. guus.der.kinderen has left
  48. moparisthebest has joined
  49. Zash has left
  50. Zash has left
  51. Zash has joined
  52. vanitasvitae has left
  53. vanitasvitae has left
  54. Holger has left
  55. moparisthebest has left
  56. Kev has left
  57. Zash has left
  58. Zash has joined
  59. moparisthebest has joined
  60. moparisthebest has left
  61. moparisthebest has joined
  62. Kev has joined
  63. Dave has left
  64. Dave has left
  65. Dave has left
  66. Dave has joined
  67. Dave has left
  68. Dave has joined
  69. Dave has left
  70. Dave has joined
  71. Dave has left
  72. Dave has joined
  73. Dave has left
  74. Dave has joined
  75. Dave has left
  76. Dave has joined
  77. guus.der.kinderen has left
  78. Holger has left
  79. Zash has left
  80. Holger has left
  81. SamWhited has joined
  82. SamWhited has left
  83. sam has joined
  84. Holger has left
  85. Kev Pre-empting the meeting somewhat, but of TOS I'll say this in advance: It seems like an abuse of adhocs.
  86. Zash Motivation?
  87. Zash Or, elaboration maybe?
  88. Kev A normal adhoc implementation can't deal with it, you need a tos implementation, and the tos server has to reject anyone trying to adhoc it without having the "I'm not really an adhoc I'm a tos" support flag.
  89. jonasw Kev, I can’t defend my case at the moment, I’m at work and about to migrate to commuting, unfortunately
  90. Kev So if you don't want any of the features of adhocs, putting it in an adhoc seems unhelpful.
  91. Kev You could have all the same properties in its own namespace for simpler implementation and less confusion.
  92. jonasw the tos server does not have to reject everyone without the tos flag
  93. jonasw it MAY do that if it needs to
  94. jonasw but I tend to agree that we might want to drop that flag out of this version; there’s nothing in the XEP as it stands which warrants that
  95. jonasw and client-side, you can do fine with a normal, compliant Ad-Hoc implementation, because Ad-Hoc commands may have multiple payloads (and the form is intentionally at the place where it is so that it takes precedence on unknowing clients)
  96. sam I've been thinking about this one and I think I agree. I'm not sure why we need to encode TOS into protocol at all. Just having a standard way to get the text seems like enough. Eg. a standard pubsub node or HTTP location from which it can be fetched.
  97. Kev I'm not intending to block it going to Experimental like this, but I would object to Draft like this.
  98. SamWhitef has joined
  99. Kev This really feels like forcing a square adhoc into a round hole.
  100. SamWhited has joined
  101. sam has left
  102. SamWhited has joined
  103. jonasw Kev, as it stands (minus the "I am tos" flag in the initial request), it /does/ work as Ad-Hoc flow, doesn’t it?
  104. Kev Other than the extra payload? Possibly. But that "I am TOS" flag changes things.
  105. Kev And that you're doing it before authentication.
  106. Kev When iqs don't really work properly, because you don't have a bound resource, etc.
  107. jonasw Kev, the extra payload is ok as per my reading of '50
  108. jonasw we have precedence for pre-bind IQs actually (bind itself being one)
  109. Kev The only one, I think, and that's generally felt to be a mistake by anyone who's had to code pre-auth flows in a server, I think.
  110. Zash Yes
  111. Kev Or pre-stream-is-running, I guess, as it's not pre-auth.
  112. Zash We finally got rid of that in Prosody, so the bind isn't treated as a stanza with exceptions in the "is this session allowed to send stanzas?" code
  113. Zash Now it's a stream element that just happens to be in the jabber:client namespace
  114. daniel has left
  115. Ge0rG has joined
  116. peter has joined
  117. Dave has left
  118. Dave has joined
  119. Kev 'Tis time, 'tis time.
  120. Kev 1) Roll call
  121. daniel hi
  122. Holger has left
  123. Kev SamWhited is expecting to be here. I don't remember abotu Ge0rG.
  124. Ge0rG I've delayed my trip home despite an empty phone battery to until after the meeting
  125. Ge0rG I'm here.
  126. SamWhited has left
  127. Kev SamWhited?
  128. Kev Maybe not.
  129. Kev 2) Isn't it nice that Tedd Sterr does the minutes?
  130. Kev Yes.
  131. Kev 3) Proposed XMPP Extension: Terms of Services Title: Terms of Services Abstract: This specification provides an in-band, unauthenticated way to request the Terms of Service of an XMPP service. URL: https://xmpp.org/extensions/inbox/tos.html
  132. Kev I don't like this much, but am not blocking it.
  133. daniel same. but i'll give me official vote on list
  134. Ge0rG I think it's great to have a machine-readable way to link the ToS; not sure about the extended features
  135. Kev (That 'not blocking' is +1 for me, BTW, although I wouldn't expect it to go to Draft like this)
  136. Kev Ge0rG: What is that in terms of a position?
  137. Ge0rG +1
  138. Kev 4) Date of next SBTSBC?
  139. Ge0rG Wow, that was quick.
  140. Kev I'll take that as a 'yes' :)
  141. Kev 5) AOB?
  142. Ge0rG I still can't guarantee my general availability for this time slot. It looks like it has mostly worked so far, so +1
  143. SamWhited Sorry, I am here, now I'm not getting any notifications for this room
  144. daniel yes i would like to continue with http upload
  145. Kev SamWhited: Just the one item for you to vote on.
  146. daniel either make another last call
  147. daniel or just vote on it
  148. Kev daniel: LCs are cheap, so shall we do that?
  149. SamWhited *nods* I'll be on list anyways
  150. daniel there is a small PR pending
  151. Kev ..so shall we do that after the small PR? :)
  152. Ge0rG I'm still not lucky about the custom headers.
  153. Ge0rG but my lack of luckiness won't be progress blocking
  154. daniel yeah why note. i was hopeing to speed things up; but why bother; it has been months anyway
  155. daniel so yeah i'll just bring it up next week
  156. Kev daniel: I think that's a reason for making a clean cut with a new LC, but can be talked out of it.
  157. Kev daniel: Or just ask the Editors to send an LC mail once your patch is merged?
  158. daniel > : daniel: Or just ask the Editors to send an LC mail once your patch is merged? yes that was the idea
  159. daniel if council is ok with that
  160. Kev Ok, cool.
  161. Kev AOAOB?
  162. daniel none from me
  163. Kev gangs the bavel
  164. Kev Thanks all.
  165. Ge0rG Thanks Kev, thanks all
  166. vanitasvitae has left
  167. Ge0rG Thanks Tedd.
  168. moparisthebest so as SamWhited already said, why not just https://XMPP_DOMAIN/.well-known/xmpp-tos.txt ?
  169. moparisthebest certainly seems easier than hacking pre-auth support into servers and clients securely
  170. Zash cries over mandatory records at domain apex
  171. Ge0rG - because not every XMPP_DOMAIN is a web server - because you usually want more markup than .txt
  172. moparisthebest Zash, but which would make you cry harder
  173. daniel > so as SamWhited already said, why not just https://XMPP_DOMAIN/.well-known/xmpp-tos.txt ? Uh I like that actually. But the anti oob people will *hate* that
  174. moparisthebest Ge0rG, like what?
  175. moparisthebest (more markup I mean)
  176. Ge0rG moparisthebest: like HTML.
  177. daniel Ge0rG: but the xep hosts the tos on http anyway, no?
  178. Ge0rG daniel: but not always on XMPP_DOMAIN
  179. Kev FWIW, I'm not a fan of forcing all this stuff about registration and TOS and etc. etc. over XMPP. ISTM that a lot of the time it's much better served by being out of band.
  180. Ge0rG So now I need to setup a dedicated web server with a 30x
  181. moparisthebest Ge0rG, so https://XMPP_DOMAIN/.well-known/xmpp-tos.html then?
  182. daniel Most good xmpp do probably. Because of websocket bosh discovery and stuff
  183. moparisthebest but now you gotta worry about javascript and XSS
  184. Ge0rG Kev: the result of that would be replacing IBR with a web form?
  185. Kev Ge0rG: Pretty much.
  186. Ge0rG Kev: which is... the current status quo?
  187. moparisthebest IBR is basically already replaced with a web form?
  188. Kev There are cases for autoregistration where inband might make sense, but mostly not for users' IM accounts, I think.
  189. Kev Ge0rG: More or less, I think.
  190. Ge0rG Because UX doesn't matter.
  191. Zash IBR can redirect to a web form, you can put the ToS there.
  192. Ge0rG Zash: can the web form than redirect back to a configured XMPP client?
  193. Kev I *do* think there's value in being able to provide a ToS banner of some sort at login, though.
  194. Ge0rG Zash: can the web form then redirect back to a configured XMPP client?
  195. Ge0rG Kev: "at login" is illusive in times of always on and 0198
  196. Zash At registration would be nicest, no?
  197. Ge0rG Zash: how do you change the ToS then?
  198. Zash Or you can send a MOTD-like message
  199. Kev Ge0rG: It is, kinda.
  200. Ge0rG MOTD is as illusive as "at login"
  201. Kev Zash: Yes, but if that's out of band that's SEP.
  202. moparisthebest or the client can just check the .well-known URL
  203. SamWhited has left
  204. Ge0rG moparisthebest: check it for what?
  205. moparisthebest whatever it wants, whenever it wants :)
  206. Ge0rG moparisthebest: how is it supposed to figure out whether the ToS have changed in any significant way? Whether user consent is required to the new ToS?
  207. moparisthebest it can't, show it to the user, done
  208. moparisthebest it's not like the user is going to read it anyway
  209. moparisthebest but they can if they wish
  210. pep. Can we seriously stop requiring http every. fking. where. Re ToS
  211. daniel And then it's up the the admin to notify existing users via message
  212. moparisthebest nope, it's already done, the battle is lost
  213. Zash Kev, what is out of band?
  214. moparisthebest is it better to invent some new complicated thing to avoid using HTTP pep. ?
  215. daniel > Can we seriously stop requiring http every. fking. where. Re ToS Told you
  216. Kev Registration.
  217. pep. moparisthebest: what's complicated
  218. pep. You ask for a document, the server gives it to you
  219. moparisthebest pep., use the correct tool for the job, you can invent some complicated XMPP extension to link to an HTTP URL, or you can use .well-known which is simple and already exists
  220. Ge0rG moparisthebest: and doesn't fulfill the required needs.
  221. daniel Fun side note stateless let's do everything over http jmap just introduced websocket support because apparently http is f*ing slow
  222. Zash ha-ha
  223. pep. When is the switch from TCP/XML to http/json planned for again
  224. Zash pep., depends on how much you wanna listen to the matrix.org ppl?
  225. pep. :)
  226. moparisthebest you know the saying, if all you have is a hammer, everything looks like a nail?
  227. Zash moparisthebest, applies in both directions
  228. moparisthebest xmpp isn't the only tool, sometimes http is more appropriate, no reason it shouldn't be used in those places
  229. Dave has left
  230. Dave has joined
  231. Ge0rG moparisthebest: please describe how you will implement mandatory consent and ToS changes with the HTTP scheme.
  232. Zash I don't see why we shouldn't try to enable in-band pointing to a ToS.
  233. Kev Zash: No, I don't think that's fine.
  234. Zash The pointer itself can be HTTP or whatever URI/URL you want
  235. moparisthebest Ge0rG, client fetches TOS before attempting to log in, refuses to log in unless user agrees?
  236. Ge0rG moparisthebest: how does the server know if the client actually checked that?
  237. moparisthebest it can't no matter what
  238. Zash How does Let's Encrypt know anyone actually read their terms?
  239. moparisthebest yep
  240. Ge0rG let's exclude malicious clients for a moment.
  241. Ge0rG How does a server know that the client actually showed the ToS to the user?
  242. moparisthebest excluding malicious clients then it just does
  243. moparisthebest it just assumes they did, it's the best you can do
  244. Ge0rG Uhm. No.
  245. Zash Kev, I don't think I can't not follow all these double negatives.
  246. pep. You'd need to require auth on your webpage
  247. moparisthebest explain how an in-band protocol is different Ge0rG ?
  248. Ge0rG You can't because you don't know whether the client actually supports the feature. And whether the client actually succeeded in fetching the ToS (think wifi portal=
  249. Kev Zash: I'm fine with a mechanism for pointing to ToS from inband. I'm not sure the current protoXEP is the right way to do it.
  250. Ge0rG Kev: you might want to argue your points on standards@
  251. moparisthebest Ge0rG, and how is that different with an in-band approach?
  252. moparisthebest I believe both are still true
  253. Ge0rG moparisthebest: https://xmpp.org/extensions/inbox/tos.html#usecase-expired-reject-bind
  254. Kev moparisthebest: Inband you know that the client requested it because it did so over the current stream.
  255. Ge0rG the inband approach also has a (theoretically) nice way to enforce tos-before-login.
  256. Zash Kev, I can go along with that.
  257. Ge0rG so it's not "we locked you out because you didn't consent in time. Good luck without us now"
  258. Ge0rG goes OOB now. seeya
  259. Kev o7
  260. moparisthebest in both cases you have the client telling you the user agreed to the TOS
  261. moparisthebest and 0 guarantee any of that happened
  262. Zash Does it matter if "the client" is a browser or an xmpp client?
  263. moparisthebest I don't think so?
  264. Zash Well then
  265. SamWhited has left
  266. Zash IIRC, in ACME, there's protocol for retrieving an pointer/URL to the terms. The client supposedly shows that to the user, then indicates acceptance by sending a hash of the terms.
  267. vanitasvitae has left
  268. vanitasvitae has left
  269. moparisthebest yea that's not bad
  270. moparisthebest at least you know the client actually got them
  271. Kev It seems an odd thing to trust the client to have shown something to the user because it said it did, and can prove it fetched it, but not trust the client to have shown something to the user because you remember it fetching it, and it says it did.
  272. moparisthebest maybe the server should just give the user a quiz about the TOS
  273. moparisthebest like 10 random questions from a pool of 50, and they need to get 80% correct to be able to log in
  274. moparisthebest thanks GDPR!
  275. Zash But ACME is IETF-approved prior art, which is why I'm thinking that following that might be sensible.
  276. SamWhited You don't have to confirm that the client did the correct thing, you can't do that anyways. All you can do is confirm that the client downloaded the terms; beyond that it's on them if they don't show it to the user.
  277. SamWhited I seriously doubt if it matters if you confirm that the client downloaded it vs. it downloaded it and hashed it.
  278. moparisthebest I actually implemented that quiz thing for a forum registration back in the day, it really cut down on the number of lazy idiots registering just to ask the same dumb question over and over :)
  279. Kev moparisthebest: I have implemented exactly such a thing for some obscure place (not work related, and not GDPR-related)
  280. moparisthebest small world :)
  281. SamWhited (the hash matters in ACME because it makes the server stateless and means you don't have to have a cookie lying about)
  282. Kev I'm not sure you do anyway, do you?
  283. Kev Or, rather, I'm not sure that there's a useful distinction between "Client downloads terms and then lies about the user accepting them" versus "Client doesn't download terms and then lies about the user accepting them".
  284. moparisthebest it does rule out network errors Ge0rG mentioned earlier I guess
  285. SamWhited Yah, I don't think it matters either way personally, but I can see wanting to make sure you've done all you can so that the client is liable if they it never shows them to the user.
  286. SamWhited Making sure it's downloaded just gives servers leverage to say that it was the client acting in bad faith because they had to actively try to trick us into thinking the user accepted (I suspect, not a lawyer, etc.)
  287. SamWhited Or at the very least gives us more confidence that a bug didn't cause it to skip the TOS request.
  288. ralphm has left
  289. Kev It suggests bad caching or whatever isn't at play, yeah.
  290. SamWhited has left
  291. guus.der.kinderen has left
  292. guus.der.kinderen has left
  293. guus.der.kinderen has joined
  294. guus.der.kinderen has left
  295. vanitasvitae has left
  296. guus.der.kinderen has left
  297. ralphm has joined
  298. vanitasvitae has left
  299. Lance has joined
  300. Lance has joined
  301. guus.der.kinderen has left
  302. peter has left
  303. SamWhited has left
  304. ralphm has left
  305. SamWhited has left
  306. Dave has left
  307. Dave has joined
  308. Dave has left
  309. Dave has joined
  310. Lance has joined
  311. Lance has joined
  312. Dave has left
  313. Dave has joined
  314. Dave has left
  315. Dave has joined
  316. Dave has left
  317. Dave has joined
  318. Holger has left
  319. Ge0rG You folks are totally missing my point, which was that with a fixed https URL, there is no way to ensure from the server side whether the client supports and performs the ToS display game. If you are in GDPR-required-consent territory, you, as a server operator, must be able to prove that the user consented.
  320. daniel Ge0rG: so as a server operator you want to seriously exclude any client that doesn't accept the tos?
  321. daniel Or in other words. Every. Single. Client.?
  322. SamWhited If you use HTTP you have to do a checksum like Zash said if you want that.
  323. Ge0rG SamWhited: no!
  324. SamWhited Ge0rG: what do you mean?
  325. Ge0rG SamWhited: I don't want proof that the client *downloaded and hashed* the ToS, I want some kind of indicator that it displayed them to the user and the user had to click the "accept" button
  326. Ge0rG SamWhited: obvioulsy a malicious client can circumvent any kind of protocol.
  327. SamWhited Ge0rG: You can't get that no matter what, and you don't need it for GDPR.
  328. Ge0rG SamWhited: I can have a data-form with a checkbox
  329. SamWhited Which the client could just submit.
  330. Ge0rG Ge0rG> SamWhited: obvioulsy a malicious client can circumvent any kind of protocol.
  331. SamWhited It doesn't matter as long as you give the client a way to get it; you can't force the user to read it or the client to display it.
  332. SamWhited Right, so there's not much point to checking.
  333. Zash You can do things in good faith and hope for the best
  334. SamWhited Right.
  335. SamWhited At best you can make sure the client actually fetched it, then it's their problem if they don't display it.
  336. Ge0rG SamWhited: there is a substantial difference between "a 'well-defined' URL might or might not provide ToS which a client might or might not download and maybe show to the user which maybe then the user can click through" and "the user had to click a button on a form linking to the ToS"
  337. SamWhited I know, that's why I said you could just do a hash or something. That gives you the bare minimum like an HTTP site would have (eg. we know it was downloaded at least).
  338. Zash daniel, the client exclusion issue also applies to registering on conversations.im and you wanting to get an email to send invoices to. can't do that with protocol atm without excluding all clients.
  339. Ge0rG An IQ with the date/version of the ToS that were accepted is sufficient for the latter.
  340. Ge0rG And if a client doesn't advertise support for xep-tos, you need to either blackhole its comms and send a server-message with the ToS or do other hackery
  341. Ge0rG But "here is a well defined URL" doesn't let the server check whether the client supports showing ToS.
  342. SamWhited This TOS thing people want only has to be done during registration right? Presumably this isn't something you'd care to do before every login.
  343. SamWhited If so, maybe it makes more sense as an extension to https://xmpp.org/extensions/xep-0389.html
  344. Ge0rG SamWhited: except when the ToS change.
  345. SamWhited Ge0rG: then you send them a message saying the TOS changed (just like websites do with email).
  346. SamWhited Or also make it a part of sasl2; there may be some room to make the challenges overlap.
  347. Ge0rG The problem, again, is that with always-on devices the user isn't guaranteed to be in front of the device when the login happens
  348. Dave has left
  349. Dave has joined
  350. Zash Ge0rG, they will notice if they are offline a while
  351. SamWhited Isn't that still a problem with the proposal as it stands right now?
  352. SamWhited Also, does it matter? When they pull their phone out or whatever it will have a TOS screen and they will have to accept. Or am I misunderstanding the problem?
  353. Dave has left
  354. Dave has joined
  355. Zash Buttons-in-messages!
  356. Zash The Slack thing
  357. Ge0rG messages-in-buttons
  358. Ge0rG buttons-in-messages-in-buttons.
  359. Dave has left
  360. Dave has joined
  361. Ge0rG SamWhited: I never claimed the current proposal is perfect. I'm just trying to define the most probable use case.
  362. Ge0rG Obviously, some server admins will just send their users a message, containing a link or the ToS as a dump, at whatever time is appropriate for the server admin, and not care that some users will be woken up by a beeping phone at 3AM
  363. Zash Perfect vs good -- FIGHT!
  364. SamWhited I think I'm just not sure what the problem is you're finding with it.
  365. Ge0rG with the current xep?
  366. SamWhited Yes, because I never suggested that you said the current proposal was perfect, so I have no idea what you're even replying to.
  367. Ge0rG I didn't even point out any issues in the current XEP.
  368. SamWhited > The problem, again, is that with…
  369. Dave has left
  370. SamWhited I'm just trying to understand if you're for or against the general idea, or the specific implementation, or what
  371. Ge0rG I'm for the general idea and not against the specific implementation
  372. Dave has joined
  373. Zash Maybe write all this down and post to standards@?
  374. Ge0rG I'm against the idea of just defining a well-known ToS URI and consider the provlem solved
  375. Dave has left
  376. Dave has joined
  377. SamWhited That makes sense; thanks. I'm against the current implementation and not against the general idea, I think, but still trying to work out how strongly I feel about it or whether I think it matters.
  378. peter has joined
  379. Dave has left
  380. Dave has joined
  381. Dave has left
  382. Dave has joined
  383. Kev Ge0rG: I don't think *anyone* is for just having a .well-known and leaving it at that.
  384. SamWhited Honestly, I'm not against that.
  385. Kev If I gave the impression that I'm arguing for that I've grossly misreprented myself.
  386. SamWhited I'm not sure that it's my preferred method, but it does seem good enough.
  387. Zash As optional discovery method, maybe.
  388. Kev But I'm just not a fan of the current spec, particularly around using adhocs with bits that aren't standard adhocs, and of having adhocs inside iqs before authentication.
  389. Zash But ugh, .well-known is meh :(
  390. Kev Or before resource binding, or whatever.
  391. Lance has joined
  392. Kev SamWhited: It depends on good enough for what. It's good enough for letting a client find ToS, but I think the ToS XEP is trying to tell the server the user has accepted terms, which a .well-known on its own clearly doesn't.
  393. Ge0rG Kev: no, you were not the one. But there was a claim in the room that this suggestion was made by SamWhited
  394. Lance has joined
  395. Ge0rG Anyway, the discussion should be moved to standards@
  396. Zash +1
  397. SamWhited Kev: yah, fair, I guess we'd need some sort of notification to the server too
  398. vanitasvitae has left
  399. Kev Ge0rG: Probably true.
  400. Kev bimbles AFK again.
  401. Zash has left
  402. guus.der.kinderen has left
  403. Tobias has joined
  404. Tobias has joined
  405. Dave has left
  406. Dave has joined
  407. daniel has left
  408. Zash has left
  409. Tobias has left
  410. Tobias has joined
  411. Zash has left
  412. vanitasvitae has left
  413. vanitasvitae has left
  414. vanitasvitae has left
  415. ralphm has joined
  416. vanitasvitae has left
  417. vanitasvitae has left
  418. vanitasvitae has left
  419. vanitasvitae has left
  420. vanitasvitae has left
  421. vanitasvitae has left
  422. vanitasvitae has left
  423. vanitasvitae has left
  424. vanitasvitae has left
  425. vanitasvitae has left
  426. SamWhited has left
  427. Dave has left
  428. Dave has joined
  429. Dave has left
  430. Dave has joined