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