XSF Discussion - 2018-05-04

GDPR

in 2 hours?

(oops did I do it wrong?)

my last information was 1300 CEST

(a.k.a. 1100Z, so maybe timezone confusion?)

probably... feel I am living in a different zone right now ;-)

"Date of Next: 2018/05/04 11:00 UTC" - I am not totally crazy ;-)

oh oops

welp

11:00Z is in two hours (just under)

From the mail from pep.

right

ah

now I’m super confused

and I *do* have UTC timestamps in MUCs.

so am I

I don’t seem to be awake

It's 09:07Z at the moment.

09:06:09 winfried> "Date of Next: 2018/05/04 11:00 UTC" - I am not totally crazy ;-)

so yes, GDPR in 2h

echo 'Etc/Utc' | ssh winfried 'sudo tee /etc/localtime'

I know where it is coming from: I always regard myself as the center of the world. :-D

will be back at 11:00 UTC ;-)

gl

second attempt ;-)

riiight, and I managed to entirely forget about this in the meantime :)

I’m goood

pep., Ge0rG, GDPR in 0

!

Same, I did also entirely forget

So, what's up for today

When updating the WiKi, I came across a question (is MAM 6.1a or 6.1b)

I want to discuss briefly how we handle existing specs

I think we settled on MAM is opt-in?

And that should be fixed in the XEP/clients

(clients)

pep.: correct, but, if i recall correctly, the reason for it was that MAM is not 'naturally' part of the package when you are communicating

We won't go as far as to prompt the user when he decides to enable MAM right? I mean from the server. « Hey you're enabling MAM, here is what happens no: [..] »

pep.: exact

noa*

*nao

I'm not sure if we should go this road

but just enabling MAM rather is requesting a service in sense of art 6.1b then an opt-in in the sense of art 6.1a

sorry I'm late.

welcome, Ge0rG

winfried, is it? I’d say it’s kinda 6.1a

is it very relevant?

(which of it it is)

yes, 6.1a has quite tight regulations (art. 7)

6.1b not

winfried, Art 7 should be no problem for enabling MAM

And the server operator should prove the client has asked the question, kind of hard

winfried, that was one of my original questions in the whole GDPR-in-XMPP discussion

who is liable if the client didn’t properly ask?

is it the client developer? or can the server operator rely on the client asking properly and blame the client if it didn’t?

yeah and we haven't answered this really. Not that I'm qualified to

we can avoid that problem altogether if it is 6.1b, what is rather appropriate IMHO because enabling MAM is requesting a storage service

I’m not convinced though that this is any type of contract

jonasw: what is your doubt?

it may be my IANAL, but when I think contract, I think more formal than ticking a box in a UI

with terms & conditions I can read and am aware of etc.

jonasw, that's what the EULA XEP is for right

maybe

When I asked above « are we going to prompt the user when he decides to enable MAM, from the server », I had in mind some version of that

the eula xep is for the obligation to inform. And because the MAM (in case of a muc) may be hosted on an other server, it may be appropiate to include a link to the EULA in that question to...

Like, client issues MAM query, EULA kicks in and requests ticking a box, and MAM gets enabled only if accepted

winfried, and then, wouldn’t the server operator still have to kinda prove that htere’s that contract with the user, in case of doubt?

I think the burden of proof is required anyway

pep.: using the service is enough burden of proof for a contract, not for 6.1a

When the user creates an account, "please read terms & conditions. Here's what going to happen to your data [for X, Y reasons]. Are you ok with it?". This is what I'm picturing

I see

pep.: when going 6.1b, just informing is enough

Shall we allow for both in EULA then? 6.1b only (no ticking box), and 6.1a (ticking box, plus blocking operations)

pep.: don't know if that is any help, you still need the infrastructure for the burden of proof of 6.1a

I think MAM would fall under 6.1b like jonasw. The operator can state in the terms, "If you enable [MAM], here is what will happen"

pep.: exactly

Ge0rG: can you give your opinion on this? I propose we move on in the mean time...

right

We have a list of XEPs that have potential deletion problems, should we check other (all?) XEPs for issues?

winfried, have you followed the discussion on standards@?

HTTP-upload?

I’d like somebody except me to reply to the last part of the thread.

yeah

nope, didn't will look into it

jonasw, the part where people don't want to mix the XEP and laws?

protocol / laws*

that, and the part with "better have a separate xep which discusses that"

Yeah. well changes are still required in the XEP to allow deletion via the protocol anyway right? This doesn't have to be because of local laws

Right, I think the two things are separate

daniel is against a deletion flow AFAIK

I'm not saying I'm in favour of deletion (or against), I just think it's a separate concern

yeah

An out-of-protocol deletion would work just as well

Meanwhile there may be a non-GDPR case where someone accidentally shares the wrong file/picture

Not so long ago a user asked on movim@ for that iirc

hah, just the other day :>

