XSF Discussion - 2020-03-19


  1. winfried

    My guestblog on E2EE at APNIC is published: https://blog.apnic.net/2020/03/19/the-hairy-issue-of-end-to-end-encrypted-instant-messaging/

  2. edhelas

    winfried awesome article, perfectly sum up my though about E2EE

  3. winfried

    thanks!

  4. pep.

    e2ee.. I'm going to link this once again: https://www.eff.org/deeplinks/2020/03/earn-it-bill-governments-not-so-secret-plan-scan-every-message-online

  5. pep.

    maybe people will care to spread it

  6. winfried

    Yeah, the most fascinating of that discussion is that the definition of 'good guys' is contextual and not stable. Except for me of course, I am always the good guy.

  7. Syndace

    winfried: Sorry but in that article you seem to selectively not talk about certain things to make E2EE look bad in general. A) What about the very simple use-case that you don't want your server admin to read your private convos? Not everybody wants to protect himself from government surveillance... B) Why do you mention manual fingerprint verification and web of trust with all their problems, but don't add a note that a master key could actually solve all of that?

  8. winfried

    Syndace: and who verifies the master key?

  9. Syndace

    I don't want you to find ways now to criticise the master key, I want you to mention it in your article next to the other options

  10. winfried

    Syndace: Yes, I left out the 'dick-pic' usecase, that is true

  11. Syndace

    Your introduction very well sets the focus on e2ee vs government surveillance, but the conclusion just bashes on e2ee in general

  12. winfried

    Syndace: my point is, a master key does not really change the discussion

  13. Syndace

    It's one single fingerprint then, tied to the identity. I think that's much more bearable than n x m verifications.

  14. Guus

    I'm not reading that as a bash on e2ee at all. Rather, as a warning that e2ee comes with drawbacks that aren't always obvious.

  15. winfried

    Syndace: not only governmental, also commercial surveillance. I see way to often people believing they are of the hook of surveillance because there is e2ee. That is the false sense of security.

  16. winfried

    (but I have an appointment out of house now, will catch up later)

  17. Syndace

    > The issues with instant messaging are so hairy that it’s safe to say: “Bad encryption is a false sense of security”. Guus: IMO that doesn't say "there are drawbacks that aren't obvious" but "please don't do e2ee"

  18. Syndace

    Anyway, just wanted to get my immediate thoughts out

  19. Guus

    "think about doing e2ee before applying it"

  20. Guus

    I have switched it off by default, for some of the reasons described in the article: usability sucks.

  21. Guus

    we might not like that it does - but for a lot of people, it does.

  22. winfried

    Syndace: appreciated, I always learn from feedback

  23. Guus

    that's not to say that there's a huge audience that can happily and effectively use e2ee

  24. Guus

    but at its current state, it is not a solution that should be deployed without considering its effects.

  25. Syndace

    Also I shouldn't forget the positive things, the rest of the article is pretty cool and I agree with all of that, I especially like that you found/included some numbers on how critical the metadata is. winfried

  26. pep.

    > So commercial surveillance doesn’t rely on the content of the message at all and E2EE does not offer any protection. winfried: I'm curious where you get your confidence about this

  27. pep.

    I'm sure commercial surveillance maps social graphs, but they do need at some point to know who's doing what

  28. pep.

    they can't go further like law enforcement and tap communications. well at least legally..

  29. pep.

    though they can very well provide bogus clients

  30. Zash

    Isn't it common that they somehow manage to scrape links you send in "encrypted" messages?

  31. pep.

    this is not an issue of e2ee, probably holes in their e2ee impl. (intentional or not)

  32. pep.

    also tbh I still don't see the point of MLS' scalability for most use-cases we see in the wild

  33. pep.

    I feel like the article doesn't cover passive / active attacks really well, probably as Syndace said. it only considers active attacks and the rest seems "pointless" ("leap of faith")

  34. larma

    pep., isn't it a thing that gmail analyzes your email contents?

  35. pep.

    yeah so no e2ee

  36. larma

    That was more related to "commercial surveillance doesn’t rely on the content of the message" when apparently Googles ad network actually does.

  37. pep.

    also the article doesn't talk about e2ee from the host's perspective

  38. pep.

    I as a service provider would like my users to have some kind or e2ee so I have a level of plausible deniability

  39. winfried

    pep.: I can't know for sure commercial surveillance sole on metadata analysis (and I have some cases at hand where it doesn't). But having said that: almost every big platform has experimented with content analysis and they all got a big public backlash. If they do it, they don't want to be caught. And the pattern is of commercial surveillance is extremely simple: I am active in chatgroup HCP3, most member of chatgroup HCP3 buy gear for field-hockey, so I am a good target for advertisment for field-hockey.

  40. winfried

    pep.: the service provider protecting itself is one of the strongest usecases for e2ee right now, the intimate chat usecase is the other one.

  41. pep.

    "intimate"? what about "privacy by default"? :)

  42. winfried

    Privacy by default is only meaningfull if you define what aspects of privacy you want to protect or explain what you mean by privacy. The metadata of me contacting my general pacticioner contains a little information you may want to protect. The metadata of me contacting a STD clinic contains a lot of information I want to protect. There is no 'default' for privacy by default.

  43. pep.

    We understand that "metadata" is not covered by e2ee in the general case, no need to rub it in :)

  44. winfried

    Yeah, already wondered if I should give a non-metadata example :-)

  45. pep.

    !

  46. pep.

    it's time

  47. pep.

    MattJ, Seve, ralphm

  48. Seve waves

  49. ralphm bangs gavel

  50. ralphm

    0. Welcome

  51. MattJ

    o/

  52. ralphm

    Hi all! Guus sent his regrets.

  53. ralphm

    Any items for the agenda?

  54. pep.

    yep

  55. MattJ

    None here

  56. pep.

    I added that two days ago

  57. pep.

    I'll send an email when there's actual content to to it

  58. pep.

    -to

  59. ralphm

    The Communications person one?

  60. pep.

    yep

  61. ralphm

    ok

  62. ralphm

    1. Minute taker

  63. pep.

    I'll do it afterwards

  64. ralphm

    Thanks pep.

  65. ralphm

    2. Hire Communications Person

  66. ralphm

    pep., do you have an idea on the types of tasks this person would perform?

  67. pep.

    At the moment I'm thinking about handling the newsletter, being present on social media. a few hours a week. I'm sure this can evolve pretty quickly, we could also ask them to talk at conferences etc. later on

  68. ralphm

    Which has most recently been done by, primarily Nyco, right?

  69. pep.

    For some time yes

  70. pep.

    Nyco hasn't really been present for a few weeks now, after summit I'd say

  71. pep.

    I would prefer this to be supported by commteam tbh

  72. pep.

    But the situation is what it is

  73. pep.

    emus is helping as he can with the newsletter lately, and I'm helping him a bit

  74. ralphm

    So currently the commteam is nyco, JC, and Seve, if I remember correctly.

  75. pep.

    We have no presence on mastodon anymore, let alone twitter

  76. pep.

    Yep

  77. emus

    Hello guys

  78. pep.

    If we don't keep up with the work nyco was doing (and possibly more), we're going to disappear again :)

  79. ralphm

    T.b.h. I have no idea on our presence on mastodon or its significance. As a platform it is too obscure to me to want to track it. I have been really happy with the increase of Tweets on @xmpp, as well as the newsletter. Post-FOSDEM is often a lower energy time. I'm sure that the current world-wide crisis doesn't help.

  80. MattJ

    Yeah, I'm in favour (as I believe Nyco was) of hiring someone

  81. ralphm

    I am, too.

  82. MattJ

    I'm also strongly in favour of a presence on Mastodon

  83. MattJ

    The reality is that a bunch of our target audience use it in preference to Twitter, for hopefully obvious reasons

  84. jonas’

    our target audience as the XSF?

  85. jonas’

    so, developers?

  86. MattJ

    A lot of discussion about XMPP (and other decentralized communication options) happens there, and it would be good to have an official presence

  87. Seve

    Well, the platform is for me not one of the important things here

  88. MattJ

    jonas’, yes

  89. Seve

    Regarding hiring somebody

  90. pep.

    Seve, yeah it's also not for me. That can be discussed once we get somebody for sure

  91. Zash

    FOSS folks are likely to appreciate a Mastodon presence. :)

  92. pep.

    So yeah there isn't much to discuss atm. I'm just looking at the kind of person we could want, what kind of work they'd do, and budget that

  93. pep.

    I started to poke around already

  94. ralphm

    We also need to figure out how to contract a person for work, proceduraly. It think we did minor things like that in the past, but am not sure. I think it would be good to ask Peter about it.

  95. pep.

    Sure, that'd be good to know. That's not the last person I want to recruit :)

  96. pep.

    I'll poke peter about this

  97. ralphm

    I didn't mean for him to be the person to hire. I mean to ask him about the process of hiring a person.

  98. pep.

    yes yes

  99. ralphm

    :-D

  100. ralphm

    Ok, good idea. Shall we keep this for next meeting

  101. ralphm

    ?

  102. pep.

    Sure

  103. ralphm

    3. Board Voting Process and Discussions

  104. ralphm

    The item we dropped last week.

  105. ralphm

    pep., you wanted to revisit this, right?

  106. pep.

    Well I don't have much to add. I initially thought it would have been a 5mn chat with not much cons, especially since you mentioned that you've been somewhat doing it already so I'm not sure why we couldn't do it

  107. pep.

    If the issue is with updating the Bylaws, I'm happy to have a list of things to change next time we update them, similar to what we have for XEPs / RFCs

  108. pep.

    (increasing the required "In favor" votes to 3 for a motion to pass)

  109. pep.

    There are other things to update in the bylaws anyway

  110. ralphm

    Ok, just to summarize for me: I am very happy to clarify to people how we do things, why we do them, etc. Not so keen on changing stuff unless really needed.

  111. pep.

    I want to make it less painful to update things, otherwise that's the behaviour we get in indeed

  112. pep.

    "I don't want to change unless necessary"

  113. pep.

    Also, the more we practice the easier it gets :P

  114. ralphm

    Maybe I could express that better: I think that often, we do not have to change, for example, our bylaws, to do a thing.

  115. pep.

    I'm not entirely fond of bylaws (or specs for that matter) not reflecting the reality of things, and just having people using loopholes here and there because "that's how things are done now"

  116. pep.

    I think documentation is key

  117. pep.

    And bylaws are part of this

  118. MattJ

    Document, and later amend bylaws if needed?

  119. ralphm

    Our bylaws, procedures, etc. form a framework for Board, our workteams and SIGs to work within. We don't have to adapt it to perfection in order to function.

  120. ralphm

    I agree that documentation helps. That's why I was also in favor of recording Board decisions on the wiki.

  121. ralphm

    I'm particularly careful with changing bylaws. I also know of no organisation that considers changing bylaws a regular activity that should be "easier with time".

  122. ralphm

    But if our Bylaws become an obstacle to effect a change or getting something done, then of course we can.

  123. ralphm

    pep., hope that helps

  124. pep.

    not really.

  125. pep.

    I'll document things and we'll see

  126. ralphm

    ok

  127. ralphm

    Anything else on this point?

  128. pep.

    Apparently not

  129. ralphm

    ok

  130. ralphm

    5. Sponsorship

  131. ralphm

    I've sent a draft to our mailinglist. Please comment.

  132. ralphm

    6. AOB

  133. ralphm

    ?

  134. Seve

    None here.

  135. pep.

    none from me either

  136. pep.

    hmm, why board for the sponsorship mail?

  137. ralphm

    because it is a draft

  138. pep.

    So members have no say in this?

  139. ralphm

    pep., the membership have elected us to run the cooperation. That means that we do on their behalf. I took drafting a letter to our sponsors as one of such tasks, and I'm asking board for its input.

  140. pep.

    Sure, but I don't see the need to restrict access to the membership to what we're doing

  141. Rob Loranger raises hand

  142. ralphm

    Rob Loranger, on this topic?

  143. pep.

    When I started the proposal for sprints I sent that to members@ and I did get valuable feedback

  144. pep.

    Even if it was a scam issue

  145. ralphm

    pep., I'm happy for you to make that call for that case. I just made a different one for this.

  146. Rob Loranger

    Yes, just that although I'm not yet a member, I don't think this is keeping anything from the membership. I live in a co-op and lots of things like this are handled by the board, they can't be going back and forth with members on everything they are doing. So as a potential member I don't see an issue

  147. MattJ

    I note that we did previously agree that board@ was for stuff that couldn't be public (or trivial noise), I don't think this is either

  148. pep.

    My point is not to get members to give feedback on everything, it's just to keep the door open in case there is feedback

  149. MattJ

    I'm less concerned about transparency and more that wider feedback may be valuable

  150. ralphm

    MattJ, sure. On the other hand, my goal was a carefully drafted letter to our sponsors. Given that currently our sponsors are also represented in the membership, arguing its contents on the members mailinglist makes sending a letter almost meaningless.

  151. pep.

    MattJ, that goes hand-in-hand to me

  152. pep.

    ralphm, I don't think so

  153. MattJ

    ralphm: that's fair reasoning to me

  154. pep.

    They can very well read the board meetings and see about the same content

  155. pep.

    So I'd be happy to get feedback from members on the final formal form as well

  156. pep.

    Anyway, that's one thing I said I disliked about board, I raised the issue and that was discussed, but I see that's not changing very much

  157. ralphm

    pep., I don't think that just because you dislike a thing, that means others must agree. I like to operate in the open as much as possible. I don't think that input from the membership for this particular thing is required. That doesn't mean that it proves your point that things don't change.

  158. pep.

    Including the bylaws thing above, I think it does a bit. But let's agree to disagree

  159. ralphm

    ok

  160. ralphm

    Oh, Rob Loranger thanks for your comment!

  161. ralphm

    7. Date of Next

  162. ralphm

    +1W

  163. ralphm

    8. Close

  164. pep.

    yep

  165. ralphm

    Thanks all!

  166. pep.

    Thanks

  167. ralphm bangs gavel

  168. Seve

    I'm all for transparency, but on this case, I don't see the problem of Board working on a draft that can be sent after to members. Actually Rob Loranger had a good point

  169. Seve

    Alright, thank you

  170. MattJ

    Thanks all

  171. ralphm

    Thanks Seve. Let's consider that said within the meeting :-D

  172. Seve

    Hehe ;D

  173. pep.

    "Rob Loranger> [..] they can't be going back and forth with members on everything they are doing", not targeting you rob here, just to answer comments on your messages, as I said this it not my point here.

  174. pep.

    And "members" is just "somebody else's email" or "one more voice during the board meeting", so I don't think that's very much of a hassle

  175. Rob Loranger

    No, and there's no reason not to ask for member input. It's just not something I as a member would be very concerned with reading beforehand. Maybe as mentioned the proposed final draft could then pass by general membership for comments.

  176. moparisthebest

    Kev, friendly reminder about promised XEP-0001 clarifications, I understand it's crazy times so no rush just wanted to bring it up since I remembered again :)

  177. Kev

    Noted.

  178. MattJ

    Kev, friendly reminder about notification management XEP you promised to take on at the summit

  179. Kev

    That one I did *not* promise to appear in any reasonable time!

  180. MattJ

    Just reminding :)

  181. jonas’

    .oO(that’s why the reminder is friendly :>)

  182. pep.

    MattJ, friendly reminder (or rather request, plz) about making a list of things to be done within iteam :p

  183. MattJ

    Done: https://github.com/xsf/infrastructure/issues

  184. MattJ

    Ok ok, there is also a Trello board somewhere :)

  185. pep.

    Is it just this one issue? :P

  186. pep.

    Can I add things?

  187. jonas’

    FTR

  188. Zash

    > No description provided. REEEEEEEE!

  189. MattJ

    pep., go ahead

  190. jonas’

    Docker images hosted by GitHub cannot be pulled without credentials

  191. Zash

    Github hosts docker images now?

  192. pep.

    MattJ, that was mostly in case we'd get somebody to do the work

  193. MattJ

    jonas’, shouldn't be an issue, Snikket uses Github to build and pushes to docker hub

  194. pep.

    > Marc has left the room (Disconnected: Received SIGTERM) > Syndace has left the room (Disconnected: Received SIGTERM) I've seen you both leave at exactly the same second twice now, do you use the same client?

  195. pep.

    Is that some weird payload?

  196. Zash

    Server, rather?

  197. pep.

    or server

  198. pep.

    I'm not moderator here

  199. pep.

    Ah, server.

  200. Zash

    That looks like what Prosody kills all sessions with when it ... receives SIGTERM.

  201. pep.

    Maintenance then maybe

  202. Marc

    > Maintenance then maybe yes

  203. Ge0rG

    So much for user-friendly termination messages.

  204. Ge0rG

    I could bet my right arm that there was an issue about making the wiki mobile-friendly on one of the XSF trackers

  205. Zash

    Ge0rG, problem: The wiki uses Postgres. All current Docker images use MySQL. Migration: probably painful.

  206. Ge0rG

    https://github.com/xsf/mediawiki-docker/issues/2

  207. Syndace

    yup, working on the server

  208. jonas’

    moparisthebest, where is your magic letsencrypt/nginx snippet?

  209. moparisthebest

    jonas’, https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mode

  210. jonas’

    hm, how do I obtain that thumbrint from certbot?

  211. Zash

    hash of the account key or something?

  212. Zash

    `base64url( sha256( json jwk ) )`

  213. Zash

    json serialized with sorted keys. mmmmmmmmm.

  214. moparisthebest

    uh, maybe the easiest way would just be to inspect the file certbot spits out jonas’ ?

  215. moparisthebest

    otherwise I'm sure there's a way, just don't have it handy

  216. jonas’

    nevermind, got it to work

  217. Rob Loranger

    I just made fake servers with nginx for any domains and import them as a hook