XSF Discussion - 2018-04-10

Kev: is there any progress on the 0050 PRs?

There isn't.

Kev: any more ideas regarding the pidgin re-addition to the client list?

I haven't given it any thought, do I need to?

I wonder if it's possible to instrument something like shodan to search for XMPP servers.

Sure

I mean, we need to send the client banner first, right?

I've used it to discover Prosody instances

MattJ: oh, that's interesting. Tell me more about it.

I don't know exactly what it sends, but it triggers an error response

Prosody's particular error message is unique, so searching for it yields results

`GET / HTTP/1.0`?

Quite possibly

I suspect it understands XMPP somewhat though, but obviously you can't determine the host from the IP address so it still doesn't work

gdpr meeting in ~5

what

crap

I totally forgot

I need to marinate some meat first, so I’ll be a bit AFK-ish

it's 12:30CEST right?

yeah

hehe

taking the laptop with me

Ge0rG, winfried, ping

Guys, sorry, I will be the available in 10 minutes

I'll put stuff on the wiki then, I sent the minutes quite late yesterday

sounds good

10 minutes for me as well

what a perfect fit

pep.: 👍

Hmm, so we already had a bit on 1.1c for s2s in the wiki, not as detailed

here I am

AOL!

It looks like we all might be there.

yes

.

!

*bang*?

baaang

winfried, are you going to chair?

*bang*

do we have enough on 1.1a-c?

S2S outbound on 1.1c?

did we cover that?

I guess the inbound covers more or less both actually

what happened to transports?

Ge0rG: yes, noticed that one too

transport will be a processing to cover in c2s too!

1.1c inbound and outbound is symmetrical, i.e. there is no need to differentiate. we need to differentiate in 1.1d though

yesx

fair enough

With the note of transports, I think we should move to 1.1d, where the fun begins...

winfried: do you have an update on the "third contries" part?

Ge0rG: yes

criteria: 3.2a offering services to EU citizens or 3.2b monitoring behaviour within the EU

I’m fully here now

3.2a: just offering in english or so is not enough, but a multiple of factors like english and accepting euro's and shipping to the eu is

winfried, what would the equivalent of "shipping" would be? not denying service?

jonasw: with a service like XMPP it is quite tricky to judge

yeah

winfried: oh, that's too broad. I was asking about s2s connections from the EU to third countries.

Ge0rG: ah, ok

Ge0rG: that one is quite clear cut, is chapter 5

First the laws of said country have to be deemed adequate right?

winfried: chapter 5 is rather long. Can you provide a TL;DR, as this is going to affect s2s

chapter 5 has different grounds, adequacy is just one of them

(adequacy is art 45)

pff, I don't want to imagine an implementation for that

diving further in my bible....

Ah, so transfer to "adequate" countries does not require any additional measures

Ge0rG: correct

yeah, art45

45.1

art 46: other possibilities are: Binding Corporate rules (when transfer inside one cooperation) (art 46.2b)

so adequate and EU countries are the same category for s2s

winfried: 46 probably doesn't apply.

Ge0rG: because?

doesn't it?

Unless your implementation forbids s2s to non-adequate third-countries ✏

winfried: or at least the contract/same-corp provisions of it

unless all xmpp servers are operated by the same BigCorp

that's 47 right?

Ge0rG: correct BCR (46.2b) doesn't apply

Ah 46.2b right

that refers to 47

46 is written in legalese, and I fail to parse it right now

isn't all

yeah, I really need my bible here...

46.2c is interesting: standard clauses

pep.: no, other parts are more appropriate

So we're trying to figure out if we'll have to filter out s2s right

winfried: I suppose 46.2c means something like safe harbor/whatisitcallednow

And/or how much ✏

pep.: right

That is really meh. Who was talking about trying to reach email people again

See how they cope with that.

no, safe harbour is part of the EU-US adequacy decision: "if you keep to privacy shield, it s adequate"

"Hey users, you can't reach half of the planet from now on"

winfried, how is this privacy shield defined?

hmm, what about 49.1a?

AFAIU third countries are also covered by user consent