:)

and that fun day when somebody posted very ... uhm ... interesting ... drawn content in prosody@

I guess I somehow missed that

I will respond in standards and I will need some time here to think it over: there are lots of things at stake in that discussion

We'll need to clear this issue while we're asking for changes in lots of other XEPs

My uninformed take on this is that the GDPR shouldn't mean any need to change any protocols, but that having notes in specs saying "but consider this" is worthwhile.

Because the same question will appear over and over

It has also to do a bit with localization of the XMPP network and values around an open internet. And *every* technology is political and XMPP certainly is. But we must take that discussion to the standards list.

winfried: sorry, got caught up in a business call

Ge0rG, pff

Ge0rG: expected sth like that

We have half an hour left now, can tick Q.2 there?

(can we)

Can we ?

is that Q1.2 rather than Q2?

I was still stuck in 1.1e in my minutes..

pep.: you are right.

I think 1.1e is about done by now

k, I'm not really clear on the boundaries of 1.1e, I have also mixed that with 1.2 certainly

and the discussion @standards certainly is 1.3 ;-)

Right

winfried: regarding the consent. I think it's technically not feasible (and neither legally reasonable) to ask for explicit consent for passing data from the user to other servers/third parties, for when the user tries to communicate with those third parties

So "by using this server to communicate with third parties you agree that data will be passed to third parties" is IMHO a good trade-off

Ge0rG: agree

Ge0rG, the consent thing was about local MAM though

pep.: plz put that sentence of Ge0rG in the minutes, we need it ;-)

winfried, we already had something similar, but yes

jonasw: re local MAM the question is interesting.

my position is that the client needs to inform the user that by enabling MAM, they will enable MAM.

or rather, ask the user for consent to store data on the server.

I've called out clients that silently auto-enable MAM before. Without success.

But client doesnt know server policies, so how good is that consent?

lovetox: did I hear "data-forms"?

yes good idea, but then its not only the client anymore 🙂

Ge0rG, so that's 6.1a realm?

And some more XEP (or just EULA?) required for this, as I was asking above

pep.: I would say: that is still informing and 6.1b

lovetox: the server has a kind of tri-state of MAM of (undefined, enabled, disabled). The client comes and silently enables MAM. Who's at fault?

all processing is odne to deliver the service the user requested, nothing more.

What i want to say is, it would make sense for the server to communicate the policy on enable, or a xep that lets us retrieve those

ok

I'm not sure how far we can put MAM in 6.1b land

so we can really inform the user, not just say "we now going to store data somewhere, for some unkown time, and we dont know what will happen with it"

lovetox: correct

ok, so what I've been asking above :P

Ge0rG: what is your doubt? MAM is an archiving service and the user agrees to use that for that service, I would say that is 6.1b

winfried, but the server would still have to prove that hte user agreed to that service, right?

jonasw: Surely that's part of the service agreement the user sigs up to?

*signs

jonasw: difficult wording there, when you decide yourself to start using a service, then you agree to the data processing that is inherent to that service

you have to know what kind of processing though

That'd have to be ack-ed before signing in

pep.: the information must be available and up to date (art 12 if I recall correctly)

Right

pep.: but for 6.1a it has to be acked on forhand, for 6.1b not

So in the IBR processus or similar, "This is what you are signing for. [Create]"

pep.: yes

hmm, trying to summarize all this..

date of next?

a hairy issue is what if a client enables MAM by default? And does it make a difference if the UI of the client suggest storage or if it suggests the absence of persistence? And who is liable then?

winfried, what jonasw was asking

20:10:05 jonasw> winfried, that was one of my original questions in the whole GDPR-in-XMPP discussion 20:10:10 jonasw> who is liable if the client didn’t properly ask? 20:10:23 jonasw> is it the client developer? or can the server operator rely on the client asking properly and blame the client if it didn’t?

pep.: translated to what we know now...

What happens if you have a web-based consent form, but the user has some obscure browser that doesn't render the page correctly

and maybe it has a bug that swaps the "I consent" and "I do not consent" button text

I think we can argue that if the client suggest immediate deletion but enables MAM silently the client is liable

MattJ, that's always been an issue? :x

winfried: But that the server presumably still had to say "If you enable MAM, we'll store X"?

GDPR is not changing anything here

Kev: yes it has to inform

pep., but the analogy help with the "what if the client doesn’t do things right" question

pep., but now the server owner is legally liable? :)

date of next?

MattJ: about what consent form are you talking? I am right now trying to circumvent all consent forms!

Mo, Tue, Thu & Fri are possible for me

Mon/Tue/Wed ok for me, the rest might be more difficult

Mon or Tue?

Actually.. I'll be in Karlsruhe with some other xsf people, so I can also do it from there :P

Assuming it's not *too* early (as I'll be in holidays ><)

Mon is not possible

Tue would work

Tue 12:30CEST?

