XSF Discussion - 2017-10-05


  1. jonasw

    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

  2. jonasw

    I guess this is what the CFE is for

  3. Kev

    Well, it's for Council to decide whether it's fine or not, no?

  4. jonasw

    Kev, yes

  5. jonasw

    you’re right about that

  6. jonasw

    what I meant is: it is not absolutely not fine

  7. jonasw

    and also council members brought that change I assume moparisthebest will do up in the discussion, so ... ;-)

  8. 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).

  9. Kev

    What's your name on the docker hub?

  10. 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.

  11. Kev

    Please don't change things without discussion.

  12. Guus

    Thanks, I won't

  13. Guus

    I'm guusdk on dockerhub

  14. Guus

    when establishing (direct) ssl, is more than one socket connection involved (is a connection re-established?)

  15. jonasw

    Guus, no

  16. jonasw

    you start TLS over the existing TCP connection

  17. Zash

    Just like STARTTLS, except without the negotiation

  18. Guus

    sounds like it's time to shout at apache mina again then

  19. Link Mauve

    Zash, s/without \(.*\)/with \1 done by the TLS library instead of by the XMPP one/

  20. Zash

    That hurt my head

  21. Zash

    Depends on how your libraries work I guess

  22. Ge0rG

    It's a great way to shave off some round-trips, though

  23. Ge0rG

    Kev: "undesirable"... I love your choice of words!

  24. jonasw

    undesirable in that context might be the XMPP-related understatement of the decade :-)

  25. 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.

  26. Kev

    It is definitely better than nothing at all.

  27. Kev

    I've long held that opinion. But if we're providing something better now, maybe it can retire.

  28. Ge0rG

    Kev: except when you end up seeing ghosts in the MUC.

  29. Kev

    You see ghosts in the MUC with or without gc1 joins, without another mechanism.

  30. Kev

    Without gc1, everyone you see (as a client) is a ghost :)

  31. Ge0rG

    Kev: yes, but then you realize that as soon as you send a message.

  32. Kev

    That is true.

  33. Ge0rG

    Kev: my point is that it's not always better than nothing.

  34. 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>

  35. Kev

    If you're referring to (3), then no.

  36. jonasw

    Zash, yes, but we can’t simply get rid of GC1, can we?

  37. Zash

    Can we?

  38. Kev

    jonasw: Can't we? :)

  39. jonasw

    Kev, council was against it.

  40. jonasw

    I mean, we can re-try, but ...

  41. jonasw

    speaking of council, still no (re-)applications?

  42. Kev

    Council may have been against it when there wasn't a better option, they may not be after this.

  43. Kev

    Only Joe Demo, by the look of it.

  44. Kev

    I hear good things about that guy.

  45. jonasw

    like Boaty McBoatface?

  46. Ge0rG

    Again, I want to propose Boardy McBoardface for Council.

  47. jonasw

    not Council McCouncilface?

  48. Ge0rG

    jonasw: no. C McC should apply for Board instead.

  49. jonasw

    for maximum confusion, I see

  50. Ge0rG

    I wonder if I should apply for Council, and then try to aggressively push the XMPP 2.0 / Easy Jabber agenda.

  51. Ge0rG

    Killing GC1.0 would be my major campain promise.

  52. jonasw

    hm, one can’t really make promises, can one?

  53. jonasw

    when running for council

  54. 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)

  55. Kev

    I kinda think that what xmpp2/easyjabber needs most, in some ways, is implementation and deployment experience.

  56. jonasw

    you can’t really do implementation without some specification

  57. Kev

    Of course you can.

  58. Zash

    Just type code into your thing!

  59. Kev

    You try something and see if it works.

  60. jonasw

    well, you shouldn’t

  61. jonasw

    hm

  62. Kev

    Also, completely untrue.

  63. Zash

    So you are a specification before implementation person?

  64. Kev

    Protocol documents based on people actually trying things is a jolly good thing.

  65. Zash

    Some are the other way around. Some think both at the same time!

  66. jonasw

    yeah, I see where you’re coming from

  67. Kev

    Everything has its place. Except the things that don't.

  68. 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

  69. Kev

    jonasw: Nothing says that has to happen in advance.

  70. Ge0rG

    Kev: I could implement Session 2.0, but then it would only work for IM.

  71. 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.

  72. 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'.

  73. 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

  74. jonasw

    itym MAM-subcsription

  75. Ge0rG

    jonasw: right. Sorry. I won't LMC that now.

  76. 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.

  77. Kev

    So all we need to do is achieve that :D

  78. Zash

    So how do we determine if a message is "chat-related"?

  79. Kev

    I did the hard work of coming up with the high-level direction. Someone else can work on the details.

  80. Zash

    type=chat would have been nice

  81. Ge0rG

    Kev: you are a genius! Why didn't anyone else think of that before? :D

  82. Ge0rG

    Zash: 0184 and CSNs happen to be type=random.

  83. jonasw

    also, what about type=normal? :)

  84. Zash

    Aren't those chat related?

  85. Ge0rG

    Zash: maybe they are.

  86. jonasw

    that certainly has messaging use-cases too, and wouldn’t you want to sync them, too?

  87. Ge0rG

    jonasw: chat is the new normal.

  88. jonasw

    that’s your opinio.n

  89. jonasw

    ;-)

  90. Ge0rG

    jonasw: that's what implementations do

  91. jonasw

    because no implemntation has a UI for type=normal

  92. jonasw

    except pidgins "let’s show this in a separate window focus stealingly" counts as UI

  93. Ge0rG

    jonasw: I think many client authors don't care about "normal" vs. "chat", and end up sending non-body messages with "normal"

  94. jonasw

    meh.

  95. Ge0rG

    Like for example ACKs.

  96. Zash

    -xep 304

  97. Bunneh

    Zash: XEP-0304: Whitespace Keepalive Negotiation (Standards Track, Deferred, 2011-08-18) See: https://xmpp.org/extensions/xep-0304.html

  98. Ge0rG

    jonasw: also guess which message type is mandated by [xep 0184]

  99. jonasw

    "whatever works"?

  100. Zash

    Ge0rG: {}

  101. Ge0rG

    Zash: -ETOOMANYDIFFERENTBOTS

  102. Zash

    Bots bots bots

  103. Ge0rG

    can't we just have all bot react to all patterns, instead of putting the cognitive load onto people?

  104. Zash

    Wasn't both 184 and csn using the standard reply pattern? Ie same type

  105. Ge0rG

    -xep standard reply pattern

  106. Bunneh

    Ge0rG: XEP-0068: Field Standardization for Data Forms (Informational, Active, 2012-05-28) See: https://xmpp.org/extensions/xep-0068.html

  107. Zash

    Copy attributes, swap to/from. If it's an error, set type=error.

  108. Ge0rG

    Zash: There is no such primitive in the XMPP lib I'm using.

  109. jonasw

    Ge0rG, switch XMPP libs then!

  110. jonasw

    Zash, also, you shouldn’t be copying the @id for anything except IQ, I think

  111. Ge0rG

    Zash: I'm not even convinced this is a good thing, generally. Maybe type=headline would be more appropriate for ACKs and CSNs?

  112. Kev

    I think acks you probably want stored in your archive, while CSNs you certainly don't.

  113. Zash

    Kev: Are you sure?

  114. Ge0rG

    Right. ACKs need to be archived.

  115. 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.

  116. jonasw

    Kev, as much as possible, of course.

  117. Ge0rG

    Kev: it's all about synchronizing a chat database.

  118. Ge0rG

    Kev: yes please. Make the most revolutionary proposal you can imagine.

  119. Kev

    Have your server handle your acks for you. Also have the server archive read receipt status for your messages.

  120. 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.

  121. Ge0rG

    Kev: I think MAM would be indeed a good place to send 0184 acks, from the bare JID

  122. Kev

    Delivered, Read, LMC. Store them, but on the message they affect, not on their own.

  123. Ge0rG

    Kev: that message collation would work much better if we had properly-generated UUIDs

  124. Ge0rG

    Does "unique" also mean that there should be only one UUID per message?

  125. Zash

    Kev: I object to anything that makes it impossible to do MAM in an append-only log store thing.

  126. Ge0rG

    Kev: BTW that almost sounds like a multi-table relational database

  127. Zash

    I object to anything that requires a relational database.

  128. Ge0rG

    Zash: better apply for Council now, then

  129. Kev

    I think the most sensible way to implement MAM is with a database of some description. But clearly it's not needed.

  130. Ge0rG

    Kev: how would clients synchronize? Atomic replacement of [Message, Delivered, Read, [LMCs], [Reactions]] n-tuples? Or do we need a separate chronological history?

  131. Kev

    Synchronise in which sense?

  132. Ge0rG

    This is again the fully-synchronized fat client vs. load-on-demand thin client debate I think

  133. Kev

    Possibly.

  134. Ge0rG

    For load-on-demand it makes sense to initially query for n-tuples, and then to receive a stream of deltas.

  135. Ge0rG

    For fat clients it makes sense to receive a stream of stored deltas, followed by live deltas.

  136. Kev

    That is possibly true.

  137. Ge0rG

    Now this is another thing I had in MAM-sync: push of MAM-IDs for sent messages.

  138. jonasw

    isn’t that already a thing in {XEP 0280}?

  139. jonasw

    damnit

  140. Zash

    -xep carbons

  141. Ge0rG

    jonasw: no

  142. Bunneh

    Zash: XEP-0280: Message Carbons (Standards Track, Proposed, 2017-02-16) See: https://xmpp.org/extensions/xep-0280.html

  143. jonasw

    no, I misremember

  144. Ge0rG

    jonasw: I tried to bring that up a year ago or two, and there were very loud voices arguing against that, because of sysload

  145. Zash

    I think someone (mattj?) suggested a carbons extension/change where you'd get your own messages reflected back

  146. jonasw

    what

  147. Zash

    syswhat

  148. Kev

    I'm not entirely convinced that just mirroring the entire (annotated) stanza back isn't sensible.

  149. Ge0rG

    If I were redoing XMPP, I'd glue together session, MAM ID reflection and 0198

  150. Ge0rG

    Kev: maybe except for https://xmpp.org/extensions/xep-0047.html#message

  151. jonasw

    what’s session in this context?

  152. Ge0rG

    jonasw: that thing you bind.

  153. jonasw

    ah

  154. 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

  155. Ge0rG

    I'm not opposed to the Carbons wire format, just the current processing logic is insane.

  156. jonasw

    sounds reasonable

  157. jonasw

    still possible to do that even without redoing xmpp

  158. Kev

    Everything's possible without redoing xmpp :)

  159. Ge0rG

    jonasw: still doesn't solve the persistency/urgency problem.

  160. jonasw

    Ge0rG, that needs fixes to MAM, Carbons, CSI and Push. All of which aren’t final yet, right?

  161. Ge0rG

    jonasw: are there any final XEPs at all? I thought Draft is the new Final.

  162. jonasw

    XEP-0030 :)

  163. jonasw

    (for example)

  164. moparisthebest

    I'm pushing to make 368 final

  165. moparisthebest

    but also considering I nor any current editors have ever seen a move to final

  166. moparisthebest

    no

  167. jonasw

    moparisthebest, no worries :)

  168. jonasw

    just prepare your PR and see what council says.

  169. moparisthebest

    yea I'm just agreeing with Ge0rG here, final isn't a thing, draft is final

  170. 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.

  171. Flow

    isn't the question what the benefit of final XEPs is, over draft XEPs?

  172. Flow

    as far as I can tell, final only has disadvantages

  173. jonasw

    Flow, what advantages does Draft have over Experimental? :)

  174. Flow

    jonasw: another review round at least by the council and probably by the xmpp community

  175. jonasw

    okay

  176. jonasw

    then final probably doesn’t bring you anything :)

  177. Flow

    plus at least so und so many implementations IIRC

  178. jonasw

    that’s only with Final IIRC

  179. Flow

    ahh right

  180. 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

  181. Flow

    (I was thinking that this was for draft)

  182. Ge0rG

    There is no technical difference between a namespace bump and a new namespace, so why are we forbidding them?

  183. SamWhited

    Ge0rG: they are not treated differently, changing the namespace is forbidden in final.

  184. Ge0rG

    SamWhited: yes, so we end up with a new XEP with a new namespace instead.

  185. 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.

  186. Ge0rG

    SamWhited: yes, I'm merely questioning the wisdom of that

  187. 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.

  188. 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".

  189. Ge0rG

    SamWhited: I'm just some random smartass, questioning everything. But I also wondered if other parts of our process might be improvable.

  190. SamWhited

    I definitely think there's room for improvement, but never stabalizing anything probably isn't it.

  191. jonasw

    yeah

  192. jonasw

    I’m already not happy with XEPs changing at all

  193. Ge0rG

    Except when they are made better?

  194. jonasw

    even draft xeps sometimes undergo massive changes, see Bookmarks.

  195. Ge0rG

    I'm not implementing Bookmarks. Because the RECOMMENDED way doesn't work, and the working way is Historical.

  196. moparisthebest

    same with omemo?

  197. jonasw

    no, OMEMO has a XEP reflecting the current state now

  198. 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.

  199. Ge0rG

    jonasw: oh, it does?

  200. jonasw

    it uses the siacs namespace at least

  201. zinid

    the problem with namespaces bump is that I need to maintain all the code for previous namespaces, blowing the codebase, this is annoying

  202. jonasw

    another issue I have with that is that old versions are barely discoverable

  203. 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

  204. Ge0rG

    zinid: we can't bump the namespace on MUC, fortunately.

  205. zinid

    Ge0rG: and we resorted to replace this monster with another monster?

  206. Ge0rG

    zinid: MUC is not a monster. It's ugly, but it's not too large.

  207. zinid

    I have 4000 LOC of mod_muc* modules, isn't this a monster?

  208. zinid

    if it's not a monster, then what it is? I can recall pubsub only

  209. Zash

    Huh

  210. Ge0rG

    zinid: you know, bad specification is not the only cause of bloated software.

  211. Ge0rG

    Sometimes the problem is in front of the terminal, actually.

  212. moparisthebest

    ‎[02:06:51 PM] ‎Ge0rG‎: *snip* I don't believe in E2EE.

  213. moparisthebest

    what

  214. moparisthebest

    what possible reason could you not believe in E2EE, and in what way

  215. Zash

    It's not the golden saviour of humanity as some would have you believe

  216. 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.

  217. Zash

    Also it invalidates a bunch of the assumptions XMPP is built on

  218. Ge0rG

    moparisthebest: just the fact that Facebook-WhatsApp rolled out E2EE should make you think.

  219. 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.

  220. 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)

  221. moparisthebest

    so I agree, it doesn't solve everything, nothing does, it also doesn't harm anything either though

  222. jonasw

    it does

  223. moparisthebest

    I run my own server but still use E2E, what if the mam database is compromised or otherwise exposed?

  224. jonasw

    take a look at the number of people complaining about issues with OMEMO and blaming it on XMPP

  225. jonasw

    like losing messages in groupchats

  226. jonasw

    they don’t think the issue might be the experimental E2EE implementation they’re using.

  227. jonasw

    (or, maybe worse, blaming it on the server)

  228. Ge0rG

    moparisthebest: OMEMO failed to address the device migration use case, among others.

  229. 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.

  230. Flow

    uh Ge0rG droped the E2EE bomb

  231. Flow

    where is my popcorn? ☺

  232. Flow

    Ge0rG: you have a point here. But I'm not sure if E2EE couldn't be made user friendly

  233. Ge0rG

    Flow: what bomb? I'm making this points for years now.

  234. Flow

    Ge0rG: well I know, but obviously there are still people who act a little bit shocked when you say that

  235. moparisthebest

    your arguments all apply to OTR

  236. moparisthebest

    not at all to PGP

  237. moparisthebest

    and only a little bit to OMEMO

  238. moparisthebest

    so

  239. 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.

  240. Ge0rG

    moparisthebest: my arguments apply to all E2EE on top of XMPP

  241. 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?

  242. Flow

    moparisthebest: surely the problem isn't E2EE *on* XMPP

  243. Flow

    moparisthebest: no, he (and I) want you to run your own XMPP service

  244. Flow

    and federate with your the XMPP server that is run by your friends

  245. moparisthebest

    so every user runs their own server?

  246. 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.

  247. Flow

    We need to go away from big centralized XMPP services like jabber.ccc.de or jabber.at

  248. Holger

    moparisthebest: No matter what E2EE you're using, you can't do server-side search on your archive.

  249. Holger

    moparisthebest: No matter what E2EE you're using, you can't do server-side spam filtering.

  250. 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

  251. Flow

    under their own domain

  252. jonasw

    Holger, incorrect, WhatsApp does server-side spam filtering only with metadata.

  253. Flow

    Holger: Now that you said it: I never received OpenPGP encrypted spam. wonder when that is going to start

  254. moparisthebest

    Holger, as Ge0rG said you have metadata, most filtering is on that anyhow?

  255. jonasw

    moparisthebest, it doesn’t work with XMPP, you need to have control over all servers to effectively filter spam on metadata

  256. moparisthebest

    in fact all the current 'must be on roster' filtering works with e2e

  257. jonasw

    (well, it’s not exactly like that, but federation makes it so much more difficult)

  258. jonasw

    must-be-on-roster is a very very bad spam filter

  259. Flow

    yep, bad idea

  260. moparisthebest

    I agree

  261. 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.

  262. 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

  263. Holger

    Flow: It'll start once OX is ubiquitous of course :-)

  264. Flow

    hehe

  265. Flow

    sadly new clients still implement xep27 ;(

  266. Holger

    moparisthebest: Yeah, dumb. In practice people just give up this XMPP shit due to the E2EE breakage we introduce.

  267. Holger

    (I've seen *two* people saying just that *today*.)

  268. moparisthebest

    it's better than nothing (xep27)

  269. Flow

    moparisthebest: I don't think so. OpenPGP without a replay mitigation is worser than no verification at all

  270. Flow

    for example

  271. moparisthebest

    replay is a type of attack, sometimes it doesn't matter

  272. Flow

    ?

  273. jonasw

    Holger, whatsapp apperently does it quite well

  274. jonasw

    but I only heard that second- or third-hand

  275. moparisthebest

    Flow, sometimes you just need to protect content and don't care about replay

  276. 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.

  277. jonasw

    we need to solve those firts

  278. moparisthebest

    it's always going to have problems, everything does

  279. jonasw

    *especially* with security systems you can’t simply handwave problems away

  280. 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

  281. jonasw

    people don’t expect replay attacks to work

  282. 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.)

  283. jonasw

    and you can’t expect people to understand that

  284. jonasw

    Holger, they don’t have multi-device support?

  285. jonasw

    I thought they did.

  286. jonasw

    but how does that relate to spam filtering?

  287. Holger

    jonasw: No, they just have a web client that talks to your phone.

  288. jonasw

    eww

  289. 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

  290. moparisthebest

    but uh, "replay" is also a huge problem without e2e, so

  291. Ge0rG

    Holger: and because they have millions of dev budget.

  292. Flow

    moparisthebest: "the "here is your report for 2017-01-01 08:32 bla bla bla" is not"?

  293. moparisthebest

    Flow, if I get a dated report from last month I'll be pretty sure it's a replay I guess

  294. Holger

    Ge0rG: RIght.

  295. 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)

  296. 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.

  297. 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

  298. moparisthebest

    now I'd much rather use OX than 27, but 27 is better than nothing

  299. 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

  300. 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

  301. Holger

    moparisthebest: Yes, "no forward secrecy" and "one key per contact rather than per device" are clearly features I appreciate compared to OTR/OMEMO.

  302. moparisthebest

    right I completely agree OX is better Flow , but 27 is better than nothing

  303. Flow

    OpenPGP certainly has it's place

  304. Flow

    moparisthebest; And that is where I disagree with you ☺

  305. moparisthebest

    I find it most handy for where I used to send cronjob output as pgp encrypted email from my servers

  306. moparisthebest

    a sendxmpp that does OMEMO seems, hard

  307. Flow

    true

  308. moparisthebest

    Flow, how could 27 possibly be worse than no encryption exactly

  309. moparisthebest

    it doesn't prevent replay or spoofing, neither does no encryption

  310. Holger

    Wrong sense of security.

  311. Flow

    moparisthebest: what holger said

  312. moparisthebest

    it does protect content

  313. moparisthebest

    that's all it does, I know that, I'm fine with that

  314. Flow

    it may be sufficently secure for the use case you described

  315. Flow

    but not for the gernal IM use case

  316. moparisthebest

    100% agree OX should be pushed forward and I will drop 27 first :P but until then

  317. Flow

    OX would be able to prevent spoofing, xep27 is not

  318. Flow

    It's such a pitty that there is no high level OpenPGP library for java

  319. moparisthebest

    you could do android first :)

  320. moparisthebest

    in fact there was a WIP OX pull request for conversations

  321. Flow

    (Java/Android that is)

  322. moparisthebest

    android has an excellent openpgp implementation/app

  323. Flow

    I know, OX was born because I meet the OpenKeychain dev's at the GSOC mentor's sumimt 2015

  324. Flow

    *met

  325. Flow

    I've been begging them to factor out the OpenPGP part of OpenKeychain into a library for Java and Android

  326. moparisthebest

    on android at least it's better as-is isn't it?

  327. moparisthebest

    as a PGP app that's usable by other apps

  328. Flow

    I'm sorry, I don't know how to parse that

  329. Flow

    Ahh yes, that was our idea for the conversations OX implemenation

  330. moparisthebest

    I don't want to import my key into conversations, and k9mail, and oandbackup

  331. moparisthebest

    I instead import it into OpenKeychain, and it does all the lifting, and the other apps just talk to it

  332. Flow

    OK (OpenKeychain) was missing a few additional exposed APIs for OX in conversations

  333. Flow

    but the effort stalled

  334. Holger

    moparisthebest: I don't want to import any keys anywhere.

  335. 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

  336. 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.

  337. moparisthebest

    oh well that's a different thing, yea I'm sure they'd add additional apis

  338. moparisthebest

    Holger, omemo?

  339. Holger

    moparisthebest: OX, maybe.

  340. Holger

    moparisthebest: https://xmpp.org/extensions/xep-0373.html#synchro-pep

  341. moparisthebest

    hmm I'm not sure 1 key being automagically distributed is better than one key per device

  342. moparisthebest

    yea I remember reading it, I'm not convinced I want my encrypted key on my server

  343. Holger

    moparisthebest: IMO it makes the difference between "completely unusable" and "maybe somewhat usable" by non-geeks.

  344. Holger

    moparisthebest: Do you have a single non-geek in your roster you're talking PGP to?

  345. moparisthebest

    I think you are right actually

  346. moparisthebest

    in that the normal case it should do that

  347. moparisthebest

    but should also allow me to use my already-set-up-not-on-server key

  348. moparisthebest

    Holger, uh yes, but you didn't ask if I had to set up their pgp key for them or not :)

  349. Holger

    Yah I'm not discussing Advanced -> Expert -> Special options.

  350. 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 :'(

  351. Holger

    I had like five and am down to three I think.

  352. Holger

    Of my ~150 contacts.

  353. Holger

    If which 100+ are geeks :-)

  354. Holger

    s/If/Of

  355. moparisthebest

    what client(s) do you use?

  356. Holger

    MCabber and Conversations.

  357. 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

  358. Holger

    I heard of various issues with Gajim's PGP support but never tried myself.

  359. Holger

    Works just fine with my two clients.

  360. 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

  361. Holger

    Ah right gpg2 is a PITA for MCabber as well. The fix is sticking to gpg1.

  362. Holger

    (Though McKael is somehow using gpg2 I think ...)

  363. moparisthebest

    iirc it worked fine with gpg 2 but 2.1 broke it

  364. moparisthebest

    I think the python lib is hardcoded to treat unknown errors fatally instead of a generic error and that breaks everything

  365. moparisthebest

    I need to look into it one day

  366. zinid

    I'm not a security expert, but what is a problem to keep private key securely on a server?

  367. McKael

    Holger: Yes I'm using GPG2 but it's painful, indeed.

  368. moparisthebest

    McKael, have any patches laying about or a terrible wrapper script or what? :)

  369. zinid

    can't I just encrypt it using my password which is supposedly stored hashed as well?

  370. McKael

    moparisthebest: No, lately I've been using the default pinentry and it messes things up

  371. McKael

    Not sure how I got rid of that before, I forgot :/

  372. 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

  373. zinid

    I don't understand, according to e2e proponents, they don't trust server admins

  374. 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 ...

  375. Wiktor

    zinid: you don't store the private key even encrypted because loss of password would compromise the key

  376. Wiktor

    I'm not using PGP with xmpp though

  377. Wiktor

    But usually you don't even store the private key in software but use hardware token

  378. Wiktor

    To further protect the key

  379. zinid

    but you can also lose private key

  380. Holger

    "usually" :-)

  381. zinid

    Holger: lol :)

  382. 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

  383. zinid

    and typically you lose private key with losing phone for example

  384. zinid

    still not clear

  385. zinid

    I cannot believe there is no solutions for this problem, key servers? kerberos? just to mention, I know jack shit about these :)

  386. Holger

    matlag: The server has a clear-text copy of the key encryption PW??

  387. matlag

    no, only the date of the latest change

  388. Holger

    Ah.

  389. Holger

    So simply a separate passphrase?

  390. matlag

    yep

  391. Holger

    "Hello User, please type your password! ... thanks, now please type your other password!"

  392. zinid

    which will be the same for the majority of users :)

  393. Holger

    They'll love you.

  394. Wiktor

    zinid: truly paranoid store their private key copies only on offline, airgapped machines, then load it on OpenPGP smart card

  395. Wiktor

    Note I'm not advocating for that

  396. zinid

    Wiktor: are we building a network for trully paranoid?

  397. zinid

    Wiktor: can we just have non-paranoid mode/

  398. zinid

    ?

  399. matlag

    well, currently the risk is "Hello User, please type your password! ... now please type your entire private key"

  400. Wiktor

    I'm not building anything just saying there are various threat models in existence

  401. matlag

    zinid, you need to fit all the needs! so paranoid should be an option

  402. zinid

    matlag: sure, don't store private keys on server, keep them on hardwared device

  403. zinid

    I mean it's totally opaque for the server where you keep your keys

  404. 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.

  405. zinid

    but still a problem with password restoration indeed

  406. 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.

  407. zinid

    I agreed

  408. 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

  409. zinid

    currently users are trying to use OMEMO, they fail and resort not to using OMEMO at all

  410. zinid

    so probably better to use less secure option?

  411. matlag

    I mean: is that so much more cumbersome than changing your home's wifi password?

  412. Holger

    zinid: They resort to ditching the non-working XMPP crap.

  413. Holger

    matlag: The point is it's so much more cumbersome than just using WhatsApp/Signal/whatever.

  414. 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

  415. matlag

    Yeah, ok, point taken

  416. 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

  417. 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

  418. zinid

    but all 16 characters will be lost?

  419. Holger

    moparisthebest: Won't help much if you're trying to protect against the case where the password is lost.

  420. zinid

    because they are stored in a single place, no?

  421. matlag

    moparisthebest, They end up typing the 16 characters and that's the same as having hte same PW for both

  422. Holger

    (zinid was faster.)

  423. 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.

  424. 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

  425. zinid

    Wiktor: but usually I'm not talking about e2e :)

  426. zinid

    I think it's still just a toy

  427. moparisthebest

    Ge0rG, meh that's still just fully trusting the server

  428. moparisthebest

    I mean you already have full disk encryption and such on the server

  429. Holger

    Wiktor: Agreed! I'd just disable encryption by default. But everyone is telling me it MUST be enabled by default, or even always.

  430. Zash

    Ge0rG: Wanna the crypto design and audit?

  431. Wiktor

    zinid: agreed, but for me it's a toy for power users, like PGP itself

  432. 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?

  433. moparisthebest

    or just don't have a password on the local pgp key

  434. 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 :-)

  435. zinid

    Wiktor: then nothing should be changed, everything is great

  436. moparisthebest

    it's storing full conversations in plain text anyway, most likely

  437. Wiktor

    Holger: on my client it's disabled by defiant and I use it with one contact for 239 unencrypted

  438. Wiktor

    For me that's a good ratio

  439. Holger

    Wiktor: The Conversations tracker is full of people complaining how OMEMO is optional and non-default.

  440. Wiktor

    zinid: w.r.t. To omemo just add support for key migration / rotation and easier adding of new devices

  441. 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

  442. Ge0rG

    Zash: maybe one day I'll find a corporate customer that will pay for it

  443. moparisthebest

    because default is how it stays 99% of the time

  444. Ge0rG

    Zash: I remember that, yeah

  445. moparisthebest

    and if we've learned anything over the past 5 years or whatever, encryption should always be default

  446. moparisthebest

    at least, most people have learned that

  447. Holger

    Wiktor: ^ see?

  448. zinid

    :D

  449. Wiktor

    Hshshw

  450. Holger

    Wiktor: So how to deal with all the moparisthebests in the community? :-)

  451. Wiktor

    Hahaha*

  452. Zash

    moparisthebest: I'm not convinced that XMPP is the right thing if you wanna have a protocol where everything is encrypted.

  453. moparisthebest

    :)

  454. Wiktor

    Great point Holger

  455. moparisthebest

    Zash, do you know of better ones that don't eat battery due to p2p ?

  456. Zash

    XMPP is a giant compromise. Compromise between p2p and centralized.

  457. 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)

  458. moparisthebest

    all of it, imho

  459. moparisthebest

    I mean, TLS/transport encryption should be mandatory with no cut-off

  460. Wiktor

    moparisthebest: well it is on xmpp since 2014?

  461. moparisthebest

    e2e should be default, with the ideal of no cut-off

  462. Holger

    moparisthebest: Apart from that, I should be rich!

  463. moparisthebest

    that's the ideal isn't it? :P

  464. 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?

  465. 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

  466. moparisthebest

    Wiktor, it still defeats passive surveillance which is ubiquitous

  467. Wiktor

    Tls defeats passive surveillance

  468. moparisthebest

    also all the server hack leaks everywhere

  469. SamWhited

    Why? What is the actual thing you are trying to accomplish by making e2e encryption the default?

  470. Zash

    moparisthebest: By whom? e2e protects against some cases of evil server, but in XMPP, if your server is evil, you are screwed

  471. moparisthebest

    you don't have to trust your server, so why trust your server

  472. moparisthebest

    and, your chat partner's server if not the same

  473. zinid

    Zash: the point I'm told is that the remote server can be evil and you can do nothing with it

  474. 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

  475. moparisthebest

    also define 'screwed', it can block your messages, it can't do anything else with e2e

  476. moparisthebest

    Wiktor, again an active attack that you can detect before, during, or after

  477. Zash

    zinid: Sure, you have to trust that your chat partner picked a trustworthy server too.

  478. moparisthebest

    vs you having no idea who has your messages when

  479. Wiktor

    Well usually only your server and your friend's has messages, in xmpp they are directly connected.

  480. zinid

    Zash: I agree you cannot build security without trust, the question is how paranoid we should be

  481. 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.

  482. moparisthebest

    Wiktor, do I know if they are connected securely

  483. moparisthebest

    do I know if the other users server mandates encryption on c2s

  484. moparisthebest

    tls in this case

  485. Wiktor

    Well your server should mandate your security standards

  486. moparisthebest

    but if you sign up for newhotserver.im

  487. moparisthebest

    you think key verification is the problem

  488. moparisthebest

    but the solution is to personally trust your server operator?

  489. moparisthebest

    seems suspicious

  490. Wiktor

    Then do you know if your friends computer is not compromised by malware?

  491. moparisthebest

    it's about minimizing risk, that's a risk either way

  492. moparisthebest

    you have to trust your friend's endpoint

  493. moparisthebest

    you don't have to trust everything in between

  494. Wiktor

    Key verification is always the biggest problems :)

  495. Wiktor

    Yes it's about minimizing risk but if the advantage is small enough then it's not ok to mandate e2e everywhere

  496. SamWhited

    Or if it actually makes things worse…

  497. moparisthebest

    what if it doesn't have any disadvantages

  498. Wiktor

    Yes, exactly. There are always trade offs

  499. zinid

    moparisthebest: but it does

  500. moparisthebest

    you mean some current systems do

  501. zinid

    yes

  502. Wiktor

    > what if it doesn't have any disadvantages I've never seen a solution to anything without disadvantages. There are always constraints.

  503. zinid

    and security is always inversly proportional to usability

  504. zinid

    whatever encryption you suggest, you lower the usability part

  505. zinid

    so users should clearyl understand why they suffer

  506. moparisthebest

    that's not true though

  507. moparisthebest

    do you have your laptop hard drive encrypted?

  508. zinid

    moparisthebest: that's not even my words, Schneier said that :)

  509. zinid

    moparisthebest: no, I don't

  510. moparisthebest

    even great guys can be wrong sometimes haha

  511. moparisthebest

    ok well that's just inexcusable why? :P

  512. moparisthebest

    I guess if it never leaves your house it's probably fine

  513. zinid

    moparisthebest: I don't know how to do this

  514. Wiktor

    HD encrypted can be a usability nightmare if you have your keys only in TPM and TPM died :)

  515. zinid

    is it ok answer? :)

  516. 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

  517. 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

  518. 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.

  519. SamWhited

    That is a trade off.

  520. 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.

  521. matlag

    if you increase security, then you need the user intervention, and as you increase it, more and more user intervention

  522. moparisthebest

    a few sectors include the key normally SamWhited

  523. 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)

  524. 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.

  525. moparisthebest

    really that's a bad example anyway, the users I see generally expect chat to be ephemeral anyway

  526. moparisthebest

    so if they forget their password and don't have logs from yesterday, oh well

  527. moparisthebest

    I guess it's a trade off but also maybe what they expect?

  528. zinid

    a good example is probably how PKIX is used currently in browsers

  529. moparisthebest

    (I'm basing this on all the users that want to be able to delete shared pictures from http upload)

  530. Ge0rG

    I expect IM history to be eternal. Maybe I'm different.

  531. zinid

    very little inconvenience

  532. moparisthebest

    Ge0rG, then you already have backups and such and will get that with e2e also

  533. Ge0rG

    moparisthebest: e2ee is more complicated than not having it.

  534. Ge0rG

    moparisthebest: the people who are the loudest to demand e2ee have the least understanding of it, usually.

  535. Ge0rG

    And I'm on the road for almost eight hours now. German public transportation has been severely impacted by some storm.

  536. moparisthebest

    I guess everything is more complicated than not having it

  537. Ge0rG

    moparisthebest: Easy XMPP is an exception

  538. zinid

    xmpp2 !!!111

  539. moparisthebest

    still more code

  540. zinid

    Ge0rG: btw, your subject about message routing didn't route further in the standards@ :)

  541. zinid

    Ge0rG: my guess is that nobody knows how to fix stuff, lol

  542. moparisthebest

    can we make direct tls the only way to connect in xmpp2 ? :P

  543. zinid

    adding more xeps => sucks breaking compatiblity => sucks

  544. zinid

    moparisthebest: is it the major problem? :)

  545. moparisthebest

    no just another nice-to-have

  546. moparisthebest

    also I don't see any trade-offs with this one haha

  547. zinid

    the trade-off is more implementation

  548. zinid

    poor library support

  549. moparisthebest

    for direct TLS ?

  550. moparisthebest

    surely it's the opposite

  551. zinid

    yes

  552. moparisthebest

    every TLS lib ever vs xmpp-specific-libs ?

  553. zinid

    you need to support SNI in server, that's some work if you use openssl ;)

  554. zinid

    ejabberd doesn't support it for this reason, the API is ugly as hell

  555. moparisthebest

    you are already doing far more work for everything else in xmpp2 surely

  556. zinid

    I need to be a man and implement it

  557. moparisthebest

    anyway it gives you tons of other advantages

  558. moparisthebest

    0-rtt, false start, everything fancy https gets

  559. zinid

    isn't this the trade-off we're talking about? :)

  560. zinid

    you get all these goods, but need to put more code, at least server side

  561. zinid

    and ALPN is only supported in openssl 1.0.2, some systems still don't have it yet

  562. moparisthebest

    you are talking about xmpp2 though, it's all more code

  563. MattJ

    I think I'd rather rewrite everything XMPP from scratch than spend time near OpenSSL's API again

  564. zinid

    moparisthebest: that was a joke actually :) obviously transition to xmpp2 will bring lots of pain

  565. moparisthebest

    also zinid 1.0.1 is already dead so I don't think anyone should care, hopefully :(

  566. moparisthebest

    yea openssl is the perfect example of a footgun api

  567. zinid

    moparisthebest: surprisingly, we get complains from time to time about cutting edge version requirement (1.0.1), lol :)

  568. Holger

    "zinid 1.0.1 is already dead"

  569. zinid

    ah

  570. Holger goes updating zinid.

  571. moparisthebest

    context, it's all about context :P

  572. zinid

    but still I think direct tls is a great idea