yes just what I pointed out I think

privacy shield is a (before GDPR) construct to legalise EU-US transfer, saying: when keeping to privacy shield, then the protection in the US is adequate and permitted

I’m trying to find a clue about it in the google privacy policy atm

(And Schrems finely argued it was not adequate becease the NSA was left out it)

So now al companies leave adequacy as ground and use standard clauses

I'd say article 49 applies quite a lot

so, there’s nothing in that

(that = google privacy policy)

with respect to federation

I begin to suspect that the following applies:

jonasw: you just found an interesting legal gap at google ;-)

jonasw: sue them!

1. the user has a clear intent to share a message with a recipient when they send a message. 2. it is up to the recipient how they handle the data. this includes whether they consent to it being stored on their server and for how long

winfried, they have more laywers than you will ever have

now how that works in the light of germany’s whatsapp decision, I don’t know.

jonasw: I tend to agree with you here, however... by sending a message you only show implicit consent in that the message is to be delivered to the recepient, not that it shall be analyzed to create a profile of your sex life.

pep.: yes, but for example when analysing Microsofts new terms, I found over a douzen issues that were violating EU law

Ge0rG, that’s true, but if the receiving party consented to that?

that’s a matter between you and the receiving party then, isn’t it?

I mean the receiving party could also simply upload all your messages manually to some service which does that to gain some moneyz.

jonasw: yes.

so nothing which concerns server operators?

interesting

jonasw: the receiving party must gain your consent to process your data.

but that’s #notourdepartment?

yes

Ge0rG, by subscribing?

so we can simply not give a fuck?

Or joining a MUC, or ..

I don’t think that subscription is consent for any level of advanced processing.

49.1b may be very applicable here

not for art 9.1 type processing at least

jonasw: maybe. Maybe we need to explicitly tell the user that their messages might leave the EU

winfried, if 49.1b is not enough, there's still 49.1a

Ge0rG, 49.1a then

explicit consent

Ge0rG, mmm, I feel that this might be a reasonable assumption.

like, if you send a message overseas, it’ll be overseas, period.

however, it’s unclear that you might send a message overseas when I send a message to somebody who is in e.g. sweden but has an account at $USProvider

I fear users do not know if it will be overseas, but we can just state the possibility in anycase

I'm pretty sure we can argue that 49.1b applies here: you have a service contract with the XMPP server, and if you want your messages to be sent overseas, the server will happily do so

jonasw: $USProvider is subject to GDPR then.

pep.: my reading is you need one of 49.1a-49.1g

winfried, yes

I think c applies

if 45 and 46 don't apply

jonasw: I don't thing 49.1c applies here

jonasw, as in, contract between server operators ?

49.1c needs a contract between server operators and it needs to be in the interest of the user. Mainly the first one is problematic, the second one may be

I think that 1b is better applicable here.

Well we don't have to settle on one, unless it's 1a

If both apply, great

49.1b says (more or less) and analouge to 6.1b: when it is needed to perform the request of the user

Yup.

yes

and that one is quite clear: we federate and transfer on request of the user

Ge0rG, oh indeed I misread

Indeed, I only have that s2s connection if a user requests it

49.1a feels a bit like a minefield to me

So I'd argue that transfer of content is covered by 49.1b because the user wanted the content to be sent to wherever, and meta-data is covered because the user wanted to subscribe or somesuch.

Ge0rG: +1

Seems good to me

It might be a good tech TODO to have that written in the data policy.

people that you approve as contacts will be able to see your online status.

Ge0rG, mmm, with subcsription I’d argue that some things aren’t obvious.

ah, that’s what you meant

makes sense

jonasw, I think we ought to make them obvious in the policies

jonasw: let's make a list

Ge0rG, ack

1. vcard avatar is always publicly visible

2. pep avatar and other pep things are most likely visible to your contacts. what things are there, besides avatars?

jonasw: vcard avatar is public data. maybe good to have a separate category for that

3. last online timestamp, status message, online status, list of online devices

list of online devices also means things like software version btw

