XSF Discussion - 2018-05-31

Kev, I heard swift can do XEP-0055 (Jabber Search). Does it support RSM-based pagination and if so, where is the RSM element included? And if not, do you think RSM would be a reasonable way to do that and if so, where would the RSM element go?

It does 55, I don't believe we RSM.

I’d very much like to not return 4000 entries in one reply though

I don't think 55 supports RSM does it?

does *anything* before XEP-0059 "support" RSM?

oh look at this, XEP-0059 even uses XEP-0055 as example for RSM

and it’s allegedly used with disco#items

(even though I haven’t seen that in the wild with MUC services yet)

I though RSM could be applied anywhere without need to specify it. This this was we answered to me when I asked for disco in the past.

(AFAICT)

I thought RSM could be applied anywhere without need to specify it. This this what was answered to me when I asked for disco in the past.

is there any standard for something like XEP-0055 (Jabber Search) but for MUCs? (not disco#items)

jonasw: what prevent you from using XEP-0055 with MUC ? It returns jid and can use data form for any extra data you wish.

goffi: sure, I can re-use bits of 55 but I was wondering whether there was any precedent for that

Board o'clock

Hey

o/

ralphm, martin, nyco ?

I am here, was held up

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

yey

1. Welcome & Agenda

Who's here and what topics do you prefer to discuss today?

I'm here

I'm here

We can discuss the next steps for the results of the survey

Also: gdpr compliance?

Cool. Maybe revisit the GDPR discussion

That should fill most of the meeting.

also: did anyone hear from Martin in the last few weeks?

he didn't renew XSF membership - I wonder if that was intentional.

Not since May 3.

Likewise

While there's no requirement to be a Member to be a Director, I share your curiosity.

2. Survey.

The survey "officially" ended yesterday, with 24 responses

Which I don't consider too bad, I was expecting worse

I haven't had time to do anything with the responses, barely look at them. I propose I do that and share a Google Spreadsheet over email, and we can discuss in more detail next week?

and if anyone has specific things they'd like to discuss (e.g. points raised) we can add those to the agenda

Sounds good to me.

Agreed

3. GDPR

So there a few things here and maybe we should split them.

1) the XSF's compliance

2) the proposed XEP

Agreed, sensible

this feels like a beast: can we further split them?

Go aheah

I would if I knew how 🙂

Well, there are a few things on 1)

- The foundation membership

- The e-mail archives

- The XMPP server with its rooms and archives

shout if you can think up more items

that is: items where we potentially store private information?

do we use cookies on the website?

s/private/personal/

personal, indeed

Matt just asked for everyone's mail address in a nice (but one-off) poll

I also stated how they would be used, and that they would not be kept permanently

We can probably continue doing all the things we do, but we have to document what we process, for what reason, etc.

ok, stepping back: I'm unsure what exactly the end-goal is (other than 'be compliant' which I don't know what that entails)

And we need to revisit/reinstate the Privacy Policy that was written in 2008

(we've got personal data in the wiki too, probably - and there's author information in each XEP)

(for a discussion on this, see the archives of this room -1W)

I also thought about the Wiki indeed, and the XEP

s

I was knee-deep in water at the time, have not read back 😕

Basically we had a PP for both jabber.org and xmpp.org, but with all the website transitions it is no longer available

we have it somewhere still, though

okay, say we are able to restore that: is there someone available that can tell if it is GDPR compliant?

First of all, no-one probably is 100% compliant, and you will know when somebody has sued you

Nobody can really say for certain, there are too many grey areas - however I'm really not worried

Pretty much all we have is public, and given by people knowingly

The focus points will be documentation, the pp, and possibly retention, and information and deletion requests.

There may be hidden things like server logs, but if we don't keep those for "too long", we "should" be ok

sure, and although I assume that that's ok, that's not based on any knowledge of gdpr on my part.

Well, I've been involved professionally, so I know a few things

good. Tag, you're it. 🙂

I think we should also involve Alex

haha, good one

Sounds like MattJ knows things, too

maybe we should task a certain group of people with doing an inventory of our data, and make recommendations?

iteam?

or an adhoc one (Ralph, Alex, the people that have bene working on the XEP)

I'd be happy to do leg-work, but I need someone to tell me what to do.

Well in the case I gave (server logs), that's something that requires iteam - an inventory of running services and what they collect

RIght - that's why I suggest to have a SIG or WT with people like yourself that know what to look for. A small group of people that maintains an overview, and coordinates efforts with other WTs and board.

