XMPP Council - 2017-10-11

Hi, I’m ill today so I won’t be here, good night. \o_

get well

hi

1) Roll call

Here

Hi

Link Mauve is excused as he's ill

have pinged dave in another channel

2) Minute taker

I can take minutes if there's no other volunteer

Please do. I'm traveling. Will do the minutes when I get back

alright

3) General reminder to vote on things, see pending votes column in trello https://trello.com/b/ww7zWMlI/xmpp-council-agenda

Jingle Encrypted Transports was apparently already published, but it's in that column

as was the color one.

Maybe Because the two weeks ran out?

Could be, I'm not actually sure which is wrong.

I don't think I voted on either. But I'm fine with it

yeah

4) Vote on advancing XEP-0387: XMPP Compliance Suites 2017

to Draft that is

I'm +1

+1

As the author I'm +0

alright. I suppose the rest will vote on list

5) Consider deprecation of Message Archiving ( https://xmpp.org/extensions/xep-0136.html )

I don't think that's in LC, is it? I don't remember seeing an LC recently, at least.

(compliance)

Mea culpa, meeting was overrunning and I didn't notice the time.

oops, yes, that was supposed to be for issuing a LC, not for advancing to draft

I figured as much

yeah

I was just coming to that conclusion. I'm fine for a last call.

LC for advancing it to Draft

SamWhited, why do you want to deprecate XEP-136?

RE Message Archiving: we've discussed this before, but I'd like to complain about it again. I was having a conversation with someone the other day that was implementing a server and they said something about having trouble with message archiving. I mentioned that most people seem to use MAM now and that they should probably do that instead and got the usual "but archiving is the recommended one, why would I do MAM?"

I think we should advance mam

Before we deprecate something else

SamWhited, I agree with the sentiment, but let's LC MAM first.

I'm entirely with you on the confusion problem

I think we either need to advance MAM and deprecate archiving, or if that's not ready we need to go ahead and deprecate archiving to prevent confusion and just only have an experimental history XEP.

yeah...I'd prefer advancing MAM first too

Since I've heard that "more work on MAM is coming soon" for at least a year, I'm not sure that it's ready to advance, but I would be all for issuing a LC and finding out.

I don't think we should deprecate before there is something else

I don't like deprecating in favour of something with lower advancement, but in this case I think the case is fairly compelling.

I disagree, I think we should absolutely deprecate if the community has standardized on something else. Even if that thing is experimental, it can still be the recommendation of this council.

SamWhited, Again, I agree with the sentiment, but I'd want to try pretty hard to nail '313 before deprecating without a replacement.

It's not like there's nothing else, just that the something else isn't Draft.

Whether we continue tweaking MAM or not, we know it's already vastly better than 136.

But I do agree that issuign a LC for MAM seems like a reasonable step, maybe I'm wrong about it needing more work.

does the Council want to encourage 136 implementations until MAM is finished?

Ge0rG: Hopefully not :)

Though I admit that the mam situation is a bit problematic. (lots of people use it but it's not really being worked on)

I hope not too

But we should fix that situation

yeah

Kev: in that case deprecating it now might be good?

Ge0rG, I take your point, but I would prefer a push on MAM *first*. If that doesn't work, let's revisit.

That is a compromise I can live with. In that case, I would like us to vote on a LC for MAM if possible.

I can probably arrange for a 313 author to request an LC if you want ...

This is the second or third time I've run into this specific XEP as a source of confusion, so I'm rather eager to find a solution

Or we can just issue one, no?

SamWhited: It was a flippancy, Matt and I are the authors.

Kev, Are you so doing? I think you need to ask an Editor, if you can find one...

SamWhited: does that work without the author requesting it?

Or is that a good idea without the author requesting it

daniel: It seems like a good way to encourage authors to submit the changes they've said they have almost ready for a year or more :)

I don't think Council needs the author to request it, although doing so when the author thinks it isn't ready might be a poor idea.

Anyway, issue the LC. No harm will come, as long as you don't then advance it prematurely :)

Let issue a LC. Maybe that encourages some discussion. Or the author to submit more changes and thus cancel lc

(Or issue the vote for an LC, as clearly I wouldn't tell Council how to vote)

Kev: if 136 is not an alternative to 313, deprecating 136 is independent of pushing forward 313, right?

sure...fine with issuing a LC

Thanks all. +1 to LC from me (obviously)

Ge0rG: I'm not Council, and Council don't want to deprecate 136 until 313 is LCd, so ... path of least resistance.

+1 for the LC

I would be happy to vote on an LC for 313 now. (And will vote for, FWIW).

Oh. So yeah, -1.

Argh.

+1. I meant +1.

ok..to make it clear in the history let's start fresh

6) Vote on issuing a LC on MAM

+1

+1

+1

+1

thanks

I'll add a card; thanks all.

7) Deprecate XHTML-IM

Lol

Link Mauve loves that xep

Where did that one spring from?

SamWhited

he wants us to discuss this yearly

:)

Oh. Has it been discussed on the list yearly, too?

I think that needs list discussion

yeah

Even though I personally hate that xep and would like to deprecate it I think it does have a lot of fans

Yeah. Last time it was discussed on the list was back in December.

Okay, back to this

I love XHTML-IM.

Or we should maybe do some 'markup in im' xep

Similar to the MAM thing, I was playing around with another web client a few days ago and found, yet again, an implementation of XHTML-IM that simply dumped HTML into the DOM and made it trivial to implement XSS's

daniel, Down. Mark*down*.

Since markup seems to be what cool IMs do theses days

