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 Aure
  172. Syndace Sure*
  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 Yep
  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 right.
  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’ "soon"
  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