XMPP Council - 2018-06-07

you know that I’m not fond of Ephemeral messages, but voting on it based on "it is NTP over XMPP" was incorrect I think. I was unable to find any NTPy thing in there, and the person who suggested that on the ML backed out of that claim.

also, I’d like to see reasons for the other -1s

Well, it's synchronizing timers and things. I'm basically not convinced of the security guarantees it's possible to offer around ephemeral messaging in general, and this seemed a particularly poor (and over complicated) rendition.

it’s not really synchronizing timers. all it does is saying "hey, your client should keep this message for at most N seconds"

there’s no synchronization going on

There's synchronisation of what you want the timers to be.

There isn't synchronisation of the time.

At least, given my reading.

But given that I found it very hard to read and extract what it intended people to do, I think that's a fair reason to reject it at the moment.

I disagree. The ability to extract the intent from the text is (in this case, I think) mostly matter of language and structure, and thus editorial. That should not be reason to reject it from going to Experimental.

(as much as I dislike the thing)

what jonasw said

I'm happy for an Editor to try to clear it up so that it's possible to read it sensibly, but as things stand I can't judge the XEP properly because I can't understand what it's trying to do properly.

so we’re going to reject this based on lack of manpower in the editor team, essentially? ;-)

I'm fairly sure that once it's clear what it's trying to do it'll be clear that it would be rejected for technical reasons.

So no, not really.

meh

From what I can tell, it's got this overcomplicated and underspecified synchronisation protocol for the expiry values, which seems out of place here.

As well as having this weird overlap between "This isn't for security, it's just for hinting" and "Here's all this extra work we're doing to try to guarantee security".

i see if i can find some time next week to come up with a protoxep that’s just the hint

this might offend the authors of that XEP

different question: would adding a note which hints to how things were done in the past (clearly marked up as "note" and "things in the past, but still around in some implementations") be editorial?

I’m "asking for a friend" who wants to add such a note to XEP-0045.

"It depends" is I think the answer.

I'd normally expect editorial changes in a Draft XEP to be typos and grammar corrections and things.

okay

gonna make a proper PR instead

there you go: https://github.com/xsf/xeps/pull/664

jonasw, You can't possibly be arguing that a XEP that's too badly written for council to understand should be accepted, can you?

Dave, when you put it that way it sounds horrible.

I don’t think though that it’s impossible to understand and that it can be fixed

So you're agreeing it can't be fixed, then? ;-)

argh

lanugage is hard

it can be fixed I mean

^^ irony.

yeah

The thing is, I don't believe one can design something that gives a message an expiry for security reasons in an open interoperable way. To get those guarantees, you need restrictions on the server and clients that are unprovable.

yes

but isn’t it worthwhile to have a common way to do this, even if it only makes sense in specialised deployments?

that would reduce the setup/development cost for those deployments.

Maybe, yes, but I think most of what's in the XEP is trying and failing to get security guarantees it can't achieve.

Dave: but arguably it is still valuable to have it standardized and then get library support so people who are using xmpp in closed environments (which I guess is the majority of people) have working solution ready

Yes.

I live in "specialised deployments", so I appreciate the sentiment. We hgave XEPs for adding classifications etc to messaging, for example. I'm all in favour of that. But those cases still provide guarantees outside of those environments. I'd be worried about the implication, so I'd want - from the outset - a clear scope on such a XEP.

But I'm not convinced that /this/ document is the way we would choose to standardise it for closed environments either.

Kev, +1 there.

Kev: no it's not

okay fine

now I wish those arguments make it into the council minutes

because having "it does NTP" as rejection reason there isn’t great

also i think one has to use signal to understand what a timer setting update is

because i dont

i mean i get that you annotate each message with a burner. but why do you need to send updates?

and what does it update?

the update is intended to make sure that the other side will use the new timer value on their next message

i.e.: A and B have agreed on timer value X A wants to use timer value Y, so sends timer update B sends their next message with timer value Y

FWIW I assumed timer updates to sync all devices a a user

ah, other devices of the same user, too

ok. a) weirdly i have never been requested to implement this feature b) arguably it should use different syntax then

is this only signal that does this? where my contact can dictate the timeout message?

I really wonder what type of people use this feature.

(well, except people who really, truely need things like that)

that seems a bit dangerous. so if i'm just in the process of sending a password or other delicate information my contact increases the time out from 60s to 5 years

good point

But this is not a security feature after all so I shouldn't really on this to hide a password right. Or is it still in the context of closed environments

I think the latter, pep.

That's the confusion. It's both trying not to be a security document, and also trying to be a security document.

no it’s a just a hint; so in case of passwords it's like here i'm sending you information which you should copy paste into your password manager and then delete from the devices history

and arguably it is doing that job

(speaking about burner messages in general now. not that particular xep)

daniel, burner messages as in "marking messages as [sensitive/private]"?

no burner messages as in 'hey it's a good idea to delete that message after you mentally or (otherwise) processed that information

a friendly reminder between friends

k

a friendly reminder between friends is also what i'm going to call the XEP

so there wont be any confusion

err, s/really/rely in a previous sentence

pep., Marking messages as sensitive/private is already covered by XEP-0258, incidentally.

I see