I have never found an XHTML-IM implementation that didn't have this issue (or rather, some didn't, but they did have it originally and it had been fixed)

*that *

Literally "never", that is not me making a grand statement for the purpose of making a point.

Big warning in <blink> and red letters at the top of the document?

I'm sure *someone* has done this right the first time, but it seems that the default is that the spec encourages people to do it wrong. By leaving it as a recommendation I think we are encouraging security issues.

SamWhited: yes I'm personally all in favor for the same arguments. I think we should even do the 'what ever is worse than deprecated'

SamWhited: all modern applications are full of security issues.

But it does need list discussion

Even if we're not comfortable deprecating Message Archiving until there is a replacement, I think this is a security problem and therefore should absolutely be obsoleted (not just deprecated) as soon as possible.

Especially if you want to get Link Mauve on board

yeah, SamWhited, do you mind writing a mail to standard about the plan of deprecating it and we'll see what comes out of that?

He *loves* xhtml

Sounds good, I'll write something up for the list.

ta

Thanks for humoring me.

7) Date of next

same time next week

Wfm

great

WFM

8) AOB

None from me

Just a heads-up that I'll be writing up Surevine's TOTP approach into a XEP or two shortly.

TOTP?

Excellent!

Tobias: time based multi-factor auth (Google Authenticator, Yubico Auth, etc.)

ahh

great

no other AOB

thanks everybody

I can't wait to see that; I'd love to be able to use my yubikey as a second factor in Conversations one of these days

I'd be happy with per-device passwords already.

I can’t believe people would simply dump an XHTML-IM tree in anything capable of doing something bad with that.

Ge0rG, That has to be included.

that makes me sad.

Ge0rG, Otherwise you end up having to hit the TOTP device every time you switch networks.

jonasw: people go for convenience first.

Ge0rG, insert rage here

dwd: right. There needs to be some sensible trade-off here.

yubikey might have some value there

but otherwise, all apps are on the phone

so to login to conversations you need your phone anyway, and you are back to 1 factor no?

moparisthebest: the trick is to have a _second_ phone for 2FA!

ah so user friendly Ge0rG :P

moparisthebest, You're right, but the 2FA control is on the account, so this is a generally recurring problem.

we really need some notion of device identity.

moparisthebest, I can recommend a watch for this, BTW. :-)

Ge0rG, you can already see your other online devices right?

moparisthebest: yes and no. Let me write a short mail to standards@.

I'm still undecided on the whole thing, I think it's fine for people that want it, I don't think I'd want it

I'm not positive it's that much better than just long random passwords for most threats

so you've got:

moparisthebest, No, it is.

1. password leaks, yahoo hacks, etc - long random unique per account password and 2fa protect you the same

2. NSA is after you - cracking long random password is harder than hacking your phone and stealing your 2fa stuff

3. Kidnapped - same

what am I missing? I guess if some random hacks your computer and not your phone? in which case 2fa is an advantage

The point is that they work together; 1. doesn't actually make sense, it's operating under the assumption that they are two orthogonal things that attempt to solve the same problems. You have to use both together, 2fa is not a replacement for long random unique-per-account passwords.

Same with two. The point is that they have to crack a long random password *and* steal your 2fa stuff. Doesn't matter which one is harder for any given actor.

but for #1 it doesn't make it any harder with 2fa

moparisthebest, Yes, it does.

#2 the NSA can just do both, *maybe* it makes it a bit harder, fair

and I mean who are we kidding, the NSA just hacks your server, it doesn't need your credentials, so that was a dumb example on my part :)

It does if your bank was storing your password in plain text. Or if it is random, long, and hard to break but your goal is to slow them down even further even if they do break it.

SamWhited, Or if you get phished.

banks are one of the few places I think 2fa makes sense

dwd: indeed

too bad none of them implement it :'(

It's also almost not worth using the NSA as an example. Most peoples threat model doesn't include a state level adversary.

yep I agree

ah yah, I missed your last statement on that.

moparisthebest, There *is* a problem in that many TOTP implementations store the TOTP secret in the clear, and that's bad. It's difficult (especially in XMPP) to do otherwise, though our implementation at least stores it encrypted in the database.

if you do, you should just stay off the internet really :)

I guess in my mind TOTP makes more sense for things you log into, do your business, and log out of

and less for something you plan on staying logged into forever

especially from your phone that doubles as your totp generator

moparisthebest, Sure, which is why any time you'd save your password in the client, you need a way to avoid the TOTP.

that sounds like a good system then dwd :)

moparisthebest, And amazing, we have already implemented most of it. Got to replace the crappy per-client password type thing with a better one I've designed, but it's certainly proved the concept.

moparisthebest, The really painful thing isn't merely using TOTP on the phone, BTW. The really painful thing is signing up to TOTP on the phone.

yea actually that would be a giant pain

back to Ge0rG 's 2 phone thing :)

moparisthebest, But yay, because I don't have a solution there at all.

what about 2 mirrors?

oh, front-facing camera and 1 mirror

problem solved!

moparisthebest, I suspect that trying to open a totp URI on Android might well actually do the right thing.

that's the way, if any totp apps support that

I find redhat's the best https://freeotp.github.io/

Minutes are out.

moparisthebest: https://mail.jabber.org/pipermail/standards/2017-October/033544.html btw

Wow deprecate xhtml-im. Didn't see that coming.

I try to keep you on your toes :)

People are dumb, sure, help them fix their client. Otherwise you can do whatever other markup you want with it. You want markdown, her xhtml-im! You want rST, use xhtml-im

use* dumb android