XSF Discussion - 2018-06-17

  1. Dave Cridland has left
  2. Dave Cridland has joined
  3. Dave Cridland has left
  4. Dave Cridland has joined
  5. labdsf has left
  6. Chobbes has joined
  7. labdsf has left
  8. labdsf has left
  9. nyco has left
  10. nyco has joined
  11. labdsf has left
  12. marc has left
  13. alexis has left
  14. alexis has joined
  15. la|r|ma has joined
  16. Nekit has joined
  17. labdsf has left
  18. marc has joined
  19. matlag has left
  20. j.r has joined
  21. rishiraj22 has left
  22. marc has left
  23. alexis has left
  24. alexis has joined
  25. la|r|ma has joined
  26. Dave Cridland has left
  27. Dave Cridland has joined
  28. Dave Cridland has left
  29. Dave Cridland has joined
  30. lorddavidiii has left
  31. jjrh has left
  32. lskdjf has joined
  33. lorddavidiii has left
  34. pep. has left
  35. jjrh has left
  36. jjrh has left
  37. alexis has left
  38. waqas has left
  39. alexis has joined
  40. alexis has left
  41. alexis has joined
  42. alexis has left
  43. alexis has joined
  44. alexis has left
  45. alexis has joined
  46. alexis has joined
  47. rishiraj22 has joined
  48. Dave Cridland has left
  49. Dave Cridland has joined
  50. Dave Cridland has left
  51. Dave Cridland has joined
  52. alexis has left
  53. alexis has joined
  54. alexis has left
  55. alexis has joined
  56. rishiraj22 has left
  57. rishiraj22 has joined
  58. efrit has joined
  59. Dave Cridland has left
  60. Dave Cridland has joined
  61. alexis has left
  62. dos has left
  63. dos has joined
  64. Dave Cridland has left
  65. Dave Cridland has joined
  66. jjrh has left
  67. rainslide has joined
  68. dos has left
  69. rainslide has left
  70. rishiraj22 has left
  71. rishiraj22 has joined
  72. Dave Cridland has left
  73. Dave Cridland has joined
  74. Dave Cridland has left
  75. Dave Cridland has joined
  76. rishiraj22 has left
  77. rishiraj22 has joined
  78. Dave Cridland has left
  79. Dave Cridland has joined
  80. efrit has left
  81. Yagiza has joined
  82. Dave Cridland has left
  83. Dave Cridland has joined
  84. Dave Cridland has left
  85. Dave Cridland has joined
  86. rishiraj22 has left
  87. Dave Cridland has left
  88. Dave Cridland has joined
  89. Dave Cridland has left
  90. Dave Cridland has joined
  91. SamWhited has left
  92. jere has left
  93. jere has joined
  94. ta has left
  95. ta has joined
  96. moparisthebest has left
  97. moparisthebest has joined
  98. ta has left
  99. ta has joined
  100. ta has left
  101. ta has joined
  102. mrdoctorwho has joined
  103. jere has left
  104. la|r|ma has joined
  105. ta has joined
  106. ta has joined
  107. Dave Cridland has left
  108. Dave Cridland has joined
  109. Dave Cridland has left
  110. Dave Cridland has joined
  111. Dave Cridland has left
  112. Dave Cridland has joined
  113. Dave Cridland has left
  114. Dave Cridland has joined
  115. alacer has joined
  116. Guus has left
  117. Guus has joined
  118. mrdoctorwho has joined
  119. Dave Cridland has left
  120. Dave Cridland has joined
  121. Dave Cridland has left
  122. Dave Cridland has joined
  123. Andrew Nenakhov has left
  124. Andrew Nenakhov has joined
  125. Andrew Nenakhov has left
  126. Andrew Nenakhov has joined
  127. Andrew Nenakhov has left
  128. Andrew Nenakhov has joined
  129. alacer has left
  130. Andrew Nenakhov has left
  131. Andrew Nenakhov has joined
  132. moparisthebest has joined
  133. Andrew Nenakhov has left
  134. Andrew Nenakhov has joined
  135. moparisthebest has joined
  136. Andrew Nenakhov has left
  137. Andrew Nenakhov has joined
  138. j.r has joined
  139. Dave Cridland has left
  140. Dave Cridland has joined
  141. Dave Cridland has left
  142. Dave Cridland has joined
  143. alacer has joined
  144. alacer has left
  145. Guus has left
  146. Guus has joined
  147. Valerian has joined
  148. Dave Cridland has left
  149. Dave Cridland has joined
  150. Dave Cridland has left
  151. Dave Cridland has joined
  152. MattJ has joined
  153. rishiraj22 has left
  154. moparisthebest has joined
  155. moparisthebest has joined
  156. Andrew Nenakhov has left
  157. Andrew Nenakhov has joined
  158. Dave Cridland has left
  159. Dave Cridland has joined
  160. Dave Cridland has left
  161. Dave Cridland has joined
  162. Guus has left
  163. Dave Cridland has left
  164. Dave Cridland has joined
  165. Guus has joined
  166. alacer has joined
  167. la|r|ma has joined
  168. la|r|ma has joined
  169. la|r|ma has joined
  170. la|r|ma has joined
  171. rishiraj22 has left
  172. Dave Cridland has left
  173. Dave Cridland has joined
  174. Dave Cridland has left
  175. Dave Cridland has joined
  176. j.r has joined
  177. waqas has joined
  178. Dave Cridland has left
  179. Dave Cridland has joined
  180. Dave Cridland has left
  181. Dave Cridland has joined
  182. la|r|ma has left
  183. la|r|ma has joined
  184. mimi89999 has joined
  185. moparisthebest has joined
  186. moparisthebest has joined
  187. Nekit has joined
  188. Dave Cridland has left
  189. Dave Cridland has joined
  190. Dave Cridland has left
  191. Dave Cridland has joined
  192. j.r has joined
  193. marc has joined
  194. j.r has joined
  195. j.r has joined
  196. Valerian has left
  197. zak has left
  198. moparisthebest has joined
  199. marmistrz has left
  200. kasper.dement has left
  201. kasper.dement has joined
  202. Guus has left
  203. Guus has joined
  204. Andrew Nenakhov has left
  205. Andrew Nenakhov has joined
  206. daniel has left
  207. muppeth has joined
  208. rishiraj22 has left
  209. alacer has left
  210. marmistrz has left
  211. Andrew Nenakhov has left
  212. Andrew Nenakhov has joined
  213. Chobbes has left
  214. lorddavidiii has left
  215. karp has left
  216. karp has joined
  217. muppeth has left
  218. muppeth has joined
  219. valo has joined
  220. valo has joined
  221. alacer has joined
  222. Chobbes has joined
  223. Guus has left
  224. Guus has joined
  225. muppeth has left
  226. muppeth has joined
  227. alacer has left
  228. alacer has joined
  229. winfried has left
  230. dos has joined
  231. alacer has left
  232. Guus has left
  233. Guus has joined
  234. lumi has joined
  235. lskdjf has joined
  236. rtq3 has joined
  237. rtq3 has left
  238. j.r has joined
  239. Guus has left
  240. Guus has joined
  241. lskdjf has joined
  242. lskdjf has joined
  243. rishiraj22 has left
  244. Dave Cridland has left
  245. Andrew Nenakhov has left
  246. Andrew Nenakhov has joined
  247. Andrew Nenakhov has left
  248. Andrew Nenakhov has joined
  249. Alex has joined
  250. Andrew Nenakhov has left
  251. Andrew Nenakhov has joined
  252. rainslide has joined
  253. alacer has joined
  254. alacer has left
  255. Neustradamus has left
  256. valo has joined
  257. valo has joined
  258. igor75 has left
  259. igor75 has joined
  260. Valerian has joined
  261. vanitasvitae has left
  262. vanitasvitae has left
  263. Valerian has left
  264. Valerian has joined
  265. rainslide has left
  266. vanitasvitae has left
  267. vanitasvitae has left
  268. Valerian has left
  269. Dave Cridland has left
  270. Dave Cridland has joined
  271. marmistrz has joined
  272. andy has joined
  273. Valerian has joined
  274. rainslide has joined
  275. lskdjf has joined
  276. muppeth has joined
  277. muppeth has joined
  278. Alex has left
  279. tux has left
  280. alacer has joined
  281. alacer has left
  282. alacer has joined
  283. Valerian has left
  284. daniel has left
  285. rainslide has left
  286. daniel has left
  287. daniel has left
  288. j.r has joined
  289. Valerian has joined
  290. vanitasvitae has left
  291. marmistrz has left
  292. valo has joined
  293. Dave Cridland has left
  294. rishiraj22 has left
  295. vanitasvitae has left
  296. Dave Cridland has joined
  297. j.r has joined
  298. j.r has joined
  299. Valerian has left
  300. j.r has joined
  301. j.r has joined
  302. goffi has joined
  303. Syndace has left
  304. Syndace has joined
  305. Andrew Nenakhov has left
  306. Andrew Nenakhov has joined
  307. rishiraj22 has left
  308. rainslide has joined
  309. j.r has joined
  310. daniel has left
  311. daniel has joined
  312. SaltyBones has left
  313. Andrew Nenakhov has left
  314. rainslide has left
  315. winfried has joined
  316. rishiraj22 has left
  317. rishiraj22 has left
  318. mimi89999 has joined
  319. Chobbes has joined
  320. daniel has left
  321. daniel has joined
  322. jere has joined
  323. vanitasvitae has left
  324. rishiraj22 has left
  325. rishiraj22 has left
  326. lnj has joined
  327. Chobbes has joined
  328. moparisthebest has joined
  329. moparisthebest has joined
  330. ralphm has joined
  331. lnj has left
  332. lnj has joined
  333. andy has left
  334. vanitasvitae has left
  335. vanitasvitae has joined
  336. rishiraj22 has left
  337. andy has joined
  338. andy has left
  339. Andrew Nenakhov has left
  340. marc has left
  341. marc has joined
  342. Alex has joined
  343. rainslide has joined
  344. nyco has left
  345. daniel has left
  346. daniel has joined
  347. nyco has joined
  348. marmistrz has left
  349. rainslide has left
  350. ta has left
  351. Dave Cridland has left
  352. Dave Cridland has joined
  353. blabla has joined
  354. matlag has joined
  355. Chobbes has joined
  356. Dave Cridland has left
  357. Dave Cridland has joined
  358. Dave Cridland has left
  359. Dave Cridland has joined
  360. valo has joined
  361. jubalh has joined
  362. Dave Cridland has left
  363. Dave Cridland has joined
  364. jubalh has joined
  365. jubalh has joined
  366. Dave Cridland has left
  367. Dave Cridland has joined
  368. ralphm has joined
  369. Dave Cridland has left
  370. Dave Cridland has joined
  371. Chobbes has joined
  372. lnj has left
  373. lnj has joined
  374. marmistrz has joined
  375. marmistrz has joined
  376. marmistrz has left
  377. marmistrz has joined
  378. jubalh has joined
  379. marmistrz has left
  380. Alex has left
  381. mrdoctorwho has left
  382. marmistrz has joined
  383. vanitasvitae has left
  384. vanitasvitae has left
  385. vanitasvitae has left
  386. alexis has joined
  387. alexis has left
  388. jubalh has joined
  389. alexis has joined
  390. alexis has left
  391. alexis has joined
  392. goffi has left
  393. kasper.dement has left
  394. Zash has left
  395. vanitasvitae has left
  396. kasper.dement has joined
  397. rion has left
  398. efrit has joined
  399. Zash has left
  400. rion has left
  401. alexis has left
  402. blabla has left
  403. alexis has joined
  404. j.r has joined
  405. la|r|ma has left
  406. Chobbes has joined
  407. jubalh has joined
  408. tux has left
  409. jubalh has left
  410. Dave Cridland has left
  411. Dave Cridland has joined
  412. Dave Cridland has left
  413. Dave Cridland has joined
  414. mrdoctorwho has joined
  415. daniel has left
  416. nyco has left
  417. vanitasvitae has left
  418. SaltyBones has left
  419. Dave Cridland has left
  420. Dave Cridland has joined
  421. j.r has joined
  422. j.r has joined
  423. jubalh has joined
  424. Chobbes has joined
  425. valo has joined
  426. Nekit has joined
  427. daniel has left
  428. Guus has left
  429. Guus has joined
  430. vanitasvitae has left
  431. vanitasvitae has joined
  432. vanitasvitae has left
  433. vanitasvitae has joined
  434. goffi has joined
  435. rishiraj22 has left
  436. rishiraj22 has left
  437. Nekit has joined
  438. rion has left
  439. dos has left
  440. Guus has left
  441. Chobbes has joined
  442. Guus has joined
  443. lskdjf has joined
  444. alexis has left
  445. daniel has left
  446. SamWhited has left
  447. valo has joined
  448. Chobbes has joined
  449. Guus has left
  450. Guus has joined
  451. jubalh has joined
  452. Chobbes has joined
  453. la|r|ma has joined
  454. rishiraj22 has left
  455. valo has joined
  456. valo has joined
  457. SaltyBones has joined
  458. SaltyBones has left
  459. rishiraj22 has left
  460. j.r has joined
  461. Valerian has joined
  462. kasper.dement has joined
  463. j.r has joined
  464. muppeth has left
  465. muppeth has joined
  466. kasper.dement has joined
  467. Chobbes has joined
  468. rishiraj22 has left
  469. alacer has left
  470. alacer has joined
  471. j.r has joined
  472. j.r has joined
  473. Andrew Nenakhov has left
  474. Andrew Nenakhov has joined
  475. kasper.dement has left
  476. SaltyBones has joined
  477. Andrew Nenakhov has left
  478. Andrew Nenakhov has joined
  479. la|r|ma has left
  480. ta has left
  481. valo has joined
  482. valo has joined
  483. ThibG has joined
  484. daniel has left
  485. dos has joined
  486. kasper.dement has joined
  487. jere has joined
  488. rishiraj22 has left
  489. kasper.dement has left
  490. jere has joined
  491. kasper.dement has joined
  492. j.r has left
  493. j.r has joined
  494. daniel has left
  495. daniel has left
  496. daniel has left
  497. jubalh has joined
  498. kasper.dement has left
  499. ta has left
  500. muppeth has left
  501. muppeth has joined
  502. mimi89999 has joined
  503. j.r has joined
  504. j.r has joined
  505. kasper.dement has joined
  506. daniel has left
  507. alacer has left
  508. daniel has left
  509. kasper.dement has left
  510. jubalh has joined
  511. dos has left
  512. dos has joined
  513. SaltyBones has left
  514. SaltyBones has joined
  515. rishiraj22 has left
  516. ThibG has joined
  517. SaltyBones has left
  518. SaltyBones has joined
  519. ThibG has joined
  520. rishiraj22 has left
  521. Valerian has left
  522. ralphm has joined
  523. Seve/SouL has left
  524. kasper.dement has joined
  525. alexis has joined
  526. jubalh has left
  527. alexis has left
  528. alexis has joined
  529. efrit has left
  530. rishiraj22 has left
  531. j.r has joined
  532. kasper.dement has left
  533. tux has left
  534. tux has joined
  535. SamWhited has left
  536. jubalh has joined
  537. rishiraj22 has left
  538. dos has left
  539. dos has joined
  540. marmistrz has left
  541. daniel has left
  542. rishiraj22 has left
  543. tux has left
  544. Neustradamus has left
  545. tux has joined
  546. daniel has left
  547. efrit has joined
  548. daniel has left
  549. daniel has left
  550. dos has left
  551. daniel has left
  552. Valerian has joined
  553. Zash has left
  554. jubalh has joined
  555. kasper.dement has joined
  556. kasper.dement has left
  557. matlag has joined
  558. alexis has joined
  559. alexis has left
  560. alexis has joined
  561. kasper.dement has joined
  562. lnj has left
  563. dos has joined
  564. lnj has joined
  565. j.r has joined
  566. kasper.dement has left
  567. Tim has joined
  568. SaltyBones has left
  569. SaltyBones has joined
  570. Valerian has left
  571. Valerian has joined
  572. Valerian has left
  573. rishiraj22 has left
  574. marmistrz has left
  575. kasper.dement has joined
  576. daniel has left
  577. alacer has joined
  578. j.r has joined
  579. j.r has joined
  580. j.r has joined
  581. Valerian has joined
  582. j.r has joined
  583. daniel has left
  584. rishiraj22 has left
  585. j.r has joined
  586. j.r has joined
  587. j.r has joined
  588. andy has joined
  589. muppeth has left
  590. j.r has joined
  591. jubalh has joined
  592. kasper.dement has left
  593. daniel has left
  594. Seve/SouL has left
  595. Zash has left
  596. rishiraj22 has left
  597. labdsf I have update Ephemeral Messages XEP: https://github.com/xsf/xeps/pull/666
  598. muppeth has joined
  599. Tobias has left
  600. Tobias has joined
  601. ta has left
  602. ta has joined
  603. jubalh has joined
  604. daniel has left
  605. daniel has left
  606. flow labdsf, if you find the time, then maybe present an htmldiff
  607. jubalh has joined
  608. flow for example by using https://github.com/cygri/htmldiff
  609. pep. has left
  610. Kev has left
  611. alacer has left
  612. labdsf has left
  613. kasper.dement has joined
  614. tux has joined
  615. tux has joined
  616. daniel has left
  617. Valerian has left
  618. Valerian has joined
  619. Tim has joined
  620. la|r|ma has joined
  621. kasper.dement has left
  622. marc has left
  623. labdsf Ok
  624. labdsf I am afk now, will make a diff later
  625. labdsf I have mostly removed support for plaintext ephemeral messages, but the ability to implement them is left for "controlled environments", where servers only federate with servers that support ephemeral messages and only accept messages from clients that support ephemeral messages.
  626. SamWhited That seems like a premature optimization for a very niche use case; unless you know of a service that does this?
  627. labdsf Maybe remove it completely
  628. labdsf It may be useful for MUC on a non-federated server
  629. labdsf When you don't want to setup OMEMO MUC (which requires members-only chat)
  630. j.r has joined
  631. SamWhited ah sorry, I see; I misunderstood what you were saying anyways
  632. SamWhited Going to re-read this with your new changes now to make sure; but tying this to OMEMO or OTR at all feels wrong to me. I don't understand why there is a distinction between plaintext and OMEMO or whatever in a XEP about something that has nothing to do with encryption
  633. SamWhited Ephemeral messages feel completely orthogonal to what goes in the body or to the wire format of the message to me.
  634. Seve/SouL has joined
  635. la|r|ma has joined
  636. labdsf In an open environment, where messages you send to bare JID or MUC may be delivered to clients that don't support ephemeral messages, OTR and OMEMO can be used to only encrypt messages for clients that have explicitly indicated support for them, as with OTR and OMEMO each device has its own private key (in contrast to OpenPGP, for example).
  637. labdsf With OTR, chats are full JID to full JID only, so you can ask the client whether it supports ephemeral messages or not.
  638. marmistrz has joined
  639. labdsf With OMEMO I add a PubSub item to show that device supports ephemeral messages.
  640. la|r|ma has joined
  641. kasper.dement has joined
  642. la|r|ma has joined
  643. la|r|ma has joined
  644. goffi has left
  645. kasper.dement has left
  646. Chobbes has joined
  647. labdsf OTR and OMEMO are the only ways to have E2E forward secrecy in XMPP now. Using OpenPGP with ephemeral messages is a bad idea, because if the device is lost (the only considered scenario), the key is also compromised in most cases (unless you set a passphrase on it).
  648. labdsf So there are two use cases.
  649. kasper.dement has joined
  650. labdsf One is the open network, where you use ephemeral messages only over OTR and OMEMO with contacts that have installed
  651. labdsf ..clients with ephemeral message support.
  652. j.r has joined
  653. rishiraj22 has left
  654. labdsf The second use case is when there is a trusted "corporate" server network, all servers have forward secrecy on transport level and all clients enable plaintext ephemeral messages.
  655. goffi has joined
  656. labdsf has left
  657. vanitasvitae has left
  658. la|r|ma has left
  659. la|r|ma has joined
  660. la|r|ma has joined
  661. j.r has joined
  662. Valerian has left
  663. valo has joined
  664. Kev Sorry, what is the issue with gpg and ephemeral messages in the device loss scenario?
  665. Kev Clearly losing your key is a Bad Thing, but I don't see how that's related to ephemeral messages particularly.
  666. la|r|ma has joined
  667. dos has left
  668. dos has joined
  669. lorddavidiii has left
  670. lnj has left
  671. SamWhited has left
  672. labdsf Message copies are left on the server, so they can be downloaded again and decrypted with the key.
  673. la|r|ma has joined
  674. mimi89999 has joined
  675. mimi89999 has left
  676. mimi89999 has joined
  677. mimi89999 has joined
  678. mimi89999 has joined
  679. labdsf In the "open network" use case no server is trusted, so forward secrecy is required to have truly ephemeral messages.
  680. SamWhited That all seems like unnecessary complexity that's just going to make people think this is a security feature; you can't enforce this sort of thing so adding security theater on top of it doesn't seem helpful to me.
  681. zak has left
  682. SamWhited has left
  683. labdsf It is a security feature as long as you trust your contact.
  684. Neustradamus has left
  685. Neustradamus has joined
  686. pep. hmm, trust and security..
  687. labdsf pep.: when you use OMEMO, you trust your contact not to leak the message contents by publishing it on twitter
  688. pep. I don't use OMEMO
  689. Link Mauve labdsf, do you?
  690. pep. labdsf, and mostly not I don't
  691. SamWhited It's not though, if you trust clients not to ignore your pep feature advertisement you have to do that regardless of whether there's encryption or not
  692. jubalh has left
  693. rion has left
  694. pep. labdsf, and mostly no I don't
  695. j.r has joined
  696. Link Mauve labdsf, encryption and recipient behaviour are two orthogonal concepts, one is technical while the other is social.
  697. labdsf SamWhited: I trust clients that specifically indicate that they support the feature, the problem is legacy clients
  698. labdsf When a contact has two clients, one is, lets say, Gajim with ephemeral message support added, and the other is Conversations, I want only Gajim to receive ephemeral message.
  699. Link Mauve I remember when people from a MUC I used to frequent started using Snapchat, soon enough someone started using a way to save the dickpics^Wfiles exchanged permanently, despite that being the main “feature” of the service.
  700. labdsf Snapchat is not my usecase, I think I stated it at the beginning of the first discussion in standards ML.
  701. marmistrz has left
  702. labdsf Because in MUC that is not members-only users are not trusted.
  703. pep. That was an example on social behaviour
  704. labdsf Ok, threat model for "open network" use case: contact is trusted, server is not.
  705. waqas Note that you are in any case trusting remote entities, e.g., I'd find it desirable to force logs in my client even if the remote party doesn't want them. GPG is about trust, while you are focusing on deniability.
  706. labdsf But contact has a legacy client.
  707. labdsf waqas: if you want to log all messages, just disable ephemeral messages
  708. Link Mauve Or still log them, despite what the other party may want.
  709. pep. But what happens when your contact sends you an ephemeral message
  710. waqas Yep, it's more fun to log them while having you think that we are not logging them
  711. waqas At the end of the day, you are trusting remote entities to not lie
  712. labdsf pep.: if you have not indicated that you support it, the message is not ephemeral
  713. pep. labdsf, that's the thing
  714. labdsf pep.: your contact knows it
  715. pep. So you won't send this kind of message if your contact doesn't support it? Or will you do it either way?
  716. marc has left
  717. labdsf waqas: lying contacts is not a part of the threat model
  718. waqas labdsf: lying servers aren't either?
  719. labdsf waqas: in "open network" use case the server is malicious
  720. waqas The server can always log without telling you
  721. labdsf waqas: that is why I say OTR and OMEMO must be used
  722. Link Mauve labdsf, I highly disagree on this point, in my open network use case, servers are often controlled by their user, if someone would lie they would have control over both their client and their server.
  723. labdsf Link Mauve: lying client is not a part of threat model
  724. valo has joined
  725. labdsf I do not consider lying clients
  726. Link Mauve The server and the client can be considered a same entity in this model.
  727. j.r has joined
  728. waqas I do see labdsf's point though. It's largely a case of protecting against current server and future client compromise, if I understand the argument correctly.
  729. pep. labdsf, how do you not consider lying clients, I'm not sure I see it
  730. pep. If a contact tells me it's supporting ephemeral, I might send what I consider a bit more private messages, assuming they're going to be deleted.
  731. pep. Where is that not an issue
  732. waqas pep.: It's protecting against a future search warrant, where clients currently are considered uncompromised
  733. daniel It's not a security feature. It's a friendly reminder to maybe to some house cleaning after you read the message
  734. pep. daniel, yeah I know it's not a security feature
  735. pep. So what does it bring to me as a user, really
  736. labdsf pep.: it is ok to send more private messages if you trust your contact not to install malicious client
  737. pep. UX fun?
  738. pep. labdsf, my contact might not know
  739. labdsf pep.: what your contact might not know? Thst it installed a malicious client?
  740. pep. Yes?
  741. pep. Took the first client, "hah it looks like conversations, it's green like conversations, must be conversations"
  742. daniel pep., as the recipient you know that a certain messages is worth deleting at some point
  743. daniel for example the sender slaps the delete hint on a password or something
  744. labdsf See, all your arguments that it is not a security feature because a trusted contact may install a malicious client also make OMEMO, OpenPGP and OTR useless.
  745. pep. labdsf, oh I agree
  746. labdsf And then, the server admin may be malicious and so on
  747. pep. yes
  748. pep. I agree OMEMO is just smoke and mirrors for most people
  749. labdsf Lets switch to twitter/mastodon and exchange messages in public only?
  750. Kev daniel: I don't think "It's not a security feature" is consistent with what labdsf is saying here.
  751. Kev If you're saying only omemo and otr as good enough, because gpg doesn't offer PFS, that sounds a lot like you're talking about security features.
  752. daniel Kev, i’m not agreeing with labdsf
  753. labdsf It is a security feature that protects messages against future device compromise.
  754. daniel i think the hint should be agnostic of what kind of messages you send
  755. Kev daniel: ok.
  756. waqas The problem here is that plausible deniability/ephemeral messages is not compatible with message authentication.
  757. pep. I also see that just as a UI/UX thing
  758. pep. Definitely no security involved here
  759. waqas GPG is mostly about trust/authentication.
  760. labdsf waqas: it is not about deniability. Though deniability and authentication are compatible, OTR does this.
  761. waqas Trusting end clients in the present (but not the future!) is a reasonable position to have, because you really can't do better if there is to be any trust/auth.
  762. daniel i haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>`
  763. labdsf daniel: consider legacy clients.
  764. labdsf I want to be able to avoid sending ephemeral messages to legacy clients.
  765. SamWhited so check if they support it and if so send to the full jid
  766. daniel i don’t think you can be reasonably sure that the recipient will obey that hint no matter what you do
  767. labdsf That is the reason for OTR/OMEMO requirement and encrypting only for clients that indicate feature support.
  768. labdsf daniel: the recipient is trusted in my threat model.
  769. SamWhited Either way, with OMEMO or without, you have to check for support and send only to that client. You can do that with or without OMEMO.
  770. labdsf But it has a legacy client
  771. SamWhited Then it won't advertise support
  772. labdsf SamWhited: that is what I do for OTR
  773. SamWhited I know, I'm saying you have to do it either way, OTR doesn't add anything.
  774. labdsf With OMEMO, I can't map device keys to resources
  775. labdsf And full JID may be offline
  776. pep. labdsf> With OMEMO, I can't map device keys to resources Yeah that's something I'd like
  777. labdsf pep.: it is impossible, device may connect with another resource next time
  778. pep. hmm, wait, no actually I don't need this
  779. la|r|ma has joined
  780. Nekit has left
  781. labdsf SamWhited: do you propose to ask all full JIDd for support of ephemeral messages and send them plaintext ephemeral messages directly if they indicate support?
  782. labdsf I think we are mostly moving to sending to bare JID only in chat clients. OTR is an exception, but is is mostly obsolete now.
  783. SamWhited Not really; I propose just making it a hint and letting clients and services deal with legacy clients however they see fit and maybe documenting some of these ideas
  784. pep. I'd just do like daniel says, send to all resources <please-delete-me seconds="60"/>, and if some support it, cool
  785. SamWhited But yes, checking for support and only sending to full JIDs that support it is one way of doing that
  786. SamWhited But yah, mostly I think clients should just do what daniel and pep. just said.
  787. labdsf pep.: and some will not support it, so it will be no more useful than snapchat
  788. pep. labdsf, sure
  789. SamWhited Define "useful"?
  790. labdsf "Can work reliably in at least on use case"
  791. SamWhited Good, then what pep. just said works reliably in the use case where this is not a security feature, it's just a fun convenience that lets you clear up messages that don't have any long term benefit if the users haven on-legacy clients.
  792. SamWhited non-legacy, even.
  793. labdsf SamWhited: but some will always have legacy clients
  794. pep. I'm not sure why you worry about those here
  795. SamWhited labdsf: yes, and that will be fine since it's not a security feature.
  796. labdsf Because I want a security feature, not funny snapchat-like feature
  797. pep. Good luck :x
  798. SamWhited That is the problem I have with this. This is not a security feature and never can be; at best it's security theater.
  799. daniel there are two use cases here. a) people building walled gardens on top of xmpp. b) jabber as the federated public ecosystem. in a) you are fine with a hint since you control all clients and servers anyways b) i expect only a tiny fraction of client implementing that. so if you limit this to clients that advertise support you probably wont be able to use that feature very often
  800. labdsf SamWhited: it is in a scenario where you have two users that trust each other.
  801. SamWhited labdsf: if you have two users that trust each other you don't need OMEMO because they can just trust that both are using clients that will support it.
  802. SamWhited Or you don't need this at all because you can just trust that they'll clear their history afterwards.
  803. labdsf daniel: i have defined these two use cases above. My XEP supports both. Your proposal is for walled gardens.
  804. labdsf If it is a walled garden, server advertises thst it supports ephemeral messages.
  805. labdsf It only federates with such servers.
  806. labdsf And only accepts clients that support this feature.
  807. labdsf That is a way to create a corporate network or snapchat.
  808. Nekit has joined
  809. labdsf Then you can exchange plaintext messages with a hint.
  810. labdsf If you connect to the federated open network, this feature is enabled for OTR and OMEMO only.
  811. labdsf SamWhited: you need OMEMO in this case, because servers are not trusted.
  812. pep. Why? I trust my server because I'm running it, and my mom is on my server.
  813. SamWhited labdsf: that's fine; if servers are not trusted individual users can use OMEMO. If they are trusted, they don't. Just like normal messages.
  814. SamWhited That doesn't really have anything to do with ephemeral messages.
  815. edhelas has left
  816. edhelas has joined
  817. labdsf SamWhited: we can extend the spec with the ability to send plaintext ephemeral messages to full JIDs, but it will only work for online clients and require trusted servers.
  818. labdsf Ok, maybe you trust the servers and want to send ephemeral message protected with TLS only. Maybe if the user sees timer but no padlock, it is clear enough and nobody makes wrong assumptions. But what about offline clients?
  819. j.r has joined
  820. pep. what about them
  821. SamWhited Just let the server store it in MAM like normal. If you trust the client to do what's right then when it comes back online and fetches them it sees that it's expired and doesn't show it.
  822. labdsf pep.: they will not receive message
  823. pep. labdsf, they'll receive it when they reconnect
  824. labdsf pep.: no, if you sent to full JIDs
  825. labdsf SamWhited: MAM will not store them if you send to full JID
  826. pep. on prosody atm if you send to an offline fulljid, it'll be sent to other resources iirc
  827. labdsf And if you send to bare JID legacy clients receive it
  828. pep. labdsf, you really can't avoid legacy clients
  829. pep. One way or another they'll get the messages
  830. labdsf pep.: no if I use OMEMO
  831. Chobbes has joined
  832. pep. So.. legacy clientA suports OMEMO message, you send to clientB that supports OMEMO and ephemeral, clientB goes offline, gets to clientA, oops.
  833. pep. So.. legacy clientA suports OMEMO, you send to clientB that supports OMEMO and ephemeral, clientB goes offline, gets to clientA, oops.
  834. daniel has left
  835. jjrh has left
  836. SamWhited has left
  837. la|r|ma has joined
  838. labdsf has left
  839. labdsf pep.: clientA and clientB have different keys
  840. labdsf clientA will not be able to decrypt
  841. pep. When you encrypt with OMEMO you encrypt for every devices right
  842. pep. and since you can't associate deviceid to resource atm, you don't have a choice
  843. labdsf pep.: in my proposal you encrypt ephemeral messages only for devices that support them
  844. pep. So you also need changes in 0384?
  845. labdsf No
  846. Chobbes has joined
  847. labdsf It is published in a separate item
  848. pep. What is?
  849. labdsf The indication of ephemeral message support
  850. pep. How do you associate deviceid to resource
  851. andy has left
  852. labdsf pep., I don't. I publish an item that says "the device 12345 supports ephemeral messages"
  853. pep. :/
  854. labdsf just like XEP 0384 publishes a Bundle
  855. j.r has joined
  856. labdsf well, the problem with XMPP is that offline clients are not registered in any way and you can't ask their capabilities and so on
  857. labdsf that is why OMEMO added its own devices that register in PEP
  858. labdsf that is why I have to build on top of OMEMO
  859. labdsf OTR is possible to support only because it already requires both clients to be offline, but I would say it is pretty much unusable
  860. pep. So you'll never want to support OX
  861. labdsf pep., yes
  862. labdsf only in "walled garden" scenario
  863. pep. meh
  864. pep. But well I don't think there's a big use-case for this feature anyway
  865. pep. The way you want it
  866. Andrew Nenakhov I'm a bit late to the party, but my take on this is simple: ephemeral messages are a joke, I'd want an option to keep them even if remote party thinks not, e2ee has nothing to do with ephemeral messages and PFS is also silly and not needed
  867. pep. Andrew Nenakhov, yes, do read above for more context
  868. dos has left
  869. dos has joined
  870. Andrew Nenakhov Glanced it briefly.
  871. labdsf Andrew Nenakhov, just don't implement it in Xabber and no valid client will send ephemeral messages to it
  872. Andrew Nenakhov Remote party should not dictate me how I use my archive and device history.
  873. Andrew Nenakhov labdsf, if it comes to that I'll probably implement it to show support and let user choose to keep it anyway. 😈
  874. pep. Andrew Nenakhov, just to prove a point that's dumb :/
  875. pep. Even if I agree it's useless in the first place
  876. labdsf Andrew Nenakhov, ok, malicious clients are not part of my threat model
  877. kasper.dement has joined
  878. pep. labdsf, I'm still not sure how you'll distinguish between malicious and not
  879. labdsf I trust my contacts not to install malicious clients
  880. pep. Yeah, that's a bit far fetched, but ok
  881. Andrew Nenakhov Such features make no sense in an open environment.
  882. labdsf Andrew Nenakhov, that is why I changed the XEP to only work over OTR and OMEMO
  883. labdsf it makes it a "closed environment", because XMPP is just a transport in this case
  884. labdsf it does not store message contents etc.
  885. Andrew Nenakhov If you trust your contacts, why run the hoops with e2ee pfs and all other fancy buzzwords?
  886. Andrew Nenakhov If you make something a XEP you are no longer talking about something you can use with your trusted contacts.
  887. labdsf because I want to be able to tick the "keep messages in this conversation for 1 week", and if my contact agrees and does not revert it, then we are sure that messages are removed after one week
  888. labdsf no need to agree verbally and delete manually
  889. Andrew Nenakhov And if you are pushing it to become a standard, you can't protect yourself from 'malicios clients'.
  890. labdsf Andrew Nenakhov, malicious clients are *not part of the threat model*, I don't want to protect against them
  891. labdsf feel free to implement one
  892. labdsf this feature already works in Wire, Signal and telegram "secret chats", everyone is free to modify the client to keep messages
  893. Yagiza has left
  894. j.r has joined
  895. labdsf telegram even has multiple alternative clients in Google Play, maybe some of them have this option to keep messages
  896. MattJ has left
  897. Andrew Nenakhov Why push it as standard then? Just use some form of custom made client and be happy with it
  898. labdsf Andrew Nenakhov, I think it may be useful to someone else
  899. Andrew Nenakhov Daniel has said he did such forks several times
  900. labdsf Andrew Nenakhov, I think he did it for "walled gardens"
  901. labdsf Also, if nobody noticed, I have modified XEP to have a simple <ephemeral timer="..."/> element without contents.
  902. labdsf So it is not really different from what Daniel proposes
  903. labdsf (for the walled garden use case)
  904. Andrew Nenakhov If you want it to me useful for someone else then you can't dismiss security threats by simply saying 'they are not part of a threat model'
  905. Andrew Nenakhov *to be useful
  906. labdsf malicious clients are not part of the threat model of GPG, for example
  907. labdsf encryption is not broken because someone implements a client that twits every encrypted email it receives
  908. Andrew Nenakhov Because gpg does what it does and nothing else.
  909. Andrew Nenakhov You are trying to mix two things of different nature into one flawed protocol.
  910. labdsf Also, from XEP: "An XMPP client SHOULD NOT try to restrict the ability of the user to copy and forward ephemeral messages. Any such measures will give the user a false sense of security, but can be easily circumvented by using a modified XMPP client."
  911. labdsf no need to implement an option to log messages, everyone can just copy all messages into text file
  912. labdsf Andrew Nenakhov, how is it flawed?
  913. Andrew Nenakhov It is flawed because it mixes ephemeral messages with e2ee
  914. labdsf Andrew Nenakhov, that is the way to avoid sending messages to legacy clients
  915. Andrew Nenakhov They are orthogonal, and has been said
  916. labdsf In walled-garden use case plaintext messages are allowed
  917. labdsf Andrew Nenakhov, they are, but OMEMO is the only possible way to send messages to a subset of offline clients supporting this feature
  918. Andrew Nenakhov labdsf, just say 'legacy clients are not part of a threat model' and 'i trust my contacts not to send messages to legacy clients' :)
  919. labdsf i can't trust my contacts not to send messages to legacy clients because it is not implementable
  920. labdsf XMPP has no way to send messages to a subset of offline clients
  921. labdsf Signal has, for example
  922. Andrew Nenakhov Signal is a centralized proprietary shit and they can do whatever they please
  923. labdsf it may be, I just say protocol-wise
  924. Andrew Nenakhov You can do same within your own domain and own client
  925. Andrew Nenakhov > it may be, I just say protocol-wise It is only possible because it is centralized proprietary shit )
  926. labdsf XMPP has no way to ask remote bare JID to get a list of devices
  927. Dave Cridland has left
  928. Dave Cridland has joined
  929. labdsf it has nothing to do with it being centralized or decentralized
  930. labdsf Andrew Nenakhov, also, Signal is not proprietary
  931. Andrew Nenakhov It is.
  932. labdsf in what sense?
  933. labdsf all clients and the server are actually open source and source code is even updated frequently
  934. labdsf it is just centralized
  935. Dave Cridland has left
  936. Dave Cridland has joined
  937. labdsf https://github.com/signalapp/Signal-Server <- server
  938. labdsf https://github.com/signalapp <- everything else
  939. labdsf AGPLv3 everything
  940. labdsf daniel, > i haven’t seen a compeling argument against a simple `<you-might-want-to-delete-me seconds="60"/>` I have modified it in https://github.com/xsf/xeps/pull/666 to be basically a simple <ephemeral timer="..."/>
  941. Andrew Nenakhov Can you build signal server and send messages to signal users? No?
  942. labdsf The only question is how to avoid sending ephemeral messages to legacy (not actively malicious) clients
  943. labdsf Andrew Nenakhov, no, because it is centralized
  944. Andrew Nenakhov *build from source
  945. labdsf but not proprietary
  946. Andrew Nenakhov labdsf, and is owned by Signal. That makes it proprietary.
  947. labdsf :/
  948. labdsf not sure what is your definition of proprietary, the software is free
  949. Andrew Nenakhov You can license code under AGPL or whatever, but your own installation remains your own
  950. labdsf the infrastructure is "proprietary", ok
  951. Andrew Nenakhov Signal messenger is proprietary.
  952. labdsf ok ok
  953. Andrew Nenakhov Because it does not work without central infrastructure.
  954. labdsf it is federated inside btw
  955. lskdjf has joined
  956. Andrew Nenakhov Ok, almost 4am here
  957. Andrew Nenakhov Bye
  958. marmistrz has left
  959. lskdjf has joined
  960. labdsf I should probably remove "plaintext/encrypted" distinction where possible and make it more clear that OMEMO is just a way to avoid sending to legacy clients
  961. j.r has joined
  962. waqas has left
  963. dos has left
  964. dos has joined
  965. la|r|ma has joined
  966. la|r|ma has joined
  967. goffi has left
  968. labdsf has left
  969. j.r has joined
  970. dos has left
  971. ta has left
  972. lskdjf has left
  973. lskdjf has joined
  974. Dave Cridland has left
  975. Dave Cridland has joined
  976. winfried has left
  977. j.r has joined
  978. winfried has left
  979. kasper.dement has left
  980. vanitasvitae has left
  981. lskdjf has left
  982. waqas has joined
  983. Chobbes has joined
  984. marmistrz has joined
  985. marmistrz has joined
  986. j.r has joined
  987. vanitasvitae has left