XSF Discussion - 2018-03-26

When is it legal to send a message _from_ a bare JID?

Ge0rG, as a client, you can’t

a server will do that when the message is "from the account", like MAM responses or PEP I think

I'm receiving spam from a bare JID.

what

goofy server I’d say

-version bnw.im

Ge0rG: bnw.im is running BnW version 0.1 on OS/360

RFC 6120 is rather clear on that: 1. When a server receives an XML stanza from a connected client, the server MUST add a 'from' attribute to the stanza or override the 'from' attribute specified by the client, where the value of the 'from' attribute MUST be the full JID (<localpart@domainpart/resource>) determined by the server for the connected resource that generated the stanza (see Section 4.3.6), or the bare JID (<localpart@domainpart>) in the case of subscription-related presence stanzas (see [XMPP-IM]).

Spam Server!

I can’t into cyrillic

seems to be some type of social network thing

All the spam is into cyrillic.

Looks like 4chan

-ping jabber.org

-ping conference.jabber.org

The host seems to not be reachable.

yeah

This is an example of why it's good to have our MUCs spread over multiple servers. We can still talk about downtime

DMUC!

or FMUC?

did anyone think about how to integrate federation in an extension to MIX?

BOMFUNK!

or maybe just cluster MIX services

Ge0rG, Boomfunk MCs?

I've been thinking about FMIX, but I think we need to get "vanilla MIX" sorted first

Steve Kille, agreed

J.org was going to be clustered, but we just never got around to it.

Ge0rG, https://www.youtube.com/watch?v=ymNFyxvIdaM

jonasw: one of my favorite pieces of 1990ies music.

Ge0rG, :-)

oh, too many os

gotta fix that in my music library

Ge0rG: Ping failed (remote-server-not-found): Server-to-server connection failed: closed

Ge0rG: Ping failed (remote-server-not-found): Server-to-server connection failed: closed

Wow, Bunneh has some serious timeout issues

Ge0rG, it’s just diligent

Ge0rG, just in case you host your server on your mobile phone.

I was shocked to hear that conversations.im has a 60 seconds 0198 ack timeout

that’s long or that’s short?

Those with IPv6 should be able to see c.j.o and j.o

Only the IPv4 connectivity seems to be dead.

I'm dualstacked. In theory.

hm,w eird

I’m dualstacked in practice, but it doesn’t work

into the debug logs!

my prosody was keeping an s2s connection and failed to send data that way.

after killing it, it retried ipv4, now ipv6.

My prosody was, as well.

I blame the SRV records

_xmpp-server._tcp.conference.jabber.org. 900 IN SRV 30 30 5269 hermes2.jabber.org. _xmpp-server._tcp.conference.jabber.org. 900 IN SRV 31 30 5269 hermes2v6.jabber.org.

why separate records for v6 and v4, and why prefer v4?

hm, my prosody does not try the next one after the first times out

might be my old 0.9.x version though

There used to be too many clients with ipv6 issues in the past.

intosi, servers, too?

IPv6 in general was an unhappier place five years ago, when these records were set up.

maybe a change is due

haven’t had issues (I know about) with dual-stacked records

Quite likely.

this would be a good time for change ;-)

There used to be a lot of Teredo links, a lot of them barely functioning.

that makes it a bit more funny that the v4 route aborts at an HE router…

also, turns out, grepping for jabber.org in debug logs isn’t htat useful. "[…]xmlns:stream='http://etherx.jabber.org/streams'[…]" and the likes

Mar 26 10:13:25 s2sout56531734a4f0 debug sending: <db:result to='conference.jabber.org' from='yax.im'> Mar 26 10:13:25 s2sout56531734a4f0 debug sent dialback key on outgoing s2s stream And then nothing happens.

So it looks like dialback is never completed, then timeouts

jonasw, I can into Cyrillic but this one is not meant to be easily understood by normal people

intosi, Kev: are you interested in further debugging why s2s over ipv6 still fails?

Ge0rG: thanks for the offer, but I can fully reproduce the issue myself at the moment.

It appears that hermes2, the host running jabber.org, has its IPv4 traffic blocked at its gateway.

Not blocked, but blackholed.

Your ISP switched you to DS-Lite, silently :P

That might be the result of excess ingress or egress connections earlier, I haven't checked yet.

Ge0rG, it's hard to get large packets as IPv6 through the big walls of a bunker

The IPv6 packets are actually getting through ;)

It's the tiny IPv4 packets that are filtered out :D

Tobias: I didn't know j.o is running on Bulletproof Hosting.

maybe they are too small to swim alone, and j.o is hosted on Sealand instead?

