XSF Discussion - 2018-04-23

Can a muc member revoke their own membership?

probably not?

I don't find anything specific related to that in the xep. Maybe some servers just allow the admin command if the removed user matches user who runs the query

Isn't membership editing limited to the owner(s)?

Yes that's what I meant. Maybe some specific implementations allow that if the member you want to edit is the requesting member

But it's certainly not explicitly mentioned in the xep

Well, that may be a GDPR issue... :-(

daniel: that's only half a step away from allowing members to make themselves an owner ;)

winfried, not sure. the owner is responsible for the members list.

much of this might boil down to the question whether users have the right to have their data deleted from other peoples data.

An exception for members leaving the group makes sense

like, my roster is *my* data, are you allowed to force me/my server operator to delete your JID from my data?

jonasw: storage and membership are two different processings

winfried, where’s the difference?

jonasw: That doesn't happen tho

Zash, what doesn’t happen?

Just updating the subscription state to none

Zash: yeah makes sense, there could be an exception for that

jonasw: showing membership, relaying messages, storing messages

Zash, I think somebody argued that even storing PII like the JID could be an issue.

Group creator storing other people's jids?

jonasw Ge0rG pep. if you are able look at the document I send to the members list before the meeting of 12:30, it would be very helpful

Ge0rG: Easy MUC leaving ?

winfried, I don’t see a document on the members list

are you subscribed?

I saw it

meh, restarting my MUA

there it is!

jonasw: Akonadi FTW!

Ge0rG, indeed. akonadictl restart and 5s later it’s on order. jokes aside, it has some weird troubles with switching networks while the notebook is suspended :/

.odt aww, you're going to force me to use the big guns

Zash: yes, storing a JID as MUC owner is a 'processing' in the context of the GDPR, but it not a very problematic processing

pep., I can put a .pdf somewhere

Nah I have libreoffice it's fine

I just never use it

No .txt? :)

sorry about that, I just wanted to go to bed after working 14 hours straight yesterday and didn't want to figure out how I would be able to put that table in the Wiki (what I would have preferred)

wiki tables are a PITA indeed

maybe Zash can apply some pandoc magic to convert this to mediawiki markup?

:-D be my guest!

Pandoc probably reads odt, so sure

we don't have to make that about gdpr. but if clients tend to show the entire member list (not just the currently joined users) we should give users the ability to actually 'leave' a muc

daniel, indeed

daniel: agreed

There being three or so separate lists is fun too

three separate lists?

owner, members admins

winfried: awesome table, looks good to me

I can’t parse the table.

speaking of which, I might not be very useful in todays meeting.

I'm on my phone with nothing installed for that ATM (still in bed :-°)

pep., I can upload you a pdf, as I said

It can wait that I get on the laptop

pep., https://sotecware.net/files/noindex/GDPR-table.pdf

Unless..

pep., but I won’t let you :>

jonasw: mentally parse?

winfried, yeah

not your fault though, I’m tired and exhausted for unrelated reasons.

jonasw: any amount of coffee that would resolve the issue?

Lazy pep. it's past 10

winfried, I’m caffeine-free for several months now; also, no :)

Maranda: BST not CEST

Pft then it's past nine still lazy

that’s some serious dedication!

or addiction.

Indeed

I think more the latter

But could be dedicated addiction

I can stop any time I want!1!!

Why would you tho

Or dedication to addiction

winfried: "how to safeguard on remote server?", that also came across last time, what falls on the recipient's consent exactly?

Whichever sounds better

Can we clarify this during the meeting

I think we don't need to ensure explicit consent to s2s delivery.

pep.: yes, please note questions like these, the thing is still subject to improvement

Ge0rG: agree, but *only* if no additional processing is done on the remote server :-(

winfried: technically, the remote server is subject to the GDPR because you forward it data from EU citizens, right? ;)

winfried: I wonder if we need contracts or in-band XML markup for that

winfried, you wrote "implicit permission" for user metadata (presence) in grounds for processing; but isn’t approving a presence subscription explicit permission?

Ge0rG, both

jonasw: it's explicit approval but implicit data sharing permission, I'd say

hmkay

