Link MauveHi, I’m ill today so I won’t be here, good night. \o_
Tobiasget well
ralphmhas joined
ralphmhas left
moparisthebesthas joined
danielhas left
ralphmhas left
Flowhas left
Flowhas joined
ralphmhas left
Tobiashi
Tobias1) Roll call
SamWhitedHere
danielHi
TobiasLink Mauve is excused as he's ill
Tobiashave pinged dave in another channel
Tobias2) Minute taker
TobiasI can take minutes if there's no other volunteer
danielPlease do. I'm traveling. Will do the minutes when I get back
Tobiasalright
Tobias3) General reminder to vote on things, see pending votes column in trello https://trello.com/b/ww7zWMlI/xmpp-council-agenda
Ge0rGhas joined
SamWhitedJingle Encrypted Transports was apparently already published, but it's in that column
SamWhitedas was the color one.
danielMaybe Because the two weeks ran out?
SamWhitedCould be, I'm not actually sure which is wrong.
danielI don't think I voted on either. But I'm fine with it
Tobiasyeah
Tobias4) Vote on advancing XEP-0387: XMPP Compliance Suites 2017
Tobiasto Draft that is
TobiasI'm +1
daniel+1
SamWhitedAs the author I'm +0
Tobiasalright. I suppose the rest will vote on list
ralphmhas left
dwdhas joined
Tobias5) Consider deprecation of Message Archiving ( https://xmpp.org/extensions/xep-0136.html )
KevI don't think that's in LC, is it? I don't remember seeing an LC recently, at least.
Kev(compliance)
dwdMea culpa, meeting was overrunning and I didn't notice the time.
SamWhitedoops, yes, that was supposed to be for issuing a LC, not for advancing to draft
danielI figured as much
Tobiasyeah
dwdI was just coming to that conclusion. I'm fine for a last call.
TobiasLC for advancing it to Draft
TobiasSamWhited, why do you want to deprecate XEP-136?
SamWhitedRE 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?"
danielI think we should advance mam
danielBefore we deprecate something else
dwdSamWhited, I agree with the sentiment, but let's LC MAM first.
danielI'm entirely with you on the confusion problem
SamWhitedI 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.
Tobiasyeah...I'd prefer advancing MAM first too
SamWhitedSince 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.
danielI don't think we should deprecate before there is something else
KevI don't like deprecating in favour of something with lower advancement, but in this case I think the case is fairly compelling.
SamWhitedI 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.
dwdSamWhited, Again, I agree with the sentiment, but I'd want to try pretty hard to nail '313 before deprecating without a replacement.
KevIt's not like there's nothing else, just that the something else isn't Draft.
KevWhether we continue tweaking MAM or not, we know it's already vastly better than 136.
SamWhitedBut I do agree that issuign a LC for MAM seems like a reasonable step, maybe I'm wrong about it needing more work.
Ge0rGdoes the Council want to encourage 136 implementations until MAM is finished?
KevGe0rG: Hopefully not :)
danielThough I admit that the mam situation is a bit problematic. (lots of people use it but it's not really being worked on)
SamWhitedI hope not too
danielBut we should fix that situation
Tobiasyeah
Ge0rGKev: in that case deprecating it now might be good?
dwdGe0rG, I take your point, but I would prefer a push on MAM *first*. If that doesn't work, let's revisit.
SamWhitedThat is a compromise I can live with. In that case, I would like us to vote on a LC for MAM if possible.
KevI can probably arrange for a 313 author to request an LC if you want ...
SamWhitedThis 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
SamWhitedOr we can just issue one, no?
KevSamWhited: It was a flippancy, Matt and I are the authors.
dwdKev, Are you so doing? I think you need to ask an Editor, if you can find one...
danielhas left
danielhas joined
danielSamWhited: does that work without the author requesting it?
danielOr is that a good idea without the author requesting it
SamWhiteddaniel: 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 :)
KevI 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.
KevAnyway, issue the LC. No harm will come, as long as you don't then advance it prematurely :)
danielLet issue a LC. Maybe that encourages some discussion. Or the author to submit more changes and thus cancel lc
Kev(Or issue the vote for an LC, as clearly I wouldn't tell Council how to vote)
Ge0rGKev: if 136 is not an alternative to 313, deprecating 136 is independent of pushing forward 313, right?
Tobiassure...fine with issuing a LC
SamWhitedThanks all. +1 to LC from me (obviously)
KevGe0rG: I'm not Council, and Council don't want to deprecate 136 until 313 is LCd, so ... path of least resistance.
daniel+1 for the LC
dwdI would be happy to vote on an LC for 313 now. (And will vote for, FWIW).
dwdOh. So yeah, -1.
dwdArgh.
dwd+1. I meant +1.
Tobiasok..to make it clear in the history let's start fresh
Tobias6) Vote on issuing a LC on MAM
Tobias+1
dwd+1
SamWhited+1
daniel+1
Tobiasthanks
SamWhitedI'll add a card; thanks all.
Tobias7) Deprecate XHTML-IM
danielLol
danielLink Mauve loves that xep
dwdWhere did that one spring from?
TobiasSamWhited
Tobiashe wants us to discuss this yearly
Tobias:)
dwdOh. Has it been discussed on the list yearly, too?
danielI think that needs list discussion
Tobiasyeah
danielEven though I personally hate that xep and would like to deprecate it I think it does have a lot of fans
dwdYeah. Last time it was discussed on the list was back in December.
SamWhitedOkay, back to this
Ge0rGI love XHTML-IM.
danielOr we should maybe do some 'markup in im' xep
SamWhitedSimilar 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
dwddaniel, Down. Mark*down*.
danielSince markup seems to be what cool IMs do theses days
SamWhitedI 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)
daniel*that *
SamWhitedLiterally "never", that is not me making a grand statement for the purpose of making a point.
ZashBig warning in <blink> and red letters at the top of the document?
SamWhitedI'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.
danielSamWhited: yes I'm personally all in favor for the same arguments. I think we should even do the 'what ever is worse than deprecated'
Ge0rGSamWhited: all modern applications are full of security issues.
danielBut it does need list discussion
SamWhitedEven 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.
danielEspecially if you want to get Link Mauve on board
Tobiasyeah, SamWhited, do you mind writing a mail to standard about the plan of deprecating it and we'll see what comes out of that?
danielHe *loves* xhtml
SamWhitedSounds good, I'll write something up for the list.
Tobiasta
SamWhitedThanks for humoring me.
Tobias7) Date of next
Tobiassame time next week
danielWfm
Tobiasgreat
SamWhitedWFM
Tobias8) AOB
danielNone from me
dwdJust a heads-up that I'll be writing up Surevine's TOTP approach into a XEP or two shortly.
TobiasTOTP?
SamWhitedExcellent!
SamWhitedTobias: time based multi-factor auth (Google Authenticator, Yubico Auth, etc.)
Tobiasahh
Tobiasgreat
Tobiasno other AOB
Tobiasbangs the gavel
Tobiasthanks everybody
SamWhitedI 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
Ge0rGI'd be happy with per-device passwords already.
jonaswI can’t believe people would simply dump an XHTML-IM tree in anything capable of doing something bad with that.
dwdGe0rG, That has to be included.
jonaswthat makes me sad.
dwdGe0rG, Otherwise you end up having to hit the TOTP device every time you switch networks.
Ge0rGjonasw: people go for convenience first.
jonaswGe0rG, insert rage here
Ge0rGdwd: right. There needs to be some sensible trade-off here.
danielhas left
danielhas joined
Flowhas left
Flowhas joined
danielhas left
moparisthebestyubikey might have some value there
moparisthebestbut otherwise, all apps are on the phone
moparisthebestso to login to conversations you need your phone anyway, and you are back to 1 factor no?
Ge0rGmoparisthebest: the trick is to have a _second_ phone for 2FA!
jerehas joined
moparisthebestah so user friendly Ge0rG :P
dwdmoparisthebest, You're right, but the 2FA control is on the account, so this is a generally recurring problem.
Ge0rGwe really need some notion of device identity.
dwdmoparisthebest, I can recommend a watch for this, BTW. :-)
moparisthebestGe0rG, you can already see your other online devices right?
Ge0rGmoparisthebest: yes and no. Let me write a short mail to standards@.
moparisthebestI'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
moparisthebestI'm not positive it's that much better than just long random passwords for most threats
moparisthebestso you've got:
dwdmoparisthebest, No, it is.
moparisthebest1. password leaks, yahoo hacks, etc - long random unique per account password and 2fa protect you the same
moparisthebest2. NSA is after you - cracking long random password is harder than hacking your phone and stealing your 2fa stuff
moparisthebest3. Kidnapped - same
moparisthebestwhat am I missing? I guess if some random hacks your computer and not your phone? in which case 2fa is an advantage
SamWhitedThe 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.
SamWhitedSame 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.
moparisthebestbut for #1 it doesn't make it any harder with 2fa
dwdmoparisthebest, Yes, it does.
moparisthebest#2 the NSA can just do both, *maybe* it makes it a bit harder, fair
moparisthebestand 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 :)
SamWhitedIt 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.
dwdSamWhited, Or if you get phished.
moparisthebestbanks are one of the few places I think 2fa makes sense
SamWhiteddwd: indeed
moparisthebesttoo bad none of them implement it :'(
SamWhitedIt's also almost not worth using the NSA as an example. Most peoples threat model doesn't include a state level adversary.
moparisthebestyep I agree
SamWhitedah yah, I missed your last statement on that.
dwdmoparisthebest, 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.
moparisthebestif you do, you should just stay off the internet really :)
moparisthebestI guess in my mind TOTP makes more sense for things you log into, do your business, and log out of
moparisthebestand less for something you plan on staying logged into forever
moparisthebestespecially from your phone that doubles as your totp generator
dwdmoparisthebest, Sure, which is why any time you'd save your password in the client, you need a way to avoid the TOTP.
moparisthebestthat sounds like a good system then dwd :)
dwdmoparisthebest, 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.
dwdmoparisthebest, 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.
moparisthebestyea actually that would be a giant pain
moparisthebestback to Ge0rG 's 2 phone thing :)
dwdmoparisthebest, But yay, because I don't have a solution there at all.
moparisthebestwhat about 2 mirrors?
moparisthebestoh, front-facing camera and 1 mirror
moparisthebestproblem solved!
dwdmoparisthebest, I suspect that trying to open a totp URI on Android might well actually do the right thing.
moparisthebestthat's the way, if any totp apps support that
moparisthebestI find redhat's the best https://freeotp.github.io/
pep.Wow deprecate xhtml-im. Didn't see that coming.
SamWhitedI try to keep you on your toes :)
pep.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
XMPP Council - 2017-10-11