moparisthebest, 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
jonasw
I guess this is what the CFE is for
jubalhhas joined
stefandxmhas left
Guushas left
uchas joined
danielhas left
Kev
Well, it's for Council to decide whether it's fine or not, no?
jonasw
Kev, yes
stefandxmhas joined
jonasw
you’re right about that
jonasw
what I meant is: it is not absolutely not fine
jonasw
and 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
Guus
Kev (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
Kev
What's your name on the docker hub?
edhelashas left
Kev
You'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.
Kev
Please don't change things without discussion.
edhelashas joined
Guus
Thanks, I won't
Guus
I'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
Guus
when 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
jonasw
Guus, no
Guushas left
jonasw
you start TLS over the existing TCP connection
stefandxmhas joined
Zash
Just like STARTTLS, except without the negotiation
Guus
sounds like it's time to shout at apache mina again then
Link Mauve
Zash, s/without \(.*\)/with \1 done by the TLS library instead of by the XMPP one/
Zash
That hurt my head
lovetoxhas left
Zash
Depends 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
Ge0rG
It's a great way to shave off some round-trips, though
Guushas left
jubalhhas joined
jubalhhas left
Alexhas left
Ge0rG
Kev: "undesirable"... I love your choice of words!
Alexhas joined
jonasw
undesirable in that context might be the XMPP-related understatement of the decade :-)
Ge0rG
Kev: 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.
Kev
It is definitely better than nothing at all.
Kev
I've long held that opinion. But if we're providing something better now, maybe it can retire.
Ge0rG
Kev: except when you end up seeing ghosts in the MUC.
zinidhas left
Kev
You see ghosts in the MUC with or without gc1 joins, without another mechanism.
Kev
Without gc1, everyone you see (as a client) is a ghost :)
lumihas joined
Ge0rG
Kev: yes, but then you realize that as soon as you send a message.
Kev
That is true.
Ge0rG
Kev: my point is that it's not always better than nothing.
Zash
If we get rid of gc1, isn't a normal presence the same as <presence><I-expect-to-still-be-in-the-room/></p>
Kev
If you're referring to (3), then no.
jonasw
Zash, yes, but we can’t simply get rid of GC1, can we?
Zash
Can we?
Kev
jonasw: Can't we? :)
jonasw
Kev, council was against it.
jonasw
I mean, we can re-try, but ...
jonasw
speaking of council, still no (re-)applications?
Kev
Council may have been against it when there wasn't a better option, they may not be after this.
Kev
Only Joe Demo, by the look of it.
Kev
I hear good things about that guy.
jonasw
like Boaty McBoatface?
Ge0rG
Again, I want to propose Boardy McBoardface for Council.
jonasw
not Council McCouncilface?
Ge0rG
jonasw: no. C McC should apply for Board instead.
la|r|mahas joined
jonasw
for maximum confusion, I see
Ge0rG
I wonder if I should apply for Council, and then try to aggressively push the XMPP 2.0 / Easy Jabber agenda.
Ge0rGhas left
Ge0rG
Killing GC1.0 would be my major campain promise.
jonasw
hm, one can’t really make promises, can one?
jonasw
when 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
Kev
I kinda think that what xmpp2/easyjabber needs most, in some ways, is implementation and deployment experience.
andrey.ghas left
jonasw
you can’t really do implementation without some specification
Kev
Of course you can.
Zash
Just type code into your thing!
Kev
You try something and see if it works.
jonasw
well, you shouldn’t
jonasw
hm
Kev
Also, completely untrue.
Zash
So you are a specification before implementation person?
Kev
Protocol documents based on people actually trying things is a jolly good thing.
Zash
Some are the other way around. Some think both at the same time!
jonasw
yeah, I see where you’re coming from
Kev
Everything has its place. Except the things that don't.
jonasw
I’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
Kev
jonasw: Nothing says that has to happen in advance.
jubalhhas joined
Ge0rG
Kev: I could implement Session 2.0, but then it would only work for IM.
Kev
e.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
Kev
Ge0rG: 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
Ge0rG
Kev: 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
jonasw
itym MAM-subcsription
Ge0rG
jonasw: right. Sorry. I won't LMC that now.
Kev
Ge0rG: 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.
Kev
So all we need to do is achieve that :D
Zash
So how do we determine if a message is "chat-related"?
Kev
I did the hard work of coming up with the high-level direction. Someone else can work on the details.
Zash
type=chat would have been nice
Ge0rG
Kev: you are a genius! Why didn't anyone else think of that before? :D
Ge0rG
Zash: 0184 and CSNs happen to be type=random.
nycohas left
jonasw
also, what about type=normal? :)
Zash
Aren't those chat related?
Guushas left
Ge0rG
Zash: maybe they are.
jonasw
that certainly has messaging use-cases too, and wouldn’t you want to sync them, too?
mimi89999has joined
Ge0rG
jonasw: chat is the new normal.
jonasw
that’s your opinio.n
jonasw
;-)
Ge0rG
jonasw: that's what implementations do
jonasw
because no implemntation has a UI for type=normal
jonasw
except pidgins "let’s show this in a separate window focus stealingly" counts as UI
Ge0rG
jonasw: I think many client authors don't care about "normal" vs. "chat", and end up sending non-body messages with "normal"
jonasw: also guess which message type is mandated by [xep 0184]
jonasw
"whatever works"?
Zash
Ge0rG: {}
Ge0rG
Zash: -ETOOMANYDIFFERENTBOTS
Zash
Bots bots bots
Ge0rG
can't we just have all bot react to all patterns, instead of putting the cognitive load onto people?
Zash
Wasn't both 184 and csn using the standard reply pattern? Ie same type
Ge0rG
-xep standard reply pattern
Bunneh
Ge0rG: XEP-0068: Field Standardization for Data Forms (Informational, Active, 2012-05-28)
See: https://xmpp.org/extensions/xep-0068.html
andrey.ghas joined
Zash
Copy attributes, swap to/from. If it's an error, set type=error.
Ge0rG
Zash: There is no such primitive in the XMPP lib I'm using.
jonasw
Ge0rG, switch XMPP libs then!
Ge0rGhas left
jonasw
Zash, also, you shouldn’t be copying the @id for anything except IQ, I think
Ge0rG
Zash: I'm not even convinced this is a good thing, generally. Maybe type=headline would be more appropriate for ACKs and CSNs?
Kev
I think acks you probably want stored in your archive, while CSNs you certainly don't.
Zash
Kev: Are you sure?
Ge0rG
Right. ACKs need to be archived.
Kev
Actually, 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.
jonasw
Kev, as much as possible, of course.
Ge0rG
Kev: it's all about synchronizing a chat database.
Ge0rG
Kev: yes please. Make the most revolutionary proposal you can imagine.
winfriedhas joined
Kev
Have your server handle your acks for you. Also have the server archive read receipt status for your messages.
Kev
Have the ability to collate messages that operate on each other in the archive, so they can be returned as state on the MAM results.
Ge0rG
Kev: I think MAM would be indeed a good place to send 0184 acks, from the bare JID
Kev
Delivered, Read, LMC. Store them, but on the message they affect, not on their own.
Ge0rG
Kev: that message collation would work much better if we had properly-generated UUIDs
Ge0rG
Does "unique" also mean that there should be only one UUID per message?
Zash
Kev: I object to anything that makes it impossible to do MAM in an append-only log store thing.
Ge0rG
Kev: BTW that almost sounds like a multi-table relational database
Zash
I object to anything that requires a relational database.
Ge0rG
Zash: better apply for Council now, then
Kev
I think the most sensible way to implement MAM is with a database of some description. But clearly it's not needed.
Ge0rG
Kev: how would clients synchronize? Atomic replacement of [Message, Delivered, Read, [LMCs], [Reactions]] n-tuples? Or do we need a separate chronological history?
Kev
Synchronise in which sense?
Ge0rG
This is again the fully-synchronized fat client vs. load-on-demand thin client debate I think
Kev
Possibly.
Ge0rG
For load-on-demand it makes sense to initially query for n-tuples, and then to receive a stream of deltas.
Ge0rG
For fat clients it makes sense to receive a stream of stored deltas, followed by live deltas.
Kev
That is possibly true.
Ge0rG
Now this is another thing I had in MAM-sync: push of MAM-IDs for sent messages.
jonasw: 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
Zash
I think someone (mattj?) suggested a carbons extension/change where you'd get your own messages reflected back
jonasw
what
Zash
syswhat
Kev
I'm not entirely convinced that just mirroring the entire (annotated) stanza back isn't sensible.
Ge0rG
If I were redoing XMPP, I'd glue together session, MAM ID reflection and 0198
lumihas left
Ge0rG
Kev: maybe except for https://xmpp.org/extensions/xep-0047.html#message
jonasw
what’s session in this context?
Ge0rG
jonasw: that thing you bind.
jonasw
ah
Ge0rG
jonasw: 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
Ge0rG
I'm not opposed to the Carbons wire format, just the current processing logic is insane.
jonasw
sounds reasonable
jonasw
still possible to do that even without redoing xmpp
Kev
Everything's possible without redoing xmpp :)
Ge0rG
jonasw: still doesn't solve the persistency/urgency problem.
jonasw
Ge0rG, that needs fixes to MAM, Carbons, CSI and Push. All of which aren’t final yet, right?
Ge0rG
jonasw: are there any final XEPs at all? I thought Draft is the new Final.
jonasw
XEP-0030 :)
jonasw
(for example)
moparisthebest
I'm pushing to make 368 final
moparisthebest
but also considering I nor any current editors have ever seen a move to final
moparisthebest
no
valohas joined
jonasw
moparisthebest, no worries :)
jonasw
just prepare your PR and see what council says.
lumihas joined
moparisthebest
yea 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
Kev
I 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
Flow
isn't the question what the benefit of final XEPs is, over draft XEPs?
Flow
as far as I can tell, final only has disadvantages
jonasw
Flow, what advantages does Draft have over Experimental? :)
Flow
jonasw: another review round at least by the council and probably by the xmpp community
jonasw
okay
jonasw
then final probably doesn’t bring you anything :)
Flow
plus at least so und so many implementations IIRC
jonasw
that’s only with Final IIRC
Flow
ahh right
Ge0rGhas left
Flow
ok, 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
Ge0rG
There is no technical difference between a namespace bump and a new namespace, so why are we forbidding them?
intosihas joined
stefandxmhas left
SamWhited
Ge0rG: they are not treated differently, changing the namespace is forbidden in final.
Ge0rG
SamWhited: yes, so we end up with a new XEP with a new namespace instead.
SamWhited
Ge0rG: 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
Ge0rG
SamWhited: yes, I'm merely questioning the wisdom of that
SamWhited
I 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.
SamWhited
I'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
Ge0rG
SamWhited: 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
SamWhited
I 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
jonasw
yeah
jonasw
I’m already not happy with XEPs changing at all
Ge0rG
Except when they are made better?
jonasw
even draft xeps sometimes undergo massive changes, see Bookmarks.
Ge0rG
I'm not implementing Bookmarks. Because the RECOMMENDED way doesn't work, and the working way is Historical.
moparisthebest
same with omemo?
jubalhhas joined
jonasw
no, OMEMO has a XEP reflecting the current state now
Ge0rG
I'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.
Ge0rG
jonasw: oh, it does?
jonasw
it uses the siacs namespace at least
zinid
the problem with namespaces bump is that I need to maintain all the code for previous namespaces, blowing the codebase, this is annoying
jonasw
another issue I have with that is that old versions are barely discoverable
jonasw
you 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
Ge0rG
zinid: we can't bump the namespace on MUC, fortunately.
zinid
Ge0rG: and we resorted to replace this monster with another monster?
Ge0rG
zinid: MUC is not a monster. It's ugly, but it's not too large.
zinid
I have 4000 LOC of mod_muc* modules, isn't this a monster?
Martinhas left
zinid
if it's not a monster, then what it is? I can recall pubsub only
Zash
Huh
Ge0rG
zinid: you know, bad specification is not the only cause of bloated software.
Ge0rG
Sometimes 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.
moparisthebest
what
moparisthebest
what possible reason could you not believe in E2EE, and in what way
Zash
It's not the golden saviour of humanity as some would have you believe
Ge0rG
moparisthebest: 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.
Zash
Also it invalidates a bunch of the assumptions XMPP is built on
Ge0rG
moparisthebest: just the fact that Facebook-WhatsApp rolled out E2EE should make you think.
mimi89999has joined
Ge0rG
moparisthebest: 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)
moparisthebest
so I agree, it doesn't solve everything, nothing does, it also doesn't harm anything either though
jonasw
it does
moparisthebest
I run my own server but still use E2E, what if the mam database is compromised or otherwise exposed?
jonasw
take a look at the number of people complaining about issues with OMEMO and blaming it on XMPP
jonasw
like losing messages in groupchats
jonasw
they don’t think the issue might be the experimental E2EE implementation they’re using.
jonasw
(or, maybe worse, blaming it on the server)
Ge0rG
moparisthebest: OMEMO failed to address the device migration use case, among others.
Ge0rG
moparisthebest: 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.
Flow
uh Ge0rG droped the E2EE bomb
Flow
where is my popcorn? ☺
Flow
Ge0rG: you have a point here. But I'm not sure if E2EE couldn't be made user friendly
stefandxmhas joined
Ge0rG
Flow: what bomb? I'm making this points for years now.
Flow
Ge0rG: well I know, but obviously there are still people who act a little bit shocked when you say that
moparisthebest
your arguments all apply to OTR
moparisthebest
not at all to PGP
moparisthebest
and only a little bit to OMEMO
moparisthebest
so
Ge0rG
Flow: 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.
Ge0rG
moparisthebest: my arguments apply to all E2EE on top of XMPP
moparisthebest
also 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
Flow
moparisthebest: surely the problem isn't E2EE *on* XMPP
Flow
moparisthebest: no, he (and I) want you to run your own XMPP service
Flow
and federate with your the XMPP server that is run by your friends
moparisthebest
so every user runs their own server?
Holger
moparisthebest: "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.
Flow
We need to go away from big centralized XMPP services like jabber.ccc.de or jabber.at
Holger
moparisthebest: No matter what E2EE you're using, you can't do server-side search on your archive.
Holger
moparisthebest: No matter what E2EE you're using, you can't do server-side spam filtering.
Flow
And to achieve that, we need to enable non-tech savy users to run their XMPP server on a vServer or on their home router
Flow
under their own domain
jonasw
Holger, incorrect, WhatsApp does server-side spam filtering only with metadata.
Flow
Holger: Now that you said it: I never received OpenPGP encrypted spam. wonder when that is going to start
emxphas joined
moparisthebest
Holger, as Ge0rG said you have metadata, most filtering is on that anyhow?
jonasw
moparisthebest, it doesn’t work with XMPP, you need to have control over all servers to effectively filter spam on metadata
moparisthebest
in 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)
jonasw
must-be-on-roster is a very very bad spam filter
Flow
yep, bad idea
lumihas joined
moparisthebest
I agree
Holger
jonasw, 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
moparisthebest
saying e2e is a bit hard so we shouldn't support it is dumb though, it's perfectly legitimate and if done right basically free
Holger
Flow: It'll start once OX is ubiquitous of course :-)
Flow
hehe
Flow
sadly new clients still implement xep27 ;(
Holger
moparisthebest: 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*.)
moparisthebest
it's better than nothing (xep27)
Flow
moparisthebest: I don't think so. OpenPGP without a replay mitigation is worser than no verification at all
Flow
for example
moparisthebest
replay is a type of attack, sometimes it doesn't matter
Flow
?
jonasw
Holger, whatsapp apperently does it quite well
jonasw
but I only heard that second- or third-hand
moparisthebest
Flow, sometimes you just need to protect content and don't care about replay
jonasw
moparisthebest, 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.
jonasw
we need to solve those firts
moparisthebest
it's always going to have problems, everything does
jonasw
*especially* with security systems you can’t simply handwave problems away
Flow
moparisthebest: 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
jonasw
people don’t expect replay attacks to work
Holger
jonasw: 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.)
jonasw
and you can’t expect people to understand that
jonasw
Holger, they don’t have multi-device support?
jonasw
I thought they did.
jonasw
but how does that relate to spam filtering?
Holger
jonasw: No, they just have a web client that talks to your phone.
jonasw
eww
mimi89999has joined
stefandxmhas left
zinidhas left
moparisthebest
Flow, 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
moparisthebest
but 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
Ge0rG
Holger: and because they have millions of dev budget.
Ge0rGhas left
Flow
moparisthebest: "the "here is your report for 2017-01-01 08:32 bla bla bla" is not"?
moparisthebest
Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess
Holger
Ge0rG: RIght.
moparisthebest
what is the argument here? xep27 is bad because it's vulnerable to replay so use no encryption? (which is also vulnerable to replay)
Holger
That'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.
moparisthebest
anecdote 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
moparisthebest
now I'd much rather use OX than 27, but 27 is better than nothing
Flow
moparisthebest: 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
Ge0rG
moparisthebest [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
Holger
moparisthebest: Yes, "no forward secrecy" and "one key per contact rather than per device" are clearly features I appreciate compared to OTR/OMEMO.
moparisthebest
right I completely agree OX is better Flow , but 27 is better than nothing
Flow
OpenPGP certainly has it's place
Flow
moparisthebest; And that is where I disagree with you ☺
moparisthebest
I find it most handy for where I used to send cronjob output as pgp encrypted email from my servers
moparisthebest
a sendxmpp that does OMEMO seems, hard
Flow
true
moparisthebest
Flow, how could 27 possibly be worse than no encryption exactly
moparisthebest
it doesn't prevent replay or spoofing, neither does no encryption
Holger
Wrong sense of security.
Flow
moparisthebest: what holger said
moparisthebest
it does protect content
moparisthebest
that's all it does, I know that, I'm fine with that
Flow
it may be sufficently secure for the use case you described
Flow
but not for the gernal IM use case
moparisthebest
100% agree OX should be pushed forward and I will drop 27 first :P but until then
Flow
OX would be able to prevent spoofing, xep27 is not
Flow
It's such a pitty that there is no high level OpenPGP library for java
moparisthebest
you could do android first :)
moparisthebest
in fact there was a WIP OX pull request for conversations
Flow
(Java/Android that is)
moparisthebest
android has an excellent openpgp implementation/app
Flow
I know, OX was born because I meet the OpenKeychain dev's at the GSOC mentor's sumimt 2015
Flow
*met
Flow
I've been begging them to factor out the OpenPGP part of OpenKeychain into a library for Java and Android
moparisthebest
on android at least it's better as-is isn't it?
moparisthebest
as a PGP app that's usable by other apps
Flow
I'm sorry, I don't know how to parse that
Flow
Ahh yes, that was our idea for the conversations OX implemenation
moparisthebest
I don't want to import my key into conversations, and k9mail, and oandbackup
moparisthebest
I instead import it into OpenKeychain, and it does all the lifting, and the other apps just talk to it
Flow
OK (OpenKeychain) was missing a few additional exposed APIs for OX in conversations
Flow
but the effort stalled
Holger
moparisthebest: 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
Holger
moparisthebest: 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.
moparisthebest
oh well that's a different thing, yea I'm sure they'd add additional apis
hmm I'm not sure 1 key being automagically distributed is better than one key per device
moparisthebest
yea I remember reading it, I'm not convinced I want my encrypted key on my server
Holger
moparisthebest: IMO it makes the difference between "completely unusable" and "maybe somewhat usable" by non-geeks.
Holger
moparisthebest: Do you have a single non-geek in your roster you're talking PGP to?
moparisthebest
I think you are right actually
moparisthebest
in that the normal case it should do that
moparisthebest
but should also allow me to use my already-set-up-not-on-server key
moparisthebest
Holger, uh yes, but you didn't ask if I had to set up their pgp key for them or not :)
Holger
Yah I'm not discussing Advanced -> Expert -> Special options.
jerehas joined
moparisthebest
do 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 :'(
Holger
I had like five and am down to three I think.
Holger
Of my ~150 contacts.
Holger
If which 100+ are geeks :-)
Holger
s/If/Of
moparisthebest
what client(s) do you use?
Holger
MCabber and Conversations.
moparisthebest
ah ok, I started with gajim and it didn't actually do carbons+pgp right, I got the impression no one else had tried
Holger
I heard of various issues with Gajim's PGP support but never tried myself.
Holger
Works just fine with my two clients.
moparisthebest
I 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
Holger
Ah 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
moparisthebest
iirc it worked fine with gpg 2 but 2.1 broke it
moparisthebest
I think the python lib is hardcoded to treat unknown errors fatally instead of a generic error and that breaks everything
moparisthebest
I need to look into it one day
zinid
I'm not a security expert, but what is a problem to keep private key securely on a server?
McKael
Holger: Yes I'm using GPG2 but it's painful, indeed.
moparisthebest
McKael, have any patches laying about or a terrible wrapper script or what? :)
zinid
can't I just encrypt it using my password which is supposedly stored hashed as well?
McKael
moparisthebest: No, lately I've been using the default pinentry and it messes things up
McKael
Not sure how I got rid of that before, I forgot :/
jubalhhas left
Wiktor
zinid: 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
zinid
I don't understand, according to e2e proponents, they don't trust server admins
Holger
zinid: 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
Wiktor
zinid: you don't store the private key even encrypted because loss of password would compromise the key
zinidhas left
Wiktor
I'm not using PGP with xmpp though
mimi89999has joined
Wiktor
But usually you don't even store the private key in software but use hardware token
danielhas joined
Wiktor
To further protect the key
zinid
but you can also lose private key
Holger
"usually" :-)
zinid
Holger: lol :)
matlag
Holger, 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
zinid
and typically you lose private key with losing phone for example
zinid
still not clear
zinid
I cannot believe there is no solutions for this problem, key servers? kerberos? just to mention, I know jack shit about these :)
Holger
matlag: The server has a clear-text copy of the key encryption PW??
matlag
no, only the date of the latest change
Holger
Ah.
Holger
So simply a separate passphrase?
matlag
yep
Holger
"Hello User, please type your password! ... thanks, now please type your other password!"
zinid
which will be the same for the majority of users :)
Holger
They'll love you.
Wiktor
zinid: truly paranoid store their private key copies only on offline, airgapped machines, then load it on OpenPGP smart card
Wiktor
Note I'm not advocating for that
zinid
Wiktor: are we building a network for trully paranoid?
zinid
Wiktor: can we just have non-paranoid mode/
zinid
?
matlag
well, currently the risk is "Hello User, please type your password! ... now please type your entire private key"
Wiktor
I'm not building anything just saying there are various threat models in existence
matlag
zinid, you need to fit all the needs! so paranoid should be an option
zinid
matlag: sure, don't store private keys on server, keep them on hardwared device
zinid
I mean it's totally opaque for the server where you keep your keys
Holger
matlag: 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.
zinid
but still a problem with password restoration indeed
Holger
matlag: 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.
zinid
I agreed
matlag
I 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
zinid
currently users are trying to use OMEMO, they fail and resort not to using OMEMO at all
zinid
so probably better to use less secure option?
matlag
I mean: is that so much more cumbersome than changing your home's wifi password?
Holger
zinid: They resort to ditching the non-working XMPP crap.
Holger
matlag: The point is it's so much more cumbersome than just using WhatsApp/Signal/whatever.
zinid
matlag: 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
matlag
Yeah, ok, point taken
moparisthebest
what 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
moparisthebest
either 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
zinid
but all 16 characters will be lost?
Holger
moparisthebest: Won't help much if you're trying to protect against the case where the password is lost.
zinid
because they are stored in a single place, no?
matlag
moparisthebest, 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.)
Ge0rG
What 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.
Wiktor
If 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
zinid
Wiktor: but usually I'm not talking about e2e :)
zinid
I think it's still just a toy
moparisthebest
Ge0rG, meh that's still just fully trusting the server
moparisthebest
I mean you already have full disk encryption and such on the server
Holger
Wiktor: Agreed! I'd just disable encryption by default. But everyone is telling me it MUST be enabled by default, or even always.
Zash
Ge0rG: Wanna the crypto design and audit?
Wiktor
zinid: agreed, but for me it's a toy for power users, like PGP itself
matlag
So 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?
moparisthebest
or just don't have a password on the local pgp key
Holger
Wiktor: 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 :-)
zinid
Wiktor: then nothing should be changed, everything is great
moparisthebest
it's storing full conversations in plain text anyway, most likely
Wiktor
Holger: on my client it's disabled by defiant and I use it with one contact for 239 unencrypted
Wiktor
For me that's a good ratio
Holger
Wiktor: The Conversations tracker is full of people complaining how OMEMO is optional and non-default.
Wiktor
zinid: w.r.t. To omemo just add support for key migration / rotation and easier adding of new devices
Zash
I 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
Ge0rG
Zash: maybe one day I'll find a corporate customer that will pay for it
moparisthebest
because default is how it stays 99% of the time
Ge0rG
Zash: I remember that, yeah
moparisthebest
and if we've learned anything over the past 5 years or whatever, encryption should always be default
moparisthebest
at least, most people have learned that
Holger
Wiktor: ^ see?
zinid
:D
Wiktor
Hshshw
Holger
Wiktor: So how to deal with all the moparisthebests in the community? :-)
Wiktor
Hahaha*
Zash
moparisthebest: I'm not convinced that XMPP is the right thing if you wanna have a protocol where everything is encrypted.
moparisthebest
:)
Wiktor
Great point Holger
moparisthebest
Zash, do you know of better ones that don't eat battery due to p2p ?
Zash
XMPP 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)
moparisthebest
all of it, imho
moparisthebest
I mean, TLS/transport encryption should be mandatory with no cut-off
Wiktor
moparisthebest: well it is on xmpp since 2014?
moparisthebest
e2e should be default, with the ideal of no cut-off
Holger
moparisthebest: Apart from that, I should be rich!
moparisthebest
that's the ideal isn't it? :P
danielhas left
Wiktor
moparisthebest: 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?
moparisthebest
I tend to agree current pgp/omemo isn't quite ready for default enforced prime-time, that's just where we should be aiming
moparisthebest
Wiktor, it still defeats passive surveillance which is ubiquitous
Wiktor
Tls defeats passive surveillance
moparisthebest
also all the server hack leaks everywhere
stefandxmhas joined
SamWhited
Why? What is the actual thing you are trying to accomplish by making e2e encryption the default?
Zash
moparisthebest: By whom? e2e protects against some cases of evil server, but in XMPP, if your server is evil, you are screwed
moparisthebest
you don't have to trust your server, so why trust your server
moparisthebest
and, your chat partner's server if not the same
zinid
Zash: the point I'm told is that the remote server can be evil and you can do nothing with it
Wiktor
Zash: 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
moparisthebest
also define 'screwed', it can block your messages, it can't do anything else with e2e
moparisthebest
Wiktor, again an active attack that you can detect before, during, or after
Zash
zinid: Sure, you have to trust that your chat partner picked a trustworthy server too.
moparisthebest
vs you having no idea who has your messages when
Wiktor
Well usually only your server and your friend's has messages, in xmpp they are directly connected.
zinid
Zash: I agree you cannot build security without trust, the question is how paranoid we should be
SamWhited
It 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.
moparisthebest
Wiktor, do I know if they are connected securely
Valerianhas joined
moparisthebest
do I know if the other users server mandates encryption on c2s
moparisthebest
tls in this case
Wiktor
Well your server should mandate your security standards
moparisthebest
but if you sign up for newhotserver.im
moparisthebest
you think key verification is the problem
waqashas left
moparisthebest
but the solution is to personally trust your server operator?
moparisthebest
seems suspicious
Wiktor
Then do you know if your friends computer is not compromised by malware?
moparisthebest
it's about minimizing risk, that's a risk either way
moparisthebest
you have to trust your friend's endpoint
moparisthebest
you don't have to trust everything in between
Wiktor
Key verification is always the biggest problems :)
Wiktor
Yes it's about minimizing risk but if the advantage is small enough then it's not ok to mandate e2e everywhere
SamWhited
Or if it actually makes things worse…
moparisthebest
what if it doesn't have any disadvantages
Wiktor
Yes, exactly. There are always trade offs
zinid
moparisthebest: but it does
moparisthebest
you mean some current systems do
zinid
yes
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
zinid
and security is always inversly proportional to usability
zinid
whatever encryption you suggest, you lower the usability part
zinid
so users should clearyl understand why they suffer
moparisthebest
that's not true though
moparisthebest
do you have your laptop hard drive encrypted?
zinid
moparisthebest: that's not even my words, Schneier said that :)
zinid
moparisthebest: no, I don't
moparisthebest
even great guys can be wrong sometimes haha
moparisthebest
ok well that's just inexcusable why? :P
moparisthebest
I guess if it never leaves your house it's probably fine
zinid
moparisthebest: I don't know how to do this
Wiktor
HD encrypted can be a usability nightmare if you have your keys only in TPM and TPM died :)
zinid
is it ok answer? :)
matlag
moparisthebest, 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
moparisthebest
the 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
SamWhited
I 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.
SamWhited
That is a trade off.
SamWhited
I 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.
matlag
if you increase security, then you need the user intervention, and as you increase it, more and more user intervention
moparisthebest
a few sectors include the key normally SamWhited
SamWhited
Doesn'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
SamWhited
The 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.
moparisthebest
really that's a bad example anyway, the users I see generally expect chat to be ephemeral anyway
moparisthebest
so if they forget their password and don't have logs from yesterday, oh well
moparisthebest
I guess it's a trade off but also maybe what they expect?
zinid
a 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)
Ge0rG
I expect IM history to be eternal. Maybe I'm different.
zinid
very little inconvenience
moparisthebest
Ge0rG, then you already have backups and such and will get that with e2e also
efrithas joined
Ge0rG
moparisthebest: e2ee is more complicated than not having it.
Ge0rG
moparisthebest: the people who are the loudest to demand e2ee have the least understanding of it, usually.
stefandxmhas left
Ge0rG
And I'm on the road for almost eight hours now. German public transportation has been severely impacted by some storm.
moparisthebest
I guess everything is more complicated than not having it
Ge0rG
moparisthebest: Easy XMPP is an exception
zinid
xmpp2 !!!111
moparisthebest
still more code
lovetoxhas joined
zinid
Ge0rG: btw, your subject about message routing didn't route further in the standards@ :)
zinid
Ge0rG: my guess is that nobody knows how to fix stuff, lol
waqashas joined
moparisthebest
can we make direct tls the only way to connect in xmpp2 ? :P
zinid
adding more xeps => sucks
breaking compatiblity => sucks
zinid
moparisthebest: is it the major problem? :)
moparisthebest
no just another nice-to-have
moparisthebest
also I don't see any trade-offs with this one haha
la|r|mahas joined
lskdjfhas joined
zinid
the trade-off is more implementation
zinid
poor library support
moparisthebest
for direct TLS ?
moparisthebest
surely it's the opposite
zinid
yes
moparisthebest
every TLS lib ever vs xmpp-specific-libs ?
zinid
you need to support SNI in server, that's some work if you use openssl ;)
zinid
ejabberd doesn't support it for this reason, the API is ugly as hell
moparisthebest
you are already doing far more work for everything else in xmpp2 surely
zinid
I need to be a man and implement it
moparisthebest
anyway it gives you tons of other advantages
moparisthebest
0-rtt, false start, everything fancy https gets
zinid
isn't this the trade-off we're talking about? :)
zinid
you get all these goods, but need to put more code, at least server side
zinid
and ALPN is only supported in openssl 1.0.2, some systems still don't have it yet
moparisthebest
you are talking about xmpp2 though, it's all more code
MattJ
I think I'd rather rewrite everything XMPP from scratch than spend time near OpenSSL's API again
zinid
moparisthebest: that was a joke actually :) obviously transition to xmpp2 will bring lots of pain
moparisthebest
also zinid 1.0.1 is already dead so I don't think anyone should care, hopefully :(
moparisthebest
yea openssl is the perfect example of a footgun api
zinid
moparisthebest: surprisingly, we get complains from time to time about cutting edge version requirement (1.0.1), lol :)