XSF Discussion - 2018-05-24

Link Mauve, not quite MUC

We call it simply group chat.

Parts of it are already working.

Andrew Nenakhov, I think he is just asking for a MUC where people can join

Like him or me

Well... We won't run 0045 MUCs.

If you tell me your JIDs I can invite you to our prototype solution. It's backwards compatible with regular clients

why?

do we need Yet Another Groupchat Standard? aren’t three enough already?

(or four if you count DMUC)

jonasw, we are building the one that works.

Holger, no.

-xkcd 927

https://imgs.xkcd.com/comics/standards.png

if it’s compatible to existing clients, how does it solve the fundamental '45 issue (resource === nickname)?

Yes yes. We don't cover everyone's use cases though.

It is of course easier to hack something to solve your own specific problems, than to produce a general solution

Just ours.

It is compatible in different way. Existing clients will treat it like a standard contact in roster.

that doesn’t sound at all like Group Chat 1.0 ✏

Steve Kille, you see, once you try to do a universal standard for everyone's needs, people will flock immediately and start demanding to add this and that

From what I understand it killed MIX before it was even born

having 10 standards for a fundamental feature like chats between more than two people will kill XMPP though :)

jonasw: that is a key point

I think the MIX split is doing much good here

uh, Steve Kille, a thought which just crossed my mind: It would be *excellent* if each sub-feature in each XEP would be marked with who is responsible to implement it. like in my email: "User Client", "User Server", "MIX Component"

this would give a very quick overview of the complexity of a MIX part for a given project

Xmpp is already mostly dead.

Making good choices as to what is in a universal standard and what is mandatory/optional is key. If you make it too thin, it is a problem because it does not solve necessary problems.

I’d like to know for example what a client needs to do in order to benefit from MIX-ANON (it doesn’t necessarily need to *know* this is an ANON room, just the basic question "can I join a MIX-ANON room without doing additional things on the client side?")

Let's start with the table you suggested.

sure, one step at a time :)

The way MIX-ANON has come out, it does not impact end user client at all. I was pleased that the split enabled this.

Steve Kille, regarding your question about the PR: you can always start working on top of your working tree, even if I haven’t merged things yet

Table will make this clear

it shouldn’t lead to conflicts (if you don’t do version blocks; which you don’t need to, in general), and if it does I can resolve them

jonasw: we need to synchronize, which is why I checked.

this is great (about MIX-ANON)

I'll bash on and do this after my bike ride to work

but it’s indeed trivial, will merge it right away

OK - so shall I add a new version number for the table (0.11.2)?

Steve Kille, you can, otherwise I will :)

(merged and pushed your editorial fixes)

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

May just be you and me though...

Hmm

No Martin?

I'd like to note that, with an iteam hat on, I'm assuming Board has done due diligence with GDPR on our infrastructure, and will tell us if anything needs to change.

There is a hugely important agendum pending, regarding the Board competence wrt. the GDPR XEP

Ge0rG: while I agree on the importance of making sure everyone is ready for the GDPR, I don't think we should rush the XEP, if that's what you're getting at

It's not.

There is also a meta-agendum regarding the process for XEPs that are neither technical nor processual, but rather legal.

The XEP was presented to Council. I don't believe Council has competence to be the approving body for such a XEP.

I don't think there should be any process for XEPs that are legal, because... we don't have legal XEPs

So the question is what to do about it that Board is happy with.

We're not an organisation that gives law advice

If Board is happy to be the approving body, we make a chance to XEP1 that allows an Informational XEP to be approved by Board.

Kev: I understand that part, and I agree with MattJ

I think stpeter's suggestion has some merit in that regard

If Board doesn't feel they have, or are able to acquire, competence here, then we probably communicate back that the XSF isn't the place for this XEP before any more work goes into it.

The central point being that I (strongly) feel that Council isn't the right place to approve a XEP giving advince on complying with the GDPR, whether that is "legal advice" or not.

Agreed - but neither is the Board. And in that case, it means the XSF as an organisation is not

I don't feel comfortable with the abstract on behalf of the XSF, either. It currently says: “This informational XEP provides information on deploying XMPP in way that is compliant with the General Data Protection Regulation (GDPR) of the European Union.”

