XSF Discussion - 2018-04-17

Maranda, I don’t think so

it also isn’t that much work to support both

jonasw, Gajim uses it at least

gdpr meeting in about in hour?

yeah

GDPR meeting in 3 minutes

.

🐈

Almost there!

Uh-oh.

! I'm here

so am I ;-)

me 2

I propose we take a look at LQ1 and subsequently continue filling the Wiki (though I have a little point we may have been forgetting)

okay

we aren’t lawyers, so how we’re supposed to deal with LQ1?

I must say, I haven't had time to update the wiki, don't know how up to date it is.

Sorry for the minutes last week, it's been a fun week

Maybe we want to start drafting a template data policy at some point?

pep.: I know the feeling... have double appointments on all days of this week

pep.: yes, I think so, but we first have to see what choices we can/have to make...

I've had a chat with our GDPR expert, and he said that message content is similar to picture uploads. As long as we treat it as an opaque blob and don't analyze it, art9 doesn't apply. He is going to send me a reference to an according legal analysis some time today

uh

nice

that is amazing news.

Ge0rG: great

--- except for your mod_firewall.

yes

I was thinking about that

(which makes me wonder about bayes filters at big mail corps, but that’s another topic)

One reaction I got on LQ1 is art. 9.2e

but that one is without references

From http://www.privacy-regulation.eu/en/recital-51-GDPR.htm > 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.

I propose to treat (for now) LQ1 as: "not subject to 9.1"

winfried, makes sense to me.

winfried: 👍

mod_firewall is not making any derivative data from what it "analyses", and there's not way for us to know what triggered it right? I mean except it you log it

with a huge "UNLESS you analyze the text in any way"

jonasw: in a way that allows to extract art9 data ✏

Ge0rG: +1

my mod_firewall isn't deriving information about sexual / religious beliefs, merely about mass-messages.

Ge0rG, did you ask your GDPR expert about the fact that MAM archives are unencrypted and thus operators may access (advertendly or inadvertendly) message content which contains art 9 data? ✏

that was raised by Peter on list I think.

jonasw: still pending.

so you did ask, but not have a reply yet?

jonasw: does MAM have a consent mechanism? What is its default?

jonasw: didn't have much time with him

winfried, I don't think it has at all atm

jonasw: we fixed that

jonasw, opt-in although most clients do it when available?

winfried, it is normally opt-in (except on Prosody in the past ;-)). ✏

winfried: there is no GDPR data consent dialog when you enable MAM. Servers and clients will auto-enable it on first use, typically

pep., yes, although that’s a problem of the client then.

yeah..

so it's rather opt-out

not conceptually, and not on the server side.

Ge0rG, you fixed that in what version of prosody, and when is it going to be deployed :P

Opt-in by server operator

This may be a point for an implementation guide.... or so

winfried, indeed, it should be mentioned in the MAM XEP.

pep., can you add that to the technical TODO?

that?

winfried: except that users don't like consent dialogs ;)

Ah, MAM

pep., "Add a note to the MAM XEP about GDPR consent requirements."

And clients don't expose the settings

> pep., "Add a note to the MAM XEP about GDPR consent requirements." 👍

Ge0rG, well.. they'll have no choice, everybody will want to cover their asses now

Ge0rG, that message did not follow my reactions draft format!

I know because JabberCat didn’t show it properly ;P

Zash: and the XEP doesn't provide a way to differentiate between "explicitly set" and "enabled by default"

jonasw: you mean my quote-with-yaxim format that you shamelessly copied?

jonasw: fix JabberCat :-P

ahm. let’s continue with on-topic *whistles*

yes please.

Ge0rG 2018-04-17T10:46:55.668869: > yes please. 🤦🏿‍♀️

derp.

jonasw: `2018-04-17T10:46:55.668869`, seriously?

okay, so LQ1 resolves to "Not 9.1, unless you extract 9.1-ish data from it somehow"