I think a work team

This all might be me being overcautious, based on a lack of understanding - if you see a way to shorttrack things, that's also fine by me.

so indeed, you need iteam for inventory, someone the leads the effort, and in any case the Secretary should be involved

There are probably helpful 10-step plans out there, but I haven't looked at that at all

I'm unsure if we can volunteer the Secretary for a WT, but we can at least ask the WT to inform the Secretary. 🙂

Ralph, would you mind spearheading that team?

you seem to have a good grasp on tings.

things*

On the involvement of the Secretary, probably yes we can volunteer him:

Section 6.7 Secretary. Unless provided otherwise by a resolution adopted by the Board of Directors, the Secretary shall keep accurate records of the acts and proceedings of all meetings of the Members and Directors. The Secretary shall give all notices required by law and by these Bylaws. He or she shall mail to all Directors within thirty (30) days after each meeting copies of all said actions and minutes of said proceedings. In addition, the Secretary shall have general charge of the corporate books and records and of the corporate seal, and he or she shall affix, or attest the affixing of, the corporate seal to any lawfully executed instrument requiring it. The Secretary shall have general charge of the membership records of the Corporation and shall keep, at the principal office of the Corporation, a record of the Members showing the name, address, telephone number, facsimile number and electronic mail address of each Member. The Secretary shall sign such instruments as may require his or her signature and, in general, shall perform all duties as may be assigned to him or her from time to time by the Chair, the Executive Director or the Board of Directors.

Note the part on 'corporate books and records'

Let's aim to have a mission statement / member list ready for next week, so that we can procedurally establish the team.

But of course we should ask Alex how he can help us on this

seems reasonable

Ok then, I guess we should move on to the other part

4. GDPR XEP

(I don't have much more time to spend today)

Oh, it is that time already.

as for the XEP: what are downsides of publishing such a XEP?

Well, in principle it is unclear if the XSF should publish a specification that would give guidelines in direct relation to the GDPR

I'm not familiar with US law, but the concept of Legal Advise is a apparently a Thing

Advice even

what is "giving legal advice" ? Does publishing that XEP qualify?

Well, in the state that it was in last week, there wasn't much in there yet

I haven't checked since

It's a combination of factors - for example, in some places you need to be licensed to practice law

But I think it is more important for any such document to provide general guidelines in terms of knowing what you process and what things to take into account to ensure privacy for your service, and leave the rest up to people who Know Things (typically lawyers) for actual compliance

It's a stretch, but if it was taken as the XSF is giving legal advice without being qualified to do so, that's illegal in those $some_places

My perspective is that I'd prefer to help the XMPP community by providing information, as long as a) we're not opening ourselves up to liability, and b) we can somehow be reasonably certain that we're not spreading misinformation.

and separate from this issue, but similar - someone could try to blame the XSF if they followed published advice but got fined under GDPR

There's a huge gap between practice law and give information

Right, so as Peter has suggested, and I agree with, I'd like any such document to be actual best practices, not related to any particular legislation

that's reasonable

Me too

ok, I need to be going now

can we pick this up next week?

Sure

4. Date of Next

+1W

5. Close

Thanks all.

Thanks

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

woah, I alt-tabbed for two seconds 🙂

thank you 🙂

☺

Also, I'm sure I used 4 two times, so whoever is making the Minutes (*wink*) should take that into account

would not it be possible for the XSF to hire some legal advisor to create a document? I mean this is expensive for a single project, but if XSF is hiring one describing general helping document, we could do some kind of crowdfunding among XMPP community. Maybe FSF have some helpful contacts

I'm pretty sure I've asked years ago on standards@ if an IQ send to the own bare JID is semantically equivalent to the same stanza without a 'to' attribute, but my google-fu is not strong enough to find that thread again

The answer is "yes". Also "no".

It is the same, except that there's some odd text still lying around that hints otherwise, like that roster queries must be no-JID (rather than bare-JID), maybe?

I feared that this was the conclusion back then

Can we have that odd text accidentally dropped down a well?

would a MAM IQ to the own bare JID be equal to the same query without to attribute?

flow: Yes.

*without 'to' attribute

As far as I'm concerned, and Prosody is concerned, yes

Prosody treats to=own bare jid identical to missing to

Can we just get rid of missing to and missing froms

In fact, it removes the 'to' and uses its absense for security related things

daniel: make them mandatory always, like on s2s?

Zash, interesting, care to elaborate on these "security related things" that you get when you handle stanzas without 'to'?