(Other options are Board reviewing it and assuring Council that it is fine to publish from a legal perspective, and that Council should only review technical content, or changing the XEP such that it's not trying to give GDPR advince)

MattJ: I think the Board saying "No can do" is a reasonable outcome, if that's what Board feels. I'm just concerned that Council can't judge this (and, even if it's not legal advice, Council can't make the call on whether it's legal advice).

I wouldn't be confortable as Council either, I agree

The thing with the GDPR is that, for example, you should not store more information than needed. This can vary quite a bit depending on the nature of a particular deployment.

Board have the option to get legal advice on it.

Council don't have that sort of authority :)

I think there are a few options

- Trim it down until it's not GDPR-specific, and we're comfortable that it's nowhere near being taken as legal advice

- Consult a (presumably costly) third-party to make us comfortable with it (and possibly aid in the editorial process)

- Don't publish it

(under the XSF)

The author(s) can still do what they like with it

Winfried has stated that #1 is not feasible, because it contains some very GDPR-specific statements, and presumably removing those may undermine the purpose of the document

#2 is not feasible because of our financial situation, in my opinion

Mind if I join in?

Please do!

Please do.

Having a list of what's a reasonable minimum to store to be able to provide a particular service would be useful. I'm curious myself about the ability to take notice of Privacy Policies.

Short, I am on the move

(let alone explicit consent for certain processing)

The issue is liability

Don't know to what extent the xsf is liable for xeps but we can limited it by presenting it as an opinion of the xsf in stead of guidelines

And things like advise on the proper protection of the data you store, but I believe that GDPR doesn't require certain types of encryption (e.g. Encryption at Rest), but you need to ensure it is protected adequately.

If someone (small independent service operator, large commercial operator) gets fined for being in violation of the GDPR but followed everything in our XEP, I can see how they may try to turn to the XSF for recompense

winfried: I personally wouldn't want to go anywhere near providing an opinion as the XSF. At most I'd record best practices and points of attention. For the rest defer to experts.

Whether they would actually have a case or not, I have no idea

Say you run a public server hosting MUC rooms only. Each of the rooms are created by the owner of the server, but everybody is free to join them. How can you provide a proper Privacy Policy, how do you collect and process what data, and why? What can you do if someone requests removal?

There's so much there.

I think there is room for an Informational "Privacy Considerations for XMPP Server Operators" XEP

Agreed, and I think *that* would be in scope for the Council just fine.

How would that be different from a GDPR-less GDPR XEP?

Note that the example above is not arbitrary. There's some work to be done here. (Nod to Kev).

Zash, it wouldn't, really

But the current document has headings like "Is the GDPR appliccable to you?" - that's not something we can answer for anyone, that they can't just as easily get answered somewhere else

Exactly.

E.g. it depends on where the server operator is located.

E.g. if you server is within the EU, I think the GDPR still applies even if all your users are not.

Well, I guess that's it then

For the record, there was never really a meeting today.

Indeed. A formal vote isn't possible with over half the Board absent

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

But I think it's ok for the the council to not accept in the meantime, and for discussion to continue on the list

(yes I can do that)

MattJ: agreed

ralphm MattJ thanks for discussing this, I will take this, I will think a bit about how to handle this. I personally don't mind putting my own head in the line of fire, so I may also publish parts of the GDPR work as a personal opinion, outside the structures of the XSF.

Sounds great - and also identify things we do need protocol features to support, such as the ToS/privacy stuff that was discussed

so, I am looking at muchopper (to index MUCs in XMPP) again. are MUC bare JIDs, Subjects and Descriptions in any way personal data under GDPR? I don’t think so from the definition of personal data in Art 4.1, but if someone disagrees, let me know.

I know this is controversial, but I'd say that public MUCs are public.

> basically anything is this personal data?

Ge0rG, indeed, I’m going to filter for MUCs which have the publicly listed flag enabled

jonasw: you could index the other ones for stats, but hide JID and meta data.

what type of stats?

occupant count?

dunno. Average number of users in a MUC? Number of people who are not in every MUC that has "xmpp" in the name?

Ge0rG, what would I use as key then in my database for those?

HMAC(some-secret, mucjid)?

Better PBKDF2 with i>9000

ELOAD

jonasw: if some-secret isn't in the DB, that's ok.

I need to store the JID to be able to re-join after a restart

Is a MUC JID personal data?

I don’t feel like it is

the domain part might be though

I don't think either is.

jonasw: you also need to store the JID to blacklist MUCs

