danielCan a muc member revoke their own membership?
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
jonaswprobably not?
danielI don't find anything specific related to that in the xep. Maybe some servers just allow the admin command if the removed user matches user who runs the query
Dave Cridlandhas left
ZashIsn't membership editing limited to the owner(s)?
Guushas left
Kevhas joined
danielYes that's what I meant. Maybe some specific implementations allow that if the member you want to edit is the requesting member
danielBut it's certainly not explicitly mentioned in the xep
winfriedWell, that may be a GDPR issue... :-(
Ge0rGdaniel: that's only half a step away from allowing members to make themselves an owner ;)
Dave Cridlandhas left
jonaswwinfried, not sure. the owner is responsible for the members list.
jonaswmuch of this might boil down to the question whether users have the right to have their data deleted from other peoples data.
ZashAn exception for members leaving the group makes sense
Guushas left
jonaswlike, my roster is *my* data, are you allowed to force me/my server operator to delete your JID from my data?
winfriedjonasw: storage and membership are two different processings
jonaswwinfried, where’s the difference?
Zashjonasw: That doesn't happen tho
jonaswZash, what doesn’t happen?
ZashJust updating the subscription state to none
SamWhitedhas joined
pep.Zash: yeah makes sense, there could be an exception for that
jonaswZash, I think somebody argued that even storing PII like the JID could be an issue.
ludohas left
intosihas joined
ludohas joined
danielhas left
Dave Cridlandhas left
ZashGroup creator storing other people's jids?
SamWhitedhas left
winfriedjonasw Ge0rG pep. if you are able look at the document I send to the members list before the meeting of 12:30, it would be very helpful
ZashGe0rG: Easy MUC leaving ?
jonaswwinfried, I don’t see a document on the members list
jonasware you subscribed?
ZashI saw it
jonaswmeh, restarting my MUA
jonaswthere it is!
Ge0rGjonasw: Akonadi FTW!
Dave Cridlandhas left
jonaswGe0rG, indeed. akonadictl restart and 5s later it’s on order. jokes aside, it has some weird troubles with switching networks while the notebook is suspended :/
pep..odt aww, you're going to force me to use the big guns
winfriedZash: yes, storing a JID as MUC owner is a 'processing' in the context of the GDPR, but it not a very problematic processing
jonaswpep., I can put a .pdf somewhere
pep.Nah I have libreoffice it's fine
lskdjfhas joined
pep.I just never use it
ZashNo .txt? :)
winfriedsorry about that, I just wanted to go to bed after working 14 hours straight yesterday and didn't want to figure out how I would be able to put that table in the Wiki (what I would have preferred)
jonaswwiki tables are a PITA indeed
jonaswmaybe Zash can apply some pandoc magic to convert this to mediawiki markup?
winfried:-D be my guest!
Dave Cridlandhas left
ZashPandoc probably reads odt, so sure
rtq3has joined
danielhas left
rtq3has left
rtq3has joined
Dave Cridlandhas left
remkohas left
remkohas joined
danielwe don't have to make that about gdpr. but if clients tend to show the entire member list (not just the currently joined users) we should give users the ability to actually 'leave' a muc
Dave Cridlandhas left
jonaswdaniel, indeed
pep.daniel: agreed
ZashThere being three or so separate lists is fun too
jonaswthree separate lists?
danielowner, members admins
Ge0rGwinfried: awesome table, looks good to me
SamWhitedhas joined
jonaswI can’t parse the table.
jonaswspeaking of which, I might not be very useful in todays meeting.
pep.I'm on my phone with nothing installed for that ATM (still in bed :-°)
jonaswnot your fault though, I’m tired and exhausted for unrelated reasons.
danielhas left
winfriedjonasw: any amount of coffee that would resolve the issue?
MarandaLazy pep. it's past 10
andyhas left
jonaswwinfried, I’m caffeine-free for several months now; also, no :)
pep.Maranda: BST not CEST
MarandaPft then it's past nine still lazy
Ge0rGtook a 1000km trip last week to grab his coffee machine.
jonaswthat’s some serious dedication!
jonaswor addiction.
MarandaIndeed
MarandaI think more the latter
SamWhitedhas left
MarandaBut could be dedicated addiction
Ge0rGI can stop any time I want!1!!
ZashWhy would you tho
MarandaOr dedication to addiction
pep.winfried: "how to safeguard on remote server?", that also came across last time, what falls on the recipient's consent exactly?
MarandaWhichever sounds better
pep.Can we clarify this during the meeting
Ge0rGI think we don't need to ensure explicit consent to s2s delivery.
winfriedpep.: yes, please note questions like these, the thing is still subject to improvement
winfriedGe0rG: agree, but *only* if no additional processing is done on the remote server :-(
rionhas joined
Ge0rGwinfried: technically, the remote server is subject to the GDPR because you forward it data from EU citizens, right? ;)
Marandalooks at the calendar
Marandaplaces a big red cross
Ge0rGwinfried: I wonder if we need contracts or in-band XML markup for that
rtq3has left
Marandaputs enphasis on the red and big
jonaswwinfried, you wrote "implicit permission" for user metadata (presence) in grounds for processing; but isn’t approving a presence subscription explicit permission?
jonaswGe0rG, both
Ge0rGjonasw: it's explicit approval but implicit data sharing permission, I'd say
jonaswhmkay
winfriedGe0rG: yes, I have the same line of thought, the question if it is subject to the GDPR is not settled yet, and probably not relevant at all
winfriedjonasw: yes, correct, plz take notes
rtq3has joined
winfriedhas to do some other job now
danielhas left
vanitasvitaehas joined
danielhas left
Guushas left
andyhas joined
rionhas left
vanitasvitaehas left
vanitasvitaehas joined
pep.And Maranda, it's not because you might have obligations that I also have to get up before 9 :p
jonaswwinfried, what do you mean by "can we safeguard XY on remote server?"?
jonaswdo you mean "can we ensure that on remote server?"?
winfriedjonasw: ensure
jonaswright
winfriedpep. Ge0rG present?
pep.!
Ge0rGhi there
winfried*bangs* the gavel
jonaswquick announcement: I’ll have a hard cutoff today at 13:30 CEST due to a meeting with my master thesis supervisor
winfriedjonasw: he can wait, this is more important :-D
lnjhas left
lnjhas left
jonaswI’ll tell him that, I bet he’ll be convinced ;-)
winfriedshall we from out the table I have build?
rtq3has joined
jonaswwinfried, so, we’re plowing through Q1.1e today?
jonaswseems good
SamWhitedhas left
winfriedAny questions / amendments / additions
winfried?
jonaswnot right now
danielhas left
winfriedOk, then lets tackle the issues top to bottom ;-)
jonaswlet’s do that
winfriedWe need to inform about the processing
jonaswthe EULA thing in the credentials row seems to be a technical TODO for the EULA-XEP
rtq3has left
rtq3has joined
Ge0rGjonasw: EULA doesn't imply EULA XEP. Yet.
winfriedjonasw: what do you mean with "EULA-XEP"? A XEP containing a standardized EULA?
pep.winfried, additions, what I asked this morning
jonaswwinfried, a XEP which defines how clients obtain the key points from a servers EULA. it would (in my mind) also contain *defaults* which apply to every xmpp server.
jonasw(that would be among them)
pep.Once the message hits s2s, is it on the recipient's consent, for whatever reason. Unless it's a service on the other end not a person
rtq3has left
Ge0rGjonasw: did you check https://en.wikipedia.org/wiki/P3P for overlaps?
rtq3has joined
jonaswno
Ge0rGpep.: I claim it's fair game to tell your users that whatever you send to a remote server is subject to that server's ToS
pep.Ge0rG, but they wouldn't know what server, would they
jonaswwith the EULA XEP it *would* be possible to have your client show you that ToS.
Ge0rGpep.: by sending a message to mark@facebook.com your messages are subject to facebook ToS.
pep.Ge0rG, but in her client it's written "Mark"
jonaswbut I think it’s even more fair game (and less critical) to say that "a message you send to someone is handled like the recipient wants, not like you want"
Ge0rGpep.: show me a client that doesn't expose the JID of newly added users
pep.jonasw, I agree with that, not sure how to expose it to users
pep.Ge0rG, ok, now explain that to users
jonaswpep., I think that’s common sense.
jonaswGe0rG, once we’re at the point of invitation URLs we might get rid of most of that. I wouldn’t rely on that.
pep.Explain to users that's it's 2 different things, localpart and domain, and not just one thing
Ge0rGjonasw: I disagree
pep.I agree with jonasw
jonaswfight!
Ge0rG"somebody who claims to be called jonas wants to add you to their contacts. [yes] [no] [wtf is jonas]"
vanitasvitaehas joined
Ge0rGnow stop bike-shedding please.
Ge0rGwe've got real business to accomplish here.
pep.Just for completeness, "Hey foo, I gave your details to bar, he's going to add you" *foo receives a contact request from _bar_* [yes] [no]
pep.back to 1.1e?
winfriedtakes my eyes of the chatwindow and sees a catfight upon return
jonasw:D
jonaswmeows innocently
lnjhas joined
jonaswso what do we have?
winfriedI propose to postpone this discussion and start a top: informing the user upon account creation
SamWhitedhas left
jonasw+1
winfriedthat doesn't need a EULA-XEP
Ge0rGwinfried: maybe it does, if the user does IBR
winfriedbut a standard/model EULA may come in here handy
winfriedGe0rG: isn't IBR evil and banned?
jonaswyeah
jonaswno, IBR isn’t banned
jonaswit’s even getting developed
jonaswsee XEP—0401 for example.
pep.And maybe in a not-so-distant future clients will support data forms
winfriedOK
Ge0rGSo there are different things we might understand under "EULA XEP":
- a template for writing server EULAs
- a protocol for informing the client about the EULA URL
- a protocol for informing the client about specific EULA details
- an s2s protocol to let remote users know of your EULAs
la|r|mahas joined
jonaswin my mind it’s a mix of the first and the third point
winfriedGe0rG: +1
pep.Ge0rG, I was kind of including all the above
jonaswyeah, kinda all of those actually
pep.Maybe less focused on s2s at first, but that was mentioned a few times
ThibGhas joined
winfriedWill that be 1 XEP or 4?
jonaswdo we need to figure out the formalities of that XEP in this meeting?
Ge0rGstrictly speaking, we don't need any of those, except #2 for IBR
pep.I think the direction is good
winfriedGe0rG: +1
Ge0rGSo I suggest we skip out the EULA topic
ZashTemplate / guidelines for writing an EULA sounds like an informal XEP if anything✎
Ge0rGZash: 👍
SamWhitedhas joined
pep.Ge0rG, the s2s thing, how do you do that without a XEP?
pep.Same for 3. actually
pep.But yes I agree the details of the XEP can be done outside this meeting
Ge0rGpep.: my point is: we haven't yet established the need for any EULAs but the ones between a user and their server
ZashTemplate / guidelines for writing an EULA sounds like an informational* XEP if anything ✏
winfriedSummary to solve first block: template EULA + protocol for informing client of EULA URL for IBR
Ge0rGpep.: and until there is a legal requirement to have remote EULA consent dialogs, we don't need an s2s EULA XEP
pep.ok ok
winfriedcorrect? Then we can move to the second blob
jonasw+1
Ge0rGOtherwise we'll have to maintain a list of remote EULAs the user has accepted and block access to any other domains. Ain't that great?
pep.Ge0rG, not saying it is, at all :/
winfriedMetadata in C2S context
winfriedI guess we need to inform server operators about the limits here
Ge0rGwinfried: good point.
Ge0rGwinfried: so we need a second document aimed at server operators outlining the limits
pep.yep
winfriedyes
jonaswyes
SamWhitedhas left
pep.Ok so 1.1e really is "come up with that document"
winfriedI guess we need also mention this in the EULA template
winfriedbut do we need to communicate any standardized EULA clauses to the clients here or a link to the EULA?
ludohas left
winfriedI guess maybe keep the link visible
jonaswboth is good
winfried(and handle changes)
jonaswwtih both I mean a combination of both
jonaswthat’s essentially whta the EULA-XEP originally was about
winfriedthird Blob
Zasheula { url, registered clauses ... }
winfriedMetadata in S2S context
Ge0rGwith standardized EULA clauses, we are really in the P3P territory and somebody should have a hard look at that prior work
jonaswI think all the "how to ensure on remote servre" things can be answered with "not".
jonaswGe0rG, I’ll put that on my todo.
jonaswbut I can’t promise anything
winfriedGe0rG: I don't know *how* standardized that has to be
winfriedBut P3P sure is a good thing to look at
Ge0rGwinfried: me neither. I'd say that having a human-readable ToS template is a good first approximation for now
winfriedGe0rG: +1
marmistrzhas left
Ge0rGunless the current s2s blob makes us formalize enforceable s2s requirements
Guushas left
Ge0rGwhich I hope to avoid at any cost
winfriedjonasw: ensuring remote server, can't be done on a technical level
jonaswwinfried, exactly
jonaswand on a legal level it’s at least questionable.
winfried(if the data is readable, ik can leak)
jonaswis it the responsibility of the service operator to ensure that all s2s peers comply?
Ge0rGwinfried: it's possible to enforce on a technical level that the claimed s2s server's policy matches the user's requirements
ZashIs it not enough to say that communication with remote peers are up to them, the user consentend when they sent a remote-addressed stanz
jonaswI’d even go as far as "sends any stanza to a user which is not themselves"
Ge0rGI see three outcomes:
- we can't / won't enforce any s2s behavior / compliance claims
- every server needs to advertise whether they comply with GDPR
- P3P style fine-grained formal description
jonaswbecause even on the same server users might’ve opted in to MAM while you didn’t
winfriedI am in doubt now
pep.jonasw, that could make sense
winfriedGe0rG: first one, we may say: transfer is obvious to other server and part of the service the user requested, so leave it
Ge0rGwinfried: does that apply both to EU and thrid contries based servers?
winfriedbut then we come in the realms of forwarding my mail to gmail
winfriedGe0rG: yes
Ge0rGdoes it need to be obvious to the user where the server is hosted?
lnjhas left
Valerianhas left
Valerianhas joined
winfriedGe0rG: good question, don't have a definitive answer to that: transfer outside the EU needs to be mentioned in the EULA, but the legal demands for S2S inside the EU are the same as outside the EU (in the context we have now)
winfried- "- every server needs to advertise whether they comply with GDPR" - that may not be needed, advertise 'no secondary use / profiling' would suffice!
winfried- "- P3P style fine-grained formal description " is in my opinion an overshoot (but that is an opion)
Ge0rGwinfried: so I suppose just covering the possibility of EU and third-country transfer in the EULA is sufficient?
winfriedGe0rG: I *guess* so, would be interesting to take to court though...
pep.hmm, can we come back to user-metadata C2S for a sec, I'm trying to find points to write down, but apart the TODO: document for server operators, I don't see much
pep.The EULA XEP is also mentioned in every step concerning C2S for now
winfriedpep.: also publish a link to the EULA, needs to stay available + system for versioning the EULA...
pep.I was hoping to include versioning into the XEP, not yet sure how/if really needed
jonaswand notifying the user of changes
pep.yeah that as well
winfriedBut do we want to reside on the most minimal version of S2S: inform it can happen, don't ensure anything on the remote server
lumihas left
pep.Inform *s2s* can happen?
Guushas left
Guushas left
Guushas left
winfriedpep.: yes
jonaswwinfried, do we have a choice?
winfriedIf it is obvious to the user it is handled by an other server with other legal status, it is ok like that, but we had that 'does my mother understand' catfight.. that is relevant here
lnjhas left
pep.I'd be enclined to even say to the user "careful your messages may be considered differently once you send any stanza to a user which is not you", as jonasw mentioned above
pep.So even C2S
jonaswwinfried, I don’t think we can make that obvious
jonaswTLDs are not a safe indicator for that, IPs are a bit better, but not available to the client.
pep.+1 to that ^
jonaswunless it does SRV lookup for the service itself
jonaswwhich may easily yield you a geo-located response with your closest entry ponit to the cluster
jonaswso it would look as if it was EU from within the EU, but in fact the servers are partially outside the EU
jonasw(DNS round-robin could case something similar with less fancy efforts)
Andrew Nenakhovhas joined
ThibGhas joined
matlaghas left
winfriedI don't think we need to handle inside EU and outside the EU differently here: both are allowed if it us needed the perform the servers the user requests
jonaswTL;DR: we can’t really show that to the user and have to assume the worst.
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
winfriedThe issue is, do we need to tell the user if more is done with the data then is needed for performing the service the user requested?
jonaswI don’t know.
pep.I think we do, yes
Andrew Nenakhovhas joined
pep.Well legally I don't know
Ge0rGwinfried: I'd say we need something like "messages sent to users on other servers are subject to those servers data usage policies"
Ge0rG+ yadda yadda non-EU countries
pep.+ other user's settings?
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
winfried+ & + +1 ;-)
pep.wat wat
Ge0rGpep.: two different statements, first about other users -> their archival config, second the above one
Ge0rGI'll make an attempt at writing an EULA once I have the time. In a month or so
jonasws/to users on other servers/to other users/;s/to those servers data usage policies/to the policies the those users agreed to, which may be more liberal than the policies you agreed to/
pep.you still have a month and 2 days before GDPR, you're safe
pep.yes I'd prefer jonasw's version
lnjhas left
pep.I don't know if that holds legally, but that's a bit more thorough
jonaswI don’t either
winfriedSo no need for a S2S EULA XEP?
pep.If we have this kind of disclaimer I don't think so?
mhterreshas joined
mhterreshas left
pep.Though, we were at "metadata"
pep.Not data, yet
pep.But I guess that still holds
winfriedI would *like* to know it, but is it needed for the GDPR? I doubt it.
winfriedmaybe write a XEP like that and advertise it as 'good practice'?
pep.winfried, probably implicit consent with roster subscriptions, or user joining MUCs etc.
Ge0rGpep.: I think everything said above also holds true for data
pep.Ge0rG, same
winfriedGe0rG: +1
jonaswGe0rG, +1
pep.Do we go with Ge0rG or jonasw's version?
rionhas joined
jonaswif the "once you send it to the recipient, the recipient is responsible" holds, we’re good with it I think
Ge0rGjonasw had the better polished wording
pep.good
winfriedeverything said here holds on the content too, except for MAM storage
jonaswΔt=-6m
pep.winfried, how does it not include MAM
jonaswwinfried, how’s MAM storage different?
pep.Plan for next?
winfriedthat one is legitimate interest of third party (maintaining a log)
winfried(art 6.1f)
Ge0rGwinfried: with the receiver being the third party?
pep.winfried, third-party as is recipient? That falls under "messages send to other users are subject to policies those users agreed to"✎
winfriedyes
jonaswwhat pep. says
pep.winfried, third-party as is recipient? That falls under "messages sent to other users are subject to policies those users agreed to" ✏
jonaswI gotta run in a few mins, plan for next?
winfriedjonasw: yes
jonaswI don’t have time tomorrow or on Wed
winfriedthursday same time?
jonaswThu or Fri would work, usual time
jonaswThu 12:30 CEST
pep.Thu same time worksforme
jonaswGe0rG, ^
Valerianhas left
Ge0rG+1 on either
jonaswit’s settled then
jonaswanything else?
winfriedThu 12:30 CEST
winfriedGood work again!
pep.We've covered credentials, User metadata/data (C2S/S2S) then
jonaswthanks all!
jonaswheading out now
winfriedpep.: much applies to content to
winfriedjonasw: good luck!
pep.yes, "data"
pep.ah it's called content
pep.ok
pep.hmm, instead of "messages", we should say "Stanza" probably?
winfriedpep.: if you mail the logs, then I will try to update the schedule
winfriedpep.: +1
pep.Or something that the end-user can undertand
ZashI pandoc'd this https://wiki.xmpp.org/web/GDPR/Table if that's fine
pep.instead of stanza
winfriedZash: yes, that would be great!
pep.Zash, nice
SamWhitedhas joined
winfriedAny possibilities to add lines between the fields?
winfriedZash: it *IS* great, thanks a lot!
ZashI don't know, I'm not /that/ familiar with mediawiki syntax.
winfriedZash: I will have look myself otherwise...
ZashPlease do, it's a wiki after all :)
winfriedZash: :-D
pep.Zash, do I include you in the participants? :)
Zashpep.: Maybe a little? I barely follow this tho.
pep.winfried, today's minutes compress well :P
jubalhhas joined
winfriedpep.: I also took some notes myself, but they are not objective ;-)