XSF Discussion - 2019-01-01

  1. l has left

  2. l has left

  3. oli has left

  4. oli has joined

  5. UsL has left

  6. UsL has joined

  7. oli has left

  8. oli has joined

  9. oli has left

  10. oli has joined

  11. Guus

    Same to you, Seve!

  12. edhelas

    Happy new year to you all 🎉🎆

  13. oli has joined

  14. Ge0rG

    XEPpy new year!

  15. UsL has joined

  16. mathieui

    zimpy new year to you, Ge0rG

  17. nyco has left

  18. oli has left

  19. oli has joined

  20. oli has left

  21. oli has joined

  22. lskdjf has left

  23. UsL has left

  24. UsL has joined

  25. oli has left

  26. oli has joined

  27. lskdjf has joined

  28. genofire has left

  29. chunk has joined

  30. flow has left

  31. flow has left

  32. flow has left

  33. flow has left

  34. flow has left

  35. Zash has left

  36. marc_ has left

  37. l has left

  38. l has left

  39. l has left

  40. Zash has left

  41. l has joined

  42. Zash has left

  43. half-shot_ has joined

  44. half-shot_ has left

  45. lskdjf has joined

  46. neshtaxmpp has joined

  47. neshtaxmpp has left

  48. neshtaxmpp has joined

  49. waqas has left

  50. neshtaxmpp has left

  51. thorsten has joined

  52. sezuan has left

  53. tux has left

  54. tux has joined

  55. thorsten has left

  56. thorsten has joined

  57. igoose has left

  58. igoose has joined

  59. waqas has joined

  60. frainz has left

  61. frainz has joined

  62. UsL has left

  63. UsL has joined

  64. alacer has joined

  65. lumi has left

  66. chunk has joined

  67. alacer has left

  68. moparisthebest has joined

  69. jjrh has left

  70. Neustradamus

    Happy new year to all

  71. jjrh has left

  72. mimi89999 has left

  73. mimi89999 has left

  74. mimi89999 has joined

  75. labdsf has left

  76. alacer has joined

  77. labdsf has joined

  78. thorsten has left

  79. moparisthebest has joined

  80. mimi89999 has joined

  81. ta has joined

  82. lnj has left

  83. alacer has left

  84. alacer has joined

  85. marc_ has joined

  86. waqas has left

  87. jjrh has left

  88. jjrh has left

  89. marc_ has left

  90. jjrh has left

  91. jjrh has left

  92. jjrh has left

  93. jjrh has left

  94. ta has joined

  95. jjrh has left

  96. Nekit has joined

  97. tux has left

  98. tux has joined

  99. jjrh has left

  100. jjrh has left

  101. lnj has joined

  102. lorddavidiii has joined

  103. lnj has left

  104. marc_ has joined

  105. nyco has joined

  106. chunk has joined

  107. alacer has left

  108. chunk has left

  109. Tobias has left

  110. Tobias has joined

  111. chunk has joined

  112. intosi has left

  113. intosi has joined

  114. oli has left

  115. oli has joined

  116. chunk has joined

  117. l has joined

  118. MattJ has left

  119. alacer has joined

  120. Zash has joined

  121. mimi89999 has joined

  122. lskdjf has joined

  123. Steve Kille has left

  124. oli has joined

  125. lovetox has joined

  126. oli has joined

  127. Steve Kille has joined

  128. ThibG has joined

  129. ThibG has joined

  130. l has left

  131. neshtaxmpp has joined

  132. moparisthebest has joined

  133. moparisthebest has joined

  134. l has joined

  135. ThibG has left

  136. ThibG has joined

  137. lorddavidiii has left

  138. Syndace

    It seems like some clients allow sending OMEMO encrypted messages even to untrusted entities. I'm not sure whether I want to allow that in my library. Any pros/cons?

  139. Syndace

    Starting off the new year with a nice little OMEMO discussion :D

  140. daniel has joined

  141. winfried has joined

  142. neshtaxmpp has left

  143. lovetox

    that makes not much sense

  144. lovetox

    if you want to do that add another trust state

  145. lovetox

    called Undecided or whatever

  146. mimi89999 has joined

  147. lovetox

    but in general i would not advise to add an option to every crazy idea a developer gets

  148. lovetox

    he can implement this on top of the lib

  149. lovetox

    in my opinion the lib should only know, should i prevent sending this or not, True or False, and this info should be supplied by the client depending on the context

  150. pep.

    I have wrongly fed Syndace with false information. I thought Conversations was allowing that, but no it does force me to trust before sending. I have "Blind Trust Before Verification" unchecked, I don't know if that happens in general

  151. neshtaxmpp has joined

  152. pep.

    lovetox, "if you want to do that add another trust state", this is only possible in the client, not in the OMEMO lib, maybe in the XMPP lib

  153. Syndace

    pep.: That's fine, I was still interested in other peoples opinions about that.

  154. lovetox

    Gajim lets you also send a message if you dont trust every device, why not?

  155. Syndace

    lovetox: Thanks, that's exactly what I thought. If someone really wants to allow that, he can circumvent my libs trust management and create his own.

  156. lovetox

    that does mean the message is encrypted to THAT device

  157. lovetox

    Syndace, he does not need to circumvent it, your lib does not implement storage or?

  158. Syndace

    lovetox: My lib does it all ^^

  159. Syndace

    Including some trust management.

  160. oli

    Syndance: what harm does it do to encrypt untrusted entities? https://tools.ietf.org/html/rfc7435

  161. lovetox

    hm where Syndace dont see it in the code

  162. lovetox

    you have a storage api, you dont implement the backend

  163. lovetox

    so you dont control what gets stored and where

  164. lovetox

    so i can manipulate this on write and on read

  165. lovetox

    your lib never knows whats stored in thedb

  166. Syndace

    Which is essentially circumnventing the trust management, right

  167. lovetox

    and i can implement 10 truststates and save it to the db

  168. Syndace

    Just what I was saying

  169. half-shot_ has joined

  170. lovetox

    and on in read i just manipulate it so that i translate it to something that your lib understands

  171. Syndace


  172. Syndace


  173. lovetox

    thats not circumventing it in my opinion, i use the api the lib provides

  174. lovetox

    you no where define in what ways i have to use it

  175. lovetox

    but thats splitting hairs

  176. Syndace

    Well you can't use the trust and distrust of the SessionMamager

  177. Syndace

    Which is the official public API to do trusting

  178. Syndace

    Okay so back to the topic. You guys say that it's a good idea to always allow even unauthenticated encryption?

  179. lovetox

    see thats maybe a option, to make that IsThisTrusted method be overwritten by the client

  180. lovetox

    if he wants

  181. lovetox

    are keytransport messages sent only if the contact is trusted?

  182. Syndace


  183. lovetox

    see thats where i would want to send maybe a keytransport message even to contacts i have no trust to, or not decided yet

  184. lovetox

    there is no harm in that for the user

  185. lovetox

    and i can answer a prekey message instantly, without asking the user for trust

  186. pep.

    Ok so in reality it's not "sending to an unstrusted device", it's the client that tells the OMEMO lib "I trust this device", even in an "undecided" state

  187. Syndace

    I think this is where the "blind trust before verification" concept comes into play

  188. lovetox

    No Syndace it means something different

  189. lovetox

    bbtv means i trust the client with everything

  190. lovetox

    i just want to establish a session and answerr a prekey message

  191. ta has joined

  192. lovetox

    either way, to answer your question as you see, clients want to do different things, so maybe your isTrusted() method, should be able to be overwritten

  193. lovetox

    so clients can implement their own concept of what is trusted and what not

  194. pep.

    yeah, trust management is done on the client

  195. pep.

    I mean,

  196. ThibG has joined

  197. pep.

    I can tell the OMEMO lib whatever I want

  198. pep.

    The lib keeps the state

  199. sezuan has left

  200. Syndace

    lovetox, just making the isTrusted method overwritable doesn't fix the issue I'm afraid

  201. benpa has joined

  202. uhoreg has joined

  203. _purple_bot has joined

  204. Matthew has joined

  205. Syndace

    You would need additional info like "this is the first keytransportmessage in response to a prekeymessage"

  206. Syndace

    To allow for complex trust stuff like you described

  207. lovetox

    Syndace, it was not a real code proposal, you know your lib, it just was to describe the concept

  208. Syndace

    Sure I get that

  209. Syndace

    I'm just thinking about how I could make such use-cases possible

  210. lovetox

    hm i would not focus on the example i have given, just how to solve it generic

  211. lovetox

    you lib loads a trust from the db

  212. lovetox

    1. do you expect a certain value here? maybe ints 1, 2, 3?

  213. lovetox

    2. and some where down the line you evaluate what you loaded in your isTrusted()

  214. Half-Shot has joined

  215. Syndace

    Yeah but that's the thing, a generic solution must also allow to implement the example you gave.

  216. lovetox

    so why not pass what was loaded from the db (which could be anything you dont have to care) to the client in a isTrusted() call

  217. lovetox

    and the client returns True or False

  218. Syndace

    And I don't see how to do that without a ton of information about the whole context of that message/conversation

  219. lovetox

    so pass another info, for what the trust is used

  220. lovetox

    KeyTransport or Message

  221. lovetox

    i mean there is only these 2 or?

  222. lovetox

    but yeah i see it gets more complicated

  223. lovetox

    hm or maybe easier

  224. Half-Shot has left

  225. lovetox

    the client invokes the encryption or not?

  226. lovetox

    maybe it can pass a "ignore_trust=True"

  227. lovetox

    on that one encryption

  228. lovetox

    for the key transport message

  229. Syndace

    Hehe that's what I had before

  230. lovetox

    yeah but then its fine for the example ive given

  231. Syndace


  232. lovetox

    i can send a message if i really have to

  233. Syndace

    I guess that's the road I have to go down again.

  234. Syndace

    Okay, so now there is a new question

  235. Syndace

    Let's only look at messages, that have actual content. A text message and not an empty KeyTransportMessage. Is there any reason to allow sending such messages to untrusted entities?

  236. lovetox

    i think we have to define what untrusted means

  237. lovetox

    for me and in gajim

  238. Syndace

    I could allow that *only* for empty KeyTransportMessage used ti do some ratchet forwarding

  239. lovetox

    untrusted means, the user set the state to RED - UNTRUSTED himself via UI

  240. lovetox

    i personally see no reason to encrypt anything to that device ever

  241. lovetox

    but maybe someone has another idea

  242. Half-Shot has joined

  243. lovetox

    then i have another state in Gajim, it is orange and means UNDECIDED, i received a message from that unknown device

  244. Syndace

    For me untrusted is everything that is not explicitly trusted. That means undecided also means untrusted.

  245. lovetox

    the user had no time to make a trust decision, or he wants to delay it, because i wants to physically check the fingerprint

  246. lovetox

    and then there is Trusted and blind trust, but it should be the same for the lib

  247. lovetox

    i specifically care about that Undecided state

  248. Syndace

    In the undecided state, does Gajim send encrypted text messages to those devices?

  249. lovetox

    but it would work for me, if i can just pass a ignore_trust=True on the key transport

  250. lovetox

    no, syndace, but it can receive messages

  251. Syndace

    Receiving is a different topic

  252. Syndace

    I allow decryption from untrusted entities

  253. lovetox

    so no, messages are not encrypted to undecided devices

  254. Syndace

    Okay. And I feel like this is the behaviour I see around clients

  255. Holger

    I think 'trusted' devices should be those I send messages to. So there's no 'undecided' state here. I either send or send not messages to a device.

  256. Holger

    The other thing is verified vs. unverified.

  257. lovetox

    You speak as a User Holger, and yes i agree because with message you mean text message

  258. lovetox

    but there are protocol messages, where no user data is sent

  259. lovetox

    and i see no problem sending these to undecided devices, there is no harm

  260. Syndace

    So can we agree that empty KeyTransportMessages should be available no matter the trust status and everything else (with actual content) is only available if you explicitly trust?

  261. Holger

    lovetox: Right.

  262. lovetox

    i think this is sensibel Syndace

  263. Syndace

    Cool! Thank you :D

  264. half-shot_ has left

  265. Half-Shot has left

  266. Half-Shot has joined

  267. oli

    From a users perspective I want green - verified yello - unverified red - blocked

  268. oli

    so if you don't allow omemo messages, would non-encrypted messages also be blocked?

  269. Syndace

    oli: Non-encrypted stuff is not affected by anything OMEMO

  270. Syndace

    so no

  271. lovetox

    Syndace, is a lib author, he has zero to do with client UI

  272. Half-Shot has left

  273. oli

    I just wanted to write that I don't see the reason to refuse sending OMEMO messages to untrusted devices at all.

  274. oli

    (if none of the fingerprints of the JID is trusted)

  275. lorddavidiii has joined

  276. oli

    but I realize that you kind of sign the encrypted message.

  277. lovetox

    we have to take care what the terms mean, untrusted means for you, you didnt trust but also not block, but in Gajim untrusted means blocked

  278. benpa has joined

  279. uhoreg has joined

  280. _purple_bot has joined

  281. Matthew has joined

  282. lovetox

    Syndace, maybe thats also a good idea, to write this down in your documentation, what untrusted means in the context of the lib

  283. lovetox

    especially that it doesnt mean "Not Trusted Yet"

  284. lovetox

    aka Undecided

  285. Syndace

    oli: I understand what you mean, I had a little read on the RFC you linked. I think that BTBV is basically the TOFU described in that RFC. But I don't think it is the job of my library to do that, but a per-client choice to go with that behaviour.

  286. Syndace

    lovetox: Yes agreed, I need some documentation about thst

  287. Half-Shot has left

  288. lovetox

    also we should move this to jdev channel, as this has not much to do with XSF or standards :)

  289. Half-Shot has left

  290. oli

    For Gajim: I think it would be nice to be able to have en encyrypted chat even with an "Not Decided" fingerprint. This gives users the opportunity to really check the fingerprint. If you prevent encryption in undecided state, users just click trusted to be able to chat.

  291. lovetox

    thats what you use verified/unverified states for in my opinion

  292. oli

    lovetox: bi

  293. oli

    but i cannot send OMEMO messages in undecided state

  294. lovetox

    im not saying that Gajim offers such states

  295. lovetox

    im just saying if i would make this possible i would introduce verified/unverified states

  296. oli

    I feel this has to do XEP-0384: "Clients MUST NOT use a newly built session to transmit data without user intervention. If a client were to opportunistically start using sessions for sending without asking the user whether to trust a device first, an attacker could publish a fake device for this user, which would then receive copies of all messages sent by/to this user." The most popular mobile client just gives a shit about this (in the default configuration)

  297. pep.

    Yes that's something I also dislike in conversations, that it forces me to trust before sending (with btbv unchecked, dunno about other states), even though I didn't actually verify the fingerprint

  298. jonas’

    to be fair, this MUST/MUST NOT is not sensible because it’s not an interoperability thing, but a policy thing

  299. oli

    lovetox‎: sorry, missread you message unverified != undecided

  300. lovetox

    oli, if you refer to conversations

  301. lovetox

    its Daniels client

  302. lovetox

    and Daniel wrote the xep

  303. lovetox

    and its not a standard, its experimental

  304. lovetox

    so if the author feels like it he can change that every day

  305. jonas’

    does xep-0384 reflect what’s actually done on the wire these days?

  306. lovetox

    The XEP should be updated, but i think they work on a bigger overhaul

  307. lovetox

    actually andi is listed as author, didnt know that

  308. pep.

    Yeah, there's probably going to be a big breakage soon.

  309. pep.

    That's going to be fun

  310. jonas’


  311. pep.

    in terms of standard progress :P

  312. oli

    Why breakage? With all the X and the namespaces, sholdn't breakage be avoided?

  313. Zash has left

  314. oli

    But as long as the cult of OMEMO believes in the evilness of OTR, everything will be fine.

  315. jonas’

    nobody believes OTR is evil

  316. lovetox

    its just not practical for todays messenger needs

  317. lovetox

    xmpp clients have mostly a big usability deficit, and everything that cant be made really stable/easy/usable for users, i would right now not invest my time into

  318. jonas’

    in the single-client, non-mobile use-case OTR is extremely usable

  319. Neustradamus

    And there is an OTRv4 in progress since a big moment...

  320. Zash

    I looked at the streamed talk from CCC. They said no multi-client support, so still terrible for XMPP.

  321. lumi has joined

  322. pep.

    No multi-client and no groupchat

  323. pep.

    They're introducing PFS though, and using doubleratchet, but this is still not a replacement to OMEMO

  324. pep.

    (Even if we defined a way not to have all that in <body/>, and how to translate if for transports etc.)

  325. oli

    Would work for a whatsapp-like model (besides the group chat)

  326. lovetox

    groupchat is an essential part of whatsapp

  327. lovetox

    so no it would not work at all

  328. pep.

    But I guess the advantage that they want to have over other mechanisms is that it doesn't require any server nor protocol support

  329. pep.

    So that's actually a feature for them to use <body/>

  330. Zash

    Something something trade-off

  331. alacer has left

  332. alacer has joined

  333. Half-Shot has left

  334. oli

    lovetox: i mean there is no multi client in whatsapp. it seems multi client is not really that important

  335. oli has left

  336. lovetox

    It is thats why whatsapp trys really hard to fake it

  337. lovetox

    A separate desktop client was always one of the major requests from whatsapp users

  338. lovetox

    then they offered their web thingy, and last time i looked they had a desktop client on mac

  339. lovetox

    i actually dont know if this is real multi device, or if its still proxied over the phone

  340. pep.

    That goes through the mobile though right?

  341. lovetox

    is this still the case?

  342. pep.

    I don't know I don't use it

  343. pep.

    I thought that's how signal did it at least

  344. lovetox

    maybe they solved that problem

  345. Half-Shot has left

  346. alacer has left

  347. winfried has joined

  348. Half-Shot has left

  349. intosi has left

  350. Half-Shot has left

  351. Half-Shot has joined

  352. !xsf_Martin has joined

  353. intosi has joined

  354. lorddavidiii has left

  355. nyco has left

  356. Half-Shot has left

  357. nyco has joined

  358. Half-Shot has left

  359. Yagiza has joined

  360. Yagiza has left

  361. Half-Shot has left

  362. Yagiza has joined

  363. marc_ has left

  364. Half-Shot has left

  365. marc_ has joined

  366. Half-Shot has left

  367. Half-Shot has left

  368. Tobias has joined

  369. tux has joined

  370. tux has joined

  371. Half-Shot has joined

  372. Tobias has joined

  373. tux has left

  374. tux has joined

  375. neshtaxmpp has left

  376. Half-Shot has left

  377. genofire has left

  378. 404.city has joined

  379. 404.city has left

  380. tux has joined

  381. tux has joined

  382. thorsten has joined

  383. Half-Shot has left

  384. tux has left

  385. tux has joined

  386. Zash has left

  387. mightyBroccoli has left

  388. mightyBroccoli has joined

  389. genofire has left

  390. ThibG has left

  391. ThibG has joined

  392. genofire has left

  393. Half-Shot has left

  394. neshtaxmpp has joined

  395. Half-Shot has left

  396. genofire has left

  397. neshtaxmpp has left

  398. neshtaxmpp has joined

  399. marc_ has left

  400. waqas has joined

  401. daniel has left

  402. daniel has joined

  403. neshtaxmpp has left

  404. Half-Shot has left

  405. Andrew Nenakhov has left

  406. Andrew Nenakhov has joined

  407. steven has left

  408. steven has joined

  409. Half-Shot has left

  410. Half-Shot has left

  411. neshtaxmpp has joined

  412. dos has left

  413. Half-Shot has joined

  414. Сейд has joined

  415. UsL has left

  416. UsL has joined

  417. dos has left

  418. Guus has left

  419. Half-Shot has left

  420. genofire has left

  421. Guus has left

  422. Half-Shot has left

  423. nyco has left

  424. oli has joined

  425. dos has left

  426. Half-Shot has left

  427. neshtaxmpp has left

  428. MattJ has joined

  429. mrDoctorWho has joined

  430. nyco has joined

  431. mrDoctorWho has joined

  432. neshtaxmpp has joined

  433. mrDoctorWho has joined

  434. mrDoctorWho has joined

  435. mrDoctorWho has left

  436. Сейд has left

  437. Half-Shot has left

  438. dos has joined

  439. dos has joined

  440. neshtaxmpp has left

  441. goffi has joined

  442. dos has joined

  443. UsL has joined

  444. UsL has joined

  445. Сейд has joined

  446. Half-Shot has left

  447. marc_ has joined

  448. 404.city has joined

  449. mrDoctorWho has left

  450. waqas has left

  451. 404.city has left

  452. mimi89999 has joined

  453. Half-Shot has left

  454. Half-Shot has left

  455. mrDoctorWho has left

  456. Tobias has left

  457. Tobias has joined

  458. genofire has left

  459. neshtaxmpp has joined

  460. neshtaxmpp has left

  461. neshtaxmpp has left

  462. neshtaxmpp has joined

  463. igoose has left

  464. igoose has joined

  465. lnj has joined

  466. oli has joined

  467. mimi89999 has left

  468. waqas has joined

  469. labdsf has left

  470. ThibG has joined

  471. Zash has left

  472. ThibG has joined

  473. labdsf has joined

  474. jjrh has left

  475. jjrh has left

  476. jjrh has left

  477. mrDoctorWho has left

  478. Half-Shot has left

  479. Half-Shot has left

  480. Half-Shot has left

  481. goffi has joined

  482. marc_ has left

  483. Half-Shot has joined

  484. labdsf has left

  485. labdsf has joined

  486. Yagiza has left

  487. jjrh has left

  488. jjrh has left

  489. Holger has left

  490. Сейд has left

  491. igoose has left

  492. labdsf has left

  493. labdsf has joined

  494. igoose has joined

  495. marc_ has joined

  496. Wiktor has left

  497. Guus has left

  498. jjrh has left

  499. jjrh has left

  500. ThibG has left

  501. ThibG has joined

  502. jjrh has left

  503. oli has left

  504. Half-Shot has left

  505. oli has left

  506. oli has joined

  507. daniel has joined

  508. daniel has joined

  509. Half-Shot has left

  510. Half-Shot has joined

  511. marc_ has left

  512. MattJ has joined

  513. ta has left

  514. thorsten has left

  515. Half-Shot has left

  516. Wiktor has left

  517. Nekit has joined

  518. Wiktor has joined

  519. ta has left

  520. !xsf_Martin has joined

  521. Half-Shot has left

  522. Half-Shot has left

  523. mimi89999 has joined

  524. Half-Shot has joined

  525. thorsten has joined

  526. oli has joined

  527. mimi89999 has joined

  528. Half-Shot has left

  529. Half-Shot has left

  530. oli has joined

  531. thorsten has left

  532. Half-Shot has left

  533. thorsten has joined

  534. vaulor has left

  535. vaulor has joined

  536. vaulor has left

  537. oli has left

  538. oli has joined

  539. 404.city has joined

  540. Half-Shot has left

  541. 404.city has left

  542. jjrh has left

  543. MattJ has joined