I was wondering if file transfer needs a special status in the processings XMPP does...

winfried: I don't think so. it's a direct client-to-client transmission, and the server only sees metadata

Were we done with Q1.1d S2S?

Ge0rG, unless BoB?

Ge0rG, uhm. In-Band Bytestreams, BoB, HTTP Upload

I'm pretty sure we have all of that covered by "user content"

so unless you happen to do TURN-less jingle (rather rare), I don’t see how that’s client-to-client.

possibly

* typical: with account, MAM/files for a given amount of time

yeah

Ge0rG: adding that covers it all?

winfried: it's in the wiki already

ah, switching back and forth on a small screen right now... (sitting in the middle of THE care ICT trade in NL right now)

Q1.1d s2s

hmm, there's a bit on 1.1d in the wiki, but that's not last week's

they are notes from earlier meetings

Also I propose we skip 1.1e, as I don't feel confident going into even more speculation

IANAL

looking at Q1.1d, I realized there are two things to cover

the transfer of the data itself

and the processing of the data on the other server

both need a legal ground

winfried: I'd argue legitimate interest of the user to get messages delivered, for both points.

winfried: that also implies that the other data processor may not apply processing to the data that goes beyond what's needed for that legitimate interest

Ge0rG: what article do you mean by legitimate interest?

winfried: 6(1)b

Ge0rG: yes agree

and agree to the limitation you mention

But we can't assume that can we

For Q1.1e we should probably write down all these things into a data processing policy

Ge0rG: exactly, this something we should cover in Q1.1e

pep.: in some way we need to 'safeguard' we can assume this

There might be server admins that will want to assume the worst and ask consent for most things

pep.: for third-country servers, Art. 49(1)b should apply in the same way as 6(1)b for intra-EU

Ge0rG: +1

I'm pretty sure we can say that the user has a contract with the server operator, and that sending data to another user on another server is part of the contract

Ge0rG: +1

Do we have Q1.1d covered like this?

winfried: is incoming s2s different from outgoing s2s? What about spam protection?

That are two questions

lets brainstorm on the first one first

outgoing: the originating server operator is responsible for the transfer

Are there any restrictions on data imported from third countries?

Ge0rG: no, because the EU has the best data protection laws :-D

yet

so outgoing the operator wants to know the incoming server stays to the 'legitimate interest'

But there is COPA!

winfried: I don't think we can enforce any kind of remote server processing restrictions at the protocol / logical level.

winfried: it might be sane to assume all data sent over s2s as "third country"

incoming: though you may have a different contract with your own users (e.g. we publish everything) you *have* to assume incoming limits to legitimate interest

so no storage in MAM?

Ge0rG: no, that is something that needs to be legally enforced

winfried: MAM is covered by legitimate interest of the receiver, I'd say

even MAM forever?

jonasw: how is MAM forever different from the receiver putting logs of the chat up into the cloud?

it may not be

jonasw: MAM is controlled by the user(s client)

so from a legal PoV, the receiving user is responsible for MAM.

and that’s what I’ve been saying a few weeks ago but I got shot down here :)

jonasw: but not by me, as I do agree with that interpretation

not sure, maybe I was simply unclear.

so incoming s2s user data: might get stored in receiver's MAM

also in offline storage, but I'd argue this is still part of the sender's legitimate interest

I am still chewing on: » [13:11:05] <jonasw> even MAM forever?

winfried: what's your issue with that?

it is disproportionate in any way, but who's responsibility is it?

It is upon request of the user (hopefully)

if it’s upon the request of the User, I’d argue that for the Purpose of storing the messages on the server, the User is the Controller and the Server (Operator) is merely the Processor.

In theory, MAM should require consent from the user.

and thus it’s the users responsibility

jonasw: that means the user needs to have full control over the data processing, including a way to purge the data.

As long as there is consent I don't think it's disproprotionate. Now, that means we also need to provide means to alter this history?

