XSF Discussion - 2018-04-30

crap, gdpr meeting today

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

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

gdpr in 7, winfried, pep., Ge0rg

👍

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

Ok

!

¡

!

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

.

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

That's my fault

Not here to blame

where are we at?

Right to erasure, a few technical TODOs

And then maybe Q2

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

Re right to erasure

pep.: what kind of pubsub?

not PEP

Any

Pubsub is not in our list of processing personal data

it does (potentially) generate interesting metadata

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

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

-xep 223

bunneh!

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

via protocol

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

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

edhelas: yes, private ones are interesting in GDPR context

because public data is public

what about exporting ?

exporting what to where?

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

plz one question at the time, edhelas ;-)

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

For any kind of data

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

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

winfried, probably not

Technically everything is done via XMPP right?

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

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

We could "export" stuff via xmpp

like MUC-MAM

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

gajim?

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

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

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

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

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

winfried, for 2., we have TODOs

( jonasw that is a question for the template too)

Maybe not *everything* yet

pep.: correct, 2 is already in the todo

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

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

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

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

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.

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

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

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

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

(re deletion)

think MUCs on different domains

do we have to handle that?

dunno

interesting point.

the same for pubsub

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

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

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

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

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

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

which is currently not possible e.g. with MAM

The user is not especially aware of that

winfried, agreed

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

the market will solve that *cough*

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.

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

Zash, plz bring back bunneh

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

pep.: xep-0227

oh neat

oh

interesting

Ge0rG, wat

so a combination of both?

Ge0rG, that is for servers

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

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

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

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

pep., no

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

ah, err

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

It's just moving data between two XMPP servers

pep., no, it preserves domains

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

(unless I’m mistaken)

Ok less interesting than I thought then

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

Ge0rG, parts of it *maybe*

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

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

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

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

in theory

winfried: what do you want to export that way?

My server stores my roster, MAM

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

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

Ge0rG: Correct

winfried: that's great.

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

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

I don't see why we should do more here

What's the exact requirement here

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

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

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

That's article 20 right?

(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)

pep.: looking in my bible for the exact requirement

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

pep.: yes, art 20

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

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

yes

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

transferable how

They already are, to the client

pep.: yes, 20.2 would be needed too

20.2 is s2s transfers yes

winfried, roster, too

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

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

jonasw, we could start from 227

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

Transferring anything really

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

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

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

What kind of auth mechanism would that take?

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

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

jonasw, I think we need both

Ge0rG, yes!

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

go go

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

So, technical TODO?

yes

Look into 227/283

ok, what’s next?

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

do we have to check the technical ToDo on deletion?

check how?

pep.: good question... ;-)

what do you mean exactly?

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?

Should we add anything to that list

223?

winfried, HTTP Upload?

private pubsub

and http-upload yes

Plus I mentioned that in the TODOs below..

PubSud does delete, so private should too, right?

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

winfried, yes yes

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

I just think that should be mentioned as well

pep.: agree

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

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

I gotta run in 5

date of next?

+1 +2 or +4

days, I presume

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

+2 is not an option since it’s wednesday

+4 could work

can do

ah wait

Ge0rG, ^

I might be late

On friday

+30min would be fine for me, too

k

(that is, Fri 13:00 CEST) ✏

That would work

winfried, Ge0rG?

probably a no from me for Thu

friday

I have a probably-cancelled appointment on Fri.

Friday 13:00 CEST WFM

Will have to phone-check with them

Also heads up, 26? days until dday

okay, can do on Fri

okay

ack

gotta run

Friday 13:00 CEST

jonasw: thanks!

Ok, minutes incoming

pep.: great!

Have some work to do, again...

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

pff that markdown editor

mention recital 68

It doesn't want to split my quotes

ok

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

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

winfried, isn't it any PII?

"shall have the right to receive the personal data"

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

oh

ah right, as specified in 20.1a

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.

Ok so there is server-side file storage involved

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

Does your implementation keep track of who uploaded what

cool

yes it does

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

Do the XEPs even talk about server-side jingle

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

winfried, agreed, I'll add it

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

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

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.

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

pep.: +1

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

For servers

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

goffi: great!

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

I should also reference your previous thread on standards

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

cool :)

anyway I'll release an alpha version soon

winfried, sending

pep.: thanks!

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'>

huhuhuhu