XSF logo XMPP Council - 2018-06-07

  1. SamWhited has left
  2. jere has left
  3. Zash has left
  4. jere has joined
  5. jere has left
  6. Dave has left
  7. Dave has left
  8. Dave has left
  9. Dave has left
  10. Dave has left
  11. flow has left
  12. moparisthebest has left
  13. moparisthebest has joined
  14. Lance has joined
  15. Lance has left
  16. jere has joined
  17. moparisthebest has left
  18. moparisthebest has joined
  19. jere has left
  20. Tobias has left
  21. Tobias has joined
  22. Dave has left
  23. Dave has left
  24. jonasw you know that I’m not fond of Ephemeral messages, but voting on it based on "it is NTP over XMPP" was incorrect I think. I was unable to find any NTPy thing in there, and the person who suggested that on the ML backed out of that claim.
  25. jonasw also, I’d like to see reasons for the other -1s
  26. guus.der.kinderen has left
  27. guus.der.kinderen has left
  28. Kev has left
  29. guus.der.kinderen has left
  30. guus.der.kinderen has left
  31. guus.der.kinderen has joined
  32. Dave has left
  33. guus.der.kinderen has left
  34. Dave has left
  35. flow has joined
  36. Dave has left
  37. Dave Well, it's synchronizing timers and things. I'm basically not convinced of the security guarantees it's possible to offer around ephemeral messaging in general, and this seemed a particularly poor (and over complicated) rendition.
  38. jonasw it’s not really synchronizing timers. all it does is saying "hey, your client should keep this message for at most N seconds"
  39. jonasw there’s no synchronization going on
  40. guus.der.kinderen has left
  41. guus.der.kinderen has left
  42. guus.der.kinderen has left
  43. guus.der.kinderen has left
  44. Kev There's synchronisation of what you want the timers to be.
  45. Kev There isn't synchronisation of the time.
  46. Kev At least, given my reading.
  47. Kev But given that I found it very hard to read and extract what it intended people to do, I think that's a fair reason to reject it at the moment.
  48. jonasw I disagree. The ability to extract the intent from the text is (in this case, I think) mostly matter of language and structure, and thus editorial. That should not be reason to reject it from going to Experimental.
  49. jonasw (as much as I dislike the thing)
  50. flow what jonasw said
  51. flow has joined
  52. Kev I'm happy for an Editor to try to clear it up so that it's possible to read it sensibly, but as things stand I can't judge the XEP properly because I can't understand what it's trying to do properly.
  53. jonasw so we’re going to reject this based on lack of manpower in the editor team, essentially? ;-)
  54. Kev I'm fairly sure that once it's clear what it's trying to do it'll be clear that it would be rejected for technical reasons.
  55. Kev So no, not really.
  56. jonasw meh
  57. Kev From what I can tell, it's got this overcomplicated and underspecified synchronisation protocol for the expiry values, which seems out of place here.
  58. Kev As well as having this weird overlap between "This isn't for security, it's just for hinting" and "Here's all this extra work we're doing to try to guarantee security".
  59. daniel i see if i can find some time next week to come up with a protoxep that’s just the hint
  60. jonasw this might offend the authors of that XEP
  61. guus.der.kinderen has left
  62. jonasw different question: would adding a note which hints to how things were done in the past (clearly marked up as "note" and "things in the past, but still around in some implementations") be editorial?
  63. jonasw I’m "asking for a friend" who wants to add such a note to XEP-0045.
  64. guus.der.kinderen has left
  65. Kev "It depends" is I think the answer.
  66. Kev I'd normally expect editorial changes in a Draft XEP to be typos and grammar corrections and things.
  67. jonasw okay
  68. jonasw gonna make a proper PR instead
  69. jonasw there you go: https://github.com/xsf/xeps/pull/664
  70. ralphm has joined
  71. daniel has left
  72. guus.der.kinderen has left
  73. guus.der.kinderen has left
  74. guus.der.kinderen has joined
  75. Dave jonasw, You can't possibly be arguing that a XEP that's too badly written for council to understand should be accepted, can you?
  76. jonasw Dave, when you put it that way it sounds horrible.
  77. jonasw I don’t think though that it’s impossible to understand and that it can be fixed
  78. Dave So you're agreeing it can't be fixed, then? ;-)
  79. jonasw argh
  80. jonasw lanugage is hard
  81. jonasw it can be fixed I mean
  82. Dave ^^ irony.
  83. jonasw yeah
  84. Dave The thing is, I don't believe one can design something that gives a message an expiry for security reasons in an open interoperable way. To get those guarantees, you need restrictions on the server and clients that are unprovable.
  85. jonasw yes
  86. jonasw but isn’t it worthwhile to have a common way to do this, even if it only makes sense in specialised deployments?
  87. jonasw that would reduce the setup/development cost for those deployments.
  88. Kev Maybe, yes, but I think most of what's in the XEP is trying and failing to get security guarantees it can't achieve.
  89. daniel Dave: but arguably it is still valuable to have it standardized and then get library support so people who are using xmpp in closed environments (which I guess is the majority of people) have working solution ready
  90. Kev Yes.
  91. Dave I live in "specialised deployments", so I appreciate the sentiment. We hgave XEPs for adding classifications etc to messaging, for example. I'm all in favour of that. But those cases still provide guarantees outside of those environments. I'd be worried about the implication, so I'd want - from the outset - a clear scope on such a XEP.
  92. Kev But I'm not convinced that /this/ document is the way we would choose to standardise it for closed environments either.
  93. Dave Kev, +1 there.
  94. daniel Kev: no it's not
  95. jonasw okay fine
  96. jonasw now I wish those arguments make it into the council minutes
  97. jonasw because having "it does NTP" as rejection reason there isn’t great
  98. daniel also i think one has to use signal to understand what a timer setting update is
  99. daniel because i dont
  100. daniel i mean i get that you annotate each message with a burner. but why do you need to send updates?
  101. daniel and what does it update?
  102. jonasw the update is intended to make sure that the other side will use the new timer value on their next message
  103. jonasw i.e.: A and B have agreed on timer value X A wants to use timer value Y, so sends timer update B sends their next message with timer value Y
  104. flow FWIW I assumed timer updates to sync all devices a a user
  105. jonasw ah, other devices of the same user, too
  106. daniel ok. a) weirdly i have never been requested to implement this feature b) arguably it should use different syntax then
  107. daniel is this only signal that does this? where my contact can dictate the timeout message?
  108. jonasw I really wonder what type of people use this feature.
  109. jonasw (well, except people who really, truely need things like that)
  110. daniel that seems a bit dangerous. so if i'm just in the process of sending a password or other delicate information my contact increases the time out from 60s to 5 years
  111. jonasw good point
  112. pep. But this is not a security feature after all so I shouldn't really on this to hide a password right. Or is it still in the context of closed environments
  113. jonasw I think the latter, pep.
  114. Kev That's the confusion. It's both trying not to be a security document, and also trying to be a security document.
  115. daniel no it’s a just a hint; so in case of passwords it's like here i'm sending you information which you should copy paste into your password manager and then delete from the devices history
  116. daniel and arguably it is doing that job
  117. daniel (speaking about burner messages in general now. not that particular xep)
  118. pep. daniel, burner messages as in "marking messages as [sensitive/private]"?
  119. daniel no burner messages as in 'hey it's a good idea to delete that message after you mentally or (otherwise) processed that information
  120. daniel a friendly reminder between friends
  121. pep. k
  122. daniel a friendly reminder between friends is also what i'm going to call the XEP
  123. daniel so there wont be any confusion
  124. pep. err, s/really/rely in a previous sentence
  125. Dave pep., Marking messages as sensitive/private is already covered by XEP-0258, incidentally.
  126. pep. I see
  127. vanitasvitae has left
  128. moparisthebest has joined
  129. daniel has left
  130. guus.der.kinderen has left
  131. guus.der.kinderen has left
  132. guus.der.kinderen has left
  133. guus.der.kinderen has left
  134. daniel has left
  135. daniel has joined
  136. vanitasvitae has left
  137. jere has joined
  138. guus.der.kinderen has left
  139. moparisthebest has joined
  140. SamWhited has left
  141. jere has left
  142. SamWhited has left
  143. jere has joined
  144. Kev has left
  145. guus.der.kinderen has left
  146. guus.der.kinderen has left
  147. Holger has left
  148. moparisthebest has left
  149. guus.der.kinderen has left
  150. guus.der.kinderen has left
  151. guus.der.kinderen has joined
  152. guus.der.kinderen has left
  153. guus.der.kinderen has left
  154. guus.der.kinderen has joined
  155. guus.der.kinderen has left
  156. daniel has left
  157. daniel has joined
  158. guus.der.kinderen has left
  159. guus.der.kinderen has left
  160. daniel has left
  161. daniel has joined
  162. guus.der.kinderen has left
  163. Lance has joined
  164. Lance has joined
  165. SamWhited has left
  166. guus.der.kinderen has left
  167. guus.der.kinderen has left
  168. vanitasvitae has left
  169. Tobias has joined
  170. Tobias has joined
  171. Zash has left
  172. Zash has left
  173. Zash has joined
  174. Lance has joined
  175. Tobias has left
  176. Tobias has joined
  177. Lance has joined
  178. Kev has left
  179. Kev has left
  180. Zash has left
  181. Tobias has left
  182. Tobias has joined
  183. Lance has joined
  184. Lance has joined
  185. Tobias has left
  186. Tobias has joined
  187. Dave has left
  188. guus.der.kinderen has left
  189. guus.der.kinderen has left
  190. guus.der.kinderen has joined
  191. SamWhited has left
  192. Dave has left
  193. Dave has left
  194. bear has left
  195. bear has joined
  196. SamWhited has left
  197. guus.der.kinderen has left
  198. Tobias has left
  199. Tobias has joined
  200. Tobias has joined
  201. Tobias has joined
  202. Tobias has joined
  203. Tobias has joined
  204. Kev has joined
  205. jere has joined
  206. Tobias has joined
  207. Dave has left
  208. Dave has left
  209. Dave has left
  210. guus.der.kinderen has left
  211. daniel has left
  212. daniel has joined
  213. SouL has left
  214. Dave has left
  215. Dave has left
  216. jere has joined
  217. Dave has left
  218. Dave has left
  219. moparisthebest has left
  220. jere has left
  221. Dave has left
  222. Dave has left
  223. Dave has left