because if you know the resource, you can IQ

jonasw: I think that #2 is actually well covered implicitly. If you "play a tune", you want that to be shared with your friends

possibly

it’s the clients job to make that explicit at least

I don't want to open _that_ can of worms

yupp

that’s fine

let’s focus on what must be done on the protocol/federation/server level.

so we need two lists: things shared with everyone; things shared with contacts

Ge0rG: yes

the latter might contain surprises to the user.

with everyone = with everyone who knows your JID

And things not shared, as in credentials etc., even if obvious

Ge0rG: you can assume a JID to be publicaly known

Ge0rG, maybe define "everyone who knows you JID" a bit more? contacts, non-anon MUC owners

winfried: can I?

other server operators

winfried, I don't think so

"contacts, chatrooms and their server operators"

don't know if that discussion is *very* relevant here/now but in practice most people publish their JID, so they can be contacted...

winfried: if you publish your JID, your JID is obviously public

winfried: but what if not

I'm going to go soon-ish, starting to get hungry

This list falls under things to be transparent about in the privacy policy then

pep.: yes, it's for the tech TODO

yep

+1

so do we have 1.1d covered now? ✏

with the remark of sensitive data or not

right.

(LQ1)

Ok

the Sword of GDamoclesPR

Can we plan next?

yes

I will try if I can get some opinions on sensitive data in some lawyer groups I participate in

I’m sure it’s sensitive data. I’d just like to have clarification on if simple store-and-forward (and no analysis) brings us into 9.1 realm

jonasw: exactly

neat

so, date of next?

my constraints shifted and I’m unavailable thursday this week

not tomorrow if possible

Fri noon?

friday would wfm, something like 10:30 CEST -- 11:30 CEST e.g.

so friday?

I'm not available in the morning

is 10:30 still morning at yours?

yes

I see

I'm blocked after 1300CEST

before 12 is morning :P

hmm

mmm, I can’t promise 12:00CEST

pep.: set up an alarm :P

Ge0rG, I have paid job to do

In between :p

yeah, right :P

Friday I am available between 12:00 and 13:30 CEST

I can do 9:30 here, 8:30UTC

if it doesn't go more than an hour

jonasw: take your laptop to the lunch break? ;)

it never went more than an hour!

Ge0rG, lunch break people won’t approach

*approve

wtf is wrong with me

ok so 10:30CEST

In the end

10:30 CEST on friday, ACK

winfried> Friday I am available between 12:00 and 13:30 CEST

oh

welp

hmm

otherwise, next week same time as today would work for me too

OK, when doing some magic with my schedule, I can be reading from 10:30 but only be (really) active from appr. 11:00

Sure, Mon, Tue workforme

we need to get this settled soon.

Fri I'm not here from 11:45 CEST to ~12:45 CEST

I blocked friday 10:30 CEST, and I blocked Tue 12:30 CEST, I don’t care which you chose :)

Tue 12:13 CEST is fine by me

Tue wfm (more or less)

What works better?

Tue

Tue when?

after 9:30 CEST

I can do 10:30 CEST again on Tue, or anytime after that

Ge0rG, 12:30 CEST on Tue?

can do

then it’s settled

Tuesday 12:30 CEST

:)

what do you call morning btw? if it's not before noon

hmmm, in german there’s "vormittag", which awkwardly translates to pre-noon.

Ok, I know in quebec they also have this weird notion of early morning and before noon, but in france I've never heard that

(french quebec)

it’s not particularly weird, considering we have the same for after noon

Sure. Though in usual my mornings are pretty short anyway, so just having one word is fine by me :P

pep.: lol

morning is the time between your first coffee and being awake.

what's in a word!

Ge0rG, can that also include noon?

Ge0rG: So morning == afternoon?

even more weird are the swedes, where "middag" is both dinner and noon. eftermiddag is only afternoon, but not after dinner.

:D

Ge0rG: that is never in my case, I don't drink coffee and I am never awake :-P

"förmiddag"

winfried: then you have an eternal morning?

I'll try to send the minutes today. And update the wiki after that

the morning that never ends?