Ge0rG: yes, I have the same line of thought, the question if it is subject to the GDPR is not settled yet, and probably not relevant at all

jonasw: yes, correct, plz take notes

And Maranda, it's not because you might have obligations that I also have to get up before 9 :p

Lazy

Just lazy

Sure

I want my sleep!

. ✏

GDPR in 2?

yes

winfried, what do you mean by "can we safeguard XY on remote server?"?

do you mean "can we ensure that on remote server?"?

jonasw: ensure

right

pep. Ge0rG present?

!

hi there

quick announcement: I’ll have a hard cutoff today at 13:30 CEST due to a meeting with my master thesis supervisor

jonasw: he can wait, this is more important :-D

I’ll tell him that, I bet he’ll be convinced ;-)

shall we from out the table I have build?

winfried, so, we’re plowing through Q1.1e today?

seems good

Any questions / amendments / additions

?

not right now

Ok, then lets tackle the issues top to bottom ;-)

let’s do that

We need to inform about the processing

the EULA thing in the credentials row seems to be a technical TODO for the EULA-XEP

jonasw: EULA doesn't imply EULA XEP. Yet.

jonasw: what do you mean with "EULA-XEP"? A XEP containing a standardized EULA?

winfried, additions, what I asked this morning

winfried, a XEP which defines how clients obtain the key points from a servers EULA. it would (in my mind) also contain *defaults* which apply to every xmpp server.

(that would be among them)

Once the message hits s2s, is it on the recipient's consent, for whatever reason. Unless it's a service on the other end not a person

jonasw: did you check https://en.wikipedia.org/wiki/P3P for overlaps?

no

pep.: I claim it's fair game to tell your users that whatever you send to a remote server is subject to that server's ToS

Ge0rG, but they wouldn't know what server, would they

I mean

I can, you can, my mom doesn't know ✏

with the EULA XEP it *would* be possible to have your client show you that ToS.

pep.: by sending a message to mark@facebook.com your messages are subject to facebook ToS.

Ge0rG, but in her client it's written "Mark"

but I think it’s even more fair game (and less critical) to say that "a message you send to someone is handled like the recipient wants, not like you want"

pep.: show me a client that doesn't expose the JID of newly added users

jonasw, I agree with that, not sure how to expose it to users

Ge0rG, ok, now explain that to users

pep., I think that’s common sense.

Ge0rG, once we’re at the point of invitation URLs we might get rid of most of that. I wouldn’t rely on that.

Explain to users that's it's 2 different things, localpart and domain, and not just one thing

jonasw: I disagree

I agree with jonasw

fight!

"somebody who claims to be called jonas wants to add you to their contacts. [yes] [no] [wtf is jonas]"

now stop bike-shedding please.

we've got real business to accomplish here.

Just for completeness, "Hey foo, I gave your details to bar, he's going to add you" *foo receives a contact request from _bar_* [yes] [no]

back to 1.1e?

:D

so what do we have?

I propose to postpone this discussion and start a top: informing the user upon account creation

+1

that doesn't need a EULA-XEP

winfried: maybe it does, if the user does IBR

but a standard/model EULA may come in here handy

Ge0rG: isn't IBR evil and banned?

yeah

no, IBR isn’t banned

it’s even getting developed

see XEP—0401 for example.

And maybe in a not-so-distant future clients will support data forms

OK

So there are different things we might understand under "EULA XEP": - a template for writing server EULAs - a protocol for informing the client about the EULA URL - a protocol for informing the client about specific EULA details - an s2s protocol to let remote users know of your EULAs

in my mind it’s a mix of the first and the third point

Ge0rG: +1

Ge0rG, I was kind of including all the above

yeah, kinda all of those actually

Maybe less focused on s2s at first, but that was mentioned a few times

Will that be 1 XEP or 4?

do we need to figure out the formalities of that XEP in this meeting?

strictly speaking, we don't need any of those, except #2 for IBR

I think the direction is good

Ge0rG: +1

So I suggest we skip out the EULA topic

Zash: 👍

Ge0rG, the s2s thing, how do you do that without a XEP?

Same for 3. actually

But yes I agree the details of the XEP can be done outside this meeting

pep.: my point is: we haven't yet established the need for any EULAs but the ones between a user and their server

