XMPP Council - 2018-05-30


  1. 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

  2. daniel

    What ever people feel is more appropriate

  3. Kev

    Pre-empting the meeting somewhat, but of TOS I'll say this in advance: It seems like an abuse of adhocs.

  4. Zash

    Motivation?

  5. Zash

    Or, elaboration maybe?

  6. 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.

  7. jonasw

    Kev, I can’t defend my case at the moment, I’m at work and about to migrate to commuting, unfortunately

  8. Kev

    So if you don't want any of the features of adhocs, putting it in an adhoc seems unhelpful.

  9. Kev

    You could have all the same properties in its own namespace for simpler implementation and less confusion.

  10. jonasw

    the tos server does not have to reject everyone without the tos flag

  11. jonasw

    it MAY do that if it needs to

  12. 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

  13. 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)

  14. 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.

  15. Kev

    I'm not intending to block it going to Experimental like this, but I would object to Draft like this.

  16. Kev

    This really feels like forcing a square adhoc into a round hole.

  17. 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?

  18. Kev

    Other than the extra payload? Possibly. But that "I am TOS" flag changes things.

  19. Kev

    And that you're doing it before authentication.

  20. Kev

    When iqs don't really work properly, because you don't have a bound resource, etc.

  21. jonasw

    Kev, the extra payload is ok as per my reading of '50

  22. jonasw

    we have precedence for pre-bind IQs actually (bind itself being one)

  23. 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.

  24. Zash

    Yes

  25. Kev

    Or pre-stream-is-running, I guess, as it's not pre-auth.

  26. 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

  27. Zash

    Now it's a stream element that just happens to be in the jabber:client namespace

  28. Kev

    'Tis time, 'tis time.

  29. Kev

    1) Roll call

  30. daniel

    hi

  31. Kev

    SamWhited is expecting to be here. I don't remember abotu Ge0rG.

  32. Ge0rG

    I've delayed my trip home despite an empty phone battery to until after the meeting

  33. Ge0rG

    I'm here.

  34. Kev

    SamWhited?

  35. Kev

    Maybe not.

  36. Kev

    2) Isn't it nice that Tedd Sterr does the minutes?

  37. Kev

    Yes.

  38. 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

  39. Kev

    I don't like this much, but am not blocking it.

  40. daniel

    same. but i'll give me official vote on list

  41. Ge0rG

    I think it's great to have a machine-readable way to link the ToS; not sure about the extended features

  42. Kev

    (That 'not blocking' is +1 for me, BTW, although I wouldn't expect it to go to Draft like this)

  43. Kev

    Ge0rG: What is that in terms of a position?

  44. Ge0rG

    +1

  45. Kev

    4) Date of next SBTSBC?

  46. Ge0rG

    Wow, that was quick.

  47. Kev

    I'll take that as a 'yes' :)

  48. Kev

    5) AOB?

  49. Ge0rG

    I still can't guarantee my general availability for this time slot. It looks like it has mostly worked so far, so +1

  50. SamWhited

    Sorry, I am here, now I'm not getting any notifications for this room

  51. daniel

    yes i would like to continue with http upload

  52. Kev

    SamWhited: Just the one item for you to vote on.

  53. daniel

    either make another last call

  54. daniel

    or just vote on it

  55. Kev

    daniel: LCs are cheap, so shall we do that?

  56. SamWhited

    *nods* I'll be on list anyways

  57. daniel

    there is a small PR pending

  58. Kev

    ..so shall we do that after the small PR? :)

  59. Ge0rG

    I'm still not lucky about the custom headers.

  60. Ge0rG

    but my lack of luckiness won't be progress blocking

  61. daniel

    yeah why note. i was hopeing to speed things up; but why bother; it has been months anyway

  62. daniel

    so yeah i'll just bring it up next week

  63. Kev

    daniel: I think that's a reason for making a clean cut with a new LC, but can be talked out of it.

  64. Kev

    daniel: Or just ask the Editors to send an LC mail once your patch is merged?

  65. daniel

    > : daniel: Or just ask the Editors to send an LC mail once your patch is merged? yes that was the idea

  66. daniel

    if council is ok with that

  67. Kev

    Ok, cool.

  68. Kev

    AOAOB?

  69. daniel

    none from me

  70. Kev gangs the bavel

  71. Kev

    Thanks all.

  72. Ge0rG

    Thanks Kev, thanks all

  73. Ge0rG

    Thanks Tedd.

  74. moparisthebest

    so as SamWhited already said, why not just https://XMPP_DOMAIN/.well-known/xmpp-tos.txt ?

  75. moparisthebest

    certainly seems easier than hacking pre-auth support into servers and clients securely

  76. Zash cries over mandatory records at domain apex

  77. Ge0rG

    - because not every XMPP_DOMAIN is a web server - because you usually want more markup than .txt

  78. moparisthebest

    Zash, but which would make you cry harder

  79. 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

  80. moparisthebest

    Ge0rG, like what?

  81. moparisthebest

    (more markup I mean)

  82. Ge0rG

    moparisthebest: like HTML.

  83. daniel

    Ge0rG: but the xep hosts the tos on http anyway, no?

  84. Ge0rG

    daniel: but not always on XMPP_DOMAIN

  85. 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.

  86. Ge0rG

    So now I need to setup a dedicated web server with a 30x

  87. moparisthebest

    Ge0rG, so https://XMPP_DOMAIN/.well-known/xmpp-tos.html then?

  88. daniel

    Most good xmpp do probably. Because of websocket bosh discovery and stuff

  89. moparisthebest

    but now you gotta worry about javascript and XSS

  90. Ge0rG

    Kev: the result of that would be replacing IBR with a web form?

  91. Kev

    Ge0rG: Pretty much.

  92. Ge0rG

    Kev: which is... the current status quo?

  93. moparisthebest

    IBR is basically already replaced with a web form?

  94. Kev

    There are cases for autoregistration where inband might make sense, but mostly not for users' IM accounts, I think.

  95. Kev

    Ge0rG: More or less, I think.

  96. Ge0rG

    Because UX doesn't matter.

  97. Zash

    IBR can redirect to a web form, you can put the ToS there.

  98. Ge0rG

    Zash: can the web form than redirect back to a configured XMPP client?

  99. Kev

    I *do* think there's value in being able to provide a ToS banner of some sort at login, though.

  100. Ge0rG

    Zash: can the web form then redirect back to a configured XMPP client?

  101. Ge0rG

    Kev: "at login" is illusive in times of always on and 0198

  102. Zash

    At registration would be nicest, no?

  103. Ge0rG

    Zash: how do you change the ToS then?

  104. Zash

    Or you can send a MOTD-like message

  105. Kev

    Ge0rG: It is, kinda.

  106. Ge0rG

    MOTD is as illusive as "at login"

  107. Kev

    Zash: Yes, but if that's out of band that's SEP.

  108. moparisthebest

    or the client can just check the .well-known URL

  109. Ge0rG

    moparisthebest: check it for what?

  110. moparisthebest

    whatever it wants, whenever it wants :)

  111. 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?

  112. moparisthebest

    it can't, show it to the user, done

  113. moparisthebest

    it's not like the user is going to read it anyway

  114. moparisthebest

    but they can if they wish

  115. pep.

    Can we seriously stop requiring http every. fking. where. Re ToS

  116. daniel

    And then it's up the the admin to notify existing users via message

  117. moparisthebest

    nope, it's already done, the battle is lost

  118. Zash

    Kev, what is out of band?

  119. moparisthebest

    is it better to invent some new complicated thing to avoid using HTTP pep. ?

  120. daniel

    > Can we seriously stop requiring http every. fking. where. Re ToS Told you

  121. Kev

    Registration.

  122. pep.

    moparisthebest: what's complicated

  123. pep.

    You ask for a document, the server gives it to you

  124. 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

  125. Ge0rG

    moparisthebest: and doesn't fulfill the required needs.

  126. daniel

    Fun side note stateless let's do everything over http jmap just introduced websocket support because apparently http is f*ing slow

  127. Zash

    ha-ha

  128. pep.

    When is the switch from TCP/XML to http/json planned for again

  129. Zash

    pep., depends on how much you wanna listen to the matrix.org ppl?

  130. pep.

    :)

  131. moparisthebest

    you know the saying, if all you have is a hammer, everything looks like a nail?

  132. Zash

    moparisthebest, applies in both directions

  133. moparisthebest

    xmpp isn't the only tool, sometimes http is more appropriate, no reason it shouldn't be used in those places

  134. Ge0rG

    moparisthebest: please describe how you will implement mandatory consent and ToS changes with the HTTP scheme.

  135. Zash

    I don't see why we shouldn't try to enable in-band pointing to a ToS.

  136. Kev

    Zash: No, I don't think that's fine.

  137. Zash

    The pointer itself can be HTTP or whatever URI/URL you want

  138. moparisthebest

    Ge0rG, client fetches TOS before attempting to log in, refuses to log in unless user agrees?

  139. Ge0rG

    moparisthebest: how does the server know if the client actually checked that?

  140. moparisthebest

    it can't no matter what

  141. Zash

    How does Let's Encrypt know anyone actually read their terms?

  142. moparisthebest

    yep

  143. Ge0rG

    let's exclude malicious clients for a moment.

  144. Ge0rG

    How does a server know that the client actually showed the ToS to the user?

  145. moparisthebest

    excluding malicious clients then it just does

  146. moparisthebest

    it just assumes they did, it's the best you can do

  147. Ge0rG

    Uhm. No.

  148. Zash

    Kev, I don't think I can't not follow all these double negatives.

  149. pep.

    You'd need to require auth on your webpage

  150. moparisthebest

    explain how an in-band protocol is different Ge0rG ?

  151. 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=

  152. 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.

  153. Ge0rG

    Kev: you might want to argue your points on standards@

  154. moparisthebest

    Ge0rG, and how is that different with an in-band approach?

  155. moparisthebest

    I believe both are still true

  156. Ge0rG

    moparisthebest: https://xmpp.org/extensions/inbox/tos.html#usecase-expired-reject-bind

  157. Kev

    moparisthebest: Inband you know that the client requested it because it did so over the current stream.

  158. Ge0rG

    the inband approach also has a (theoretically) nice way to enforce tos-before-login.

  159. Zash

    Kev, I can go along with that.

  160. Ge0rG

    so it's not "we locked you out because you didn't consent in time. Good luck without us now"

  161. Ge0rG goes OOB now. seeya

  162. Kev

    o7

  163. moparisthebest

    in both cases you have the client telling you the user agreed to the TOS

  164. moparisthebest

    and 0 guarantee any of that happened

  165. Zash

    Does it matter if "the client" is a browser or an xmpp client?

  166. moparisthebest

    I don't think so?

  167. Zash

    Well then

  168. 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.

  169. moparisthebest

    yea that's not bad

  170. moparisthebest

    at least you know the client actually got them

  171. 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.

  172. moparisthebest

    maybe the server should just give the user a quiz about the TOS

  173. moparisthebest

    like 10 random questions from a pool of 50, and they need to get 80% correct to be able to log in

  174. moparisthebest

    thanks GDPR!

  175. Zash

    But ACME is IETF-approved prior art, which is why I'm thinking that following that might be sensible.

  176. 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.

  177. SamWhited

    I seriously doubt if it matters if you confirm that the client downloaded it vs. it downloaded it and hashed it.

  178. 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 :)

  179. Kev

    moparisthebest: I have implemented exactly such a thing for some obscure place (not work related, and not GDPR-related)

  180. moparisthebest

    small world :)

  181. SamWhited

    (the hash matters in ACME because it makes the server stateless and means you don't have to have a cookie lying about)

  182. Kev

    I'm not sure you do anyway, do you?

  183. 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".

  184. moparisthebest

    it does rule out network errors Ge0rG mentioned earlier I guess

  185. 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.

  186. 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.)

  187. SamWhited

    Or at the very least gives us more confidence that a bug didn't cause it to skip the TOS request.

  188. Kev

    It suggests bad caching or whatever isn't at play, yeah.

  189. 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.

  190. daniel

    Ge0rG: so as a server operator you want to seriously exclude any client that doesn't accept the tos?

  191. daniel

    Or in other words. Every. Single. Client.?

  192. SamWhited

    If you use HTTP you have to do a checksum like Zash said if you want that.

  193. Ge0rG

    SamWhited: no!

  194. SamWhited

    Ge0rG: what do you mean?

  195. 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

  196. Ge0rG

    SamWhited: obvioulsy a malicious client can circumvent any kind of protocol.

  197. SamWhited

    Ge0rG: You can't get that no matter what, and you don't need it for GDPR.

  198. Ge0rG

    SamWhited: I can have a data-form with a checkbox

  199. SamWhited

    Which the client could just submit.

  200. Ge0rG

    Ge0rG> SamWhited: obvioulsy a malicious client can circumvent any kind of protocol.

  201. 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.

  202. SamWhited

    Right, so there's not much point to checking.

  203. Zash

    You can do things in good faith and hope for the best

  204. SamWhited

    Right.

  205. SamWhited

    At best you can make sure the client actually fetched it, then it's their problem if they don't display it.

  206. 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"

  207. 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).

  208. 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.

  209. Ge0rG

    An IQ with the date/version of the ToS that were accepted is sufficient for the latter.

  210. 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

  211. Ge0rG

    But "here is a well defined URL" doesn't let the server check whether the client supports showing ToS.

  212. 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.

  213. SamWhited

    If so, maybe it makes more sense as an extension to https://xmpp.org/extensions/xep-0389.html

  214. Ge0rG

    SamWhited: except when the ToS change.

  215. SamWhited

    Ge0rG: then you send them a message saying the TOS changed (just like websites do with email).

  216. SamWhited

    Or also make it a part of sasl2; there may be some room to make the challenges overlap.

  217. 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

  218. Zash

    Ge0rG, they will notice if they are offline a while

  219. SamWhited

    Isn't that still a problem with the proposal as it stands right now?

  220. 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?

  221. Zash

    Buttons-in-messages!

  222. Zash

    The Slack thing

  223. Ge0rG

    messages-in-buttons

  224. Ge0rG

    buttons-in-messages-in-buttons.

  225. Ge0rG

    SamWhited: I never claimed the current proposal is perfect. I'm just trying to define the most probable use case.

  226. 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

  227. Zash

    Perfect vs good -- FIGHT!

  228. SamWhited

    I think I'm just not sure what the problem is you're finding with it.

  229. Ge0rG

    with the current xep?

  230. 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.

  231. Ge0rG

    I didn't even point out any issues in the current XEP.

  232. SamWhited

    > The problem, again, is that with…

  233. SamWhited

    I'm just trying to understand if you're for or against the general idea, or the specific implementation, or what

  234. Ge0rG

    I'm for the general idea and not against the specific implementation

  235. Zash

    Maybe write all this down and post to standards@?

  236. Ge0rG

    I'm against the idea of just defining a well-known ToS URI and consider the provlem solved

  237. 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.

  238. Kev

    Ge0rG: I don't think *anyone* is for just having a .well-known and leaving it at that.

  239. SamWhited

    Honestly, I'm not against that.

  240. Kev

    If I gave the impression that I'm arguing for that I've grossly misreprented myself.

  241. SamWhited

    I'm not sure that it's my preferred method, but it does seem good enough.

  242. Zash

    As optional discovery method, maybe.

  243. 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.

  244. Zash

    But ugh, .well-known is meh :(

  245. Kev

    Or before resource binding, or whatever.

  246. 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.

  247. Ge0rG

    Kev: no, you were not the one. But there was a claim in the room that this suggestion was made by SamWhited

  248. Ge0rG

    Anyway, the discussion should be moved to standards@

  249. Zash

    +1

  250. SamWhited

    Kev: yah, fair, I guess we'd need some sort of notification to the server too

  251. Kev

    Ge0rG: Probably true.

  252. Kev bimbles AFK again.