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
jonasw
gdpr in 7, winfried, pep., Ge0rg
Ge0rG
👍
j.rhas left
jonasw
pep.: 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
winfried
I didn't had time to process minutes of meeting 9 yet, but I did do 8
pep.
That's my fault
jonaswhas left
winfried
Not here to blame
jonasw
where 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
Ge0rG
pep.: what kind of pubsub?
pep.
not PEP
pep.
Any
winfried
Pubsub is not in our list of processing personal data
winfried
it does (potentially) generate interesting metadata
Ge0rG
winfried: it's also "user data", probably
edhelas
dependes if they are public pubsub nodes or private ones no ?
pep.
-xep 223
pep.
bunneh!
jonasw
pep., in any case, pubsub *does* allow deletion
jonasw
via protocol
pep.
jonasw, yes, but just as we mentioned PEP I thought we could mention it as well
jonasw
either by retracting individual items or by deleting or truncating the whole node
nycohas left
Ge0rG
edhelas: yes, private ones are interesting in GDPR context
Ge0rG
because public data is public
edhelas
what about exporting ?
Ge0rG
exporting what to where?
jonasw
Ge0rG, probably the right to get a zipfile with all your data?
winfried
plz 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?)
winfried
jonasw: is there any place except the logfiles where the stored data can't be obtained in a machine readable format?
jonasw
winfried, probably not
pep.
Technically everything is done via XMPP right?
edhelas
pep. no I don't, just having the room open
jonasw
winfried, except maybe archives where you don’t have access anymore for some reason.
pep.
We could "export" stuff via xmpp
jonasw
like MUC-MAM
pep.
"just" need a client that supports every single XEP :-°
pep.
gajim?
Ge0rG
jonasw: even when you do have access, you can't delete from MUC-MAM
jubalhhas joined
jjrhhas left
jonasw
Ge0rG, we’re on export now, not on deletion.
Ge0rG
Aren't they sufficiently related to better treat both at once?
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
Guushas left
winfried
2 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
winfried
pep.: correct, 2 is already in the todo
pep.
Though I think we've covered that pretty much last time
winfried
I guess PubSub can be handled as a combination of MAM and everything else
winfried
BTW: 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.
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.
pep.
We might want to provide a tool (client) that does that, dump everything?
jonasw
pep., 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?
jonasw
problem is, how to find all your data scattered across the different services?
pep.
(re deletion)
jonasw
think MUCs on different domains
pep.
do we have to handle that?
jonasw
dunno
Ge0rG
interesting point.
Ge0rG
the same for pubsub
pep.
Unlike most email setup, we don't keep track of what you've sent
winfried
The idea of downloading is not to get a PDF like facebook sends, but to be able to migrate
jonasw
my understanding would be that each domain is its own operator and you’d have to ask them for your data...
jonasw
winfried, 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
winfried
I guess migration is makes most sense to do live from the network, not from a stored file
jonasw
which is currently not possible e.g. with MAM
pep.
The user is not especially aware of that
jonasw
winfried, agreed
winfried
jonasw: feeding back is funny enough not part of the GDPR
Ge0rG
the market will solve that *cough*
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.
pep.
for migration, can we not revive {xep moved}?
pep.
Zash, plz bring back bunneh
jonasw
pep., https://xmpp.org/extensions/xep-0283.html
Ge0rG
pep.: xep-0227
jonasw
oh neat
pep.
oh
pep.
interesting
jonasw
Ge0rG, wat
pep.
so a combination of both?
jonasw
Ge0rG, that is for servers
danielhas joined
Ge0rG
pep.: moved is for when you change your JID. 227 is for when you move your domain to another hoster
Ge0rG
With 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
jonasw
Ge0rG, buuut that is off-topic for user GDPR things
jonasw
pep., no
ibikkhas joined
Tobiashas joined
jonasw
when 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
jonasw
pep., no, it preserves domains
jonasw
it 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
Ge0rG
jonasw: I'd say that 227 qualifies as an "export format"
jonasw
Ge0rG, parts of it *maybe*
Ge0rG
jonasw: it's the best we have on that front
jonasw
(also, it needs to be updated. it expects plaintext passwords)
rionhas left
dwdhas left
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
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
Ge0rG
in theory
Ge0rG
winfried: what do you want to export that way?
winfried
My server stores my roster, MAM
winfried
I can be owner of pubsub nodes, I can always download those
Ge0rG
winfried: so you argue that you can get your roster and MAM data as an "export" just by querying them in-band?
winfried
Ge0rG: Correct
Ge0rG
winfried: that's great.
pep.
Ge0rG, that's also what I thought when I mentioned an "export tool" (a client)
Ge0rG
I'd say we need to list all the data types and their respective means of export.
winfried
I 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
winfried
Ge0rG: yes, if we need to do anything more here, then it would be such a list
Ge0rG
winfried: 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)
winfried
pep.: 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"
winfried
pep.: 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."
winfried
Look also at this: https://gdpr-info.eu/recitals/no-68/
pep.
yes
winfried
20.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
winfried
pep.: yes, 20.2 would be needed too
pep.
20.2 is s2s transfers yes
nonfreepizzahas left
Guushas left
jonasw
winfried, roster, too
jonasw
regarding 20.2, I think as long as we don’t have a XEP for that, it’s not technically feasible
winfried
jonasw: do we store roster under 6.1a or 6.1b?
pep.
jonasw, we could start from 227
winfried
jonasw: 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
winfried
So 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"
winfried
What kind of auth mechanism would that take?
jonasw
I’d probably rather build on top of XEP-0238 (Moved)
ThibGhas joined
Ge0rG
yeah, if we remove the "manual approval needed" from 0238, it'd be great.
pep.
jonasw, I think we need both
pep.
Ge0rG, yes!
Ge0rG
I planned to dump that into standards@ for a year now
pep.
go go
jonasw
I don’t want to get into technical details here.
pep.
So, technical TODO?
jonasw
yes
pep.
Look into 227/283
vanitasvitaehas left
jonasw
ok, what’s next?
pep.
I think that's about the end of 1.1e?
vanitasvitaehas left
winfried
do we have to check the technical ToDo on deletion?
pep.
check how?
Guushas left
winfried
pep.: good question... ;-)
jonasw
what do you mean exactly?
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?
winfried
Should we add anything to that list
pep.
223?
jonasw
winfried, 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..
winfried
PubSud 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
winfried
But 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
winfried
pep.: agree
pep.
This list is not just for those where it's not implemented
winfried
Maybe we / somebody should make a list where deletion may be applicable and check where it is implemented and where not...
https://cryptpad.fr/code/#/1/edit/zSeJf1fqWnhVVk6LEjM0Xg/9CRtkSfVga8dtSuc8oDxjtv4/ anything I missed?
Guushas left
pep.
pff that markdown editor
winfried
mention recital 68
pep.
It doesn't want to split my quotes
pep.
ok
goffihas joined
winfried
Note: 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"
winfried
pep.: 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
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.
pep.
Ok so there is server-side file storage involved
goffi
yes, and I plan to add file deletion before release.
pep.
Does your implementation keep track of who uploaded what
pep.
cool
goffi
yes it does
Guushas left
pep.
Is that specified in the XEP(s) you used?
pep.
Do the XEPs even talk about server-side jingle
winfried
pep.: I think we should report / be open that we are overshooting on transfer
pep.
winfried, agreed, I'll add it
goffi
the XEP is for sharing file listing. Deletion is not specified, I'm planing to use ad-hoc commands for that.
jerehas joined
winfried
goffi: better should be a protocol for that (not overseeing its feasibility)
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.
pep.
winfried, might be good to add a TODO for this as well
winfried
pep.: +1
pep.
goffi, sure. We're just looking at what needs to be done in the context of GDPR
pep.
For servers
goffi
winfried: I'm experimenting, and will propose protoXEP for each thing not implemented as soon as possible
winfried
goffi: 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
goffi
pep.: sure. I'm willing to write a blog post about that for weeks, but lacking time