Template / guidelines for writing an EULA sounds like an informational* XEP if anything ✏

Summary to solve first block: template EULA + protocol for informing client of EULA URL for IBR

pep.: and until there is a legal requirement to have remote EULA consent dialogs, we don't need an s2s EULA XEP

ok ok

correct? Then we can move to the second blob

+1

Otherwise we'll have to maintain a list of remote EULAs the user has accepted and block access to any other domains. Ain't that great?

Ge0rG, not saying it is, at all :/

Metadata in C2S context

I guess we need to inform server operators about the limits here

winfried: good point.

winfried: so we need a second document aimed at server operators outlining the limits

yep

yes

yes

Ok so 1.1e really is "come up with that document"

I guess we need also mention this in the EULA template

but do we need to communicate any standardized EULA clauses to the clients here or a link to the EULA?

I guess maybe keep the link visible

both is good

(and handle changes)

wtih both I mean a combination of both

that’s essentially whta the EULA-XEP originally was about

third Blob

eula { url, registered clauses ... }

Metadata in S2S context

with standardized EULA clauses, we are really in the P3P territory and somebody should have a hard look at that prior work

I think all the "how to ensure on remote servre" things can be answered with "not".

Ge0rG, I’ll put that on my todo.

but I can’t promise anything

Ge0rG: I don't know *how* standardized that has to be

But P3P sure is a good thing to look at

winfried: me neither. I'd say that having a human-readable ToS template is a good first approximation for now

Ge0rG: +1

unless the current s2s blob makes us formalize enforceable s2s requirements

which I hope to avoid at any cost

jonasw: ensuring remote server, can't be done on a technical level

winfried, exactly

and on a legal level it’s at least questionable.

(if the data is readable, ik can leak)

is it the responsibility of the service operator to ensure that all s2s peers comply?

winfried: it's possible to enforce on a technical level that the claimed s2s server's policy matches the user's requirements

Is it not enough to say that communication with remote peers are up to them, the user consentend when they sent a remote-addressed stanz

I’d even go as far as "sends any stanza to a user which is not themselves"

I see three outcomes: - we can't / won't enforce any s2s behavior / compliance claims - every server needs to advertise whether they comply with GDPR - P3P style fine-grained formal description

because even on the same server users might’ve opted in to MAM while you didn’t

I am in doubt now

jonasw, that could make sense

Ge0rG: first one, we may say: transfer is obvious to other server and part of the service the user requested, so leave it

winfried: does that apply both to EU and thrid contries based servers?

but then we come in the realms of forwarding my mail to gmail

Ge0rG: yes

does it need to be obvious to the user where the server is hosted?

Ge0rG: good question, don't have a definitive answer to that: transfer outside the EU needs to be mentioned in the EULA, but the legal demands for S2S inside the EU are the same as outside the EU (in the context we have now)

- "- every server needs to advertise whether they comply with GDPR" - that may not be needed, advertise 'no secondary use / profiling' would suffice!

- "- P3P style fine-grained formal description " is in my opinion an overshoot (but that is an opion)

winfried: so I suppose just covering the possibility of EU and third-country transfer in the EULA is sufficient?

Ge0rG: I *guess* so, would be interesting to take to court though...

hmm, can we come back to user-metadata C2S for a sec, I'm trying to find points to write down, but apart the TODO: document for server operators, I don't see much

The EULA XEP is also mentioned in every step concerning C2S for now

pep.: also publish a link to the EULA, needs to stay available + system for versioning the EULA...

I was hoping to include versioning into the XEP, not yet sure how/if really needed

and notifying the user of changes

yeah that as well

But do we want to reside on the most minimal version of S2S: inform it can happen, don't ensure anything on the remote server

Inform *s2s* can happen?

pep.: yes

winfried, do we have a choice?

If it is obvious to the user it is handled by an other server with other legal status, it is ok like that, but we had that 'does my mother understand' catfight.. that is relevant here

I'd be enclined to even say to the user "careful your messages may be considered differently once you send any stanza to a user which is not you", as jonasw mentioned above

So even C2S

winfried, I don’t think we can make that obvious

TLDs are not a safe indicator for that, IPs are a bit better, but not available to the client.

