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
Dave Cridlandhas left
Steve Killehas left
Guushas left
Guushas left
Guushas left
pep.jonasw, no progress on the xep template? (for the minutes)
dwdhas left
Steve Killehas joined
Guushas left
goffihas left
lumihas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Dave Cridlandhas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
Guushas left
jonaswhas joined
jonaswgdpr in 7, winfried, pep., Ge0rg
Ge0rG👍
j.rhas left
jonaswpep.: I have something uncommitted locally, still need to figure out who has to approve such a change
rtq3has left
rtq3has joined
j.rhas joined
pep.Ok
Guushas left
pep.!
Ge0rG¡
jubalhhas joined
winfried!
rionhas left
rionhas joined
pep.Right, this time I'm starting minutes right now.
jerehas joined
winfriedbangs a gavel ;-)
jonasw.
muchopperhas joined
winfriedI didn't had time to process minutes of meeting 9 yet, but I did do 8
pep.That's my fault
jonaswhas left
winfriedNot here to blame
jonaswwhere are we at?
pep.Right to erasure, a few technical TODOs
pep.And then maybe Q2
pep.As I asked above, did we forgot to mention pubsub?
pep.Re right to erasure
Ge0rGpep.: what kind of pubsub?
pep.not PEP
pep.Any
winfriedPubsub is not in our list of processing personal data
winfriedit does (potentially) generate interesting metadata
Ge0rGwinfried: it's also "user data", probably
edhelasdependes if they are public pubsub nodes or private ones no ?
pep.-xep 223
pep.bunneh!
jonaswpep., in any case, pubsub *does* allow deletion
jonaswvia protocol
pep.jonasw, yes, but just as we mentioned PEP I thought we could mention it as well
jonasweither by retracting individual items or by deleting or truncating the whole node
nycohas left
Ge0rGedhelas: yes, private ones are interesting in GDPR context
Ge0rGbecause public data is public
edhelaswhat about exporting ?
Ge0rGexporting what to where?
jonaswGe0rG, probably the right to get a zipfile with all your data?
winfriedplz one question at the time, edhelas ;-)
pep.yeah, we should also answer this question, at some point
pep.For any kind of data
pep.(edhelas do you have a hl on pubsub btw?)
winfriedjonasw: is there any place except the logfiles where the stored data can't be obtained in a machine readable format?
jonaswwinfried, probably not
pep.Technically everything is done via XMPP right?
edhelaspep. no I don't, just having the room open
jonaswwinfried, except maybe archives where you don’t have access anymore for some reason.
pep.We could "export" stuff via xmpp
jonaswlike MUC-MAM
pep."just" need a client that supports every single XEP :-°
pep.gajim?
Ge0rGjonasw: even when you do have access, you can't delete from MUC-MAM
jubalhhas joined
jjrhhas left
jonaswGe0rG, we’re on export now, not on deletion.
Ge0rGAren't they sufficiently related to better treat both at once?
winfriedI 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
Guushas left
winfried2 deletion is not everywhere part of the protocol and needs to be added
pep.winfried, for 2., we have TODOs
winfried( jonasw that is a question for the template too)
pep.Maybe not *everything* yet
winfriedpep.: correct, 2 is already in the todo
pep.Though I think we've covered that pretty much last time
winfriedI guess PubSub can be handled as a combination of MAM and everything else
winfriedBTW: see table https://wiki.xmpp.org/web/GDPR/Table I don't talk about issues to solve anymore but resolutions
danielhas left
andyhas left
jerehas left
jerehas joined
pep.What do we do about export then. There's no need for anything particular in the protocol as it's already there.
jonaswwinfried, 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.
pep.We might want to provide a tool (client) that does that, dump everything?
jonaswpep., that’d be a technical todo. makes a lot of sense.
pep.jonasw, as a first step maybe. On "big" deployments, handling that might be demanding?
jonaswproblem is, how to find all your data scattered across the different services?
pep.(re deletion)
jonaswthink MUCs on different domains
pep.do we have to handle that?
jonaswdunno
Ge0rGinteresting point.
Ge0rGthe same for pubsub
pep.Unlike most email setup, we don't keep track of what you've sent
winfriedThe idea of downloading is not to get a PDF like facebook sends, but to be able to migrate
jonaswmy understanding would be that each domain is its own operator and you’d have to ask them for your data...
jonaswwinfried, in that case, we’d also need ways to feed things back into the (presumably new) service.
pep.jonasw, that's also what I would I thought. Now I don't know
winfriedI guess migration is makes most sense to do live from the network, not from a stored file
jonaswwhich is currently not possible e.g. with MAM
pep.The user is not especially aware of that
jonaswwinfried, agreed
winfriedjonasw: feeding back is funny enough not part of the GDPR
Ge0rGthe market will solve that *cough*
jonaswpep., 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.
Ge0rGpep.: moved is for when you change your JID. 227 is for when you move your domain to another hoster
Ge0rGWith the huge number of commercial XMPP domain hosters, this is a real problem.
pep.Ge0rG, when you move your domain to another hoster you also change JIDs
jonaswGe0rG, buuut that is off-topic for user GDPR things
jonaswpep., no
ibikkhas joined
Tobiashas joined
jonaswwhen you move your *domain* to another hoster, the domain stays the same.
pep.ah, err
Tobiashas joined
Dave Cridlandhas left
pep.227 also allow moving from one domain to another right? It doesn't care
pep.It's just moving data between two XMPP servers
jonaswpep., no, it preserves domains
jonaswit does care, and it is off-topic to the end-user GDPR discussion.
winfriedis tired and in overflow mode. what are the demands of the GDPR here? AFAIK only being able to download in a machine readable format
jonasw(unless I’m mistaken)
pep.Ok less interesting than I thought then
Ge0rGjonasw: I'd say that 227 qualifies as an "export format"
jonaswGe0rG, parts of it *maybe*
Ge0rGjonasw: it's the best we have on that front
jonasw(also, it needs to be updated. it expects plaintext passwords)
rionhas left
dwdhas left
Ge0rGjonasw: 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
winfriedWhy 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
Ge0rGin theory
Ge0rGwinfried: what do you want to export that way?
winfriedMy server stores my roster, MAM
winfriedI can be owner of pubsub nodes, I can always download those
Ge0rGwinfried: so you argue that you can get your roster and MAM data as an "export" just by querying them in-band?
winfriedGe0rG: Correct
Ge0rGwinfried: that's great.
pep.Ge0rG, that's also what I thought when I mentioned an "export tool" (a client)
Ge0rGI'd say we need to list all the data types and their respective means of export.
winfriedI don't see why we should do more here
pep.What's the exact requirement here
pep.Do we have to provide a format that can be used by other servers
winfriedGe0rG: yes, if we need to do anything more here, then it would be such a list
Ge0rGwinfried: if we want to export the data in a way that allows uploading it into another hoster, we are left with 227.
pep.That's article 20 right?
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)
winfriedpep.: looking in my bible for the exact requirement
pep."in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller"
winfriedpep.: yes, art 20
pep.20.2, "shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible."
winfriedLook also at this: https://gdpr-info.eu/recitals/no-68/
pep.yes
winfried20.1a is also interesting, that would mean only mam and pubsub needs to be transferable
pep.transferable how
pep.They already are, to the client
winfriedpep.: yes, 20.2 would be needed too
pep.20.2 is s2s transfers yes
nonfreepizzahas left
Guushas left
jonaswwinfried, roster, too
jonaswregarding 20.2, I think as long as we don’t have a XEP for that, it’s not technically feasible
winfriedjonasw: do we store roster under 6.1a or 6.1b?
pep.jonasw, we could start from 227
winfriedjonasw: btw, transfering your roster would be a great thing to offer
pep.Transferring anything really
pep.Being able to move servers with the click of a button would be great
goffihas left
Dave Cridlandhas left
winfriedSo make an up to date version of 227 that allows transfer of one user?
pep.That's more or less what's asked, no? "where technically feasible"
winfriedWhat kind of auth mechanism would that take?
jonaswI’d probably rather build on top of XEP-0238 (Moved)
ThibGhas joined
Ge0rGyeah, if we remove the "manual approval needed" from 0238, it'd be great.
pep.jonasw, I think we need both
pep.Ge0rG, yes!
Ge0rGI planned to dump that into standards@ for a year now
pep.go go
jonaswI don’t want to get into technical details here.
pep.So, technical TODO?
jonaswyes
pep.Look into 227/283
vanitasvitaehas left
jonaswok, what’s next?
pep.I think that's about the end of 1.1e?
vanitasvitaehas left
winfrieddo we have to check the technical ToDo on deletion?
pep.check how?
Guushas left
winfriedpep.: good question... ;-)
jonaswwhat do you mean exactly?
winfriedFrom 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?
winfriedShould we add anything to that list
pep.223?
jonaswwinfried, HTTP Upload?
pep.private pubsub
pep.and http-upload yes
Steve Killehas left
Steve Killehas left
pep.Plus I mentioned that in the TODOs below..
winfriedPubSud does delete, so private should too, right?
dwdhas left
pep.jonasw, server-side stored files then. because it's possibly not just http-upload
pep.winfried, yes yes
winfriedBut maybe we should expand that list to XEPs and RFC's that need deletion...
Steve Killehas joined
pep.I just think that should be mentioned as well
winfriedpep.: agree
pep.This list is not just for those where it's not implemented
winfriedMaybe we / somebody should make a list where deletion may be applicable and check where it is implemented and where not...
jonaswI gotta run in 5
jonaswdate of next?
rtq3has left
rtq3has joined
winfried+1 +2 or +4
jonaswdays, I presume
Dave Cridlandhas left
jonaswnot sure if I can make +1 due to the holiday
jonasw+2 is not an option since it’s wednesday
jonasw+4 could work
pep.can do
pep.ah wait
jonaswGe0rG, ^
pep.I might be late
pep.On friday
jonasw+30min would be fine for me, too
jonasw(that is, Fri 13:00 CEST
pep.k
jonasw(that is, Fri 13:00 CEST)
pep.That would work
jonaswwinfried, Ge0rG?
Ge0rGprobably a no from me for Thu
pep.friday
Ge0rGI have a probably-cancelled appointment on Fri.
winfriedFriday 13:00 CEST WFM
Ge0rGWill have to phone-check with them
Guushas left
pep.Also heads up, 26? days until dday
Ge0rGokay, can do on Fri
pep.okay
jonaswack
jonaswgotta run
winfriedFriday 13:00 CEST
winfriedjonasw: thanks!
winfriedbangs the gavel
pep.Ok, minutes incoming
winfriedpep.: great!
winfriedHave some work to do, again...
pep.https://cryptpad.fr/code/#/1/edit/zSeJf1fqWnhVVk6LEjM0Xg/9CRtkSfVga8dtSuc8oDxjtv4/ anything I missed?
Guushas left
pep.pff that markdown editor
winfriedmention recital 68
pep.It doesn't want to split my quotes
pep.ok
goffihas joined
winfriedNote: we are overshooting the GDPR requirements here, strictly only MAM and PubSun need to be transferable
Guushas left
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
pep.winfried, isn't it any PII?
pep."shall have the right to receive the personal data"
winfriedpep.: No, only PII that is processed under 6.1a (see art 20.1a)
pep.oh
pep.ah right, as specified in 20.1a
Guushas left
goffipep.: 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.
pep.Ok so there is server-side file storage involved
goffiyes, and I plan to add file deletion before release.
pep.Does your implementation keep track of who uploaded what
pep.cool
goffiyes it does
Guushas left
pep.Is that specified in the XEP(s) you used?
pep.Do the XEPs even talk about server-side jingle
winfriedpep.: I think we should report / be open that we are overshooting on transfer
pep.winfried, agreed, I'll add it
goffithe XEP is for sharing file listing. Deletion is not specified, I'm planing to use ad-hoc commands for that.
jerehas joined
winfriedgoffi: better should be a protocol for that (not overseeing its feasibility)
goffipep.: 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.
pep.winfried, might be good to add a TODO for this as well
winfriedpep.: +1
pep.goffi, sure. We're just looking at what needs to be done in the context of GDPR
pep.For servers
goffiwinfried: I'm experimenting, and will propose protoXEP for each thing not implemented as soon as possible
winfriedgoffi: great!
pep.goffi, can I add that in the minutes? Saying you're looking into it?
pep.I should also reference your previous thread on standards
Dave Cridlandhas left
goffipep.: sure. I'm willing to write a blog post about that for weeks, but lacking time