wfm

I'm in CEST next week btw, all week

Ge0rG?

wfm

I will have to go, won't be waiting for Ge0rG

okay

The minutes won't appear just right now but I'll try to do that quickly

pep.: thanks once more!

next week I'm completely unavailable

:-( is there any way we can still get your input?

thanks MattJ ! so XEP-0368 is constructed the same way (same misunderstanding of requirements section) and I copied from there so this has been a long ongoing misunderstanding :)

Heh, so it is... never noticed :)

it even got all the way to Draft that way haha

Yeah, surprised nobody else noticed

It's documented here: https://xmpp.org/extensions/xep-0143.html#sections-reqs

The technical stuff should be in "Use Cases", as e.g. "This is how a client should connect to the server" etc. etc.

I *probably* copied an existing XEP back in 2015 but I couldn't even begin to guess

Take a look at https://xmpp.org/extensions/xep-0297.html#requirements for a simple example, or https://xmpp.org/extensions/xep-0313.html#requirements for an example that replaces an existing protocol (and discusses why)

https://github.com/xsf/xeps#new-protoxeps should mention XEP-0143 I think

again I can't recall but I don't exactly remember reading it

moparisthebest, that README is for editors, not for authors

ok, then there should be a readme/section for authors :)

right on the top it says: > To submit a new proposal for consideration as a XEP, please read this page: https://xmpp.org/about/standards-process.html#submitting-a-xep

ah yes and then suggests the wrong way to do it

(email editors instead of pull request)

that’s not wrong

just old

and both links https://xmpp.org/extensions/xep-template.xml and https://xmpp.org/about/xsf/xsf-source-control/ is broken

mailing the editors is still totally a fine thing to do

moparisthebest, PRs against the website welcome

I would just put the correct procedure at the top of the readme in the xeps repository

why not both

yea and fix the website

PRs welcome

will be happy to review htem

"By creating a post, you agree to Imgur's [Terms of Service] and [Privacy Policy]" What imgur.com has btw

wait until May 25th

I’m still getting at least two mails per week from esrvices which have adapted their ToS/Privacy stuff

and imgur didn’t do that yet

so that may still be a WIP

yeah

I'm also getting spammed by policy updates

There is an easy solution to the GDPR now! https://gdpr-shield.io/

ha I love it

> We provide you with a JavaScript snippet that you'll paste into your site's existing HTML code > We'll check every user that visits your site and block access to users from the EU. This happens in the background and doesn't affect your site's speed for non-EU users

This!

<stream:stream><script...

Or just put a "EU citizens not allowed" disclaimer in your TOS, that's what I did in the motd of my IRC server for German citizens

moparisthebest: I'd say that doesn't qualify

Why not?

How could I be liable if you illegally use my service in violation of my terms?

moparisthebest: I'd say you need to explicitly block the EU IPs

Why?

Does it really apply to moparisthebest's IRC server? I guess he doesn't collect any personal info there.

I think similar should work everywhere even if you do collect PII

Yeah but irc doesn't need your personal data and by design it's a public forum.

but most nickservs operate using email adrseses

which are PII

And IPs. You need those against spambots!

A similar thread was recently here https://news.ycombinator.com/item?id=16661323

> Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR. Source: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en

interesting

I think a ToS like moparisthebest would strongly signal it does not target EU.

Wiktor: I think that "specifically targeting" are weasel words that need to be checked by courts.

Sure, I'm not your lawyer, but I wouldn't panic if I was moparisthebest :)

Why, you can't panic often enough.

EU citizens are forbidden from using this IRC server - This is specified so the GDPR does not apply: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en

added that to my motd, done and done, GDPR is easy!

I really don't think it works like that :)

MattJ: I might have said the same thing before, without convincing anybody.

no one is going to sue me for that anyway, but if they do, I think 'they were forbidden from using my server' is a pretty strong argument

also 'go *&@! yourself I'm not flying to the EU to appear in court' is pretty good too

re gdpr-shield, I was going to ask what if I disable JS, but in that case I probably won't have access to the website anyway :)

pep.: websites on .io require JS, didn't you know?

yeah I know

That's why I corrected myself

> This won't apply to every U.S. business — just the ones that are knowingly, and actively, conducting business in the EU. In this vein, EU courts have the discretionary ability to determine if a U.S. company was purposely collecting EU resident data and subverting GDPR compliance. So, in some cases, the inadvertent collection of personal data will be forgiven if it is found to have been occasional and "unlikely to result in a risk to the rights and freedoms of natural persons." Source: https://community.spiceworks.com/topic/2007530-how-the-eu-can-fine-us-companies-for-violating-gdpr

does anyone know if any servers implement bcc from here? https://xmpp.org/extensions/xep-0033.html#addr-type

https://hg.prosody.im/prosody-modules/file/f66a08f208ad/mod_addressing/mod_addressing.lua#l19

thanks