pep.: consent from the receiving user?

user can't be the controller (in the legal sense) but a controller may process when the user wants him too

Ge0rG, or just prune parts

Ge0rG, we need that for MAM anyways, I think?

Ge0rG, yes receiving

tombstoning is at least provisioned. purging everything *up to a date* is possible, too.

yes

jonasw: will MAM auto-purge if you disable it?

Ge0rG, I sure hope so :)

I find tombstones useless, as it will only be for this particular user, the rest don't have to respect that, but well. purging has different use-cases

Ge0rG: that should be added to the MAM-XEP too...

winfried: I tend to agree.

Is there a way to disable even

Also MAM MUC is separate right?

pep.: yes

and yes

On a MAM MUC: policy of publishing logs should be published

winfried, publishing as in http-like?

Or just providing MAM for other participants

pep.: yes

winfried: MUC MAM should mimic MUC access.

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

not sure if more hints are needed there.

Yeah I agree with Ge0rG on that

should we plan for next?

yes please.

I would argue that it is not obvious that the logs are published and it is not necessary for 6.1b

winfried: I think that like with MAM, this is a client UX todo

so should be a tech todo for us

Ge0rG, hmm, publishing logs publicly (or even with some kind of auth) is server policy

also please put the "spam handling" question on our TODO for next

Ge0rG: +1

(some kind of auth, not over xmpp**)

So, next?

https://xmpp.org/extensions/xep-0045.html#enter-logging

> If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged.

(Yes, I can live with a tech todo on announcing log publication)

winfried, MUC MAM access should be clearly defined (tech TODO), and there’s a presence status code for public logging (some clients already show that)

Ge0rG, yes, so that's handled already which is good, but it is a concern

Spam handling for next meeting

I can't do +1, can do +2 and more

I can't do this time Wed or Thu.

this week is not possible for me... or it should be friday on 16:00 CEST

+1 for Fri 1600CEST

Fine by me

jonasw: Friday 16:00 CEST?

The spam handling question is in relation to 9.1 right? or not just?

pep.: yes, we may enter the realms of 9.1 there, but we may also run into some different issues, like automated decision making

(to add more fun to it....)

Does that fall under anything? it's "analysing" right?

I mean worst that can happen to that is 9.1 right?

winfried, hm, that’s tricky for me

but I can arrange that once

jonasw: If possible, that would be great

okay

pep.: the question is probably whether we can do spam detection without going outside of 6.1

will do

Ge0rG, yeah

jonasw: thanks

We should also try to see where we are with the goals at some point, regarding the "deadline"

Fri 1600CEST it is then

*bang*

I think we are chewing away slowly

but doing a great job, bit by bit things are getting clear

and I think we are closer then we expect!

I should try to come up with some requirements for the EULA XEP

keep up the job!

I have no idea what to use protocol-wise, but we can do that later

pep.: yes, think we are about at that point, Q1.1e

pep.: I thik we should first create the general EULA/ToS structure, then see which parts of it need encoding

There is also https://en.wikipedia.org/wiki/P3P

nice

I wonder why that is "obsolete"

yes, it is, but probably an overshoot for our purposes

"[..] P3P has not been implemented widely due to the difficulty and lack of value."

it is hard to uniquely encode legal stuf to computer code

Lack of value as in, every website has a privacy policy?

right

no pressing legal needs, not high enough fines ;-)

the GDPR may resurrect it...

nah I think everybody's got their own framework nowadays

At least the big ones

pep.: it tries to solve an esoteric problem that most people neatly try to ignore

even in the medical world (where legal status is a big issue), everybody loves to ignore the problems that come along with it

or to state it differently: if you can communicate about a problem, you also need to solve it...

Ah, my coworker sent me some info re 9.1: profile photos of employees are not article9 related data as long as they are not analyzed

What does analyze mean here?

If they're displayed internally that's ..?

