XSF Discussion - 2018-04-30


  1. pep.

    crap, gdpr meeting today

  2. pep. doing minutes

  3. pep.

    dropping this here for later, did we forget about pubsub re right to erasure. Deletion is already in the protocol (right?), but we did mention PEP

  4. pep.

    jonasw, no progress on the xep template? (for the minutes)

  5. jonasw

    gdpr in 7, winfried, pep., Ge0rg

  6. Ge0rG

    👍

  7. jonasw

    pep.: I have something uncommitted locally, still need to figure out who has to approve such a change

  8. pep.

    Ok

  9. pep.

    !

  10. Ge0rG

    ¡

  11. winfried

    !

  12. pep.

    Right, this time I'm starting minutes right now.

  13. winfried bangs a gavel ;-)

  14. jonasw

    .

  15. winfried

    I didn't had time to process minutes of meeting 9 yet, but I did do 8

  16. pep.

    That's my fault

  17. winfried

    Not here to blame

  18. jonasw

    where are we at?

  19. pep.

    Right to erasure, a few technical TODOs

  20. pep.

    And then maybe Q2

  21. pep.

    As I asked above, did we forgot to mention pubsub?

  22. pep.

    Re right to erasure

  23. Ge0rG

    pep.: what kind of pubsub?

  24. pep.

    not PEP

  25. pep.

    Any

  26. winfried

    Pubsub is not in our list of processing personal data

  27. winfried

    it does (potentially) generate interesting metadata

  28. Ge0rG

    winfried: it's also "user data", probably

  29. edhelas

    dependes if they are public pubsub nodes or private ones no ?

  30. pep.

    -xep 223

  31. pep.

    bunneh!

  32. jonasw

    pep., in any case, pubsub *does* allow deletion

  33. jonasw

    via protocol

  34. pep.

    jonasw, yes, but just as we mentioned PEP I thought we could mention it as well

  35. jonasw

    either by retracting individual items or by deleting or truncating the whole node

  36. Ge0rG

    edhelas: yes, private ones are interesting in GDPR context

  37. Ge0rG

    because public data is public

  38. edhelas

    what about exporting ?

  39. Ge0rG

    exporting what to where?

  40. jonasw

    Ge0rG, probably the right to get a zipfile with all your data?

  41. winfried

    plz one question at the time, edhelas ;-)

  42. pep.

    yeah, we should also answer this question, at some point

  43. pep.

    For any kind of data

  44. pep.

    (edhelas do you have a hl on pubsub btw?)

  45. winfried

    jonasw: is there any place except the logfiles where the stored data can't be obtained in a machine readable format?

  46. jonasw

    winfried, probably not

  47. pep.

    Technically everything is done via XMPP right?

  48. edhelas

    pep. no I don't, just having the room open

  49. jonasw

    winfried, except maybe archives where you don’t have access anymore for some reason.

  50. pep.

    We could "export" stuff via xmpp

  51. jonasw

    like MUC-MAM

  52. pep.

    "just" need a client that supports every single XEP :-°

  53. pep.

    gajim?

  54. Ge0rG

    jonasw: even when you do have access, you can't delete from MUC-MAM

  55. jonasw

    Ge0rG, we’re on export now, not on deletion.

  56. Ge0rG

    Aren't they sufficiently related to better treat both at once?

  57. winfried

    I see two issues raised here: 1 pubsub allows a private form, that is not just 6.1b (implied consent, as used almost everywhere) but also explicit consent, 6.1a as in MAM

  58. winfried

    2 deletion is not everywhere part of the protocol and needs to be added

  59. pep.

    winfried, for 2., we have TODOs

  60. winfried

    ( jonasw that is a question for the template too)

  61. pep.

    Maybe not *everything* yet

  62. winfried

    pep.: correct, 2 is already in the todo

  63. pep.

    Though I think we've covered that pretty much last time

  64. winfried

    I guess PubSub can be handled as a combination of MAM and everything else

  65. winfried

    BTW: see table https://wiki.xmpp.org/web/GDPR/Table I don't talk about issues to solve anymore but resolutions

  66. pep.

    What do we do about export then. There's no need for anything particular in the protocol as it's already there.

  67. jonasw

    winfried, do we need to add deletion to the protocol for sure? AFAIK it would be sufficient to have a way for operators to conveniently delete data.

  68. pep.

    We might want to provide a tool (client) that does that, dump everything?

  69. jonasw

    pep., that’d be a technical todo. makes a lot of sense.

  70. pep.

    jonasw, as a first step maybe. On "big" deployments, handling that might be demanding?

  71. jonasw

    problem is, how to find all your data scattered across the different services?

  72. pep.

    (re deletion)

  73. jonasw

    think MUCs on different domains

  74. pep.

    do we have to handle that?

  75. jonasw

    dunno

  76. Ge0rG

    interesting point.

  77. Ge0rG

    the same for pubsub

  78. pep.

    Unlike most email setup, we don't keep track of what you've sent

  79. winfried

    The idea of downloading is not to get a PDF like facebook sends, but to be able to migrate

  80. jonasw

    my understanding would be that each domain is its own operator and you’d have to ask them for your data...

  81. jonasw

    winfried, in that case, we’d also need ways to feed things back into the (presumably new) service.

  82. pep.

    jonasw, that's also what I would I thought. Now I don't know

  83. winfried

    I guess migration is makes most sense to do live from the network, not from a stored file

  84. jonasw

    which is currently not possible e.g. with MAM

  85. pep.

    The user is not especially aware of that

  86. jonasw

    winfried, agreed

  87. winfried

    jonasw: feeding back is funny enough not part of the GDPR

  88. Ge0rG

    the market will solve that *cough*

  89. jonasw

    pep., agreed, but your own operator can’t do anything about it -- unless they log every domain you ever interacted with. that seems like an undue burden and also an unfortunate accumulation of data.

  90. pep.

    for migration, can we not revive {xep moved}?

  91. pep.

    Zash, plz bring back bunneh

  92. jonasw

    pep., https://xmpp.org/extensions/xep-0283.html

  93. Ge0rG

    pep.: xep-0227

  94. jonasw

    oh neat

  95. pep.

    oh

  96. pep.

    interesting

  97. jonasw

    Ge0rG, wat

  98. pep.

    so a combination of both?

  99. jonasw

    Ge0rG, that is for servers

  100. Ge0rG

    pep.: moved is for when you change your JID. 227 is for when you move your domain to another hoster

  101. Ge0rG

    With the huge number of commercial XMPP domain hosters, this is a real problem.

  102. pep.

    Ge0rG, when you move your domain to another hoster you also change JIDs

  103. jonasw

    Ge0rG, buuut that is off-topic for user GDPR things

  104. jonasw

    pep., no

  105. jonasw

    when you move your *domain* to another hoster, the domain stays the same.

  106. pep.

    ah, err

  107. pep.

    227 also allow moving from one domain to another right? It doesn't care

  108. pep.

    It's just moving data between two XMPP servers

  109. jonasw

    pep., no, it preserves domains

  110. jonasw

    it does care, and it is off-topic to the end-user GDPR discussion.

  111. winfried is tired and in overflow mode. what are the demands of the GDPR here? AFAIK only being able to download in a machine readable format

  112. jonasw

    (unless I’m mistaken)

  113. pep.

    Ok less interesting than I thought then

  114. Ge0rG

    jonasw: I'd say that 227 qualifies as an "export format"

  115. jonasw

    Ge0rG, parts of it *maybe*

  116. Ge0rG

    jonasw: it's the best we have on that front

  117. jonasw

    (also, it needs to be updated. it expects plaintext passwords)

  118. Ge0rG

    jonasw: you can get parts of your export in-band (MAM, PubSub - if you know the nodes); and you can use 227 for the whole of your account

  119. winfried

    Why don't we take the most minimalist approach: XMPP is a machine downloadable format (better documented then every thing else you will see), just use XMPP

  120. Ge0rG

    in theory

  121. Ge0rG

    winfried: what do you want to export that way?

  122. winfried

    My server stores my roster, MAM

  123. winfried

    I can be owner of pubsub nodes, I can always download those

  124. Ge0rG

    winfried: so you argue that you can get your roster and MAM data as an "export" just by querying them in-band?

  125. winfried

    Ge0rG: Correct

  126. Ge0rG

    winfried: that's great.

  127. pep.

    Ge0rG, that's also what I thought when I mentioned an "export tool" (a client)

  128. Ge0rG

    I'd say we need to list all the data types and their respective means of export.

  129. winfried

    I don't see why we should do more here

  130. pep.

    What's the exact requirement here

  131. pep.

    Do we have to provide a format that can be used by other servers

  132. winfried

    Ge0rG: yes, if we need to do anything more here, then it would be such a list

  133. Ge0rG

    winfried: if we want to export the data in a way that allows uploading it into another hoster, we are left with 227.

  134. pep.

    That's article 20 right?

  135. jonasw

    (227 is maybe a good start, but not a silver bullet to this; it isn’t suited to transfer between different JIDs, due to deep references to the original JID)

  136. winfried

    pep.: looking in my bible for the exact requirement

  137. pep.

    "in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller"

  138. winfried

    pep.: yes, art 20

  139. pep.

    20.2, "shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible."

  140. winfried

    Look also at this: https://gdpr-info.eu/recitals/no-68/

  141. pep.

    yes

  142. winfried

    20.1a is also interesting, that would mean only mam and pubsub needs to be transferable

  143. pep.

    transferable how

  144. pep.

    They already are, to the client

  145. winfried

    pep.: yes, 20.2 would be needed too

  146. pep.

    20.2 is s2s transfers yes

  147. jonasw

    winfried, roster, too

  148. jonasw

    regarding 20.2, I think as long as we don’t have a XEP for that, it’s not technically feasible

  149. winfried

    jonasw: do we store roster under 6.1a or 6.1b?

  150. pep.

    jonasw, we could start from 227

  151. winfried

    jonasw: btw, transfering your roster would be a great thing to offer

  152. pep.

    Transferring anything really

  153. pep.

    Being able to move servers with the click of a button would be great

  154. winfried

    So make an up to date version of 227 that allows transfer of one user?

  155. pep.

    That's more or less what's asked, no? "where technically feasible"

  156. winfried

    What kind of auth mechanism would that take?

  157. jonasw

    I’d probably rather build on top of XEP-0238 (Moved)

  158. Ge0rG

    yeah, if we remove the "manual approval needed" from 0238, it'd be great.

  159. pep.

    jonasw, I think we need both

  160. pep.

    Ge0rG, yes!

  161. Ge0rG

    I planned to dump that into standards@ for a year now

  162. pep.

    go go

  163. jonasw

    I don’t want to get into technical details here.

  164. pep.

    So, technical TODO?

  165. jonasw

    yes

  166. pep.

    Look into 227/283

  167. jonasw

    ok, what’s next?

  168. pep.

    I think that's about the end of 1.1e?

  169. winfried

    do we have to check the technical ToDo on deletion?

  170. pep.

    check how?

  171. winfried

    pep.: good question... ;-)

  172. jonasw

    what do you mean exactly?

  173. winfried

    From the minutes (9): Data that will need to be deleted on Right to Erasure (17.1) request: - MAM contents - Offline messages (if separate from MAM) - Roster - XML Private Storage - PEP - other custom processing?

  174. winfried

    Should we add anything to that list

  175. pep.

    223?

  176. jonasw

    winfried, HTTP Upload?

  177. pep.

    private pubsub

  178. pep.

    and http-upload yes

  179. pep.

    Plus I mentioned that in the TODOs below..

  180. winfried

    PubSud does delete, so private should too, right?

  181. pep.

    jonasw, server-side stored files then. because it's possibly not just http-upload

  182. pep.

    winfried, yes yes

  183. winfried

    But maybe we should expand that list to XEPs and RFC's that need deletion...

  184. pep.

    I just think that should be mentioned as well

  185. winfried

    pep.: agree

  186. pep.

    This list is not just for those where it's not implemented

  187. winfried

    Maybe we / somebody should make a list where deletion may be applicable and check where it is implemented and where not...

  188. jonasw

    I gotta run in 5

  189. jonasw

    date of next?

  190. winfried

    +1 +2 or +4

  191. jonasw

    days, I presume

  192. jonasw

    not sure if I can make +1 due to the holiday

  193. jonasw

    +2 is not an option since it’s wednesday

  194. jonasw

    +4 could work

  195. pep.

    can do

  196. pep.

    ah wait

  197. jonasw

    Ge0rG, ^

  198. pep.

    I might be late

  199. pep.

    On friday

  200. jonasw

    +30min would be fine for me, too

  201. jonasw

    (that is, Fri 13:00 CEST

  202. pep.

    k

  203. jonasw

    (that is, Fri 13:00 CEST)

  204. pep.

    That would work

  205. jonasw

    winfried, Ge0rG?

  206. Ge0rG

    probably a no from me for Thu

  207. pep.

    friday

  208. Ge0rG

    I have a probably-cancelled appointment on Fri.

  209. winfried

    Friday 13:00 CEST WFM

  210. Ge0rG

    Will have to phone-check with them

  211. pep.

    Also heads up, 26? days until dday

  212. Ge0rG

    okay, can do on Fri

  213. pep.

    okay

  214. jonasw

    ack

  215. jonasw

    gotta run

  216. winfried

    Friday 13:00 CEST

  217. winfried

    jonasw: thanks!

  218. winfried bangs the gavel

  219. pep.

    Ok, minutes incoming

  220. winfried

    pep.: great!

  221. winfried

    Have some work to do, again...

  222. pep.

    https://cryptpad.fr/code/#/1/edit/zSeJf1fqWnhVVk6LEjM0Xg/9CRtkSfVga8dtSuc8oDxjtv4/ anything I missed?

  223. pep.

    pff that markdown editor

  224. winfried

    mention recital 68

  225. pep.

    It doesn't want to split my quotes

  226. pep.

    ok

  227. winfried

    Note: we are overshooting the GDPR requirements here, strictly only MAM and PubSun need to be transferable

  228. pep.

    goffi, your jingle-ft component, is it only to put in relation two clients atm? Does it store anything on the server? I haven't had a look yet

  229. pep.

    winfried, isn't it any PII?

  230. pep.

    "shall have the right to receive the personal data"

  231. winfried

    pep.: No, only PII that is processed under 6.1a (see art 20.1a)

  232. pep.

    oh

  233. pep.

    ah right, as specified in 20.1a

  234. goffi

    pep.: the component is for server side things, so it keep stuff and this can be shared with as much people as you want (based on a whitelist). In addition, there is also a P2P sharing which is not using the component.

  235. pep.

    Ok so there is server-side file storage involved

  236. goffi

    yes, and I plan to add file deletion before release.

  237. pep.

    Does your implementation keep track of who uploaded what

  238. pep.

    cool

  239. goffi

    yes it does

  240. pep.

    Is that specified in the XEP(s) you used?

  241. pep.

    Do the XEPs even talk about server-side jingle

  242. winfried

    pep.: I think we should report / be open that we are overshooting on transfer

  243. pep.

    winfried, agreed, I'll add it

  244. goffi

    the XEP is for sharing file listing. Deletion is not specified, I'm planing to use ad-hoc commands for that.

  245. winfried

    goffi: better should be a protocol for that (not overseeing its feasibility)

  246. goffi

    pep.: the XEP was done for P2P sharing between device, which is my second use case. I'm just using it in a component to have server file storage.

  247. pep.

    winfried, might be good to add a TODO for this as well

  248. winfried

    pep.: +1

  249. pep.

    goffi, sure. We're just looking at what needs to be done in the context of GDPR

  250. pep.

    For servers

  251. goffi

    winfried: I'm experimenting, and will propose protoXEP for each thing not implemented as soon as possible

  252. winfried

    goffi: great!

  253. pep.

    goffi, can I add that in the minutes? Saying you're looking into it?

  254. pep.

    I should also reference your previous thread on standards

  255. goffi

    pep.: sure. I'm willing to write a blog post about that for weeks, but lacking time

  256. pep.

    cool :)

  257. goffi

    anyway I'll release an alpha version soon

  258. pep.

    winfried, sending

  259. winfried

    pep.: thanks!

  260. Maranda

    Apr 30 22:07:08 s2sin5f23e00 debug Received[s2sin_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls> Apr 30 22:07:08 mod_s2s debug sending: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>

  261. Maranda

    huhuhuhu