jonaswmoparisthebest, a change from SHOULD to MAY is a technical change. However, given that there has no advancement been made to the XEP yet, that’ll be fine
jonaswI guess this is what the CFE is for
jubalhhas joined
stefandxmhas left
Guushas left
uchas joined
danielhas left
KevWell, it's for Council to decide whether it's fine or not, no?
jonaswKev, yes
stefandxmhas joined
jonaswyou’re right about that
jonaswwhat I meant is: it is not absolutely not fine
jonaswand also council members brought that change I assume moparisthebest will do up in the discussion, so ... ;-)
danielhas joined
Guushas left
goffihas joined
intosihas joined
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
Tobiashas left
danielhas left
danielhas joined
GuusKev (others): please elevate me from member to owner on our github repo, add me to the team on dockerhub, and provide me with the twitter credentials. It'd be good to have someone else be available to help people out with requests in order to speed up things (and as I'm currently the requestee most of the time, who's also in iteam, I'd be a logical candidate).
Guushas left
KevWhat's your name on the docker hub?
edhelashas left
KevYou've got ownership of the github org now, I'll sort out docker at some point later when I know your account, and Twitter I need to sort out password changing and distribution of the password.
KevPlease don't change things without discussion.
edhelashas joined
GuusThanks, I won't
GuusI'm guusdk on dockerhub
uchas joined
danielhas left
danielhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
Guushas left
Ge0rGhas left
Kevhas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
jcbrandhas joined
nycohas left
sezuanhas left
sonnyhas joined
Ge0rGhas left
jcbrandhas left
zinidhas left
zinidhas left
zinidhas joined
uchas joined
winfriedhas joined
winfriedhas left
Ge0rGhas left
jubalhhas joined
Ge0rGhas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
winfriedhas left
Martinhas joined
Ge0rGhas left
uchas joined
tim@boese-ban.dehas joined
Ge0rGhas left
winfriedhas left
Zashhas left
winfriedhas joined
jubalhhas joined
Ge0rGhas left
zinidhas left
zinidhas left
Ge0rGhas left
Martinhas left
Guushas left
Ge0rGhas left
Martinhas joined
Ge0rGhas left
lumihas joined
andrey.ghas left
sonnyhas left
andrey.ghas joined
lovetoxhas joined
andrey.ghas joined
stefandxmhas left
Ge0rGhas left
lovetoxhas left
lovetoxhas joined
andrey.ghas joined
mimi89999has joined
andrey.ghas joined
Guuswhen establishing (direct) ssl, is more than one socket connection involved (is a connection re-established?)
zinidhas left
matlaghas left
matlaghas joined
andrey.ghas joined
zinidhas left
Alexhas joined
andrey.ghas joined
jonaswGuus, no
Guushas left
jonaswyou start TLS over the existing TCP connection
stefandxmhas joined
ZashJust like STARTTLS, except without the negotiation
Guussounds like it's time to shout at apache mina again then
Link MauveZash, s/without \(.*\)/with \1 done by the TLS library instead of by the XMPP one/
ZashThat hurt my head
lovetoxhas left
ZashDepends on how your libraries work I guess
stefandxmhas left
lumihas left
mimi89999has joined
Ge0rGhas left
Kevhas left
Guushas left
Zashhas left
Zashhas left
Zashhas joined
winfriedhas joined
winfriedhas joined
Guushas left
Ge0rGIt's a great way to shave off some round-trips, though
Guushas left
jubalhhas joined
jubalhhas left
Alexhas left
Ge0rGKev: "undesirable"... I love your choice of words!
Alexhas joined
jonaswundesirable in that context might be the XMPP-related understatement of the decade :-)
Ge0rGKev: killing GC1 was brought up to the council, but without a well worded motivation. I also agree we need to kill it, but it is to some degree a better resync mechanism than nothing at all.
KevIt is definitely better than nothing at all.
KevI've long held that opinion. But if we're providing something better now, maybe it can retire.
Ge0rGKev: except when you end up seeing ghosts in the MUC.
zinidhas left
KevYou see ghosts in the MUC with or without gc1 joins, without another mechanism.
KevWithout gc1, everyone you see (as a client) is a ghost :)
lumihas joined
Ge0rGKev: yes, but then you realize that as soon as you send a message.
KevThat is true.
Ge0rGKev: my point is that it's not always better than nothing.
ZashIf we get rid of gc1, isn't a normal presence the same as <presence><I-expect-to-still-be-in-the-room/></p>
KevIf you're referring to (3), then no.
jonaswZash, yes, but we can’t simply get rid of GC1, can we?
ZashCan we?
Kevjonasw: Can't we? :)
jonaswKev, council was against it.
jonaswI mean, we can re-try, but ...
jonaswspeaking of council, still no (re-)applications?
KevCouncil may have been against it when there wasn't a better option, they may not be after this.
KevOnly Joe Demo, by the look of it.
KevI hear good things about that guy.
jonaswlike Boaty McBoatface?
Ge0rGAgain, I want to propose Boardy McBoardface for Council.
jonaswnot Council McCouncilface?
Ge0rGjonasw: no. C McC should apply for Board instead.
la|r|mahas joined
jonaswfor maximum confusion, I see
Ge0rGI wonder if I should apply for Council, and then try to aggressively push the XMPP 2.0 / Easy Jabber agenda.
Ge0rGhas left
Ge0rGKilling GC1.0 would be my major campain promise.
jonaswhm, one can’t really make promises, can one?
jonaswwhen running for council
zinidhas left
jonasw(well, one can... but in the end it all depends on who else gets elected. then again, that’s the same for all elections)
Guushas left
KevI kinda think that what xmpp2/easyjabber needs most, in some ways, is implementation and deployment experience.
andrey.ghas left
jonaswyou can’t really do implementation without some specification
KevOf course you can.
ZashJust type code into your thing!
KevYou try something and see if it works.
jonaswwell, you shouldn’t
jonaswhm
KevAlso, completely untrue.
ZashSo you are a specification before implementation person?
KevProtocol documents based on people actually trying things is a jolly good thing.
ZashSome are the other way around. Some think both at the same time!
jonaswyeah, I see where you’re coming from
KevEverything has its place. Except the things that don't.
jonaswI’m not necessarily, but Session 2.0 is a thing where many parties need to play together, so there needs some kind of coordination, that is, specification, on what the parties implement each
Kevjonasw: Nothing says that has to happen in advance.
jubalhhas joined
Ge0rGKev: I could implement Session 2.0, but then it would only work for IM.
Keve.g. if I had spare person-hours, I'd have something that worked implemented in M-Link and the Swifts, and we could use that experience to feed into the specs.
uchas joined
KevGe0rG: Sure. But 'try stuff and see if it works' doesn't mean 'specify what was implemented and treat it as set in stone because you coded some prototype'.
andrey.ghas joined
Guushas left
Ge0rGhas left
Ge0rGKev: I also need to read up what I have "proclaimed" in the last two years under the "MUC-subscription" label. I think it's all the same basic idea, and maybe I forgot something important in the last iteration
jonaswitym MAM-subcsription
Ge0rGjonasw: right. Sorry. I won't LMC that now.
KevGe0rG: I *think* the important thing there is simply that everything that's chat-related you want both in your archive and on all your devices.
KevSo all we need to do is achieve that :D
ZashSo how do we determine if a message is "chat-related"?
KevI did the hard work of coming up with the high-level direction. Someone else can work on the details.
Zashtype=chat would have been nice
Ge0rGKev: you are a genius! Why didn't anyone else think of that before? :D
Ge0rGZash: 0184 and CSNs happen to be type=random.
nycohas left
jonaswalso, what about type=normal? :)
ZashAren't those chat related?
Guushas left
Ge0rGZash: maybe they are.
jonaswthat certainly has messaging use-cases too, and wouldn’t you want to sync them, too?
mimi89999has joined
Ge0rGjonasw: chat is the new normal.
jonaswthat’s your opinio.n
jonasw;-)
Ge0rGjonasw: that's what implementations do
jonaswbecause no implemntation has a UI for type=normal
jonaswexcept pidgins "let’s show this in a separate window focus stealingly" counts as UI
Ge0rGjonasw: I think many client authors don't care about "normal" vs. "chat", and end up sending non-body messages with "normal"
Ge0rGjonasw: also guess which message type is mandated by [xep 0184]
jonasw"whatever works"?
ZashGe0rG: {}
Ge0rGZash: -ETOOMANYDIFFERENTBOTS
ZashBots bots bots
Ge0rGcan't we just have all bot react to all patterns, instead of putting the cognitive load onto people?
ZashWasn't both 184 and csn using the standard reply pattern? Ie same type
Ge0rG-xep standard reply pattern
BunnehGe0rG: XEP-0068: Field Standardization for Data Forms (Informational, Active, 2012-05-28)
See: https://xmpp.org/extensions/xep-0068.html
andrey.ghas joined
ZashCopy attributes, swap to/from. If it's an error, set type=error.
Ge0rGZash: There is no such primitive in the XMPP lib I'm using.
jonaswGe0rG, switch XMPP libs then!
Ge0rGhas left
jonaswZash, also, you shouldn’t be copying the @id for anything except IQ, I think
Ge0rGZash: I'm not even convinced this is a good thing, generally. Maybe type=headline would be more appropriate for ACKs and CSNs?
KevI think acks you probably want stored in your archive, while CSNs you certainly don't.
ZashKev: Are you sure?
Ge0rGRight. ACKs need to be archived.
KevActually, I'm fairly sure you want something more sophisticated than just putting acks in your archive, but I'm not sure how revolutionary I should be today.
jonaswKev, as much as possible, of course.
Ge0rGKev: it's all about synchronizing a chat database.
Ge0rGKev: yes please. Make the most revolutionary proposal you can imagine.
winfriedhas joined
KevHave your server handle your acks for you. Also have the server archive read receipt status for your messages.
KevHave the ability to collate messages that operate on each other in the archive, so they can be returned as state on the MAM results.
Ge0rGKev: I think MAM would be indeed a good place to send 0184 acks, from the bare JID
KevDelivered, Read, LMC. Store them, but on the message they affect, not on their own.
Ge0rGKev: that message collation would work much better if we had properly-generated UUIDs
Ge0rGDoes "unique" also mean that there should be only one UUID per message?
ZashKev: I object to anything that makes it impossible to do MAM in an append-only log store thing.
Ge0rGKev: BTW that almost sounds like a multi-table relational database
ZashI object to anything that requires a relational database.
Ge0rGZash: better apply for Council now, then
KevI think the most sensible way to implement MAM is with a database of some description. But clearly it's not needed.
Ge0rGKev: how would clients synchronize? Atomic replacement of [Message, Delivered, Read, [LMCs], [Reactions]] n-tuples? Or do we need a separate chronological history?
KevSynchronise in which sense?
Ge0rGThis is again the fully-synchronized fat client vs. load-on-demand thin client debate I think
KevPossibly.
Ge0rGFor load-on-demand it makes sense to initially query for n-tuples, and then to receive a stream of deltas.
Ge0rGFor fat clients it makes sense to receive a stream of stored deltas, followed by live deltas.
KevThat is possibly true.
Ge0rGNow this is another thing I had in MAM-sync: push of MAM-IDs for sent messages.
Ge0rGjonasw: I tried to bring that up a year ago or two, and there were very loud voices arguing against that, because of sysload
Yagizahas joined
ZashI think someone (mattj?) suggested a carbons extension/change where you'd get your own messages reflected back
jonaswwhat
Zashsyswhat
KevI'm not entirely convinced that just mirroring the entire (annotated) stanza back isn't sensible.
Ge0rGIf I were redoing XMPP, I'd glue together session, MAM ID reflection and 0198
lumihas left
Ge0rGKev: maybe except for https://xmpp.org/extensions/xep-0047.html#message
jonaswwhat’s session in this context?
Ge0rGjonasw: that thing you bind.
jonaswah
Ge0rGjonasw: what I mean is: have a separate session type (XMPP2, MAM-sub or whatever you name it), which replaces carbons and 0198 with a logic that feeds back MAM IDs for sent messages and either Carbons or direct messages of all incoming data
Ge0rGhas left
Ge0rGI'm not opposed to the Carbons wire format, just the current processing logic is insane.
jonaswsounds reasonable
jonaswstill possible to do that even without redoing xmpp
KevEverything's possible without redoing xmpp :)
Ge0rGjonasw: still doesn't solve the persistency/urgency problem.
jonaswGe0rG, that needs fixes to MAM, Carbons, CSI and Push. All of which aren’t final yet, right?
Ge0rGjonasw: are there any final XEPs at all? I thought Draft is the new Final.
jonaswXEP-0030 :)
jonasw(for example)
moparisthebestI'm pushing to make 368 final
moparisthebestbut also considering I nor any current editors have ever seen a move to final
moparisthebestno
valohas joined
jonaswmoparisthebest, no worries :)
jonaswjust prepare your PR and see what council says.
lumihas joined
moparisthebestyea I'm just agreeing with Ge0rG here, final isn't a thing, draft is final
danielhas left
danielhas joined
jerehas joined
danielhas left
danielhas joined
Ge0rGhas left
KevI think that might have something to do with our habit of getting something 'good enough' but not quite right, and so not being willing to advance it further.
Guushas left
danielhas left
danielhas joined
sonnyhas joined
Ge0rGhas left
lskdjfhas joined
la|r|mahas joined
uchas joined
uchas joined
winfriedhas joined
lumihas left
waqashas joined
Ge0rGhas left
Martinhas joined
Ge0rGhas left
Ge0rGhas joined
Wiktorhas joined
Wiktorhas left
Wiktorhas joined
winfriedhas joined
Flowhas joined
tuxhas joined
Wiktorhas joined
Wiktorhas left
Wiktorhas joined
Flowhas left
Flowhas joined
stefandxmhas left
Flowisn't the question what the benefit of final XEPs is, over draft XEPs?
Flowas far as I can tell, final only has disadvantages
jonaswFlow, what advantages does Draft have over Experimental? :)
Flowjonasw: another review round at least by the council and probably by the xmpp community
jonaswokay
jonaswthen final probably doesn’t bring you anything :)
Flowplus at least so und so many implementations IIRC
jonaswthat’s only with Final IIRC
Flowahh right
Ge0rGhas left
Flowok, so after reading xep1 once more and to sum up: final has the disadvantage that no namespace bumps can be made, which is probably not an issue (see ecaps2). And the advantage that feedback was given and there are multiple interoperable implementations required
Flow(I was thinking that this was for draft)
jubalhhas joined
la|r|mahas joined
lskdjfhas joined
Ge0rGhas left
danielhas left
danielhas joined
intosihas left
Martinhas left
stefandxmhas joined
jubalhhas left
jubalhhas joined
Martinhas joined
jubalhhas left
jubalhhas joined
danielhas left
Ge0rGThere is no technical difference between a namespace bump and a new namespace, so why are we forbidding them?
intosihas joined
stefandxmhas left
SamWhitedGe0rG: they are not treated differently, changing the namespace is forbidden in final.
Ge0rGSamWhited: yes, so we end up with a new XEP with a new namespace instead.
SamWhitedGe0rG: Yes, that's the point, after something has reached final if you want to replace it you need to create a new XEP.
Ge0rGhas left
Ge0rGSamWhited: yes, I'm merely questioning the wisdom of that
SamWhitedI don't even know where to begin with that… you want XEPs to never stabalize? We have enough problems with people not wanting to implement experimental XEPs because they're a moving target without saying that all XEPs have the potential to change and break compatibility and fragment the ecosystem at any time.
SamWhitedI'm all for going to final slowly, it's nice to have the flexibility to change things, but at some point when things are widely implemented we need to stop breaking compatibility and call it "good enough".
Flowhas left
stefandxmhas joined
Ge0rGhas left
Flowhas joined
danielhas joined
Guushas left
Flowhas left
lumihas joined
la|r|mahas joined
Guushas left
Ge0rGSamWhited: I'm just some random smartass, questioning everything. But I also wondered if other parts of our process might be improvable.
Ge0rGhas left
Ge0rGhas left
Guushas left
Ge0rGhas left
Guushas left
stefandxmhas left
savostinhas joined
nycohas left
Guushas left
matlaghas left
Martinhas left
Martinhas joined
matlaghas left
Guushas left
Martinhas left
matlaghas left
SamWhitedI definitely think there's room for improvement, but never stabalizing anything probably isn't it.
matlaghas left
Martinhas joined
danielhas left
mhterreshas joined
mhterreshas left
nycohas left
Ge0rGhas left
uchas joined
matlaghas left
waqashas left
Ge0rGhas left
Ge0rGhas left
jubalhhas joined
jerehas joined
jubalhhas joined
jerehas joined
jubalhhas left
waqashas joined
lumihas left
mimi89999has joined
Ge0rGhas left
Ge0rGhas left
sonnyhas left
sonnyhas joined
jjrhhas left
Ge0rGhas left
Yagizahas left
intosihas left
mimi89999has joined
emxphas joined
emxphas joined
jjrhhas left
mimi89999has joined
jjrhhas left
jjrhhas left
Martinhas left
Martinhas joined
nycohas left
sonnyhas left
sonnyhas joined
stefandxmhas joined
Valerianhas joined
winfriedhas joined
ralphmhas left
Valerianhas left
Flowhas joined
Flowhas left
Flowhas joined
stefandxmhas left
Valerianhas joined
Valerianhas left
mimi89999has joined
Flowhas left
Flowhas joined
jonaswyeah
jonaswI’m already not happy with XEPs changing at all
Ge0rGExcept when they are made better?
jonasweven draft xeps sometimes undergo massive changes, see Bookmarks.
Ge0rGI'm not implementing Bookmarks. Because the RECOMMENDED way doesn't work, and the working way is Historical.
moparisthebestsame with omemo?
jubalhhas joined
jonaswno, OMEMO has a XEP reflecting the current state now
Ge0rGI'm not implementing OMEMO because the deployed protocol is not specified, the specified protocol is not deployed, because it adds major UX bumps and because I don't believe in E2EE.
Ge0rGjonasw: oh, it does?
jonaswit uses the siacs namespace at least
zinidthe problem with namespaces bump is that I need to maintain all the code for previous namespaces, blowing the codebase, this is annoying
jonaswanother issue I have with that is that old versions are barely discoverable
jonaswyou could see a XEP for the first time a day after the last namespace bump, implement it, and see that nobody implements that version in the wild yet
Ge0rGzinid: we can't bump the namespace on MUC, fortunately.
zinidGe0rG: and we resorted to replace this monster with another monster?
Ge0rGzinid: MUC is not a monster. It's ugly, but it's not too large.
zinidI have 4000 LOC of mod_muc* modules, isn't this a monster?
Martinhas left
zinidif it's not a monster, then what it is? I can recall pubsub only
ZashHuh
Ge0rGzinid: you know, bad specification is not the only cause of bloated software.
Ge0rGSometimes the problem is in front of the terminal, actually.
jubalhhas left
jubalhhas joined
moparisthebest[02:06:51 PM] Ge0rG: *snip* I don't believe in E2EE.
moparisthebestwhat
moparisthebestwhat possible reason could you not believe in E2EE, and in what way
ZashIt's not the golden saviour of humanity as some would have you believe
Ge0rGmoparisthebest: E2EE is often advertised as the solution to dragnet surveillance, but it doesn't fix the biggest problem: three-letter agencies are interested in meta-data more than in actual content.
ZashAlso it invalidates a bunch of the assumptions XMPP is built on
Ge0rGmoparisthebest: just the fact that Facebook-WhatsApp rolled out E2EE should make you think.
mimi89999has joined
Ge0rGmoparisthebest: if you really want to prevent meta-data collection, you must run your own server for family&friends. And then you don't need E2EE any more.
jonasw(I find that argument rather convincing, by the way. And I belong to the group of people who’re still using OTR, because reasons)
moparisthebestso I agree, it doesn't solve everything, nothing does, it also doesn't harm anything either though
jonaswit does
moparisthebestI run my own server but still use E2E, what if the mam database is compromised or otherwise exposed?
jonaswtake a look at the number of people complaining about issues with OMEMO and blaming it on XMPP
jonaswlike losing messages in groupchats
jonaswthey don’t think the issue might be the experimental E2EE implementation they’re using.
jonasw(or, maybe worse, blaming it on the server)
Ge0rGmoparisthebest: OMEMO failed to address the device migration use case, among others.
Ge0rGmoparisthebest: my position is: XMPP is already f***ing complicated and has too many corner cases that break the UX. We shouldn't be adding yet another one.
Flowuh Ge0rG droped the E2EE bomb
Flowwhere is my popcorn? ☺
FlowGe0rG: you have a point here. But I'm not sure if E2EE couldn't be made user friendly
stefandxmhas joined
Ge0rGFlow: what bomb? I'm making this points for years now.
FlowGe0rG: well I know, but obviously there are still people who act a little bit shocked when you say that
moparisthebestyour arguments all apply to OTR
moparisthebestnot at all to PGP
moparisthebestand only a little bit to OMEMO
moparisthebestso
Ge0rGFlow: I'm sure it's possible to make E2EE more user-friendly than it is now. However, it won't be as polished as WhatsApp E2EE any time soon, and we (as the Jabber community) already lack the resource to make XMPP more user-friendly.
Ge0rGmoparisthebest: my arguments apply to all E2EE on top of XMPP
moparisthebestalso Ge0rG your argument was if you want privacy have all your friends have an account on your server? kind of kills federation no?
Valerianhas joined
Flowmoparisthebest: surely the problem isn't E2EE *on* XMPP
Flowmoparisthebest: no, he (and I) want you to run your own XMPP service
Flowand federate with your the XMPP server that is run by your friends
moparisthebestso every user runs their own server?
Holgermoparisthebest: "not at all to PGP" -- no matter what E2EE you're using, you either don't verify keys or break communication by insisting on verified keys.
FlowWe need to go away from big centralized XMPP services like jabber.ccc.de or jabber.at
Holgermoparisthebest: No matter what E2EE you're using, you can't do server-side search on your archive.
Holgermoparisthebest: No matter what E2EE you're using, you can't do server-side spam filtering.
FlowAnd to achieve that, we need to enable non-tech savy users to run their XMPP server on a vServer or on their home router
Flowunder their own domain
jonaswHolger, incorrect, WhatsApp does server-side spam filtering only with metadata.
FlowHolger: Now that you said it: I never received OpenPGP encrypted spam. wonder when that is going to start
emxphas joined
moparisthebestHolger, as Ge0rG said you have metadata, most filtering is on that anyhow?
jonaswmoparisthebest, it doesn’t work with XMPP, you need to have control over all servers to effectively filter spam on metadata
moparisthebestin fact all the current 'must be on roster' filtering works with e2e
jonasw(well, it’s not exactly like that, but federation makes it so much more difficult)
jonaswmust-be-on-roster is a very very bad spam filter
Flowyep, bad idea
lumihas joined
moparisthebestI agree
Holgerjonasw, moparisthebest: I doubt that filtering purely on metadata can get you an accuracy anywhere near to filters that also take the body into account.
emxphas joined
emxphas joined
moparisthebestsaying e2e is a bit hard so we shouldn't support it is dumb though, it's perfectly legitimate and if done right basically free
HolgerFlow: It'll start once OX is ubiquitous of course :-)
Flowhehe
Flowsadly new clients still implement xep27 ;(
Holgermoparisthebest: Yeah, dumb. In practice people just give up this XMPP shit due to the E2EE breakage we introduce.
Holger(I've seen *two* people saying just that *today*.)
moparisthebestit's better than nothing (xep27)
Flowmoparisthebest: I don't think so. OpenPGP without a replay mitigation is worser than no verification at all
Flowfor example
moparisthebestreplay is a type of attack, sometimes it doesn't matter
Flow?
jonaswHolger, whatsapp apperently does it quite well
jonaswbut I only heard that second- or third-hand
moparisthebestFlow, sometimes you just need to protect content and don't care about replay
jonaswmoparisthebest, I don’t say we shouldn’t support e2ee at all. but Jabber as an IM system has much worse problems than not supporting E2EE currently.
jonaswwe need to solve those firts
moparisthebestit's always going to have problems, everything does
jonasw*especially* with security systems you can’t simply handwave problems away
Flowmoparisthebest: but especially in IM you want to know that the "I aggree" from the other side was a current response, and not from days ago
jonaswpeople don’t expect replay attacks to work
Holgerjonasw: Yes much better than we do, mostly because they hide verification very well and don't have MAM/multi-device support. (And of course because they avoid implementation issues by controlling the clients.)
jonaswand you can’t expect people to understand that
jonaswHolger, they don’t have multi-device support?
jonaswI thought they did.
jonaswbut how does that relate to spam filtering?
Holgerjonasw: No, they just have a web client that talks to your phone.
jonasweww
mimi89999has joined
stefandxmhas left
zinidhas left
moparisthebestFlow, yes the "I agree" replay is potentially a problem, the "here is your report for 2017-01-01 08:32 bla bla bla" is not
moparisthebestbut uh, "replay" is also a huge problem without e2e, so
jjrhhas left
jjrhhas left
zinidhas left
jjrhhas left
zinidhas left
Ge0rGhas left
pep.has joined
Ge0rGHolger: and because they have millions of dev budget.
Ge0rGhas left
Flowmoparisthebest: "the "here is your report for 2017-01-01 08:32 bla bla bla" is not"?
moparisthebestFlow, if I get a dated report from last month I'll be pretty sure it's a replay I guess
HolgerGe0rG: RIght.
moparisthebestwhat is the argument here? xep27 is bad because it's vulnerable to replay so use no encryption? (which is also vulnerable to replay)
HolgerThat's not my argument, no. I use 0027 with the two-and-a-half geeks that manage to cope with key deployment in my roster myself.
moparisthebestanecdote of course but I switched to xmpp specifically so I could use PGP, then omemo came along and I use it sometimes, PGP still has a place
moparisthebestnow I'd much rather use OX than 27, but 27 is better than nothing
Flowmoparisthebest: The point is that xep27 is badly designed, allowing for replay attacks because the recipient (and a timestamp) is not part of the secured data
Ge0rGmoparisthebest [21:22]:
> Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess
And if the report author gets a "the report is okay, publish it", you can't know for sure
Holgermoparisthebest: Yes, "no forward secrecy" and "one key per contact rather than per device" are clearly features I appreciate compared to OTR/OMEMO.
moparisthebestright I completely agree OX is better Flow , but 27 is better than nothing
FlowOpenPGP certainly has it's place
Flowmoparisthebest; And that is where I disagree with you ☺
moparisthebestI find it most handy for where I used to send cronjob output as pgp encrypted email from my servers
moparisthebesta sendxmpp that does OMEMO seems, hard
Flowtrue
moparisthebestFlow, how could 27 possibly be worse than no encryption exactly
moparisthebestit doesn't prevent replay or spoofing, neither does no encryption
HolgerWrong sense of security.
Flowmoparisthebest: what holger said
moparisthebestit does protect content
moparisthebestthat's all it does, I know that, I'm fine with that
Flowit may be sufficently secure for the use case you described
Flowbut not for the gernal IM use case
moparisthebest100% agree OX should be pushed forward and I will drop 27 first :P but until then
FlowOX would be able to prevent spoofing, xep27 is not
FlowIt's such a pitty that there is no high level OpenPGP library for java
moparisthebestyou could do android first :)
moparisthebestin fact there was a WIP OX pull request for conversations
Flow(Java/Android that is)
moparisthebestandroid has an excellent openpgp implementation/app
FlowI know, OX was born because I meet the OpenKeychain dev's at the GSOC mentor's sumimt 2015
Flow*met
FlowI've been begging them to factor out the OpenPGP part of OpenKeychain into a library for Java and Android
moparisthebeston android at least it's better as-is isn't it?
moparisthebestas a PGP app that's usable by other apps
FlowI'm sorry, I don't know how to parse that
FlowAhh yes, that was our idea for the conversations OX implemenation
moparisthebestI don't want to import my key into conversations, and k9mail, and oandbackup
moparisthebestI instead import it into OpenKeychain, and it does all the lifting, and the other apps just talk to it
FlowOK (OpenKeychain) was missing a few additional exposed APIs for OX in conversations
Flowbut the effort stalled
Holgermoparisthebest: I don't want to import any keys anywhere.
zinid> incorrect, WhatsApp does server-side spam filtering only with metadata.
No surprise, for centralized servers it's much easier to fight against spam when you control *every* user
Holgermoparisthebest: The key should silently be created by the app I'm using and auto-deployed to any other devices. Anything else will end up being completely unusable.
moparisthebestoh well that's a different thing, yea I'm sure they'd add additional apis
moparisthebesthmm I'm not sure 1 key being automagically distributed is better than one key per device
moparisthebestyea I remember reading it, I'm not convinced I want my encrypted key on my server
Holgermoparisthebest: IMO it makes the difference between "completely unusable" and "maybe somewhat usable" by non-geeks.
Holgermoparisthebest: Do you have a single non-geek in your roster you're talking PGP to?
moparisthebestI think you are right actually
moparisthebestin that the normal case it should do that
moparisthebestbut should also allow me to use my already-set-up-not-on-server key
moparisthebestHolger, uh yes, but you didn't ask if I had to set up their pgp key for them or not :)
HolgerYah I'm not discussing Advanced -> Expert -> Special options.
jerehas joined
moparisthebestdo I have anyone in my roster I talk to with PGP that I didn't fully set up their key manually for them for? no :'(
HolgerI had like five and am down to three I think.
HolgerOf my ~150 contacts.
HolgerIf which 100+ are geeks :-)
Holgers/If/Of
moparisthebestwhat client(s) do you use?
HolgerMCabber and Conversations.
moparisthebestah ok, I started with gajim and it didn't actually do carbons+pgp right, I got the impression no one else had tried
HolgerI heard of various issues with Gajim's PGP support but never tried myself.
HolgerWorks just fine with my two clients.
moparisthebestI put in a patch to fix that and it worked great for years until new gpg broke the python gpg lib, and I haven't looked at it
HolgerAh right gpg2 is a PITA for MCabber as well. The fix is sticking to gpg1.
Holger(Though McKael is somehow using gpg2 I think ...)
jerehas joined
moparisthebestiirc it worked fine with gpg 2 but 2.1 broke it
moparisthebestI think the python lib is hardcoded to treat unknown errors fatally instead of a generic error and that breaks everything
moparisthebestI need to look into it one day
zinidI'm not a security expert, but what is a problem to keep private key securely on a server?
McKaelHolger: Yes I'm using GPG2 but it's painful, indeed.
moparisthebestMcKael, have any patches laying about or a terrible wrapper script or what? :)
zinidcan't I just encrypt it using my password which is supposedly stored hashed as well?
McKaelmoparisthebest: No, lately I've been using the default pinentry and it messes things up
McKaelNot sure how I got rid of that before, I forgot :/
jubalhhas left
Wiktorzinid: defense in depth, one can tell that your server is already protected by password so no need for PGP private key passwords, but you use it anyway to have layers of protection
zinidI don't understand, according to e2e proponents, they don't trust server admins
Holgerzinid: Yes that's how I'd do it. Not sure how to survive forgotton/restored passwords though. Maybe each client needs an unencrypted copy of the key to re-encrypt it on password change or something ...
tim@boese-ban.dehas joined
Wiktorzinid: you don't store the private key even encrypted because loss of password would compromise the key
zinidhas left
WiktorI'm not using PGP with xmpp though
mimi89999has joined
WiktorBut usually you don't even store the private key in software but use hardware token
danielhas joined
WiktorTo further protect the key
zinidbut you can also lose private key
Holger"usually" :-)
zinidHolger: lol :)
matlagHolger, I would separate the account's PW from the key's encryption PW, then the server also stores the latest modif of the encryption PW, when the user connects, the client checks if its stored PW is the latest, and if not prompt the user for the new one
zinidand typically you lose private key with losing phone for example
zinidstill not clear
zinidI cannot believe there is no solutions for this problem, key servers? kerberos? just to mention, I know jack shit about these :)
Holgermatlag: The server has a clear-text copy of the key encryption PW??
matlagno, only the date of the latest change
HolgerAh.
HolgerSo simply a separate passphrase?
matlagyep
Holger"Hello User, please type your password! ... thanks, now please type your other password!"
zinidwhich will be the same for the majority of users :)
HolgerThey'll love you.
Wiktorzinid: truly paranoid store their private key copies only on offline, airgapped machines, then load it on OpenPGP smart card
WiktorNote I'm not advocating for that
zinidWiktor: are we building a network for trully paranoid?
zinidWiktor: can we just have non-paranoid mode/
zinid?
matlagwell, currently the risk is "Hello User, please type your password! ... now please type your entire private key"
WiktorI'm not building anything just saying there are various threat models in existence
matlagzinid, you need to fit all the needs! so paranoid should be an option
zinidmatlag: sure, don't store private keys on server, keep them on hardwared device
zinidI mean it's totally opaque for the server where you keep your keys
Holgermatlag: My point was about increasing the usablity of E2EE, not about increasing it's security. The latter is easier, the problem is just that you end up with zero users of your secure solution.
zinidbut still a problem with password restoration indeed
Holgermatlag: As a well-hidden *option* you can make it as secure and unusable as you like. The interesting part to achieve is to implement a default behavior that doesn't break day-to-day communication.
zinidI agreed
matlagI admit it's not so friendly, but on the other hand, you can store the key PW on the client and then you don't need to change it as long as you don't change the key PW
zinidcurrently users are trying to use OMEMO, they fail and resort not to using OMEMO at all
zinidso probably better to use less secure option?
matlagI mean: is that so much more cumbersome than changing your home's wifi password?
Holgerzinid: They resort to ditching the non-working XMPP crap.
Holgermatlag: The point is it's so much more cumbersome than just using WhatsApp/Signal/whatever.
zinidmatlag: did you really contact with a regular user? my wife's mother cannot configure wifi for example, but she loves whatsapp, so a potential user
matlagYeah, ok, point taken
moparisthebestwhat if you make them have 16 character passwords and take the first 8 for the key password and send the second 8 to the server for login
moparisthebesteither way yea I want to decrypt my pgp key with a seperate password, normal users probably don't need it encrypted on the device at all
zinidbut all 16 characters will be lost?
Holgermoparisthebest: Won't help much if you're trying to protect against the case where the password is lost.
zinidbecause they are stored in a single place, no?
matlagmoparisthebest, They end up typing the 16 characters and that's the same as having hte same PW for both
Flowhas left
Holger(zinid was faster.)
Ge0rGWhat would be great is an xmpp server that encrypts everything for a user with a key pair where the private key is only unlocked while the user is logged in.
WiktorIf your target user is a mother in law you shouldn't be talking about encryption because she probably doesn't care if whatsapp is encrypted but of easy contact discovery and on boarding process
zinidWiktor: but usually I'm not talking about e2e :)
zinidI think it's still just a toy
moparisthebestGe0rG, meh that's still just fully trusting the server
moparisthebestI mean you already have full disk encryption and such on the server
HolgerWiktor: Agreed! I'd just disable encryption by default. But everyone is telling me it MUST be enabled by default, or even always.
ZashGe0rG: Wanna the crypto design and audit?
Wiktorzinid: agreed, but for me it's a toy for power users, like PGP itself
matlagSo let's assume most users don't care about encryption but you want a default encryption for them: most can use the same PW for account and private key, others can have them separated?
moparisthebestor just don't have a password on the local pgp key
HolgerWiktor: So I'm getting to think about how to enable E2EE in order to make the geek marketing department happy without breaking stuff for the mother in law :-)
zinidWiktor: then nothing should be changed, everything is great
moparisthebestit's storing full conversations in plain text anyway, most likely
WiktorHolger: on my client it's disabled by defiant and I use it with one contact for 239 unencrypted
WiktorFor me that's a good ratio
HolgerWiktor: The Conversations tracker is full of people complaining how OMEMO is optional and non-default.
Wiktorzinid: w.r.t. To omemo just add support for key migration / rotation and easier adding of new devices
ZashI did a prototype of a thing where some data is encrypted using a key derived from a SCRAM thing that you only have during login
Ge0rGZash: maybe one day I'll find a corporate customer that will pay for it
moparisthebestbecause default is how it stays 99% of the time
Ge0rGZash: I remember that, yeah
moparisthebestand if we've learned anything over the past 5 years or whatever, encryption should always be default
moparisthebestat least, most people have learned that
HolgerWiktor: ^ see?
zinid:D
WiktorHshshw
HolgerWiktor: So how to deal with all the moparisthebests in the community? :-)
WiktorHahaha*
Zashmoparisthebest: I'm not convinced that XMPP is the right thing if you wanna have a protocol where everything is encrypted.
moparisthebest:)
WiktorGreat point Holger
moparisthebestZash, do you know of better ones that don't eat battery due to p2p ?
ZashXMPP is a giant compromise. Compromise between p2p and centralized.
SamWhited> encryption should always be default
Define "encryption"? Are you still talking about e2e encryption like most of this conversation (I've just been passively following)
moparisthebestall of it, imho
moparisthebestI mean, TLS/transport encryption should be mandatory with no cut-off
Wiktormoparisthebest: well it is on xmpp since 2014?
moparisthebeste2e should be default, with the ideal of no cut-off
Holgermoparisthebest: Apart from that, I should be rich!
moparisthebestthat's the ideal isn't it? :P
danielhas left
Wiktormoparisthebest: what is your threat model? Why do you want e2e6by default? Do you understand that without face to face fingerprint comparisons e2e does not provide any significant advantages?
moparisthebestI tend to agree current pgp/omemo isn't quite ready for default enforced prime-time, that's just where we should be aiming
moparisthebestWiktor, it still defeats passive surveillance which is ubiquitous
WiktorTls defeats passive surveillance
moparisthebestalso all the server hack leaks everywhere
stefandxmhas joined
SamWhitedWhy? What is the actual thing you are trying to accomplish by making e2e encryption the default?
Zashmoparisthebest: By whom? e2e protects against some cases of evil server, but in XMPP, if your server is evil, you are screwed
moparisthebestyou don't have to trust your server, so why trust your server
moparisthebestand, your chat partner's server if not the same
zinidZash: the point I'm told is that the remote server can be evil and you can do nothing with it
WiktorZash: exactly. moparisthebest If your server lies about your keys and you don't compare them live then the security model has been broken
Valerianhas left
moparisthebestalso define 'screwed', it can block your messages, it can't do anything else with e2e
moparisthebestWiktor, again an active attack that you can detect before, during, or after
Zashzinid: Sure, you have to trust that your chat partner picked a trustworthy server too.
moparisthebestvs you having no idea who has your messages when
WiktorWell usually only your server and your friend's has messages, in xmpp they are directly connected.
zinidZash: I agree you cannot build security without trust, the question is how paranoid we should be
SamWhitedIt sounds like "encryption" is being equated with "security" here, and that's always dangerous. If you ignore the user aspect (you're making all sorts of trade offs by forcing everything to be e2e encrypted) they'll just go somewhere else or develop bad habits that make things worse. If you can't clearly articulate a reason other than "why not?" you may want to think about it more. That's never an okay way to approach thinking about security.
moparisthebestWiktor, do I know if they are connected securely
Valerianhas joined
moparisthebestdo I know if the other users server mandates encryption on c2s
moparisthebesttls in this case
WiktorWell your server should mandate your security standards
moparisthebestbut if you sign up for newhotserver.im
moparisthebestyou think key verification is the problem
waqashas left
moparisthebestbut the solution is to personally trust your server operator?
moparisthebestseems suspicious
WiktorThen do you know if your friends computer is not compromised by malware?
moparisthebestit's about minimizing risk, that's a risk either way
moparisthebestyou have to trust your friend's endpoint
moparisthebestyou don't have to trust everything in between
WiktorKey verification is always the biggest problems :)
WiktorYes it's about minimizing risk but if the advantage is small enough then it's not ok to mandate e2e everywhere
SamWhitedOr if it actually makes things worse…
moparisthebestwhat if it doesn't have any disadvantages
WiktorYes, exactly. There are always trade offs
zinidmoparisthebest: but it does
moparisthebestyou mean some current systems do
zinidyes
Wiktor> what if it doesn't have any disadvantages
I've never seen a solution to anything without disadvantages. There are always constraints.
Valerianhas left
zinidand security is always inversly proportional to usability
zinidwhatever encryption you suggest, you lower the usability part
zinidso users should clearyl understand why they suffer
moparisthebestthat's not true though
moparisthebestdo you have your laptop hard drive encrypted?
zinidmoparisthebest: that's not even my words, Schneier said that :)
zinidmoparisthebest: no, I don't
moparisthebesteven great guys can be wrong sometimes haha
moparisthebestok well that's just inexcusable why? :P
moparisthebestI guess if it never leaves your house it's probably fine
zinidmoparisthebest: I don't know how to do this
WiktorHD encrypted can be a usability nightmare if you have your keys only in TPM and TPM died :)
zinidis it ok answer? :)
matlagmoparisthebest, In this case, for example, the only way to have a solution that guarantees no user intervention is to have the private key stored on server and encrypted with the user's account PW: no degradation of usability, BUT: not nearly as safe as the blows and whistle you hear for great E2E
moparisthebestthe point I was going to make was it's the same either way, you type a password to get into it regardless, and nowadays it doesn't even run slower
SamWhitedI have two laptops, one has the disk encrypted and one doesn't. The one with the disk encrypted I have to type a password in every time I boot and if the sector that contains the key gets corrupt the whole harddrive is lost instead of just that one sector.
SamWhitedThat is a trade off.
SamWhitedI only chose to make it on one laptop because I have a very specific threat I am trying to protect against with that specific machine.
matlagif you increase security, then you need the user intervention, and as you increase it, more and more user intervention
moparisthebesta few sectors include the key normally SamWhited
SamWhitedDoesn't matter, it is more likely that I lose all the data (I do actually have it in two key slots, I also keep an offsite backup, another tradeoff I made)
goffihas left
SamWhitedThe point is there are tradeoffs to the thing you used as an example too. If you don't even know what threat you're trying to protect against, there's little point in making some of these trade offs.
moparisthebestreally that's a bad example anyway, the users I see generally expect chat to be ephemeral anyway
moparisthebestso if they forget their password and don't have logs from yesterday, oh well
moparisthebestI guess it's a trade off but also maybe what they expect?
zinida good example is probably how PKIX is used currently in browsers
moparisthebest(I'm basing this on all the users that want to be able to delete shared pictures from http upload)
Ge0rGI expect IM history to be eternal. Maybe I'm different.
zinidvery little inconvenience
moparisthebestGe0rG, then you already have backups and such and will get that with e2e also
efrithas joined
Ge0rGmoparisthebest: e2ee is more complicated than not having it.
Ge0rGmoparisthebest: the people who are the loudest to demand e2ee have the least understanding of it, usually.
stefandxmhas left
Ge0rGAnd I'm on the road for almost eight hours now. German public transportation has been severely impacted by some storm.
moparisthebestI guess everything is more complicated than not having it
Ge0rGmoparisthebest: Easy XMPP is an exception
zinidxmpp2 !!!111
moparisthebeststill more code
lovetoxhas joined
zinidGe0rG: btw, your subject about message routing didn't route further in the standards@ :)
zinidGe0rG: my guess is that nobody knows how to fix stuff, lol
waqashas joined
moparisthebestcan we make direct tls the only way to connect in xmpp2 ? :P
zinidadding more xeps => sucks
breaking compatiblity => sucks
zinidmoparisthebest: is it the major problem? :)
moparisthebestno just another nice-to-have
moparisthebestalso I don't see any trade-offs with this one haha
la|r|mahas joined
lskdjfhas joined
zinidthe trade-off is more implementation
zinidpoor library support
moparisthebestfor direct TLS ?
moparisthebestsurely it's the opposite
zinidyes
moparisthebestevery TLS lib ever vs xmpp-specific-libs ?
zinidyou need to support SNI in server, that's some work if you use openssl ;)
zinidejabberd doesn't support it for this reason, the API is ugly as hell
moparisthebestyou are already doing far more work for everything else in xmpp2 surely
zinidI need to be a man and implement it
moparisthebestanyway it gives you tons of other advantages