Zash, do you have a highlight on "swede"?

Ge0rG: welcome in my life ;-)

jonasw, he has a highlight on "coffee"

MattJ, that makes sense

A highlight on "highlight"

is dwd saying "do a PR, because a vote without PR isn’t really useful at all"?

if so, I find that hard to get from that email :)

Well, he's not instructing, but... yes

Voting on "X is a nice idea" and "PR X is good to merge" are different things. But I imagine Ge0rG would rather not work on a PR unless the council indicates it would be in favour of the idea of removing GC1

What MattJ said.

I can only imagine that Dave assumes I'm not sufficiently familiar with the Council process.

or maybe is confused by your attempts to vote to abolish pidgin ;-)

I don't *think* Dave's mail says that.

I *think* he's just observing that the vote has no practical effect, rather that that it's a bad idea to have the vote.

The practical effect will be that I'll get green lights on preparing a PR, and maybe even some Feedback From The Elders.

Ge0rG: That's not an effect of the vote, though, that's an effect of us discussing it.

Obviously, a Council member could decide to lure me by +1ing the general principle vote and then blocking any follow-up PR, but I don't hope this is going to happen.

I think the vote's a sensible thing to do, as a forcing function for discussion, but it doesn't achive anything that the discussion without out a vote wouldn't.

Kev: there is actually one outcome I'm looking for: Council consensus on removal of GC1.

Kev: if we don't manage to achieve that consensus, I'm not going to prepare a PR.

I think that's very sensible.

Which probably wasn't crystal clear from my e-mail.

And I think a vote as a forcing function on the discussion is sensible, too.

Just that it's not really *necessary*.

Right.

I'm painfully aware that if the vote is accepted, we'll have a second vote on the subject matter of the PR.

Even my mail to standards@ can be used to discuss the motion in the wider community.

I'm against it on the basis of having been reworking M-Link's MUC implementation recently and I implemented and tested GC1 joins :p

