jdev - 2022-01-11

  1. suohua has left

  2. debacle has left

  3. thomaslewis has joined

  4. thomaslewis has left

  5. larma has left

  6. thomaslewis has joined

  7. thomaslewis has left

  8. suohua has joined

  9. thomaslewis has joined

  10. thomaslewis has left

  11. kikuchiyo has left

  12. drops has left

  13. kikuchiyo has joined

  14. suohua has left

  15. thomaslewis has joined

  16. thomaslewis has left

  17. mac has left

  18. mac has joined

  19. thomaslewis has joined

  20. thomaslewis has left

  21. inky has left

  22. 9lakes has joined

  23. inky has joined

  24. inky has left

  25. kikuchiyo has left

  26. kikuchiyo has joined

  27. doge has joined

  28. spectrum has left

  29. spectrum has joined

  30. kikuchiyo has left

  31. thomaslewis has joined

  32. kikuchiyo has joined

  33. thomaslewis has left

  34. thomaslewis has joined

  35. xnamed has left

  36. 9lakes has left

  37. bung has left

  38. nixi has left

  39. thomaslewis has left

  40. mac has left

  41. mac has joined

  42. Yagizа has joined

  43. sonny has left

  44. sonny has joined

  45. sonny has left

  46. sonny has joined

  47. suohua has joined

  48. sonny has left

  49. sonny has joined

  50. atomicwatch has joined

  51. suohua has left

  52. SouL has joined

  53. kikuchiyo has left

  54. doge has left

  55. emus has joined

  56. kikuchiyo has joined

  57. COM8 has joined

  58. COM8 has left

  59. COM8 has joined

  60. COM8 has left

  61. nephele has joined

  62. nephele has left

  63. nephele has joined

  64. rafasaurus has left

  65. suohua has joined

  66. nephele has left

  67. dezant has left

  68. nephele has joined

  69. suohua has left

  70. rafasaurus has joined

  71. pasdesushi has joined

  72. nephele has left

  73. me9 has joined

  74. sonny has left

  75. sonny has joined

  76. dezant has joined

  77. jgart has left

  78. COM8 has joined

  79. COM8 has left

  80. wurstsalat has joined

  81. me9 has left

  82. marc0s has left

  83. marc0s has joined

  84. marc0s has left

  85. marc0s has joined

  86. atomicwatch has left

  87. dezant has left

  88. jubalh has joined

  89. Yagizа has left

  90. msavoritias has joined

  91. Alex has left

  92. Yagizа has joined

  93. dezant has joined

  94. Yagizа has left

  95. jgart has joined

  96. Alex has joined

  97. marmistrz has joined

  98. rafasaurus has left

  99. rafasaurus has joined

  100. debacle has joined

  101. dezant has left

  102. doge has joined

  103. dezant has joined

  104. antranigv has left

  105. antranigv has joined

  106. kikuchiyo has left

  107. nephele has joined

  108. nephele has left

  109. nephele has joined

  110. jgart has left

  111. kikuchiyo has joined

  112. nephele has left

  113. Yagizа has joined

  114. msavoritias has left

  115. msavoritias has joined

  116. doge has left

  117. Yagizа has left

  118. nixi has joined

  119. nixi has left

  120. jubalh has left

  121. Yagizа has joined

  122. Yagizа has left

  123. Martin has left

  124. larma has joined

  125. Martin has joined

  126. tsk has left

  127. tsk has joined

  128. dezant has left

  129. larma has left

  130. 9lakes has joined

  131. nephele has joined

  132. Millesimus has joined

  133. bung has joined

  134. dezant has joined

  135. nephele has left

  136. defanor

    The OMEMO XEP doesn't provide a way to ensure that all the connected clients/resources have matching key bundles published, does it?

  137. mac has left

  138. kikuchiyo has left

  139. inky has joined

  140. kikuchiyo has joined

  141. Millesimus has left

  142. jubalh has joined

  143. pep.

    It doesn't, no

  144. bung has left

  145. bung has joined

  146. defanor

    Seems like if it (as well as the OpenPGP one) did, clients could take that responsibility from a user (i.e., at least show whether decryption issues seem likely), making the usage a bit easier.

  147. flow

    can't a client discover if his bundle is published?

  148. Millesimus has joined

  149. defanor

    AIUI a client can check whether its own bundle is published, since they know their own device ID, but others (those who want to send them a message) can't check IDs of all the connected devices.

  150. pep.

    defanor, you can deduce it, but yeah there's no explicit mechanism to get this information

  151. 9lakes has left

  152. pep.

    You see a new deviceid in the list you can't associate it right away

  153. flow

    defanor, why just *connected* devices?

  154. flow

    wouldn't you want to also check for offline devices too?

  155. defanor

    Well, with connected ones it at least seems possible; offline ones may include future ones if we're considering history/offline messages.

  156. flow

    it appears that this boils down that we don't have a way to register and unregister user devices, and even if we had, it would probably be not absolutely reliable

  157. flow

    I am not sure why it should be the possiblity of the sending entity to ensure that the receiving entity has published all bundles

  158. flow

    even if the sending entity could determine that a bundle is missing, it can't do much about it

  159. flow

    also the receiving entity has an inventive to ensure that the bundles of all their devices are up-to-date

  160. flow

    *should be the *responsibility* of the sending entity

  161. bung has left

  162. bung has joined

  163. defanor

    Here's the awkward situation that happens sometimes: a user (receiving entity) connects from two clients/devices, only one publishes the keys, incoming messages get encrypted, the user is confused. They indeed should publish keys from every client or from none now, to ensure reliable delivery, and only stick to clients supporting those then, but it's not the sort of thing most users know about or do, I think. I'm even hesistant myself to publish the keys, since I may have to connect using a client without OMEMO or OpenPGP support, and then there will be all the awkwardness with lost messages again.

  164. flow

    there shouldn't be any lost message, but potentially warning messages from the receiving client that the received message could not be encrypted

  165. flow

    (in an ideal world that is)

  166. defanor

    Yeah, that's the best-case scenario; I saw them both hidden/eaten by a client, and just that situation where you have to ask the other party to disable the encryption and resend messages.

  167. flow

    defanor, I am also not sure what your idea to improve the situtation exactly is?

  168. pulkomandy has left

  169. pulkomandy has joined

  170. flow

    because I feel any "improvement" could lead to open up a encryption downgrade attack vector

  171. flow

    because I feel any "improvement" could lead to open up an encryption downgrade attack vector

  172. flow

    basically UX with mixed OMEMO and non-OMEMO clients is sometimes terriable and I think there is not much you can do about it

  173. flow

    basically UX with mixed OMEMO and non-OMEMO clients is sometimes terrible and I think there is not much you can do about it

  174. defanor

    I think if it was possible at least to find out whether currently connected target user's devices seem capable of decrypting messages, it'd mitigate the issue: the sending client's UI would be able to show what to expect. That's far from perfect too, but better than to not know even whether to expect the connected clients to be able to read (decrypt) the message.

  175. flow

    well if you have presence subscription to the receiving entity, then you could query the clients for the omemo feature

  176. larma has joined

  177. flow

    although, I am not sure if the omemo xep currently says that clients should annouce such a feature

  178. Wojtek has joined

  179. jubalh has left

  180. flow

    so yes, mandating that clients annouce that feature and having the sending entity check if all clients support it, could maybe improve the situation a bit

  181. defanor

    Supporting a feature at all is indeed a suggestion that they potentially can decrypt messages, but knowing that the keys are published by those clients/devices gives a bit more certainty still.

  182. pep.

    « flow> although, I am not sure if the omemo xep currently says that clients should annouce such a feature » also that doesn't say they're actually using it at the moment you query

  183. flow

    of course, it's a bandaid

  184. flow

    and I believe the don't want that kind of logic in encrypted messaging

  185. 9lakes has joined

  186. pulkomandy has left

  187. pulkomandy has joined

  188. bung has left

  189. 9lakes has left

  190. bung has joined

  191. marmistrz has left

  192. goffi has joined

  193. Ingolf has left

  194. Ingolf has joined

  195. inky has left

  196. marmistrz has joined

  197. xnamed has joined

  198. dezant has left

  199. dezant has joined

  200. atomicwatch has joined

  201. SouL has left

  202. SouL has joined

  203. bung has left

  204. bung has joined

  205. bung has left

  206. dezant has left

  207. dezant has joined

  208. PapaTutuWawa has joined

  209. MattJ

    FWIW this is something I intend to add to Snikket in the future (server-side sanity check that all your devices have published keys)

  210. pep.

    I guess Snikket can do that because it's Snikket

  211. MattJ

    It's just a little tricky when we don't currently know what devices exist

  212. MattJ

    pep.: partly, though it would be sensible to have some all-or-nothing check for other servers too

  213. pep.

    My poezio OMEMO plugin is temporarily borked, should I prevent people from sending encrypted messages to me at all?

  214. MattJ

    That's up to you 🙂

  215. pep.

    Or am I condemned to receive encrypted messages at all times? :x

  216. mac has joined

  217. MattJ

    If you publish keys.... pretty much yes

  218. MattJ

    Even if only one of your clients published keys, that's it

  219. pep.

    That's in theory, and in some threat model

  220. marc0s has left

  221. marc0s has joined

  222. jonas’

    no, that's what happens in practice ;)

  223. pasdesushi has left

  224. tsk has left

  225. doge has joined

  226. mac has left

  227. mac has joined

  228. pep.

    No it's not, maybe only with that-one-client

  229. pep.

    Or maybe in Snikket

  230. sonny has left

  231. sonny has joined

  232. jonas’

    and you can't control what clients other people use

  233. jonas’

    so it's what happens in practice :)

  234. pep.

    Practice is a mix of all this

  235. xnamed has left

  236. tsk has joined

  237. pep.

    Atm I'd say the behaviour much more depends on what the user has set their client to do in a specific tab. If it's set to encrypt then surely the client will encrypt as long as the user doesn't change the setting. Dino for sure doesn't change when the recipient has published keys, I've been bitten multiple times when opening a tab I had never opened (1:1 or group). And I'm sure there's also some of this in C. If the other side starts sending me unencrypted messages, I'll continue sending messages not because C "knows" it was encrypted before but because it's now configured to encrypt

  238. Yagizа has joined

  239. xnamed has joined

  240. mac has left

  241. x51 has joined

  242. nephele has joined

  243. nephele has left

  244. nephele has joined

  245. pasdesushi has joined

  246. bung has joined

  247. nephele has left

  248. atomicwatch has left

  249. nephele has joined

  250. atomicwatch has joined

  251. mac has joined

  252. PapaTutuWawa has left

  253. Wojtek has left

  254. Wojtek has joined

  255. kikuchiyo has left

  256. x51 has left

  257. Wojtek has left

  258. Wojtek has joined

  259. 9lakes has joined

  260. Millesimus has left

  261. Wojtek has left

  262. 9lakes has left

  263. x51 has joined

  264. jgart has joined

  265. 9lakes has joined

  266. Millesimus has joined

  267. kikuchiyo has joined

  268. pulkomandy has left

  269. doge has left

  270. pulkomandy has joined

  271. kikuchiyo has left

  272. Yagizа has left

  273. Yagizа has joined

  274. jubalh has joined

  275. pulkomandy has left

  276. pulkomandy has joined

  277. nephele has left

  278. nephele has joined

  279. kikuchiyo has joined

  280. kikuchiyo has left

  281. Wojtek has joined

  282. Wojtek has left

  283. FireFly has left

  284. FireFly has joined

  285. x51 has left

  286. thomaslewis has joined

  287. kikuchiyo has joined

  288. mac has left

  289. larma has left

  290. thomaslewis has left

  291. qy

    now i remember why i burnt out on rewriting to c++

  292. qy

    having to write a snazzy weechat api wrapper

  293. qy

    i definitely did not KISS, and as such it got instantly ridiculous

  294. pulkomandy has left

  295. pulkomandy has joined

  296. jubalh has left

  297. pulkomandy has left

  298. thomaslewis has joined

  299. pulkomandy has joined

  300. Millesimus has left

  301. bung has left

  302. thomaslewis has left

  303. bung has joined

  304. COM8 has joined

  305. kikuchiyo has left

  306. COM8 has left

  307. jubalh has joined

  308. tsk has left

  309. rafasaurus has left

  310. rafasaurus has joined

  311. thomaslewis has joined

  312. tsk has joined

  313. thomaslewis has left

  314. atomicwatch has left

  315. kikuchiyo has joined

  316. atomicwatch has joined

  317. nephele has left

  318. nephele has joined

  319. kikuchiyo has left

  320. kikuchiyo has joined

  321. larma has joined

  322. thomaslewis has joined

  323. thomaslewis has left

  324. thomaslewis has joined

  325. thomaslewis has left

  326. Yagizа has left

  327. serge90 has joined

  328. homebeach has left

  329. Matrix Traveler (bot) has left

  330. Matrix Traveler (bot) has joined

  331. homebeach has joined

  332. PapaTutuWawa has joined

  333. serge90 has left

  334. Wojtek has joined

  335. thomaslewis has joined

  336. Wojtek has left

  337. thomaslewis has left

  338. thomaslewis has joined

  339. xnamed has left

  340. thomaslewis has left

  341. thomaslewis has joined

  342. thomaslewis has left

  343. Millesimus has joined

  344. Millesimus has left

  345. Millesimus has joined

  346. xnamed has joined

  347. me9 has joined

  348. thomaslewis has joined

  349. thomaslewis has left

  350. xnamed has left

  351. Millesimus has left

  352. xnamed has joined

  353. Millesimus has joined

  354. al has joined

  355. huhn has left

  356. larma has left

  357. pasdesushi has left

  358. pasdesushi has joined

  359. emus has left

  360. emus has joined

  361. atomicwatch has left

  362. thomaslewis has joined

  363. me9 has left

  364. thomaslewis has left

  365. thomaslewis has joined

  366. thomaslewis has left

  367. nephele has left

  368. nephele has joined

  369. al has left

  370. atomicwatch has joined

  371. nephele has left

  372. Millesimus has left

  373. larma has joined

  374. Millesimus has joined

  375. PapaTutuWawa has left

  376. nephele has joined

  377. msavoritias has left

  378. inky has joined

  379. nephele has left

  380. nephele has joined

  381. thomaslewis has joined

  382. thomaslewis has left

  383. thomaslewis has joined

  384. thomaslewis has left

  385. nephele has left

  386. bung has left

  387. goffi has left

  388. marc0s has left

  389. marc0s has joined

  390. sonny has left

  391. sonny has joined

  392. inky has left

  393. wurstsalat has left

  394. marc0s has left

  395. marc0s has joined

  396. emus has left