+1 to that ^

unless it does SRV lookup for the service itself

which may easily yield you a geo-located response with your closest entry ponit to the cluster

so it would look as if it was EU from within the EU, but in fact the servers are partially outside the EU

(DNS round-robin could case something similar with less fancy efforts)

I don't think we need to handle inside EU and outside the EU differently here: both are allowed if it us needed the perform the servers the user requests

TL;DR: we can’t really show that to the user and have to assume the worst.

The issue is, do we need to tell the user if more is done with the data then is needed for performing the service the user requested?

I don’t know.

I think we do, yes

Well legally I don't know

winfried: I'd say we need something like "messages sent to users on other servers are subject to those servers data usage policies"

+ yadda yadda non-EU countries

+ other user's settings?

+ & + +1 ;-)

wat wat

pep.: two different statements, first about other users -> their archival config, second the above one

I'll make an attempt at writing an EULA once I have the time. In a month or so

s/to users on other servers/to other users/;s/to those servers data usage policies/to the policies the those users agreed to, which may be more liberal than the policies you agreed to/

you still have a month and 2 days before GDPR, you're safe

yes I'd prefer jonasw's version

I don't know if that holds legally, but that's a bit more thorough

I don’t either

So no need for a S2S EULA XEP?

If we have this kind of disclaimer I don't think so?

Though, we were at "metadata"

Not data, yet

But I guess that still holds

I would *like* to know it, but is it needed for the GDPR? I doubt it.

maybe write a XEP like that and advertise it as 'good practice'?

winfried, probably implicit consent with roster subscriptions, or user joining MUCs etc.

pep.: I think everything said above also holds true for data

Ge0rG, same

Ge0rG: +1

Ge0rG, +1

Do we go with Ge0rG or jonasw's version?

if the "once you send it to the recipient, the recipient is responsible" holds, we’re good with it I think

jonasw had the better polished wording

good

everything said here holds on the content too, except for MAM storage

Δt=-6m

winfried, how does it not include MAM

winfried, how’s MAM storage different?

Plan for next?

that one is legitimate interest of third party (maintaining a log)

(art 6.1f)

winfried: with the receiver being the third party?

yes

what pep. says

winfried, third-party as is recipient? That falls under "messages sent to other users are subject to policies those users agreed to" ✏

I gotta run in a few mins, plan for next?

jonasw: yes

I don’t have time tomorrow or on Wed

thursday same time?

Thu or Fri would work, usual time

Thu 12:30 CEST

Thu same time worksforme

Ge0rG, ^

+1 on either

it’s settled then

anything else?

Thu 12:30 CEST

Good work again!

We've covered credentials, User metadata/data (C2S/S2S) then

thanks all!

heading out now

pep.: much applies to content to

jonasw: good luck!

yes, "data"

ah it's called content

ok

hmm, instead of "messages", we should say "Stanza" probably?

pep.: if you mail the logs, then I will try to update the schedule

pep.: +1

Or something that the end-user can undertand

I pandoc'd this https://wiki.xmpp.org/web/GDPR/Table if that's fine

instead of stanza

Zash: yes, that would be great!

Zash, nice

Any possibilities to add lines between the fields?

Zash: it *IS* great, thanks a lot!

I don't know, I'm not /that/ familiar with mediawiki syntax.

Zash: I will have look myself otherwise...

Please do, it's a wiki after all :)

Zash: :-D

Zash, do I include you in the participants? :)

pep.: Maybe a little? I barely follow this tho.

winfried, today's minutes compress well :P

pep.: I also took some notes myself, but they are not objective ;-)

Zash: lines added...

winfried, https://bpaste.net/show/23e279a44f9e

I'm going to send this

pep.: great!

I'll include a link to the table as well

pep.: missing the 'inform server operators' from the logs ;-)

at what point

[12:53:14] <winfried> I guess we need to inform server operators about the limits here

I meant, where does that go

what limits

It is about the limits of using art 6.1b and 49.1b

Also I should include Ge0rG's points on the EULA XEP

And that it won't be tackled during this meeting

so it is a limit to what processing can be handled with this EULA template

Right

Have to go now, other business to attend...

thanks, pep.