daniel, in a way I prefer it, you know this stanza isn't going anywhere

Zash: yes. If you want to send something to your account you have to address it

And vice versa

flow, these stanzas are typically special in most XEPs (from user to their own account), they are privileged and Prosody handles them separately from normal stanzas that are to be routed

daniel: I want the opposite

and we normalize the to/from to 'missing to' so that there can't be any JID normalization accidents in modules

And then it bites Ge0rG right in the carbons

MattJ: but if you address your server the stanza isn't going anywhere either...

For some definition of not going anywhere

MattJ: Do you do some sort of NAT to get the right address injected when you reply then?

Kev, 'from' is always set, and that's what we reply to

and 'to' is not needed on c2s streams

Because replying to a to=bare stanza with missing from isn't ok. ✏

to and from should default to the entities on each end of c2s streams, ie the client and their account

Obviously from and to are swapped in any reply

One has to be fairly careful when claiming anything is obvious, when talking about this ;)

Kev, why is it not ok? missing from is identical to comes from bare jid, isn’t it?

client sending <message> == <message from=ownfulljid to=ownbare>

(missing from when server sends)

oh okay, MUST include the from attribute

I am /pretty/ sure that I’ve seen servers which do not do that.

I have ugly workarounds for that

ah, no I am at the wrong place in the text

Whowhere?

3. When the server generates a stanza from the server for delivery to the client on behalf of the account of the connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (a) not include a 'from' attribute or (b) include a 'from' attribute whose value is the account's bare JID (<localpart@domainpart>).

Kev, so, there’s no NAT needed, just don’t emit the @from in the reply ^

Zash: hoover?

jonasw: Yes, but if it's a reply to a stanza the client sent, the server must swap the to/from.

🕴

You can't, as a server, receive a stanza that is to=bare JID, and reply with no from.

Kev, says?

The holy text.

MattJ: 6120, somewhere.

e.g. for error stanzas "The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza"

That's a stretch to say it applies to all stanzas, as you're saying

Yes, that was just the quickest thing to find.

I think the text jonasw pasted is pretty clear that the server has two valid options

Yes, but not clear that both are always right.

Then that text might as well be removed, and let the text you remember specify what the 'from' should be

Kev, ok, then I found a server with a bug.

because that’s why I needed workarounds (because servers did exactly that)

ah, well

if the swap is only a SHOULD, I can see this to be an exception

I can't find the odd text about rosters now on a quick search either, so there's clearly text I'm failing to find.

jonasw: We have handling too, in https://github.com/swift/swift/blob/master/Swiften/Queries/Request.cpp#L79

(In fact, we have further workarounds for ejabberd issues where they used to reply with full JIDs)

oh yes

I love those

hey, i just setup my own xmpp server

Welcome to the cool club. Or something.

:)

yeah, i just can't get omemo to work on ejabberd

As far as I remember omemo is disabled by default in ejabberd, but you may check in ejabberd room

xmpp:ejabberd@conference.process-one.net?join

Ge0rG, chat.yax.im down?

jonasw: works for me

yeah, it just had a few minutes of hangup

17:04:14 <--- You (jonasw) left the room (the MUC server is not responding) 17:07:17 ---> You (jonasw) joined the room

(or maybe it was just the link between us. who knows)

So MIX proxy JIDs... if someone creates a MIX channel that is <1023 bytes>@mix.example.com... what happens to the userid part?

"boom"

I imagine servers simply wouldn’t allow that

So how long is the generated id?

probably service-defined

It's such a hack

do you have a better suggestion?

Well instead of overloading what should be an opaque identifier why not re-use a mechanism that is already in the protocol as a secondary identifier behind bare JIDs?

because that leads to the same situation

just in a different part and with different moving parts

with Kevs variant (1), the multiple pieces are in the nodepart, with variant (2) the multiple pieces are in the resource

so both are bad w.r.t. that

one way out of that would be to use $service-wide-user-id@$service-domain/$resource instead (so the MIX identifier wouldn’t be part of the node at all). but that requires to have the JID of the MIX inside the relevant stanzas

All existing routing, libraries and... everything already knows how to correctly split a JID

true

and I think that the semantics assumed with "bare JID" work better with variant (1) than with variant (2)

Trust me, someone will want to implement some higher-level logic to know which messages are associated with a MIX channel

Except with variant (1) you can't really do that

You have to know it *is* a MIX channel, and that you have to strip the bit before the #

Block a MIX channel? Ok, but messages from participants would still reach you