That requires consent I assume

pep.: categorized to categories like: 'gender, color of skin, skin-disorders, gaydar result' etc

displaying needs consent

have to go now, see you on friday

see you

gaydar haha

I guess its time to submerge in the gdpr stuff. Havn't really had the time yet. This metting made me curious

s/metting/meeting

Ge0rG, so if we regard messages as opaque, that means we can also do the same for emails right. That would definitely simplify things here at work

pep.: yes, I'd say so

pep.: same spam caveats apply

Yeah

Though, for company emails that's different right? Maybe the company can assume that everything that's done under company email is for work (even if I know it's never always the case)

> winfried: I don't think we can enforce any kind of remote server processing restrictions at the protocol / logical level. > winfried: it might be sane to assume all data sent over s2s as "third country" 🕺

The watchdog’s actions prompted Kremlin officials to move from Telegram to the ICQ chat service, owned by billionaire Alisher Usmanov’s Mail.ru, for communications with Russian and international media.

soooo, ICQ still exists? wow

Yes

ICQ is owned by Russia now? wow

Ge0rG: as is vKontakte :)

a far leap from the Israeli mirabilis..

Mossad, CIA, FSB. It's been a long journey

indeed : )

The expert believes that another way to blackmail inattentive server owners is by creating snapshots of the exposed servers and contacting companies after May 25, asking for a Bitcoin ransom not to report the company to EU authorities, where they stand to receive a hefty fine.

ha who knew EU was introducing a new way to blackmail companies? thanks EU ! :)

well so Cisco Jabber is actually capable of STARTTLS on s2s streams 🤔

why not enabling that on cisco.com then

pft

maranda: it is. iirc you only get that if you talk to the people over there though

fippo I'm not sure I understand, a lot of users on my server have cisco.com contacts and cisco.com never encrypts, that's why I need to still have an exception for it.

Maranda: Same here. And yes Cisco Jabber does support STARTTLS on s2s.

maranda: s/people/admins/

🤔

from what i heard they need to enable tls for a particular peer domain. but that was ~5 years ago

fippo, and they don't enable it on cisco.com ? lol

I think he means they need to enable it for your domain

That seems like such a pain

waqas, and I repeat: *and they don't enable it on cisco.com ? lol*

😏

cisco.com admins have to enable tls for your domain.

cisco.com *IS* the domain

you run cisco.com?

No I don't

But I'm connecting to it

...

(via s2s)

(and viceversa)

so cisco.com will look at your domain, check its config "is this guy trustworthy to enable tls?" and probably not find anything

. . .

Maranda: Pretty sure you wrote a plugin that does exacly this.

Ok sorry I got it now, and it's hilarious.

So,

*they* have to enable tls for s2s on a particular *remote* domain? *REALLY*?

job security for the admin. i've seen similar things in lync

Zash, mine is an exception to make it work, this is just purely demented.

fippo, and I didn't catch "peer" when reading, tired eyes/brain :)

at least you don't start scratching your eyes out now that you understood it :-)

our lync only federates if the admins explicitly set it up for specific remote domains

basically ruins the concept of federation, but ¯\_(ツ)_/¯

that's fair

not enabling tls *if offered* without admin intervention is dumb imho.

yes that does seem far dumber

What's wrong with per remote feature settings? Other than the usuall _encrypt all the things_

If I respond nothing other than, will that trigger some trap? 😎

You will be locked in a room along with a packet capture and not let out until you find the layer 8 problem in the encrypted stream.

Disabling TLS does make sense if the other end does have issues with it or not support, the other way around: E_DOESNT_COMPUTE

Hehe

You can enable TLS for all s2s connections in Cisco Jabber these days.

Holger, yes I found out stumbling on buffalo.edu

Hm. The only contact I had on Cisco.com changed his job recently, so I can't care much any more

That's maybe a sign

Ge0rG, I still see traffic, also there some more contacts from I think hosted domains, also nike.com

