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

Kinda surprised enterprises are going slack considering it's like $8 a seat.

I mean $80 a month for 10 users is pretty steep

That's probably nothing for an ENTERPRISE

Yeah, or they just stick to the free plan somehow

I'm not sure it's a great deal for enterprises who need like 1000 seats.

Any idea how much Lync costs?

jjrh, for 5000 users with M$ Exchange you may arrive to pay like $800k a year

Any idea how much the coffee consumed by 1k people costs?

Maranda, yeah but exchange provides a whole lot more than chat.

(that's licensing)

I mean that's still nutty to me but considering email is in many cases more critical than even phones I can see businesses justifying it.

jjrh, hmm not really beside some very nutty cases of course :P

jjrh, and doesn't provide that much, spam wise for example Exchange doesn't support SPF, DMARC or DKIM iirc, only O365/OWA (Hotmail) does.

protip: enterprises don't care at all how much it costs as long as they can get a demo, good support, and a fixed and predictable price that includes the ability to expand service in the future. $8 per seat is *nothing* compared to the cost of the paycheck of all the people who will have to set it up and deal with it.

SamWhited, not at that level :P, infact you won't see a single ISP (beside Microsoft itself) ever deploying Exchange.

SamWhited, I mean I totally get that and i'm not suggesting enterprises deploy and support their own solution for chat, but it seems like $8 per seat (and their enterprise version is like $12) isn't a great deal when say https://about.mattermost.com/pricing/ has a $3.25 a seat and a 'custom pricing' for when you have a lot of users.

I dunno maybe mattermost sucks never used it

but of course 8*5000 = 40k so it's doable :P

12 per seat as well

Does mattermost provide them with a person who flies out and does a demo?

Do they provide SLAs? Really good tech support?

Probably

I wonder how people will do with the recent Slack introductions

I have no idea, they might, but the price just doesn't matter at all.

in terms of privacy

I'd be curious how much profit slack is actually making. Maybe their pricing is to offset the free offerings and their hosting costs are dirt cheap so they don't really need many customers

Also, places that used to buy from a previous job I was in did heavy risk analysis: will mattermost go out of business tomorrow and we'll have to switch again? Not likely, but maybe. Will Slack? Probably not.

(Like that a team owner or something has access to all the data, even private message)

Do you not have that with mattermost? Because that's also a plus for slack in the enterprise space if so

compliance logging and such, yeah

But anyways, point was that price doesn't matter at all. It's probably not even part of their considerations. Stuff like that does.

I'm not sure I would bank on slack staying in business. Chat is fickle, and a logical thing for voip providers to start selling.

I would think that enterprises would be a little nervous about having their chat data hosted in datacenters they don't own. Maybe if you're dropping half a million a year slack will do whatever you want.

Yah, that part is the tough one. Depending on who you are and what you do, a lot of places really have to have a behind-the-firewall version, which is why HipChat Server makes so much money.

cisco also had some fancy stuff about full encryption (including search) for spark. selling point apparently

oh nifty, I didn't know that; I really wanted to try to build something like that while at HipChat but couldn't convince anyone that it would be a selling point.

samwhited: https://www.cisco.com/c/dam/en/us/solutions/collateral/collaboration/cloud-collaboration/cisco-spark-security-white-paper.pdf

thanks

Most BigCorp have adopted the cloud by now so on premise chat servers are only interesting for medical and military services now

They have adopted the cloud but their own cloud

and on premise is more "on our vpn"

jjrh: not my experience with multiple big customers

Interesting. I would have thought there would be legal implications depending on where the server is located and a risk that the SAS company could be compelled to give up your data if they run into issues.

Ge0rG: that's actually what I've found to be true for the most part. At ThreatGRID we couldn't do anything that wasn't a physical on-prem device because we serviced a lot of financial sector people, but at HipChat Server we *only* supported AWS, because basically everyone had their private networks hooked up to Amazon or entirely within Amazon.

jjrh: that was my initial guess as well, but if you are an international company, you are susceptible to the laws of whoever wants your data anyway

So outside of finance and military stuff, everyone seemed to be fine with "private clouds"

"private" networks.

They're private, because if they're not Amazon gets sued for billions of dollars. They have good insentive to make them as private as possible.

Yeah, seeing an enterprise with 100k+ employees fully embracing O365 made my head spin.

0365?

Microsoft Office 365, the cloud offering

0 or O

ahh,

I assumed you did not mean XEP-0365, or RFC 365, neither of which made sense but both of which I thought of in the context of this chat

But isn't the difference here that if you use slack they are running 100% of the show - today they might be on AWS, tomorrow on some other service, but you as a customer really don't have any say regarding that.

Zash: fix your font

heh, they look completely different in my terminal and I still didn't notice that that was an "O"

Bummer.

ОO0ΟΘ

Ω