XSF Discussion - 2018-03-27

  1. moparisthebest

    I haven't read exactly but last I had heard that was out

  2. Williams W


  3. Williams W


  4. Williams W


  5. Williams W


  6. flow

    Williams W, hi

  7. Williams W


  8. pep.

    GDPR thing in 10min

  9. winfried


  10. Ge0rG

    winfried: do you happen to be using an old Gajim version?

  11. jonasw


  12. winfried

    Ge0rG: nope, Psi+

  13. jonasw

    can we discuss the time frame for this meeting real quick?

  14. winfried

    because of my (y)

  15. jonasw

    I allocated an hour, would be happy with less too, more would be an issue.

  16. Ge0rG

    yeah, we should attemt to get through this quickly, I'm 2hr over the time budget already.

  17. winfried

    good, I will aim for a close at 13:15 at max

  18. winfried


  19. Williams W


  20. Williams W


  21. winfried

    pep.: are you there?

  22. jonasw


  23. pep.


  24. winfried

    nice aditions from peter btw

  25. jonasw


  26. winfried

    I will try to setup a wiki page today

  27. winfried

    (beside my other work)

  28. pep.

    I'll continue with the minutes

  29. jonasw

    pep., will you be taking minutes again? :)

  30. jonasw

    thanks :)

  31. winfried


  32. winfried

    think it is best to discuss federation right away now

  33. jonasw


  34. pep.

    Q1) 1. What consequences does the GDPR has for the Jabber network? 2. .. Jabber server operators? 3. .. what can/should do the XSF with that? Q2) What consequences does the GDPR has for the XSF running Jabber server? Q3) What consequences does the GDPR has for the work processes of the XSF itself (membership, voting, wiki etc)?

  35. Ge0rG

    I think we didn't cover d-f of Q1.1 yet?

  36. pep.


  37. Ge0rG

    pep.: from yesterday's list of aspects

  38. Kev

    I'd suggest (and I don't really want to get involved in this) that Q2 and Q3 are much more urgently important for the XSF than Q1.

  39. pep.

    Both of them depend on Q1

  40. pep.

    Well, Q2 at lesat

  41. winfried


  42. pep.

    Well, Q2 at least

  43. winfried

    Ge0rG: what is on your list about Q1.1?

  44. Ge0rG

    a is it in the GDPR jurisdiction, what data is b what data is processed c what processing is done d what ground does the processing have e possible consequences

  45. Ge0rG

    Maybe there was no f.

  46. pep.

    no f

  47. jonasw

    no f

  48. winfried

    we didn't fully cover grounds for c2s, true

  49. Ge0rG

    I'd like to cover the grounds before moving on with the other Qs

  50. winfried

    Ge0rG: good

  51. Ge0rG

    the potential consequences are vague at best anyway.

  52. Ge0rG

    vaguely scary.

  53. winfried

    Ge0rG: Yes, it is the GDPR ;-)

  54. Ge0rG

    I'd argue that if the user sends content via our server, they are giving implicit consent for us to process it.

  55. jonasw

    Ge0rG, I’m so sure this is false.

  56. jonasw

    the user could expect e.g. the server to forward it, but not to store it in MAM

  57. Ge0rG

    jonasw: I'd argue that either Art 6 §1 or §2 apply.

  58. jonasw

    or store it for less time

  59. Ge0rG

    no, way. §1 a or b.

  60. jonasw

    consent needs to be explicit

  61. jonasw

    (b) may very well apply

  62. winfried

    I would vote for 6.1b

  63. jonasw

    but that is overridden by 9.1

  64. jonasw

    and after Peters comments I think that 9.1 very much applies to messages.

  65. Ge0rG

    jonasw: I'm not sure about that.

  66. Ge0rG

    maybe this is actually something to ask a lawyer about

  67. jonasw

    okay, so maybe let’s write that down as something somebody should definitely consult a lawyer on.

  68. jonasw


  69. pep.

    hmm, I don't see how 9.1 fits in that. I'll add a TODO

  70. Ge0rG

    LQ1: does 9.1 automatically apply to all (not e2ee encrypted) user-sent content, or only if we are analyzing it for profiling/other purposes?

  71. jonasw

    pep., in my mind, most of the GDPR handles general personal data, and 9.1 adds overrides for a certain type of personal data and prohibits all use except that outlined in 9.2

  72. winfried

    look at 9.2e...

  73. jonasw

    winfried, I’d argue that sending a message to another user is "not making it public"

  74. winfried

    hmmm, but the xmpp server(operator) is third party...

  75. jonasw

    winfried, I’d argue that sending a message to another user is not "making it public"

  76. winfried

    pep., can you note this as subject for further consulting?

  77. pep.

    hmm, let me see if I get this

  78. pep.

    what is "this" in your sentence

  79. jonasw


  80. pep.

    Ah, yes it's aded already

  81. pep.

    Ah, yes it's added already

  82. Ge0rG

    jonasw: lawyer-question

  83. pep.

    This is for Q1.1.a then?

  84. jonasw

    Ge0rG, I am aware.

  85. jonasw

    Ge0rG, I made a suggestion for what winfried might be talking about :)

  86. pep.


  87. Ge0rG

    jonasw: ah, that wasn't clear to me. sorry

  88. pep.


  89. winfried

    Ok: art 6.1 is explicit permission, art 6.2 is implicit permission. Article 9.1 overrides article 6 and sets its grounds in article 9.2. So if the messages are of the categories in 9.1, then we must go for explicit permission from 9.2a, otherwise we can do 6.2

  90. Ge0rG

    we need to cover d) for all data types

  91. winfried

    Ge0rG: exact

  92. Ge0rG

    server logs are the easiest thing.

  93. Ge0rG

    we have those under R49

  94. winfried

    so the question for a lawyer is: are message bodies 9.1 or not?

  95. jonasw

    winfried, yes.

  96. winfried

    Ge0rG: yes, agree with logs

  97. Ge0rG

    if we consider the usage of an XMPP server as a contract between the user and the server operator = controller, 6.1b should apply to most things

  98. jonasw

    ... except that it should be clearly stated what happens, right?

  99. Ge0rG

    credentials are required, IP addresses might be argued under R49, timestamps / presence timestamps are complicated.

  100. jonasw

    presence timestamps shouldn’t be 9.1 at least

  101. Ge0rG

    presence timestamps are probably covered by user's consent when they accept a subscription

  102. jonasw

    I have the feeling you’re lax with consent.

  103. jonasw

    maybe it’s just me, but I think consent can’t be established without the user being informed. so unless we inform the user actively what "add a contact" means regarding metadata, we can’t talk about consent here.

  104. pep.

    I also feel that needs to be specified in EULA of some sort

  105. Ge0rG

    jonasw: > any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her

  106. pep.

    Ge0rG, that means they understand the protocol though, right?

  107. jonasw

    > informed

  108. Ge0rG

    So XMPP clients need to show a warning in the add-contact dialog, that metadata will be published to their new contact?

  109. jonasw


  110. winfried

    Isn't that for permission according to 6.1?

  111. pep.

    I would say this needs to be specified when signing in for an account instead?

  112. jonasw

    pep., that would work too

  113. jonasw

    probably better

  114. jonasw

    because this takes the load off clients

  115. pep.


  116. jonasw

    (aside from that they need to support the EULA XEPρ

  117. jonasw

    (aside from that they need to support the EULA XEP)

  118. pep.

    yes, that still needs figuring out

  119. winfried

    I think 13.1 applies here

  120. Ge0rG

    winfried: is 13.1 in addition to asking for consent?

  121. Ge0rG

    or is it possible to have a published data collection policy and assume implicit consent from users?

  122. jonasw

    13.1 feels weird

  123. winfried

    the last

  124. pep.

    Ge0rG, [x] I have read the conditions and agree

  125. jonasw

    I think i need an epub of that thing and read it on the trains

  126. winfried

    btw: all of 13 is applicable

  127. winfried

    13.4 is also interesting ;-)

  128. jonasw

    winfried, right

  129. pep.

    So that means EULA should do

  130. jonasw

    I think sot oo

  131. winfried

    IF we can do it under 6.2

  132. Ge0rG

    I'd argue that we don't need explicit consent for 6.2, and if we ask for explicit consent, we can tell the user not to upload 9.1 relevant data ;)

  133. jonasw

    Ge0rG, "so, hey, we’ve got an IM system here. but don’t use it for private communications."

  134. Ge0rG

    jonasw: yes

  135. jonasw


  136. Ge0rG

    jonasw: this is clearly legalese blame shifting.

  137. pep.

    Ge0rG, I feel 9.1 applies only if we do more than storage on the data, but yeah that's LQ1, we'll see

  138. jonasw

    Ge0rG, but if we ask for consent, why not ask for consent for 9.1 data, too?

  139. jonasw

    pep., storage IS processing

  140. pep.

    I know

  141. winfried

    I would say: if we go for consent, we should go for consent as in 9.2, so 9.1 is covered

  142. pep.

    That's why I specified

  143. jonasw

    winfried, +1

  144. pep.

    Ah, hmm

  145. pep.

    Ok so 9.1 is meh, and we should probably cover ourselves, ask for consent as well

  146. jonasw


  147. jonasw

    but also the risk things Peter mentioned

  148. pep.

    let me read that, one sec

  149. jonasw

    specifically: > It could be argued that storing very sensitive personal information, albeit for a short time, unencrypted, visible to anyone with access to the backend server (and perhaps more), does not constitute proportional data protection measure, knowing how sensitive the information can be in some cases. It could therefore also be argued, that the processing “reveals” this information to unauthorized persons, by the way it is implemented. It could therefore be argued, that such processing is contrary to what is required by article 9.

  150. jonasw

    his suggestions boil down to exactly what Ge0rG said

  151. winfried

    jonasw: yes, but at how many servers is it easy for the operator to read MAM archives or view their rosters and bookmarks?

  152. jonasw

    winfried, ssh myserver; cat /var/log/prosody/archive/**/*

  153. jonasw

    winfried, ssh myserver; cat /var/lib/prosody/archive/**/*

  154. Kev

    winfried: All, I'd assume.

  155. jonasw

    similarly for bookmarks and roster

  156. jonasw

    it’s trivial

  157. pep.

    Also, in any case, the hosting provider will have access to the data

  158. jonasw

    yes, but that surely is covered somehow.

  159. jonasw

    probably something about "processor"

  160. Ge0rG

    We need to do encryption!11

  161. jonasw

    Ge0rG, yes, that seems to be the safest course of action

  162. winfried

    jonasw: yes, controller / processor thing

  163. jonasw

    e2ee everywhere

  164. pep.

    Ge0rG, even with full-drive encryption, as long as the provider has access to the virtualization software..

  165. jonasw

    pep., yes.

  166. winfried

    You can do technical protection and legal protection

  167. Ge0rG

    pep.: yes, but the checkmark is crossed.

  168. pep.

    hmm, I want to believe you

  169. Ge0rG

    Regulatory Compliance is a complicated thing.

  170. jonasw

    i wanna burn something now

  171. winfried

    jonasw: my 320p bible on the GDPR?

  172. Ge0rG

    okay, we are not moving forward.

  173. pep.

    Ok so, where are we for d) ?

  174. pep.

    With this big passage about 9.1 and consent

  175. winfried

    we have LQ1

  176. Ge0rG

    pep.: somewhere between 6.1a, 6.1b and 9.2

  177. winfried

    and the question of privacy by design of storage at the server

  178. Ge0rG

    I'll ask my local GDPR expert as well, and maybe Peter can shed some light as well

  179. Ge0rG

    winfried: that's a technical question though.

  180. pep.

    Ge0rG, 9.2a specifically?

  181. Ge0rG

    pep.: "explicit consent"

  182. pep.


  183. winfried

    Ge0rG: but it may be a consequence that technical measure need to be taken :-(

  184. jonasw

    I’m pretty sure that we’ll need to take technical measures.

  185. Ge0rG

    we need to take technical measures anyway.

  186. Ge0rG

    even for 6.1a/b

  187. winfried

    Ge0rG: depending on the risk assesment, but looking at ubbers practices, yes...

  188. Ge0rG

    winfried: the exact amount of technical measures is subject to discussion.

  189. winfried

    Ge0rG: yes

  190. Ge0rG

    winfried: I think we can't cover that here.

  191. Ge0rG

    So I suggest we skip over "consequences" and follow to the next questions

  192. Ge0rG

    Or maybe we look at federation now

  193. winfried

    Ge0rG: not here, not now.

  194. winfried

    Ge0rG: we have got 20 minutes left, and need some time for discussing next steps/next appointments

  195. winfried

    so, lets say 10 minutes federation?

  196. Ge0rG

    winfried: +1

  197. Ge0rG

    we need to differentiate whether the other server is under GDPR as well or not.

  198. winfried

    Ge0rG: yes and wether the server is making secondary use of the data or not

  199. pep.

    I'm sure it is, but how

  200. Ge0rG

    By sending a message to somebody, a user clearly wants us to deliver that message to somebody.

  201. jonasw

    I somehow managed to kill my poezio

  202. jonasw

    Ge0rG, aren’t all servers under GPDR potentially?

  203. pep.

    jonasw, I'm sure I can do that blindfolded

  204. jonasw

    Ge0rG, because they might receive data from entities from the EU

  205. jonasw

    9.1 data even (if messages fall in that category)

  206. Ge0rG

    So when we are the sending server, we just follow what the user asked for and we don't need to ensure the receiving server is GDPR compliant.

  207. Ge0rG

    jonasw: they can block federation with the EU ;)

  208. Ge0rG

    my point is: our user gave us that message with the explicit request to deliver it to some other entity.

  209. Ge0rG

    that's what we do (plus local archive storage), and that's where our responsibility ends

  210. pep.

    Ge0rG, delivery is a thing, processing on the other side is another. Maybe we should look into transfer regulations?

  211. jonasw

    Ge0rG, but does the user also consent to have their message stored by the other entity?

  212. winfried

    I think the line of reasoning is:

  213. winfried

    - transfer to an other controller is one possible processings to

  214. winfried

    - it can be covered by the same concent as the other processings (LQ1)

  215. Ge0rG

    jonasw: I think that the receiving user giving consent is sufficient.

  216. jonasw

    Ge0rG, I’d like to have that settled properly, though

  217. winfried

    - EXCEPT when the other server is making secondary use of the data (then at least 6.2 can't apply anymore)

  218. Ge0rG

    jonasw: the sender indicated that they want the message delivered

  219. jonasw

    Ge0rG, given that sharing phone contact info wiht WA is illegal in DE, I imagine that things might be worse with 9.1 data being stored without "proportional means of protection"

  220. winfried

    jonasw: yes, that is the other issue: jurisdiction

  221. jonasw

    Ge0rG, in the WA case, the victim gave their phone number to the offender, which forwarded it to WA.

  222. jonasw

    I think this is a very similar case.

  223. jonasw

    but with more sensitive data

  224. jonasw

    but IANAL

  225. Ge0rG

    jonasw: I don't think it's the same.

  226. jonasw

    why not?

  227. pep.

    I think we need LQ2 here

  228. Ge0rG

    jonasw: in this case, the victim sends the content to the offender via the evil server.

  229. Ge0rG

    I wonder how SMS/MMS processing is legally protected

  230. jonasw

    Ge0rG, I had the same thought.

  231. jonasw

    but probably that’s not an issue because they don’t store data for that long

  232. jonasw

    only as long as needed to deliver

  233. winfried

    Ge0rG:SMS/MMS seperate telecom laws

  234. jonasw

    which is reasonable or something

  235. pep.

    jonasw, sure but then processing is done on the other side

  236. jonasw

    Ge0rG, email would be more interesting

  237. Ge0rG

    winfried: how are we different from them? ;)

  238. Ge0rG

    okay, I don't want to be required to do LE

  239. pep.

    I agree with Ge0rG it's pretty similar

  240. Ge0rG

    email is surely very similar, but I can't find any info on email GDPR short of email marketing

  241. pep.

    Can we try and ask big providers see how they deal with it

  242. jonasw

    could probably read googles new privacy policy?

  243. pep.

    Anybody knows one somewhat open to questions/collaboration?

  244. pep.


  245. winfried

    I feel we need to structure this part of the discussen better next time... but don't know how yet

  246. pep.

    Basically lots of thing here will rely on user consent

  247. pep.

    But to what extent can we use it we don't seem to agree

  248. pep.

    Or who needs to ask for it

  249. winfried

    but LQ2 may be: can (implicit) consent also apply to transfer to other controller by addres

  250. winfried

    (needs a bit better formulation)

  251. Ge0rG

    I think that we can apply 6.1f ("processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party") for federation

  252. pep.

    winfried, what do you mean with "by address"?

  253. Ge0rG

    the third party is the remote user, and their interest is to be able to communicate

  254. edhelas


  255. Ge0rG

    that should cover storage and delivery, but not profiling

  256. winfried

    when using @other.domain (xmpp & e-mail)

  257. jonasw

    Ge0rG, maybe chapter 5 applies?

  258. winfried

    Ge0rG: no, I think that article is meant for other cases

  259. jonasw

    in the end, the other service is a "third party"

  260. winfried

    Chapter 5 applies, and that is also ..... lets say, interesting

  261. pep.

    Where is chapter 5 again?

  262. pep.


  263. pep.

    got it

  264. winfried

    art 44-50

  265. jonasw

    pep., you might want to bookmark this: https://gdpr-info.eu

  266. pep.

    Yes I think that falls under this

  267. pep.

    jonasw, yeah I have it opened

  268. pep.

    So I propose we all study chapter 5 for next time? :P

  269. pep.

    And we can sum up here

  270. pep.

    5min to go

  271. winfried

    pep.: +1 ;-)

  272. jonasw

    from a quick glimpse, it’s not directly applicable to federation between two entities within GDPR jurisdiction

  273. jonasw

    but yeah

  274. winfried

    jonasw: yes, but federation is not limited to GDPR jurisdiction....

  275. jonasw

    so for next, I won’t be available until thursday next week (5th of April) aside from best-effort

  276. pep.

    Date of next?

  277. jonasw

    I suggest that we select a few dates from that thursday to the following monday and post them to the list

  278. jonasw

    maybe Peter can join at one of them

  279. jonasw

    does anyone know his timezone?

  280. winfried

    jonasw: +1

  281. Ge0rG

    https://www.gdpreu.org/the-regulation/key-concepts/legitimate-interest/ is interesting here, scroll down to "Recital 47"

  282. pep.

    jonasw, no idea about his tz

  283. pep.

    jonasw, let's say date of next: 5th April, 12:15CEST, and also ask on the ML

  284. jonasw

    I can’t make that specific time on that thursday

  285. jonasw

    at least I can’t guarantee that

  286. jonasw

    13:00CEST would probably work

  287. pep.

    works for me

  288. jonasw

    but if we assume that peter is more US based, later might be better

  289. jonasw

    but yeah

  290. jonasw

    probably best to post that as a suggestion to the list and ask for suggestions if anyone wants to join

  291. pep.

    I would say decide of a date now, that we can move if we all agree. In the meantime we have a date.

  292. winfried

    on the 5th I have a meeting from 12:15 to 13:15 with appr. 1,5 hour offline time before and after

  293. pep.

    is Apr. 6th ok then?

  294. jonasw

    I can probably make 13:15 on apr. 6th

  295. winfried

    jonasw: #meetoo

  296. pep.

    Ok for me

  297. jonasw


  298. jonasw

    Ge0rG, ^

  299. Ge0rG

    I have no other appointments on 5th/6th, so whatever works

  300. pep.

    Ok, Apr. 6th 13:15CEST

  301. pep.


  302. jonasw


  303. jonasw


  304. winfried

    thanks again guys!

  305. jonasw

    I wonder how this plays with the GDPR:

  306. jonasw


  307. pep.

    jonasw, "EDIT: Except for EU citizen :-°"

  308. jonasw


  309. pep.

    jonasw, what article was peter referring to again? I cna't seem to find it ("proportional means of protection")

  310. pep.

    Ah, he says article 9, and "revealing"

  311. pep.

    hmm, ok that's why LQ1 then.

  312. pep.

    That doesn't explain the part of our discussion about encryption

  313. Ge0rG

    pep.: encryption is one of the mechanisms mandated to protect user data

  314. pep.

    I guess that's art 35

  315. pep.

    https://mastodon.social/@Gargron/99730137003463631 they don't seem worried

  316. pep.

    Anybody what goes into that audit log? http://dougbelshaw.com/blog/2018/01/31/social-network/

  317. pep.

    (grep GDPR)

  318. moparisthebest

    I wonder how far a non-EU citizen/service is required to go to ensure non-EU people use their service?

  319. moparisthebest

    is the GDPR only enforceable if an EU citizen sues you?

  320. jonasw

    moparisthebest, I wish I knew at least that

  321. pep.

    anybody knows*

  322. moparisthebest

    if so, then everyone can just put up notices like "EU citizens are forbidden from using this service"

  323. moparisthebest

    because they wouldn't have standing to sue you about GDPR stuff in court, because they violated your terms?

  324. moparisthebest

    at least, I think

  325. jonasw

    I have no idea

  326. pep.

    I have a feeling I should prepend IANAL to any comment I make during our sessions

  327. jonasw

    pep., easy. /nick pep.> IANAL:

  328. pep.


  329. moparisthebest

    yea until we get a single lawyer in here ever, maybe a server plugin should do it automatically?

  330. pep.

    jonasw, will do next time

  331. jonasw


  332. jonasw

    the MUC won’t let you

  333. jonasw

    moparisthebest, yeah, no

  334. pep.


  335. jonasw

    that might be a solution for you USians

  336. jonasw

    for certain definitions of "solution"

  337. jonasw

    or, wait, you aren’t talking about the "no EU citizens" thing anymore?

  338. Ge0rG

    moparisthebest: I think it's about targeting. If you have a european domain, support languages spoken here, etc.

  339. moparisthebest

    I mean't a server plugin should prepend IANAL to what everyone says :)

  340. jonasw

    Ge0rG, "support languages spoken here". english?

  341. moparisthebest

    what languages *aren't* spoken in EU ?

  342. moparisthebest

    I feel like that'd be the shorter list

  343. Ge0rG


  344. pep.


  345. pep.

    You could state "Here we speak only en_US"

  346. moparisthebest

    or maybe you limit the character set to ASCII

  347. moparisthebest

    that would de-facto ban most of the EU

  348. Ge0rG

    moparisthebest: switch to IBM EBCDIC

  349. jonasw

    to ban the whole world?

  350. Ge0rG

    jonasw: there is no world beyond the US of A

  351. jonasw

    I forogt

  352. Ge0rG

    I, for one, am proud to be an EU citizen, and to finally have legal remediation against Silicon Valley sucking up and reselling all my private data.

  353. moparisthebest

    except turns out it's the same kind of legal protection you had before

  354. moparisthebest

    that is, to just not use the services

  355. Ge0rG

    moparisthebest: I'm not using Facebook. I'm not using WhatsApp. And still they have data about me.

  356. jonasw

    Ge0rG, +1

  357. moparisthebest

    not data you didn't share somehow, presumably

  358. jonasw

    moparisthebest, but did I share it intentionally?

  359. moparisthebest

    it's the #1 rule of the internet, put it on the internet, it's there forever

  360. jonasw

    moparisthebest, I didn’t put my phone number on the internet.

  361. jonasw

    yet, whatsapp has it most likely

  362. moparisthebest

    no laws are going to change that

  363. Ge0rG

    moparisthebest: oh yes, our laws will change that.

  364. moparisthebest

    yea the law changes things, now you can't use open federated services

  365. moparisthebest

    good work

  366. Ge0rG

    moparisthebest: but it depends on what you mean with "put it on the internet" - make it public? use some internet service? contact your friends?

  367. Ge0rG

    related: https://twitter.com/iamdylancurran/status/977559925680467968

  368. Ge0rG

    BTW, that the BigCorps are required to provide all the data they store about you is also based on EU regulations

  369. pep.

    Ok so I have https://cryptpad.fr/code/#/1/edit/eitMC7lM6yOU4kFtNf1Nag/gvYO8K5YdRtKg-b7hNLd7mEz/ Ge0rG jonasw winfried, can you have a quick look

  370. jonasw


  371. jonasw

    I hate that noscript b ug

  372. jonasw

    pfew, I was in luck. but still

  373. jonasw

    pep., looks good to me

  374. pep.

    Most of what we talked about today goes into Q1.1d

  375. pep.

    There's this "Server logs: r49" line that's kind of sitting alone there, the rest is about consent :P

  376. winfried

    pep.: nice!

  377. pep.

    jonasw, also I'd be inclined to say 9.1 only applies to "processing revealing [such information]", as peter suggests? But IANAL

  378. jonasw

    pep., peter argues that processing which stores the data in plaintext may reveal it to operators

  379. pep.

    Ah, in that sense

  380. jonasw

    also, I think the recital is clear that the *data* reveals the information, not the processing

  381. pep.

    Well, so full-disk encryption is besides the point right?

  382. jonasw

    the legal text is ambiguous IMO

  383. jonasw

    in both translations oddly enough

  384. jonasw

    (it could be either the processing or the data which reveals info, in both en and de)

  385. pep.

    Because operators will most likely always have access to this information, except in the e2ee case

  386. jonasw

    pep., exactly.

  387. pep.

    Even in the e2ee case really, it's still possible, as not many people actually checks

  388. pep.

    That would be making significant effort though, for the operator, and could be caught as well

  389. jonasw

    that would require an additional action you normally wouldn’t do though

  390. pep.

    Security goes as far as one is wiling to apply it (and even then..)

  391. pep.

    So I'm tempted to remove the full-disk encryption part in the minutes, and add a bit about e2ee

  392. pep.

    (Since it was my misunderstanding)

  393. Ge0rG

    pep.: "encryption" is just a control you "need" to checkmark.

  394. jonasw

    I think tehre was talk about both

  395. pep.

    Ge0rG, what encryption, where

  396. pep.

    jonasw, yeah, right

  397. Ge0rG

    pep.: a secure service will deploy a combination of disk encryption, stream encryption, user data encryption and e2ee

  398. jonasw

    pep., in line 64, it was definitely about FDE

  399. jonasw

    pep., maybe add a note about "ubiquitous E2EE would save us from 9.1"

  400. pep.

    I wish

  401. pep.

    Ge0rG, right

  402. pep.

    jonasw, here, done

  403. jonasw


  404. pep.

    Ok, sending that

  405. jonasw

    thank you for that already :)

  406. pep.

    Wow, the mails take quite some time to arrive

  407. Kev

    It takes a while for all the racial profiling the server needs to do before sending them out.

  408. pep.

    I see

  409. pep.

    Makes sense

  410. moparisthebest

    is there a reason the members mailing list is not linked from here: https://xmpp.org/community/mailing-lists.html

  411. jonasw

    moparisthebest, possibly because it’s only for members

  412. moparisthebest

    I was trying to give a link to the GDPR discussion to someone and had to manually construct it

  413. jonasw

    I don’t think you can subcsribe as non-member.

  414. moparisthebest

    jonasw, if that's true it's incorrectly configured to be public https://mail.jabber.org/pipermail/members/2018-March/thread.html

  415. pep.


  416. jonasw

    moparisthebest, maybe

  417. moparisthebest

    (I clicked on 'standards' then changed 'standards' in the url to 'members')

  418. jonasw

    iteam? (cc @ Kev, intosi) ^

  419. pep.

    it's listed here

  420. moparisthebest

    I personally don't see a reason for it to be private, I'd just like to see it listed next to the rest :)

  421. Kev

    What's the problem here? The list should be invite-only, public archives.

  422. jonasw

    Kev, then there’s no problem :)

  423. moparisthebest

    except it's not listed on https://xmpp.org/community/mailing-lists.html

  424. jonasw

    Kev, except htat maybe it should be moderated-by-default and free to subscribe, if the archives are public anyways.

  425. Kev

    I see no benefit to that.

  426. jonasw

    Kev, ease of use

  427. Kev

    It's easy to use for members, and that's all that matters here.

  428. Ge0rG

    I'm not even sure what the ML is *for*

  429. jonasw

    Kev, arguably, that discussion is interesting for non-members too.

  430. jonasw

    but I don’t think that standards@ would be the right venue

  431. jonasw

    what would be the most appropriate list then?

  432. Ge0rG

    operators probably

  433. pep.

    Yeah I don't think either. Maybe _only_ operators, would be best

  434. Kev

    I'd have thought if this is an XSF activity, members is appropriate, with CC to operators anything that will interest them.

  435. moparisthebest

    yea I was just linking other people for some feedback

  436. moparisthebest

    and it was super hard to find a link that I assumed would be on the mailing lists page that I assumed would list all mailing lists :)

  437. Neustradamus

    Kev, intosi: it will be nice to have a ML for jabber.org service and updates on https://www.jabber.org/notices.html about problems like previously

  438. Neustradamus

    http://mail.jabber.org/mailman/listinfo/juser <-- not clear if it is for jabber.org service

  439. SamWhited

    IETF folks that also idle here: are you aware of any SASL mechanisms similar to SCRAM (active or in development) that use Argon2 instead of PBKDF.2? I was going to use Argon2 on some passwords since it's the current OWASP recommendation, but there's a chance I'll want to use the same credentials with an XMPP server later (though not in a way that requires wide support, so it doesn't matter if it's still in draft or something).

  440. SamWhited

    I assume a quick search would have revealed it if it was already a thing, but I figured there might be an I-D which tend to be harder to find.

  441. Zash

    Not sure if I qualify, but I'm pretty sure you can swap out PBKDF2 for some other equivalent construct.

  442. SamWhited

    In SCRAM you mean? I think it allows you to swap out the hash used in the HMAC, but not the key derivation function. Let me double check, it would be nice if I was mistaken.

  443. Zash

    I do believe that the general construct still makes sense with a different key derivation function.

  444. SamWhited

    Oh yah, it does, but I'm hesitant to do something completely non-standard

  445. jonasw

    yeah, but it’s not standardised

  446. jonasw

    SamWhited, cp scram-rfc.xml argon-scram-rfc.xml; sed -i s/pbkdf2/argon2/g argon-scram-rfc.xml; submitrfc argon-scram-rfc.xml? ;-)

  447. SamWhited

    jonasw: what and where are those XML files located?

  448. SamWhited

    "What are those XML files and where are the located", that is. That sentence got away from me.

  449. SamWhited

    They… *facepalm* I really can't type.

  450. Zash

    Yeah, where are those?

  451. SamWhited

    I only recently discovered that there actually is a big XML file with RFC information… the IETF has even worse search engine rankings and visibility problems than we do, I'm pretty convinced.

  452. SamWhited

    But it's not detailed and doesn't include I-Ds, as far as I know.

  453. Zash


  454. SamWhited

    ooh that's a good idea, thanks. Although I don't think that lists any I-Ds that might be floating around out there; still, good starting place!

  455. moparisthebest

    hey, ALPN ids are listed now https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

  456. moparisthebest

    kind of a strange way to word the protocol, but I guess it's correct enough?

  457. moparisthebest

    XMPP jabber:client namespace

  458. moparisthebest

    XMPP jabber:server namespace

  459. Tobias

    wonder why some IDs are rather long and some others short

  460. Zash

    SamWhited: There's http://www.ietf.org/download/id-index.txt but it's huuuuuuuuuuuuuuge

  461. moparisthebest

    oh that's how it's listed in the XEP too, did I do that? hehe

  462. Zash

    And maybe the kitten wg?

  463. Tobias

    ah..it's the idrect textual representation

  464. Zash

    https://tools.ietf.org/wg/sasl/ https://tools.ietf.org/wg/kitten/

  465. pep.

    https://bpaste.net/show/138cf21c832d irccloud.com just updated their term apparently, some IRC web client. I feel this will be relevant to movim instance admins, edhelas

  466. Ge0rG

    That's interesting, they claim to be a data processor.

  467. pep.

    yeah I noticed as well

  468. lovetox

    Syndace, how is your omemo lib writing going

  469. Syndace

    lovetox, I spent the last days trying to get a simple client up and running that echoes OMEMO messages, with partial success. Debugging is extremely annoying as the OMEMO of the official clients is a mess. I once accidantly published some wrong data to the pep node and the OMEMO plugin for Gajim completely died and remained unusable till now. Trying to send messages just fills my terminal with stack traces. Conversations sends some weird empty message after the initial handshake. I thought I understood why it sends that message but then I found that Conversations 2.0 sends a different, even weirder message... The small success: If my handmade client does the active handshake, the echoing works with Conversations as expected, so the crypto should be fine :) I'm at the point where I'd probably need to dig into the code of conversations and gajim to understand the problem, but I really really really don't want to, got a lot of work atm. But thank you for asking, I just remembered that my goal is to provide the crypto and not to provide a working client. Tomorrow I'll clean up a last few things and release it, so you can try your luck with other clients :D

  470. Syndace

    Neustradamus: Hi! I'm fine, thanks :D

  471. lovetox

    im the developer of the omemo plugin

  472. lovetox

    in gajim

  473. lovetox

    so if you need help add me lovetox@conversations.im

  474. lovetox

    also if you release your work i can adapt it to gajim, and then you dont have to put work into the whole client and xmpp protocol stuff

  475. pep.

    Syndace, delegate! :)

  476. pep.

    less work for you

  477. lovetox

    yes, its really better you just release the work, and let client devs implement it

  478. lovetox

    afterwards you can use the client to debug encryption related stuff

  479. lovetox

    im offering to do this as soon as you release it

  480. Syndace

    One question about the licensing stuff: I already have MIT checked into the repo currently. Now, I have to release GPL as we discussed recently. If I just commit the new license, then someone can clone an earlier commit and get the earlier code including the MIT file. Is that a problem?

  481. Syndace

    Wow thank you!

  482. pep.

    hmm, I guess they can fork an ealier version of the work, though they would be liable? Maybe you can explain the reasons you're changing to GPL somewhere

  483. peter

    It's always dangerous to change licenses in midstream...

  484. pep.


  485. jonasw

    SamWhited, it was merely a convoluted way of saying "take the SCRAM rfc and do the same for argon2" sorry I got your hopes up (cc @ Zash)

  486. Syndace

    pep.: Thing is, I'm not just "changing" the license because I want to but the first license was never the correct one and I could get sued if I don't publish as GPL. git filter branch? Those dark areas of git that I try to avoid :D

  487. jonasw

    Syndace, git filter-branch or something equivalent is your only way.

  488. jonasw

    alternatively, you can squash the history

  489. jonasw

    why are you bound to GPL though?

  490. Zash

    Are you, really?

  491. Zash

    Probably should take what us non-lawyers say with a truckload of salt

  492. lovetox

    Syndace, clone your repo somewhere for backup

  493. lovetox

    squash everything into one inital commit before releasing

  494. lovetox

    upload finished

  495. pep.

    squash is meh :/

  496. Syndace

    Zash, I am bound to GPL. Until we define our own wireformat.

  497. jonasw

    Syndace, what

  498. jonasw

    source for that?

  499. Syndace

    jonasw, for what? That I'm bound to GPL?

  500. jonasw


  501. Syndace

    I guess I could create a fresh repo with just the newest commit and release that one

  502. jonasw

    that doesn’t make sense to me

  503. lovetox

    someone told him here

  504. lovetox

    because he looked into signal source for the wire format

  505. Syndace

    jonasw, to be abled to talk to libsignal I needed to copy a few params from theit code

  506. Syndace

    I don't think there is any way that is not GPL

  507. jonasw

    isn’t there a specification aside from that code?

  508. Syndace

    For large parts, yes

  509. jonasw

    anyways, heading out.

  510. Syndace

    But the specification says for example: "Set this parametet to an application specific ASCII string"

  511. Syndace

    Which I had to copy from libsignal because it is not defined anywhere

  512. Syndace

    But then again, it's no problem to switch to MIT once we define our own parameters

  513. pep.

    Not really sure what's frightening about GPL tbh

  514. Zash

    Probably a bit of FUD on account of Moxie & co being weird with reimplementation of signalprotocol

  515. pep.

    I meant, why not just stick to GPL

  516. Syndace

    pep.: GPL is fine for now but I personally don't like the philosophy to force open sourcers to use some license.

  517. pep.

    Depends on your end goal

  518. lovetox

    pep., because not every client can ship gpl code

  519. lovetox

    there is a huge discussion about this

  520. lovetox

    on the list

  521. pep.

    lovetox, that can be distributed via another channel? You already have plugins for gajim for example

  522. Zash

    pep.: I was on why GPL, not why not.

  523. pep.

    But tbh if it were me I'd just put the client under GPL

  524. lovetox

    poezio for example is not under GPL if i remember correctly

  525. mathieui

    zlib indeed

  526. lovetox

    also jitsi i think

  527. pep.

    yeah but we also have plugins. There is no case for now for external plugins though, since all are commited in the source

  528. lovetox

    smacks lib i think is also not

  529. pep.

    But it would be doable

  530. mathieui

    lovetox, it was gplv3 at the beginning though

  531. lovetox

    yeah of course, but if someone does the work and rewrites a whole lib from scratch

  532. lovetox

    why not work to the goal to make it with a good license

  533. lovetox

    that lets every option open

  534. Syndace

    lovetox: my thoughta

  535. pep.

    good is definitely subjective here. It also lets the option for companies to just reuse it and use your work without giving anything back

  536. pep.

    Or anybody really

  537. SamWhited

    That seems perfectly fine… I don't really care if people give back to my work, I just want it to be as usable as possible.

  538. pep.

    I do care

  539. Syndace

    I'll go with the beer license

  540. SamWhited

    I'd rather not force a choice on the majority of people who will give back and use my open source in a good way. If one or two people are bad actors that's unfortunate, but it's not worth hurting the large number of people who aren't already using the GPL just for the possibility that one person might do something bad.

  541. Syndace

    and make it copyleft

  542. pep.

    SamWhited, I guess I see it the other way around. What would it cost you to release under GPL, and also have the one next to you release under GPL, etc. The main reason I see not wanting to use GPL is if you explicitely want to allow not giving back

  543. SamWhited

    Why should I relicense my thing just because you want to use a different license? It seems arrogant of you to want me to change what I've already done just because you think something else is better.

  544. lovetox

    pep. you use it if you want that as many people as possible use it

  545. pep.

    lovetox, usage is not restricted in any case

  546. lovetox

    yes it is if it means i have to publish my source

  547. SamWhited

    But yes, I want my thing distributed as widely as possible, so I'm not going to put stupid restrictions on that. If someone abuses it, that's unfortunate, but most people won't.

  548. lovetox

    you say its not restricted under X conditions

  549. pep.

    lovetox, right sorry I was out

  550. lovetox

    some people cant just live with these conditions so will not use it

  551. pep.

    lovetox, I wouldn't go as far as that

  552. SamWhited

    And especially if it's a security thing then I definitely want it to be usable by proprietary closed source software. We're not going to get rid of it by using the GPL, but we can possibly make it more secure by not using the GPL.

  553. pep.

    SamWhited, I'm not sure where you want to go with the security thing.

  554. lovetox

    it simple if you have higher goals

  555. pep.

    If people want to use a library they can'T, then too bad for them?

  556. pep.

    either they comply or they don't use it

  557. lovetox

    if my goal is government not spying on people because i think it makes a better world

  558. SamWhited

    Exactly where I went; if someone is making a bunch of garbage IOT devices that are insecure, and I make a library that makes auth easy and they consider using it, I don't want them not to use it because I arrogantly claim that they have to release their source if they bundle my library.

  559. lovetox

    i couldnt care less if companys use my encryption and make money with it

  560. lovetox

    because my goal is still reached

  561. SamWhited

    What lovetox said; of course, that's a very specific niche goal, I'm just sick of people pretending that there's no downside or tradeoffs with the GPL.

  562. SamWhited

    There are plenty of reasons not to use it.

  563. lovetox

    also companys like google do this

  564. pep.

    Ok, well we definitely don't have the same goals, I guess I got that

  565. lovetox

    this is my opinion of course

  566. lovetox

    but often they release under licenses that allow not to give back

  567. lovetox

    because if you use there stuff it gets spreaded

  568. lovetox

    and when everyone uses it you depend on google stuff suddenly

  569. lovetox

    they profit in other ways from it

  570. pep.

    Note, I didn't say a word about me making profit

  571. moparisthebest

    I think I'm the one that said that, and IANAL

  572. moparisthebest

    but I believe that if you copy even any tiny part from a GPL library, or possibly even look at it before implementing a replacement, it's a derivitive work that must be licenensed GPL, does that sound right?

  573. moparisthebest

    besides if API's are copyrightable I'm not sure anything matters anymore https://www.bloomberg.com/news/articles/2018-03-27/oracle-wins-revival-of-billion-dollar-case-against-google ...

  574. flow

    moparisthebest, that is my interpretation too