Ge0rG, winfried: +10min for me

!

?

hello

Hello

Hello

china ?

im china~

`

Hi,

sorry for being a bit late, had to fetch my luunch ;-)

winfried, !

I haven't had lunch yet.

jonasw said +10mn apparently

It's still 11am for me :-°

pep.: I know

(about jonasw )

Shall we start and check with jonasw when he joins us?

Some meeting going on now?

Seve/SouL: GDPR & XSF meeting

also good ;-)

I guess we can wait a bit, it's already :09 ✏

I'm close

here I am

!

welcome, should someone bang a gafel?

Sure

Ge0rG, jonasw, winfried, pep.!

*bang*

so, I‘ve got a few things

;-)

I think there are three questions at hand: Q1) What consequences does the GDPR has for the Jabber network and Jabber server operators and what can/should do the XSF with that? Q2) What consequences does the GDPR has for the XSF run Jabber server? Q3) What consequences does the GDPR has for the work processes of the XSF itself (membership, voting, wiki etc)?

if it’s okay, I‘ll just dump a few notes I took during a talk about GDPR for self-hosters at the chemnitzer linux tage

jonasw: go ahead!

it’s mostly a random collection of stuff which I felt was important

first some key articles about the rights of the subjects of the data: art. 13, 14, plus possibly 7, 15, 12, 16, 17, 21 and 20

Yes please. I also had a talk with out GDPR expert regarding self-hosting, so we should be able to align those

there are rights for transfer of data between providers, in article 20

some risk management articles: 5, and consent in 7 and 8, with proof

and the articles about notifying about data breaches, 33 and 34

and something about a directory of data stored, processed and shared supposedly detailed in article 30

as I mentioned, those are really just quick notes I took, I haven’t had the chance to look deeply into this. Those are the articles I plan to have a deeper look, and which might be most relevant. but IANAL

for the german folks: the speaker said that most of the GDPR has been german law for ages already, so germans have even less of an excuse ;-)

end-of-dump

winfried: do you want to chair this? Maybe we should split the three questions from Q1 into individual ones, and also put https://trello.com/c/t79C3Yds/307-gdpr-advice on the agenda

we might also want to look very closely at the legal definitions of Controller and Processor and Join Controller etc.

Ge0rG: if jonasw and pep. don't mind me chairing, yes

as well as the intent, which isn’t defined clearly

winfried, sure

the speaker mentioned that the intent as well as the separation of controller and processor or something can make a huge difference. he for example assumed that their company wasn’t affected much because while they have their users data (as a hoster), they do not directly work with that (so no intent of usage) and thus they’re not affected

he was from hostsharing.net fwiw (german)

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

I propose to take step beck: there is the legal discussion about things like jurisdiction, processor/controller, legal ground for processing, risk of data, transfer etc

but there is also a question about cooperation with the IETF for example on this

winfried: the IETF is facing the same problems we are?

Ge0rG: possibly, the IETF was mentioned in the mail to the board

(because someone mentioned it here, actually.)

winfried: do we know who at the IETF is working on it?

I have no idea

(how) should we collaborate with them?

Somebody needs to find out and contact them then

who takes notes? I see a to-do here ;-)

we need a minute taker!

:-P

Can do, that'll force me to understand what's been said

Sorry, I'm 120% busy with work, so this is borrowed time already.

this seems to touch on Q3 and I’d like to challenge the premise of that

pep.: :+1:

jonasw: this may touch Q1 too

jonasw: can you elaborate your challenge?

to my knowledge, the XSF does not handle non-public data

voting may be the only exception

the MUCs are public, the wiki is public

the only non-public data aside from voting *may* be the email adresses used for wiki accounts; which aren’t sensitive according to article 9 (1), so much less relevant.

jonasw: and the e-mail adresses are inherent to the service provided. Still we can question if the GDPR is applicable to the XSF at all

(one could construe that voting data are "political opinions" though)

winfried, that’s another matter, indeed

but even if it does apply, I don’t think it matters

email addresses are not sensitive, but they are personal data. So we _are_ storing personal data.

But to apply to become a member, I have to state my real name on a public wiki and I have to include my employer (and contact data). Are there any rules about how long that should be stored / stay public?

jonasw, does everything on the member application fall under 9.1?

fullname, email, employer, etc.

Though these pages are public indeed

pep., the member application (like everything else on the wiki) is covered by article 9 (2) e) I think

> processing relates to personal data which are manifestly made public by the data subject;

hmm, is it really email we ask for on the membership or JID?

Wiki accounts can be created by non-members, so their email address is not published by themselves.

pep., email is needed for a wiki account

pep.: both

jonasw: yes, I think it is 9.2, but is that the right discussion to have right here right now?

winfried: you are the chair!

winfried, dunno, I answered pep.s question :)

Sorry, just for the notes

:-)

Ok, then I make a procudural proposal:

I popsted 3 issues

I think we should take each of them and inventise how big the potential problem is and what research we still need to do

winfried: yes. also please split up Q1.

winfried, okay

make a headline and we’re good to go :)

and then try to make a (preliminary) assesment of a good strategy

Agreed, we should split Q1

*** Q1 ***

proposals to split?

winfried: Q1.1 What consequences does the GDPR has for the Jabber network Q1.2 ... and Jabber server operators Q1.3 ... and what can/should do the XSF with that?

Also Q2 goes into Q1.2 doesn't it?

pep.: Q2 depends on Q1.2

yes

k

*** Q1.1 ***

Q1.1 raises the question of how consent works in a federated network.

we have no idea.

jonasw: wait, what? elaborate that please

I think it is good to follow the line: a is it in the GDPR jurisdiction, what data is

Ge0rG, I send you a message. you have MAM which stores forever. I never consented to your servers MAM storage.

I think he's referring to the questions he raised for the previous board

b what data is processed

c what processing is done

(forgetting about responsible party/processer)

d what ground does the processing have

e possible consequences

winfried: (a) processing data of users in the EU requires GDPR compliance. Maybe also processing of data inside the EU, regardless of where the users are.

winfried, what is "it" in your (a)?

winfried: so basically all servers that are not geo-locked to exclude the EU fall under GDPR

jonasw: good question in a federated network

I think we should regard each server as its own legal entity, and the federation as a kind of processing (exchanging data)

I think it makes sense to define the roles as well. An XMPP server operator is a "controller", and whoever does the hosting and other services for them is a "processor"

Ge0rG: +1

winfried: we have strong parallels to email. I agree with your conclusion regarding server = legal entity

Hmm, that doesn't fit with what you said winfried

pep.: ?

You said "exchanging data", would that fit into "transfering data", and not "processing" per se

I suggest we first focus on a single server before widening up to federation

k

The c2s-only case is a lot more straightforward

pep.: (breaking my head, is transfering / exchangeing legally seen also a kind of processing, let that discussion dangle for a moment)

Ge0rG: +1

Ge0rG: on your: "Maybe also processing of data inside the EU, regardless of where the users are. " - I think we can safely say yes in that one

though not cast in iron, the first opinions point in that direction

Ge0rG, winfried, alternatively, in the case of MAM, we could argue that the User is the Controller and the server doing the storage is the Processor.

winfried: I've heard different opinions on that, we should say "probably yes"

jonasw: no!

Ge0rG, why?

we should also add a non-EU server targeting EU-citizens

jonasw: as far as I know the user can't be the controller, just the data subject...

winfried: non-EU server targeting EU-citizens must also comply with GDPR

Ge0rG: yes

so we've got (a) now, up to (b)?

yes, please ;-)

does a xmpp server (c2s) process personal data? I think that is a yes too:

this is a strong YES

jid as identifyer

it is even sensitive data according to article 9 (1), I’m pretty sure.

ip-adresses

A server is storing a users' JID and login credentials, roster content (with names), bookmarks, offline/MAM history

http upload, too

jonasw: I don't think it's sensitive.

avatar and vcard are "meant to be public"?

Ge0rG, depends on the message content, doesn’t it?

you have to assume it is

jonasw: I'm not sure this is how it works.

why not?

think it is good to distrinc here between the data that is structurally collected and data like the content that is forwarded/stored

jonasw: I assume that art9 applies if you collect sensitive data from users, not if they give it to you without you asking

Ge0rG, any source for that?

is anybody aware of an analyses of the status of communication services within the GDPR?

Ge0rG, I'd say any <message> almost, rather than MAM? or "history" in general (nit)

> How Cloud Communications Can Help You Comply With GDPR

oh my god

jonasw: I would argue as follows: the user uploads the data because they want you to forward it to the receipient, so there is a art6 §1 d or f legitimate interest

I think we can use the pictures analogy here: you can find out if people have certain diseases from a picture, but pictures aren't sensitive data until you analyse them

Ge0rG, I thought that Article 9 (1) overrides that.

jonasw: you can't google that. don't even try "email gdpr"

mind that article 9 (1) is not (only) a definition, but a "shall be prohibited" and only (2) defines exceptions for that.

Ge0rG, though jingle-ft could be used for that, most of the time

storing and forwarding a (very) personal chat may keep us out of 9.1 as long it isn't analysed / indexed on words as 'sex'...

The legitimacy of server-side component lies for offline delivery, and groupchats(?)

(a) the data subject has given explicit consent to the processing of those personal data

winfried, pictures are explicitly handled in the recitals though ✏

so maybe that analogy doesn’t work

> The processing of photographs should not systematically be considered to be processing of special categories of personal data as they are covered by the definition of biometric data only when processed through a specific technical means allowing the unique identification or authentication of a natural person.

jonasw: true

That's actually a good analogy.

Ge0rG, regarding Art. 9 (2) a): exactly, which is why I said we need a way to make users express consent for that.

and server operators need a way to be sure of that to an extent where they can blame others if the recorded statement is false

So we have the meta-data actually requested by the XMPP server: JID, name(?), email(?), IP address(es)(?)

this meta-data is not sensitive.

note that "storing" is a subset of processing.

and we have the actual data that's sent by the user, which is stored / processed. As long as we don't do racial profiling on that, it's not sensitive either.

jonasw, true

I’m not convinced

Ge0rG, I think it must still be declared and the user must still consent for storage at least, because of the risk of data breaches.

jonasw: wait, are you still talking of art9?

I think so

Analyzing for SPAM, does that matter?

jonasw: I agree regarding the general requirements of the GDPR, but not art9

Zash: yes

Zash: not for art9, I'd say. Unless your SPAM detector is a Jew detector in practice.

Ge0rG, it might be a sexual content detector in practice.

for email at least.

or a cyrillic detector

:-°

jonasw: I think the only viable reason to run a sexual content detector is to block the latter, in which case GDPR does not apply?

Ge0rG: not 'in practice' but explictely

I have a feeling that as long as we don't analyse data (content AND metadata) on patterns that indicate categories from art 9.1, 9.1 is not appliccable

winfried, I like that idea. I’m not sure on that though. It would be good to get legal advice on this.

this might be focused enough to actually get an answer to.

but what do I know.

pep.: I see a to-do ;-)

yep

so any kind of mod_firewall trickery will probably get us off that safe land?

What's meant by "analyse" here exactly

Also, "from art 9.1, 9.2", right?

analyze to an extent where you could say "this person would elect Democrats in the next election"

(or similar statements about the other sensitive attributes mentioned in 9.1)

or 'this person has sex once a month'

k

Not the things needed for routing, right

Zash: exactly

Zash, depends? Maybe you'll route differently if they have sex more often

Anyway, going on?

yes

That's b and c "sorted"?

For the C2S case

Maybe c not entirely "what processing is done", we could maybe list a few common cases

I think we can safely say a XMPP server operator is a controller (not the hoster)

I think what we *at the very minimum* learn from this given the technical means in the Jabber network is: you absolutely must not do any kind of data mining on message content which might come from federation.

winfried, agreed on that

jonasw: agree

jonasw, why especially federation

pep., because federated users cannot consent

you could get consent from your local users

I see

do we have a clear idea of the data collected and processed in a xmpp server?

and operators might fall for "I got consent from my users, so I’m fine with processing their messages" but that’s in fact false because you’d need consent from the senders too

winfried, I think Ge0rG gave a list earlier

I have listed: - JID - login credentials - roster content (with names) - bookmarks - "history" (offline/MAM)

roster, timestamp of last available presence, mam, offline messages, http upload, in-flight messages

ah

Ah right presence

pep., add "timestamp of last available presence"

and in general presence is saved transiently to anwser probes

logfiles with connection data

winfried, as in? IP? (re private data)

http upload, too

pep., timestamps and IP, yes

jonasw, or any kind of server-side component storage files?

storing*

pep., yeah

MUC history, too

also PEP data

MUC history, only applying to private MUCs?

PEP is by default public

would it make sense to put all that under "user content"?

probably

except for the logfiles

login credentials are hardly user content, too

what about the roster?

jonasw: agreed, they may have a different legal status

I think that roster / bookmarks are special, but (actual) PEP, MAM, offline, HTTP-Upload is all user content

why are roster and bookmarks special?

jonasw: PII, passwords

are bookmarks PII?

"Georg's private Sex Toys Chat"

ah, I forgot about that one ;-)

but isn’t that like message content?

jonasw: not sure.

jonasw: I think so

Ge0rG, why would it be different from message content?

so we have: - credentials - user content (roster, bookmarks, PEP, messages, files) - server logs

+1

Ge0rG, timestamp of last presence isn’t user content though

jonasw: "server logs"?

kinda, but it’s shared to peers

so we have: - credentials - user content (roster, bookmarks, PEP, messages, files) - user metadata (IPs, last activity, ...) - server logs

yeah, I’d like to have this separate, because you’re not "safe" as operator just because you turned off logging.

user metadata also includes data on the xmpp client

winfried: what does an xmpp server store about the client?

server logs do include all the above though ✏

Ge0rG, entity caps, which may allow mapping to disco#info, which may inclued software and OS version

probably neither sensitive nor PII

pep., not credentials, I hope :)

jonasw: it can show when I am at home, at my laptop or only on the mobile

I'd argue that server logs fall under http://www.privacy-regulation.eu/en/r49.htm

it may also show when my connected sex toy is online...

jonasw, if scram then no, otherwise I could imagine it being in there

winfried: your resource string is either user-data or user-metadata

winfried, I think that’s user content/message content though because clients usually do that by themselves by asking for your disco#info. nothing special is done by the server here.

(unless it does caps optimization, in that case see above)

pep., if a server ever logs a password sent with PLAIN, report that as a bug

even a SCRAM exchange shouldn’t be logged imo.

For debug purposes, for example

pep., there’s no reason to log passwords for debug reasons.

but we digress I thnik

Ge0rG, but only for limited time. a proper logrotate would have to be in place ✏

I think: - credentials - user content (roster, bookmarks, PEP, messages, files) - user metadata (IPs, last activity, ...) - server logs is a good devision, because it devides the data in different legal categories

winfried, I agree (not that I knew about which legal categories there are)

jonasw: I don't see a time limitation in R49

Ge0rG, to the extent strictly necessary and proportionate

I think it’s hard to argue that you need to store full prosody debug logs for 2y for example.

jonasw: good point

credentials: by creating these, you may implilcitly give permission for processing pii by the service

I don’t think there’s such a thing as implicit consent

So we have (b) covered as well now.

in GDPR at least

user content: limit discussed earlier

user metadata: as user contant, possible different limitations

server logs r49, with limitations as above

what's this r49 exactly, let me find it

winfried: what about (c), what processing is done? is that implicitly clear?

pep.: http://www.privacy-regulation.eu/en/r49.htm

Ge0rG, https://gdpr-info.eu/art-30-gdpr/

that’s probably most relevant regarding (c)

wait, I might be confused

ah

don’t wait though

in any case, taht article is relevant, probably not for (c) though

or maybe it is :)

i just lost all context

jonasw: I don't understand the coffee cup my client is showing me...

winfried: your client is broken, it replaces letters in braces by pictures of things

'( c )'

winfried: b = beer, c = coffee

dunno about a=(a)

c) is what processing is done. For that atm I have a quote from winfried, "we should not analyse data (content and metadata) on patterns that indicate categories from art 9.1 and 9.2", and then jonasw's "you absolutely must not do any kind of data mining on message content which might come from federation"

We haven't done b) for the S2S case, we'll get to that afterwards?

pep.: correct

you can leave out the 'might come from federation' part

winfried, you *can* do data maning if you got consent from your users -- but not on federated messages

unless you do some captcha thing

I feel that’s important to mention

jonasw, more details on the captcha thing?

my take: - credentials: stored as long as the account exists, limited further processing (check user JID against well-know spammer patterns) - user content: stored as long as the account exists (roster, bookmarks, PEP) / for a limited time (messages, http upload)

not that I’d condone data mining of any kind, but if an operator chooses to do so with consent of their users, they have to restrict to non-federated.

jonasw: I can also ask for consent from federated users

pep., like, on the first message from a federated user, hold that message and make the federated user click a button on a website with terms of services for all messages sent to that domain.

winfried, yes, but harder

because they don’t sign up.

and it might not be obvious

I think we should focus on what processing is technically required, what is typical and not focus on special cases of user-targeting

jonasw: yes, so it is an administrative / technical issue, but legally it seems the same to me

Ge0rG, +1

also please keep federation out yet

Ge0rG: +1

I think that federation is the most tricky part though ;-)

jonasw: +1

jonasw: maybe it's not.

so can we get back to minimal and typical please?

agreed with Ge0rG's split for b)

credentials: minimal = store as long as the account exists | typical = spam bot detection user metadata: minimal = store during connection | typical = store with account, spam detection, expose to other users (last activity)

"typical = spam bot detection" for credentials?

do you store plaintext passwords to detect spam bots? ✏

localpart or server I guess

Ah wait, not server, just localpart for c2s

user content: minimal = roster,bookmarks with account, PEP in RAM only, offline messages until first client connects | typical = with account, MAM/files for a given amount of time

jonasw: I'm checking usernames against patterns

Ge0rG, right

I was thinking about storage only, you were (rightfully so) thinking about processing

(brb, 1 minute)

Ge0rG: I like that list

- server logs: minimal = no logs | typical = some days / weeks of logrotate, maybe with IP addresses / message metadata. I'm storing debug logs for two weeks plus additional spam detection logs

addenum for user metadata/typical: IP address of registration / of last login

storage of ^

and I nothing that is disproportional or outside reasonable user expectation

Somebody should wifiky that. Or put it into a proper table

Ge0rG: our notekeeper is afk ;-)

Sorry, I've vastly exceeded my timebox for this conference, and I need to catch up. I'm semi-AFK now while you figure out the legal grounds beyond R49

!

I'm also usually storing debug logs on the server, and rotating them

lets see where we are now, I have to leave in 20 minutes too

we have come quite far with the c2s part of Q1.1

Yeah, this last bit was d)

For C2S

still have the tough issue of s2s (federation) open

Ge0rG, "PEP in RAM", some servers provide persistency here, and soon(tm) prosody as well. I would just put that with roster/bookmarks ✏

winfried: I have some information on federation, but I think we should make a follow up appointment

Ge0rG: +1

Agreed for the follow-up, I think we can summarize quickly and call it a day

There's already quite a lot of stuff to digest

pep.: you volunteered to create a page on the wiki with the content table, I've heard... 😀

heh

pep.: I can help building the wiki page

can we set a new date?

winfried: yes please

This week? Next week? How quick do you want to figure this out

This week, some day, same time

pep.: I prefer a short, compact, traject

+2 days? (wed)

pep.: works for me

WFM

jonasw,

I'll try to send minutes soon

pep.: great, thanks a lot

pep.: yay!

wednesday doesn’t work for me

sorry, I was distracted

+3 days? +4 doesn't work for me

I can’t make reliable statements about any day after wednesday until next weeks thursday

Friday is so temptingly empty on the calendar...

so the closest thing which would work would be tomorrow, ohterwise it’ll be best-effort on my side.

tomorrow works for me

I can do +4 but after 13CET. I can do +1 yes

WFM too

okay

ok, +1 day, 12CET

12:15 CEST would be easier for me

(as I learnt today)

ok, 12:15CET.

CEST please

+1

not CET.

(like today)

Ah, oh

DST.

pep.: CET will be again in half a year

yeah.

Cool, +1 day 12:15CEST then.

*bang*

thank you

Thank *you*!

nice work guys!

obligatory XKCD: https://xkcd.com/1883/

Wait so what time is now now in CEST land

pep.: CEST

14:00

> 14:00:18 pep.> Wait so what time is now now in CEST land

cool

is it*

jonasw, :D

yeah, had a laugh on that one too... though I like the idea of california drifting of the mainland :-P

Was this meeting announced somewhere? I think I missed some information on this, didn't know this was going to happen

Seve/SouL: no, we just made the appointmet in this muc after last boardmeeting

Seve/SouL: do you want to be involved?

Thank you winfried, it's not like I can help on this topic :) Just wondering if I was missing important events. Do not worry, thank you very much :)

It *should* have been announced on members@

in the board meeting minutes

but apparently the minutes haven’t been sent yet

btw, anybody knows where I can find more info about the derogation mentioned in https://gdpr-info.eu/recitals/no-13/

pep., https://gdpr-info.eu/art-30-gdpr/ 30.5

jonasw, thanks

Now I'm not sure most services will fall under that derogation though.

"[..] unless [..] the processing is not occasional"

Ok I'll keep that for next time

> jonasw> some risk management articles: 5, and consent in 7 and 8, with proof What did you mean with "with proof"?

> 2. This Regulation does not apply to the processing of personal data: > (c) by a natural person in the course of a purely personal or household activity;

How does that relate to self-hosting?

Yeah I was wondering as well. Will add that to the questions. I guess that's good when you do it for yourself, or with people that also have access to the machine and take care of it (xmpp service)? And doesn't qualify if you start giving accounts to people who don't?

pep., you probably need proof for consent

Has anyone figured out how to get consent over the Internet yet?

Zash: [ ] I accept that you'll bend me over and take my virgi^W data

my virginia drivers license? no way!

Self hosting is an interesting case too!

winfried: self-hosting for yourself or for others?

> Has anyone figured out how to get consent over the Internet yet? Yes, there are quite clear cut rules for, technically not too complicated in matter of facts, de hardest part is asking the right question...

that's been solved a long time, you just pop up a 15,000 word EULA asking for everything in a tiny window and an 'Accept' button right?

Ge0rG: both are interesting! Though when it among a collective of friends or family it will probably be the same case, but good to check

moparisthebest: that one has never been valid in the netherlands, if you can't download it in plain text or PDF, it was not legal and standard Dutch law applies!

ctrl+c/ctrl+v downloaded in plain text and therefore legal

reminds me of the first generation of Facebook export, where you got a 500 page PDF file containing all your data.

moparisthebest: nope, not valid here 😃

Ge0rG you can add &exportformat=xml-xmpp to the FB export URL

edhelas: I can't.

edhelas: because I don't have a Facebook account, I will never know what Facebook logs about me.

time to subscribe!

The mysterious Shadow Ge0rG

https://tools.ietf.org/html/draft-tenoever-hrpc-research-05#section-5.2.6

did the authors of this reach out to "us" (i.e. the xmpp community)?

-rfc 8280

Zash: Research into Human Rights Protocol Considerations. N. ten Oever, C. Cath. October 2017. (Status: INFORMATIONAL) https://tools.ietf.org/html/rfc8280

https://tools.ietf.org/html/rfc8280#section-5.2.3.4

https://takeout.google.com/

Wait what

> While the protocol does not specify that the resource must be exposed by the client's server to remote users, in practice this has become the default behavior.

Well I suppose you can do without presence, but uh

Wait. So telling your contacts that you are available is a bad thing now?

flow: I'm not sure I immediately associate any of the authors or thanked people to XMPP

daniel: doesn't your client show a GDPR disclaimer before you accept a subscription?

The death of pars

j.o is still down.

-ping jabber.org

Zash: Pong from jabber.org in 4.463 seconds

What? Why?

Oh, poezio won't auto-rejoin on its own. Sorry.

Because IPv6

Only Legacy IP is affected.

Zash: s2s IPv6 failed today as well. I blame prosody

| -> conference.jabber.org [s2sout56531a7fbce0] (authenticated) (encrypted) (IPv6) | <- conference.jabber.org [s2sin5653218deb10] (authenticated) (encrypted)

There is an interesting discrepancy.

firewall is blocking incoming ipv4 but not outgoing ipv4

DoS protection or something?

DoS-by-DoS-protection.

No, firewall blocks ipv4 the main address, both ingress and egress.

I added temp a secondary IP.

Ah, that also explains why it didn't work at all in the beginning.

I suppose the fallback to IPv6 egress didn't happen?

It kinda did, but not entirely.

We really need better debugging tools. Something like a dynamic log where we can easily filter by JID

Maybe I need to dump all my prosody logs into something like kibana or elasticsearch.

I was looking into elasticsearch for MAM...

I think it's overkill though

MattJ: not for MAM, for log analysis

I know, my message was semi-unrelated

I put my logs into elasticsearch for a while and didn't find any use for it so stopped.

it would be great to have a mod_log_json which would dump structured records of each event via some socket interface

Was dog-something related to logs, or just stats?

Kev: yesterday I sent a message to a MUC on my server from my mobile client, and it was rejected. As I don't have logs from the mobile, there is no way to find out what happened now.

Zash, Datadog added log support recently (it might still be in beta, not sure)

Ge0rG: Me not finding a use for something and it not being useful aren't quite the same thing. Despite me obviously being the center of the world.

Kev: let me remind you of H2G2.

H2G2

🤔 🤔 🤔 🤔

-EEMOJIOVERFLOW

let's remove emojis support from XMPP ;-)

let's remove Maranda support from xsf@ :PP

ASCII-only

stty -emoji ?

-E_STOPUSINGCONSOLECLI_PROBLEM_SOLVED

:P

with XHTML-IM I can send images to all the XMPP clients, so ASCII-only will do

My console has a perfect two-way mapping of Unicode Emoji to ASCII. It only ever failed on foo:iq:bar

Ge0rG, and male emojis *coughs*

Zash, can you reply to the minutes I just sent for your question earlier?

Under Q1.1.a I guess

(re personal/household activity)

Are <stanza-id> elements mandatory in MUC history playback on a MAM-enabled MUC?

pep.: Please wait for food coma to subside ✏

pep.: to the time machine! 😁 > Date of Next: 2018/03/17

ah merde

pep.: let me read the whole thing before you send out an update :D

k

We do cover c) with some stuff in b), I guess I could have split that

pep.: okay, everything else is fine with me :)

pep.: thanks for taking minutes, and it's nice to see the conscise form of the discussion

:)

pep.: maybe members@ is not the right venue, though

I feel it is the righter venue than standards@

Yeah I was wondering, I'm not sure

jonasw: what do you feel is the most rightest one?

But I don't think it should be in standards. if any I would have put that in operators as well maybe

I think members@ is a good start for now

we might want to cross-post to operators@ at some point.

:)

pep., hmm, now that I think of it, getting people from operators@ on board could be a good idea

pep., could you forward the mail to operators@ with a fixed date? maybe someone will show up. ✏

Sure

Phew

Zash: you are the one with the conversion magic skills. I'm looking for a way to convert https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ into something I can read on a mobile device

Ge0rG: How is the HTML?

Ge0rG, xml2rfc --raw?

Zash: it sucks.

It's like ASCII text, but with added references.

And the text/plain?

Hm

hm, --raw isn’t great

xml2rfc had a better html output when I tried it the other day

I want something like epub, where the text reflow is controlled by the client UI in accordance with my font settings and viewport size.

It has ASCII diagrams in it

MattJ: I can live with horizontal scrolling on those.

Ge0rG: How is this on your device? https://xmpp.org/rfcs/rfc6120.html

Ge0rG, xml2rfc --html

That's (I think) what you get from `xml2rfc --html`

Ge0rG, https://sotecware.net/files/noindex/draft-ietf-mile-xmpp-grid-05.html example

the width is set dynamically

(it is just a max-width)

https://upload.yax.im/upload/2D5IcQiw14tuMVQa/Screenshot_20180326-174545.png

which is good

"Using the XMPP publish-subscribe extension [XEP-0030],"

jonasw: your rendering sets the width to 75% of my screen, but at least I can zoom in the other 25%, making the size almost bearable

m(

I tried it on my device

stupid

Ge0rG, interestingly, the ctrl+shift+m thing on firefox which is supposed to emulate mobile devices does it better than the actual mobile firefox.

Really, can't we just have epub/mobi? With HTML, browser vendors haven't figured out to remember the screen position I stopped reading at. In 2018. It's a shame.

Almost as bad as XMPP.

Ge0rG, they do? don't they?

FF does that for me

Ge0rG, reload mine

pep.: sometimes they do, but as soon as they have to rerender the page, all bets are off

oh reader mode actually works fine

on that rendering

so maybe just use that

meh,e xcept for the ascii diagrams of course

The Debian man page for xml2rfc is awesome as well: > The xml2rfc script requires python 2, with a version of 2.6 or higher. Can't proceed, quitting.

Can haz xml2rfc2epub ?

Ge0rG, re-try my rendering. you have to zoom in because of the diagrams, but otherwise it should be fine

I've pretty much given in to the fact that I'll always be required to have python 2 and 3 on every computer forever

Ge0rG: pandoc can turn html into epub, but it's usually kinda messy

it’s xml2rfc with <meta name="viewport" content="width=device-width, initial-scale=1" /> added

jonasw: how do I do "Reader mode" on mobile FF?

it’s next to the address bar

gah, forgot to enter my email password

Ah. Thanks. It even supports changing the font size. Almost awesome.

Ge0rG, yeah, aside from the ascii art diagrams :(

But still not epub. I don't trust it to remember my reading position over the next OOM kill.

it won’t probably

Whoever thought having the same keybinding for "back" and "quit" in mutt ...

you should’ve said that at the beginning, Ge0rG

:(

And it's grey on grey.

it’s black on white here

Ge0rG: pandoc blah.html -o blah.epub ?

or -s -o b blah.markdown and tweak it a bit then -o epub

Basically how I read blags these days

Okay, epub has great text rendering, but the ASCII diagrams are unusable :D

Thanks everyone.

jonasw: FF reader mode is light-grey on dark-grey. I have no idea who thought that's a good idea.

Ge0rG, switch the color scheme

it defaults to auto

maybe something is weird on your device

(it’s in the same menu as the font size)

jonasw: mine is "dark", and that's a low-contrast theme.

switch to light.

it's better contrast, but I actually wanted a dark theme.

okay, my FBReader might be a bit extreme, 50% red on 100% black

Infamous "Disco Pub(Sub)" xep

but it's great for OLED display reading at night

Now I understand Yaxim's colour scheme reason.

Ge0rG, I feel you might actually want redshift instead.

(or LiveDisplay how LineageOS calls it)

the most amazing thing invented for displays

(also known as f.lux or xflux)

pep., I forgot to say it, thanks a lot for taking the minutes :-)

You're welcome

I forgot to specify maybe we haven't treated S2S cases yet, and that's going to come later on. Will indicate that tomorrow

How's jabber.org doing?

I’m joined in jdev@

so I assume I got lucky with ipv6?

v4 still blackholes

yay presence-less clients. andrey.g is spamming the room with join/parts :x

TLS 1.3 approved https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html

Woohoo

So, does it hide SNI and ALPN or did the firewall vendors manage to block that?

Seemed to go back and forth a bit on that IIRC