and other people want to have high-level logic to konw which messages are associated with a MIX channel occupant.

any kind of filtering or logic based on the channel JID now almost always will need to be adapted to look for the # part

we should’ve followed email and allowed multiple @s in addresses

Yes, that would really have helped... :)

so now nobody knows what an email address actually is, but everyone has their own idea that's good enough for them

Pretty much what's going on here, to be honest :)

The # is the extra @ to the entities that can see it

To the others, it's not and it's weird

the variant (2) would make things worse than MUC actually

Can you (or someone) lay down the reasons for that?

didn’t I?

I didn't see if you did, /me checks

but the point which I just realized is, that with variant (2), there’s no single JID which will ever occur in a message identifies an occupant

so if you wanted to filter all messages from an occupant, you’d have to know that they’re MIX messages

to split them correctly

kinda the same issue you describe with MIX channels in variant (1)

Hmm, what do you mean?

for example, presence

and avatar hashes

I keep those in a cache, usually keyed by the bare JID

which I can’t do for MUC, I have to use the full JID, but that’s okay

(I actually have to break layers to detect that a presence is MUC related at that point)

now with MIX, it’s worse, because not only do I have to check that it’s MIX-related, I also have to use a non-RFC6122 splitting function on the JID to determine the cache key

i.e. do determine the identity this JID belongs to

really, the same thing you described earlier, just with occupants instead of channels

Right

I think your issue is more server-side and my issue is more client-side, actually, and that might be why we see them strongly each

(clients may be more interested in occupant identities, while servers may be more interested in channel identities because that’s the granularity they work on)

So how do you know it's a MIX message and you need to split the nodepart? Payload?

yes

Strawman proposal: - proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart - resource as usual - MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example/client-resource" to="user@other.example" type="groupchat"><mix channel="..."/></message> ✏

Heh, part of me wants to dislike that, but I prefer it

I feel like the security aspects need to be investigated here though

that’s not how straw-mans are supposed to work

which part exactly?

Well you need to verify the service in every case, I think

what do you mean exactly?

Otherwise I register mattj#rocks@jabber.org and send you a message wih a MIX payload

and then?

Don't know, currently I got as far as "your client breaks"

the client or server would drop it because it doesn’t know about a MIX rocks@jabber.org

just like we currently drop type="groupchat" from MUCs we don’t know.

Right, the whole "participant's server needs to know MIX" thing

at least we’re honest about it this time (not like with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames) ✏

I like your straw-man because it opens up the possibility for a user on a MIX service to have a stable JID across multiple channels

I’m not sure that’s a good thing

but mmm, it could be

it makes it more difficult for MIX services though

How so?

when I send a message to ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example, they need to verify that I share a channel with them

(or may need to, depending on the service policies; but I assume that this is how most services will want to operate)

hm, or we require <mix channel="…"/> elements even in non-groupchat messages

then the sender would assert through which channel this message shall be "tunneled" and the server would not have to form the intersection of both channel lists

question is whether that’s reasonable

Totally if you ask me

so I’ll post that to the list now

Variant 3! Thanks :)

Advantages: - No re-write of resources - Bare JID refers to occupant identity (good for clients) - Servers can simply filter on message/mix@channel - Opens up the possibility of re-using the same proxy JID for the same occupant across different channels (may be useful in some deployments, via MattJ) Disadvantages: - All (including 1:1) stanzas exchanged between occupants require the <mix channel="…"/> element for MIX channels to be able to easily route them - Entities filtering on MIX channel identity still need to know about MIX (and the <mix channel="…"/> element)

did I miss something?

sent

Sorry, lgtm

I'll reply properly onlist in the morning, but now you need to do DPI to be able to do routing in your client, because the routing information is no longer in the header? That's terribly unpleasant. ✏

i.e. I think option 3 is the worst of the three.

(And possibly worse, your server needs to be doing DPI in order to make archiving work)

Kev, don’t you need to do DPI anyways because you need to be sure you’re looking at a MIX message?

(otherwise, the "MIX JID splitting function" (whatever that is) would operate on non MIX JIDs and possibly yield wrong results)

No, you don't :)

servers need to do DPI anyways today for archiving to work.

Not at this level.

normally, type="groupchat" isn’t archived at all, right?

That obviously has to change.

for MIX, yes

type=groupchat to the bare JID gets archived.

(Once routing/archiving rules are fixed)

right

that would work

I have to sort out bins and then go to bed, but I think option 3 has worse issues than the conflation in option 1/2.

looking forward to your reply

and the discussion :)