(No, I'm not really)

Kev: you have nobody but yourself to blame. I've clearly stated my goal of burning GC1 half a year ago

I'm not opposed in principle, but I do think we should have a story for how to address the 'just fix out of sync' that GC1 currently works for.

Kev: "works"

Kev: It does the opposite of fixing anything.

It's not good, but it *does* work around some things at the moment.

e.g. if you've desynched then at least a presence broadcast means you start getting messages again.

Kev: You'll still be desynced

We should describe how to detect and resolve those cases at the same time as getting rid of GC1.

As in, your view of the participant list may be outdated.

Zash: You will. You'll also be receiving messages.

I think I made multiple proposals back in October.

I could make an even more revolutionary one: let the MUC respond to self-pings by a participant.

Kev: True. Sending a full join bundle would help in that case.

Zash: not quite

Ge0rG: Assuming clients understand "ok, forget everything, here's the current state", which might need adding

Zash: because you'll end up with zombie users in your participant list

Zash: yes. Assuming there is some kind of marker in the stream telling the client when to forget everything from before

which there isn't in the normal join bundle

Correct. So Kev says we should address that.

Returning an error and making the client rejoin does have the same end result tho, at the cost of a roundtrip

Zash: except that most clients suck at rejoining.

Zash: somebody could implement a server-side MUC bouncer that hides all of this from the client.

Ge0rG: *ahem* mod_minimix?

Zash: I don't appreciate that name very much, but yes.

Naming things is hard

Zash: also I had a brief look at the source code and decided not to load it on yax.im

Ge0rG: Sane choice.

mod_minix -- run a minix inside lua and own all your traffic

mod_mimimix -- complain about all attempts to join MIXes in the logs

mod_mixtape - play low-quality music whenever somebody joins a mix

Hold on, how do you trick a MUC into subscribing to your presence?

Oh. Hm.

Right, adding a MUC to your roster doesn't imply much.

I wonder what happens if you send a subscription request to a MUC

My concern is that things are bad with desyncs, and we'll make them worse by just stopping doing gc1.

And on a Draft XEP that's not on.

Kev: we'll just make clear how bad it actually is.

Kev, silently losing messages (what we currently have) is worse than explicitly dropping out of a MUC.

Kev: but I'm open to suggestions how to transition into the new world of awesome MUC without causing regressions

jonasw: And that's not what's on the table.

Kev, it’s not?

jonasw: What's on the table is silently losing some messages vs silently losing more messages.

Kev, no, you don’t *silently* lose more mesasges

the user and client are aware that they’re losing messages, which isn’t the case with a silent pseudo-resync which happens on accidental GC1.0

are aware that they *were* losing messages,

Ge0rG, true.

jonasw: But how many existing clients are dealing with whatever behaviour we're moving towards?

So in the end "user must explicitly give consent to treatment of his/her data by 3rd parties (receiving) when using s2s" is legally covering glad we got to that at least.

Kev, if the MUC replies with a "kicked" status code, every single one I think.

jonasw: I'm not opposed to fixings, but we do have to be sure we're actually fixing them.

jonasw: I really dislike "kicked" as opposed to a presence-error

jonasw: Great, so the user isn't getting messages and eventually they might wonder why that tab has gone quiet and look why and see they left 3 days ago.

jonasw: because a sane client won't auto-rejoin after being kicked

Ge0rG, kicked + 333 maybe?

jonasw: that's not backward compatible to clients not parsing 333.

Ge0rG, I’m not sure if clients handle type="error"

jonasw: I'm speaking of "sane" clients.

Kev, dunno, I’d *expect* clients to tell me that I got kicked out of a MUC.

Ge0rG, me too

so are we discussing MUC or what the new lighter MUC will be

Ge0rG, have you made a survey how many handle type="error"?

Anu, MUC

Anu, uncertain.

Kev: yes. It's better to see after three days that you got kicked than to lose three days worth of discussion and then silently rejoin

ah

Ge0rG: except probably you don't lose 3 days of messages under gc1, because you will have silently kinda rejoined.

Anu: I've stirred some controversy on the standards@ ML

I'm not saying gc1 is a good thing.

Or arguing that it should stay.

Kev: maybe you only rejoined after two days.

I'm just saying that it's not clear that we yet have a story for what happens next.

And why auto-rejoining is insane?

🤔

Maranda: it isn't, unless you were just kicked

Group chat (as people expect it) is such a solved problem. In my honest opinion, we should probably spit up the IRC clone from the kind of group chat people use today (which is more of a distribution list)

Anu: yes, but then everybody wanted their favorite feature in and we ended up with MIX

MIX?

Anu, XEP-0396

eh

Anu, XEP-0369

Anu: https://xmpp.org/extensions/xep-0369.html

good bot Ge0rG

It's MUC with the issues fixed.

Kev: that's the optimistic view.

-xep 369

Maranda: Mediated Information eXchange (MIX) (Standards Track, Experimental, 2018-03-18) See: https://xmpp.org/extensions/xep-0369.html

I'm not convinced that MIX actually solves the problem we are talking about (s2s desync). All it provides is some hand-wavy "use MAM"

-xep 396

Maranda: Jingle Encrypted Transports - OMEMO (Standards Track, Experimental, 2017-11-29) See: https://xmpp.org/extensions/xep-0396.html

Ge0rG: I think that's right, actually. We do need to get the MAM resync in there.

:O

yeah, MIX is in the state of "silent message loss", but with better recovery times than MUC

jonasw: recovery times? I don't see no recovery times in MIX

Ge0rG, in theory, each message stanza would trigger an s2sout attempt at the MIX side of things.

Kev: so I assume your statement should read "MIX is MUC with additional issues." :P

which is *probably* better than what happens with MUC-GC1.0-pseudo-resync which only happens when a client happens to update its presence.

MIX fixes the resource part abuse.

And the long-term join.

And the multi-client.

everybody loves core dumps

Stick a state somewhere in that last sentence

jonasw: I'm not sure this is a real problem. And if it is, I'm not sure that abusing the localpart of the MIX JID to contain two fields is a good solution.

Kev: we can solve multi-client long-term join in MUC without touching a single line of XEP.

Agreed

I'm quite sure that's not true.

All we need is a bouncer on the user's account that syncs with 0048.

Ge0rG, it doesn’t shake the concept of "same bare JID == same identity", which is good enough for me I think

Or 0402, or whatever.

As long as we have full-JID sharing, iq is going to be broken.

yeah

jonasw: except in MIX you have a 1:N relationship between identities and JIDs over different MIXes

Although I'm somehow also sure somehow "bncs" will also be a cause of nuclear meltdowns

Ge0rG, I’m not sure that matters much.

Kev: what are the IQ use cases in MUC?

Any time you want to do anything that involves an iq.

Ge0rG, initiating a call with an occupant (not the whole MUC)

So the same as non-MUC.

Kev: and self-references are self-references.

The only IQs I'm actively using are (self)ping and version, and I just made a proposal to fix #1 and I can live with the ambiguity of #2

desync = netsplit ?

Anu: kind of.

Anu: https://mail.jabber.org/pipermail/standards/2017-October/033501.html has an in-depth explanation

Ge0rG vcard:temp also

Maranda, vcard:temp is on the account, not on the resource ✏

And time

so that’s about the one case where it doesn’t matter in MUC :)

