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