danielI 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
danielWhat ever people feel is more appropriate
KevPre-empting the meeting somewhat, but of TOS I'll say this in advance: It seems like an abuse of adhocs.
ZashOr, elaboration maybe?
KevA 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.
jonaswKev, I can’t defend my case at the moment, I’m at work and about to migrate to commuting, unfortunately
KevSo if you don't want any of the features of adhocs, putting it in an adhoc seems unhelpful.
KevYou could have all the same properties in its own namespace for simpler implementation and less confusion.
jonaswthe tos server does not have to reject everyone without the tos flag
jonaswit MAY do that if it needs to
jonaswbut 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
jonaswand 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)
samI'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.
KevI'm not intending to block it going to Experimental like this, but I would object to Draft like this.
KevThis really feels like forcing a square adhoc into a round hole.
jonaswKev, as it stands (minus the "I am tos" flag in the initial request), it /does/ work as Ad-Hoc flow, doesn’t it?
KevOther than the extra payload? Possibly. But that "I am TOS" flag changes things.
KevAnd that you're doing it before authentication.
KevWhen iqs don't really work properly, because you don't have a bound resource, etc.
jonaswKev, the extra payload is ok as per my reading of '50
jonaswwe have precedence for pre-bind IQs actually (bind itself being one)
KevThe 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.
KevOr pre-stream-is-running, I guess, as it's not pre-auth.
ZashWe 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
ZashNow it's a stream element that just happens to be in the jabber:client namespace
Kev'Tis time, 'tis time.
Kev1) Roll call
KevSamWhited is expecting to be here. I don't remember abotu Ge0rG.
Ge0rGI've delayed my trip home despite an empty phone battery to until after the meeting
Kev2) Isn't it nice that Tedd Sterr does the minutes?
Kev3) Proposed XMPP Extension: Terms of Services
Title: Terms of Services
This specification provides an in-band, unauthenticated way to request
the Terms of Service of an XMPP service.
KevI don't like this much, but am not blocking it.
danielsame. but i'll give me official vote on list
Ge0rGI think it's great to have a machine-readable way to link the ToS; not sure about the extended features
Kev(That 'not blocking' is +1 for me, BTW, although I wouldn't expect it to go to Draft like this)
KevGe0rG: What is that in terms of a position?
Kev4) Date of next
Ge0rGWow, that was quick.
KevI'll take that as a 'yes' :)
Ge0rGI still can't guarantee my general availability for this time slot. It looks like it has mostly worked so far, so +1
SamWhitedSorry, I am here, now I'm not getting any notifications for this room
danielyes i would like to continue with http upload
KevSamWhited: Just the one item for you to vote on.
danieleither make another last call
danielor just vote on it
Kevdaniel: LCs are cheap, so shall we do that?
SamWhited*nods* I'll be on list anyways
danielthere is a small PR pending
Kev..so shall we do that after the small PR? :)
Ge0rGI'm still not lucky about the custom headers.
Ge0rGbut my lack of luckiness won't be progress blocking
danielyeah why note. i was hopeing to speed things up; but why bother; it has been months anyway
danielso yeah i'll just bring it up next week
Kevdaniel: I think that's a reason for making a clean cut with a new LC, but can be talked out of it.
Kevdaniel: Or just ask the Editors to send an LC mail once your patch is merged?
daniel> : daniel: Or just ask the Editors to send an LC mail once your patch is merged?
yes that was the idea
danielif council is ok with that
danielnone from me
Kevgangs the bavel
Ge0rGThanks Kev, thanks all
moparisthebestso as SamWhited already said, why not just https://XMPP_DOMAIN/.well-known/xmpp-tos.txt ?
moparisthebestcertainly seems easier than hacking pre-auth support into servers and clients securely
Zashcries over mandatory records at domain apex
Ge0rG- because not every XMPP_DOMAIN is a web server
- because you usually want more markup than .txt
moparisthebestZash, but which would make you cry harder
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
moparisthebestGe0rG, like what?
moparisthebest(more markup I mean)
Ge0rGmoparisthebest: like HTML.
danielGe0rG: but the xep hosts the tos on http anyway, no?
Ge0rGdaniel: but not always on XMPP_DOMAIN
KevFWIW, 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.
Ge0rGSo now I need to setup a dedicated web server with a 30x
moparisthebestGe0rG, so https://XMPP_DOMAIN/.well-known/xmpp-tos.html then?
danielMost good xmpp do probably. Because of websocket bosh discovery and stuff
Ge0rGKev: the result of that would be replacing IBR with a web form?
KevGe0rG: Pretty much.
Ge0rGKev: which is... the current status quo?
moparisthebestIBR is basically already replaced with a web form?
KevThere are cases for autoregistration where inband might make sense, but mostly not for users' IM accounts, I think.
KevGe0rG: More or less, I think.
Ge0rGBecause UX doesn't matter.
ZashIBR can redirect to a web form, you can put the ToS there.
Ge0rGZash: can the web form than redirect back to a configured XMPP client?✎
KevI *do* think there's value in being able to provide a ToS banner of some sort at login, though.
Ge0rGZash: can the web form then redirect back to a configured XMPP client? ✏
Ge0rGKev: "at login" is illusive in times of always on and 0198
ZashAt registration would be nicest, no?
Ge0rGZash: how do you change the ToS then?
ZashOr you can send a MOTD-like message
KevGe0rG: It is, kinda.
Ge0rGMOTD is as illusive as "at login"
KevZash: Yes, but if that's out of band that's SEP.
moparisthebestor the client can just check the .well-known URL
Ge0rGmoparisthebest: check it for what?
moparisthebestwhatever it wants, whenever it wants :)
Ge0rGmoparisthebest: 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?
moparisthebestit can't, show it to the user, done
moparisthebestit's not like the user is going to read it anyway
moparisthebestbut they can if they wish
pep.Can we seriously stop requiring http every. fking. where. Re ToS
danielAnd then it's up the the admin to notify existing users via message
moparisthebestnope, it's already done, the battle is lost
ZashKev, what is out of band?
moparisthebestis it better to invent some new complicated thing to avoid using HTTP pep. ?
daniel> Can we seriously stop requiring http every. fking. where. Re ToS
pep.moparisthebest: what's complicated
pep.You ask for a document, the server gives it to you
moparisthebestpep., 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
Ge0rGmoparisthebest: and doesn't fulfill the required needs.
danielFun side note stateless let's do everything over http jmap just introduced websocket support because apparently http is f*ing slow
pep.When is the switch from TCP/XML to http/json planned for again
Zashpep., depends on how much you wanna listen to the matrix.org ppl?
moparisthebestyou know the saying, if all you have is a hammer, everything looks like a nail?
Zashmoparisthebest, applies in both directions
moparisthebestxmpp isn't the only tool, sometimes http is more appropriate, no reason it shouldn't be used in those places
Ge0rGmoparisthebest: please describe how you will implement mandatory consent and ToS changes with the HTTP scheme.
ZashI don't see why we shouldn't try to enable in-band pointing to a ToS.
KevZash: No, I don't think that's fine.
ZashThe pointer itself can be HTTP or whatever URI/URL you want
moparisthebestGe0rG, client fetches TOS before attempting to log in, refuses to log in unless user agrees?
Ge0rGmoparisthebest: how does the server know if the client actually checked that?
moparisthebestit can't no matter what
ZashHow does Let's Encrypt know anyone actually read their terms?
Ge0rGlet's exclude malicious clients for a moment.
Ge0rGHow does a server know that the client actually showed the ToS to the user?
moparisthebestexcluding malicious clients then it just does
moparisthebestit just assumes they did, it's the best you can do
ZashKev, I don't think I can't not follow all these double negatives.
pep.You'd need to require auth on your webpage
moparisthebestexplain how an in-band protocol is different Ge0rG ?
Ge0rGYou 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=
KevZash: 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.
Ge0rGKev: you might want to argue your points on standards@
moparisthebestGe0rG, and how is that different with an in-band approach?
Kevmoparisthebest: Inband you know that the client requested it because it did so over the current stream.
Ge0rGthe inband approach also has a (theoretically) nice way to enforce tos-before-login.
ZashKev, I can go along with that.
Ge0rGso it's not "we locked you out because you didn't consent in time. Good luck without us now"
Ge0rGgoes OOB now. seeya
moparisthebestin both cases you have the client telling you the user agreed to the TOS
moparisthebestand 0 guarantee any of that happened
ZashDoes it matter if "the client" is a browser or an xmpp client?
moparisthebestI don't think so?
ZashIIRC, 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.
moparisthebestyea that's not bad
moparisthebestat least you know the client actually got them
KevIt 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.
moparisthebestmaybe the server should just give the user a quiz about the TOS
moparisthebestlike 10 random questions from a pool of 50, and they need to get 80% correct to be able to log in
ZashBut ACME is IETF-approved prior art, which is why I'm thinking that following that might be sensible.
SamWhitedYou 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.
SamWhitedI seriously doubt if it matters if you confirm that the client downloaded it vs. it downloaded it and hashed it.
moparisthebestI 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 :)
Kevmoparisthebest: I have implemented exactly such a thing for some obscure place (not work related, and not GDPR-related)
moparisthebestsmall world :)
SamWhited(the hash matters in ACME because it makes the server stateless and means you don't have to have a cookie lying about)
KevI'm not sure you do anyway, do you?
KevOr, 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".
moparisthebestit does rule out network errors Ge0rG mentioned earlier I guess
SamWhitedYah, 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.
SamWhitedMaking 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.)
SamWhitedOr at the very least gives us more confidence that a bug didn't cause it to skip the TOS request.
KevIt suggests bad caching or whatever isn't at play, yeah.
Ge0rGYou 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.
danielGe0rG: so as a server operator you want to seriously exclude any client that doesn't accept the tos?
danielOr in other words. Every. Single. Client.?
SamWhitedIf you use HTTP you have to do a checksum like Zash said if you want that.
SamWhitedGe0rG: what do you mean?
Ge0rGSamWhited: 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
Ge0rGSamWhited: obvioulsy a malicious client can circumvent any kind of protocol.
SamWhitedGe0rG: You can't get that no matter what, and you don't need it for GDPR.
Ge0rGSamWhited: I can have a data-form with a checkbox
SamWhitedWhich the client could just submit.
Ge0rGGe0rG> SamWhited: obvioulsy a malicious client can circumvent any kind of protocol.
SamWhitedIt 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.
SamWhitedRight, so there's not much point to checking.
ZashYou can do things in good faith and hope for the best
SamWhitedAt best you can make sure the client actually fetched it, then it's their problem if they don't display it.
Ge0rGSamWhited: 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"
SamWhitedI 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).
Zashdaniel, 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.
Ge0rGAn IQ with the date/version of the ToS that were accepted is sufficient for the latter.
Ge0rGAnd 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
Ge0rGBut "here is a well defined URL" doesn't let the server check whether the client supports showing ToS.
SamWhitedThis 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.
SamWhitedIf so, maybe it makes more sense as an extension to https://xmpp.org/extensions/xep-0389.html
Ge0rGSamWhited: except when the ToS change.
SamWhitedGe0rG: then you send them a message saying the TOS changed (just like websites do with email).
SamWhitedOr also make it a part of sasl2; there may be some room to make the challenges overlap.
Ge0rGThe problem, again, is that with always-on devices the user isn't guaranteed to be in front of the device when the login happens
ZashGe0rG, they will notice if they are offline a while
SamWhitedIsn't that still a problem with the proposal as it stands right now?
SamWhitedAlso, 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?
ZashThe Slack thing
Ge0rGSamWhited: I never claimed the current proposal is perfect. I'm just trying to define the most probable use case.
Ge0rGObviously, 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
ZashPerfect vs good -- FIGHT!
SamWhitedI think I'm just not sure what the problem is you're finding with it.
Ge0rGwith the current xep?
SamWhitedYes, because I never suggested that you said the current proposal was perfect, so I have no idea what you're even replying to.
Ge0rGI didn't even point out any issues in the current XEP.
SamWhited> The problem, again, is that with…
SamWhitedI'm just trying to understand if you're for or against the general idea, or the specific implementation, or what
Ge0rGI'm for the general idea and not against the specific implementation
ZashMaybe write all this down and post to standards@?
Ge0rGI'm against the idea of just defining a well-known ToS URI and consider the provlem solved
SamWhitedThat 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.
KevGe0rG: I don't think *anyone* is for just having a .well-known and leaving it at that.
SamWhitedHonestly, I'm not against that.
KevIf I gave the impression that I'm arguing for that I've grossly misreprented myself.
SamWhitedI'm not sure that it's my preferred method, but it does seem good enough.
ZashAs optional discovery method, maybe.
KevBut 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.
ZashBut ugh, .well-known is meh :(
KevOr before resource binding, or whatever.
KevSamWhited: 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.
Ge0rGKev: no, you were not the one. But there was a claim in the room that this suggestion was made by SamWhited
Ge0rGAnyway, the discussion should be moved to standards@
SamWhitedKev: yah, fair, I guess we'd need some sort of notification to the server too