We should all just use EF net and be happy

What? Hmm is there a difference jonasw?

Maranda: yes, in MUC you query the full JID for the vcard, and it gets routed by the MUC to the account of the participant

jonasw: No, actually, vcard:temp is another example of iq being broken.

Because it should go to the full JID of the occupant, not to their bare JID.

Kev, wha?

ITYM the other way round?

So all* MUC implementations have some special casing to detect a vcard and send it to the wrong place (bare JID) instead of the normal routing rules [*probably].

Kev: so there is a viable workaround for that.

ah, "should" in the sense of "the normal routing rules"

Ge0rG, so we wanna staple further workarounds onto MUC for every IQ which might ever need to go to the bare JID?

Waiting for cell to return ™️

jonasw: I'm sure the incremental overhead is minuscule.

Ge0rG, but the adoption delay?

and the difficulties for new implementers.

and of course, the client code which needs to special-case requesting stuff from MUC occupants.

jonasw: write it down in 0045.

you mean like the vcard:temp hack is written down?

jonasw: the special-casing in my client is just in two places :>

jonasw: dunno. I'm not a server author. I'm busy enough keeping 0045 usable for client devs.

Well iq routing has always been hassle in muc, e.g. who do you send to on ping, version, time etc

a.k.a. not my department.

In case of shared nick

😎

Maranda: I suggest "highest priority"

Maranda: Yes, that's one of the things that's fundamentally broken with MUC addressing.

no, "most available"

I suggest least mobile

Least mobile 🤔😆

And no hacks aren't written down e.g. Multi resource nicks

Maranda: PR the XEP!

Ge0rG I would use someone more literate than myself english wise

😜

Maranda: just don't plaster it with Emoji :P

#18.1.2 Ghost Users 👻

#5 Roles, Affiliations, and Privileges 😱

Mobile Chrome even hangs browsing xeps

🤔

I was going to suggest status code 666 for the Ghost Rider.

Or maybe the GOST Rider. zinid and Andrew would appreciate that.

666 which in reality is 999

edhelas: great idea. And then I quit XMPP and everybody's clients go offline

then I'm adding "Ge0rG MUST stay online" to the XEP

edhelas: I'm not sure you need to write that into the XEP, it might suffice to get a Council vote.

I'll request XSF funding for a multi-homed redundant-hardware HA cluster to run my poezio.

Oh, wait. poezio needs restarts as well. I will request funding to develop a new client written in Erlang.

Maranda, regarding english literacy, that’s the editors job when in doubt

😲

jonasw: I didn't want to say that, knowing that the editors are pretty busy

Ge0rG, that’s no reason not to say the truth :)

jonasw: while you are there... I have some pending PRs :D

Ge0rG, I know that

I have a pending PR mysefl

but unfortunately, what you were saying is also true ("the editors are pretty busy")