no

Ah, right. HMAC is sufficient

MUCs can blacklist muchopper by banning its JID ✏

That, too.

if a join fails due to a ban, data is purged

How do you remember that someone does not want your cookies?!!!

but for restoring state I’ll need the JID, so I’ll always have to store the JID

Hmm, tbh the board discussion above seemed like one of our gdpr meetings, like beheaded chickens not really understanding what's happening

As I said before all this started, that's the best that anyone can do right now :)

pep.: is it possible that you and me were in different GDPR meetings?

jonasw: personal data is any data relating to a natural person on its own or in combination with other data. This includes all kinds of identifiers, including JIDs

Ge0rG: for the purposes of the GDPR it doesn't matter if something is public or not

ralphm: "It includes all kinds of identifiers, including JIDs" - but doesn't include all JIDs, correct?

A place someone goes to can imply interests which is personal info.

Kev: JIDs leading to invidivuals

Right.

so that includes the participant JID in MUC or proxyJID in MIX

ralphm: that's true. But I still wonder what kind of data processing can be made on data that was made public by its owners.

Hmm. But a proxy JID in MIX is something that is assigned by the service, and doesn't identify the user, kinda.

It is an identifier for the user, yet doesn't identify the user, if that makes any sense at all.

Ge0rG: the XSF is forwarding your message to everyone in this room. That's processing. And for a specific, explict and legitimate purpose.

We are also storing logs.

I guess MIX proxy JIDs are actually quite similar to IPs.

So yeah, point withdrawn.

Kev: it is a stable identifier for a natural person in the context of the MIX room. So yes, under the GDPR that is personal.

ralphm: my question wasn't even about the xsf, but in that specific situation you could probably argue that the user gives consent by entering a public MUC and writing something

Yes, already talked myself around.

Ge0rG: consent needs to be explicit and specific. In this case, you probably want a Privacy Policy to cover this use.

We have voted on one in 2008. Can't find it right now.

Was probably lost in the Battle-Tested and Secure website update :)

Kev: privacy.shtml

there's a copy here: https://web.archive.org/web/20120808002100/https://www.jabber.org/service-policy/

You mean you've got it, or you'd like me to search on the server for it?

Ah, cool.

And I have it in my gitorious clone of the xmpp repo

That's jabber.org's, though, not xmpp.org's?

Or is it so old it predates the split?

well, haha: https://xmpp.org/2008/12/privacy-policy-approved/

Ah, no, loaded now. That's jabber.org's, not the XSF's.

ralphm: I didn't see a consent dialog popup when joining this room for the first time.

Kev: which seems to imply things I'm very curious about now.

Ge0rG: yes, indeed

but pizza

ARGH!

I didn't reload the mail config?

:(

"and nothing of value was lost" :P

Why does the mailman archive not show dates?

Uh, does doing the member survey mean I agree to Googles privacy policy etc?

probably

Just in time. https://yaxim.org/blog/2018/05/24/updated-yax-dot-im-policies/

Congratulations, would be interesting if you get any message from one of your users regarding this, like requesting information, etc.

...or a nightmare letter: https://www.linkedin.com/pulse/nightmare-letter-subject-access-request-under-gdpr-karbaliotis

meh, so apparently there’s no way to know whether a MUC wants to be listed publicly unless one has privileges over that MUC

the #roominfo from distributed via disco#info doesn’t contain it, and the #roomconfig isn’t available to unprivileged users

isn't checking MUC server to see if the room is listed there sufficient?

Wiktor, the list could be extremely long

Won't it *not* be in disco#items?

Zash, I might have the MUC jid from another user or invite, and I need to know if the room wants to be publicly listed

jonasw: yep, but that's additional info for your bot :)

so... the only way to do that is by iterating MUC directories .. :/

> :tag("feature", {var = get_hidden(event.room) and "muc_hidden" or "muc_public"}):up();

ohh features

right

Is this some magical thing only Prosody trunks MUC does?

jonasw: Oh I thought this was what you already checked?

ejabberd also des it

Zash, no, I looked at the #roominfo form

Ah, ok

jonasw, Ge0rG, winfried, my presence my be spotty tomorrow I just recalled I'm taking a train. At that time I should be waiting for it (queueing) so I should be able to attend from the phone

Is there an XMPP mastodon account? I was searching, but could not find one...