Lync was the other service I was thinking of where I had to deal with this. I'm happy I haven't had to deal with Lync in a few years…it's great for job security though

it's "Skype for Business" now, and blue instead of green, still can't reliably send files though so at least some things don't change

It was very much enterprise, MS tech people helping us set it up failed (because we had a cloud based environment, and they had a very weird set of hardware and network topology requirements…)

I'd love to know how to federate with Lync from my XMPP server. Or even how to login from XMPP as a given Lync user.

the lync admins have to set up a special XMPP federation bridge

and in practice it seems no one does this

What if our Lync is hosted in O365?

I used to have a lync transport from xmpp, using libpurple-sipe and such, but it broke years ago

libpurple. I'm not going down that road.

MattJ: Had we succeeded in the Prosody-Lync bridge, or did we never manage it? I recall it being a works-with-ejabberd product, not proper XMPP.

ours is on O365 and federation is still something they have to turn on manually, maybe it's just an admin setting there? don't know

IIRC it was sensitive to e.g., certain consecutive parts of the stream being in the same TCP packet or not, etc. Lots of other fun things we ran into. Skype for Business UX also is terrible.

(dumb stuff like sending an XMPP message to someone wouldn't show a notification, so they'd never know)

🤔

all the time we get a popup in the corner 'PERSONX sent you a message [accept] [ignore]'

and then you click accept, and you don't see the first few messages they sent before you clicked accept

I honestly don't know how people think this is a good system

didn't you need some Lync Edge Server vattelapesca thing for xmpp federation?

moparisthebest: Ask your admins :P

Yes, it's a bridge

the best thing is just a braindead policy decision

We were annoyed enough that we were considering if it'd be saner to use a Prosody->SIP->Lync setup

we must use contractors for new development, contractors can have VPN access to our systems, contractors cannot have lync accounts, so we can't IM them

I ended up setting up an IRC server and https://kiwiirc.com/ on a dev server :'(

I don't wanna know the usual CAL junk in le MS Fashion behind something like Lync though (one of the reason everyone needing M$ going cloudy these days)

(the CALs are "included")

now corporate is spamming us with these emails to use "Yammer" which as far as I can tell is a microsoft workplace facebook/twitter clone or something

who would seriously want to do this?????

So everyone agrees Lync is a horrible mess. But nobody has an XMPP-based drop-in replacement with screen sharing and VoIP

Jitsi?

doesn't matter, lync screen sharing and voip never works

we use webex for that

moparisthebest: screen sharing works well here, voip mostly

voip on lync has *never* worked for us, we use conference calls or webex

screen sharing used to work until about a month ago

then they decided to fix the terrible latency by reducing quality to a point where you can't read letters anymore

so, now it is also useless

Ge0rG: An XMPP replacement wouldn't help. Those who could already jumped over to Slack (I know a few orgs which migrated to Slack from enterprise IM solutions).

I think the Lync team has learned that given how their product is sold to enterprise exec teams, usability and quality doesn't actually impact the bottom line.

moparisthebest: hm. interesting point. I had bad lags with a coworker today, but I blamed his wifi

that seems correct waqas , it's just part of the exchange/outlook package

waqas: I don't care about Slack and I'd love to migrate our 20-person business away.

waqas: unfortunately, the Outlook / calendar integration is a huge selling point

And integration with the MS stack in general, the admin tools, policies, etc

Yeah, but I suppose I could convince my coworkers with a better mobile UX if we keep screen sharing and possibly VoIP

How's skype for business on mobile? I've only seen it on desktop

waqas: it sucks. Pretty bloated app, and you don't get messages to both Desktop and mobile

So you have message loss along the way

Kind of like xmpp without 0198 and carbons

And crashes on startup sync in the best Skype tradition?

:P

or not?

our stuff is hosted on O365 but still only allows connections from the work VPN

so it's the worst of both worlds