XMPP Council - 2018-05-30

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

What ever people feel is more appropriate

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

Motivation?

Or, elaboration maybe?

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.

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

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

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

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

it MAY do that if it needs to

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

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)

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.

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

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

Kev, as it stands (minus the "I am tos" flag in the initial request), it /does/ work as Ad-Hoc flow, doesn’t it?

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

And that you're doing it before authentication.

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

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

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

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.

Yes

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

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

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

'Tis time, 'tis time.

1) Roll call

hi

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

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

I'm here.

SamWhited?

Maybe not.

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

Yes.

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

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

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

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

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

Ge0rG: What is that in terms of a position?

+1

4) Date of next SBTSBC?

Wow, that was quick.

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

5) AOB?

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

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

yes i would like to continue with http upload

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

either make another last call

or just vote on it

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

*nods* I'll be on list anyways

there is a small PR pending

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

I'm still not lucky about the custom headers.

but my lack of luckiness won't be progress blocking

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

so yeah i'll just bring it up next week

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

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

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

if council is ok with that

Ok, cool.

AOAOB?

none from me

Thanks all.

Thanks Kev, thanks all

Thanks Tedd.

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

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

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

Zash, but which would make you cry harder

> 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

Ge0rG, like what?

(more markup I mean)

moparisthebest: like HTML.

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

daniel: but not always on XMPP_DOMAIN

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.

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

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

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

but now you gotta worry about javascript and XSS

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

Ge0rG: Pretty much.

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

IBR is basically already replaced with a web form?

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

Ge0rG: More or less, I think.

Because UX doesn't matter.

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

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

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

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

At registration would be nicest, no?

Zash: how do you change the ToS then?

Or you can send a MOTD-like message

Ge0rG: It is, kinda.

MOTD is as illusive as "at login"

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

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

moparisthebest: check it for what?

whatever it wants, whenever it wants :)

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?

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

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

but they can if they wish

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

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

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

Kev, what is out of band?

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

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

Registration.

moparisthebest: what's complicated

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

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

moparisthebest: and doesn't fulfill the required needs.

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

ha-ha

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

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

:)

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

moparisthebest, applies in both directions

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

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

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

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

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

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

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

it can't no matter what

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

yep

let's exclude malicious clients for a moment.

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

excluding malicious clients then it just does

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

Uhm. No.

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

You'd need to require auth on your webpage

explain how an in-band protocol is different 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=

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.

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

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

I believe both are still true

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

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

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

Kev, I can go along with that.

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

o7

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

and 0 guarantee any of that happened

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

I don't think so?

Well then

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.

yea that's not bad

at least you know the client actually got them

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.

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

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

thanks GDPR!

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

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.

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

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

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

small world :)

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

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

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

it does rule out network errors Ge0rG mentioned earlier I guess

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.

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

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

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

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.

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

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

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

SamWhited: no!

Ge0rG: what do you mean?

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

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

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

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

Which the client could just submit.

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

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.

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

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

Right.

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

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"

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

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.

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

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

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

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.

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

SamWhited: except when the ToS change.

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

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

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

Ge0rG, they will notice if they are offline a while

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

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?

Buttons-in-messages!

The Slack thing

messages-in-buttons

buttons-in-messages-in-buttons.

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

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

Perfect vs good -- FIGHT!

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

with the current xep?

Yes, because I never suggested that you said the current proposal was perfect, so I have no idea what you're even replying to.

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

> The problem, again, is that with…

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

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

Maybe write all this down and post to standards@?

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

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.

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

Honestly, I'm not against that.

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

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

As optional discovery method, maybe.

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.

But ugh, .well-known is meh :(

Or before resource binding, or whatever.

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.

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

Anyway, the discussion should be moved to standards@

+1

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

Ge0rG: Probably true.