XSF Discussion - 2018-05-04

  1. winfried


  2. jonasw

    in 2 hours?

  3. winfried

    (oops did I do it wrong?)

  4. jonasw

    my last information was 1300 CEST

  5. jonasw

    (a.k.a. 1100Z, so maybe timezone confusion?)

  6. winfried

    probably... feel I am living in a different zone right now ;-)

  7. winfried

    "Date of Next: 2018/05/04 11:00 UTC" - I am not totally crazy ;-)

  8. jonasw

    oh oops

  9. jonasw


  10. Kev

    11:00Z is in two hours (just under)

  11. winfried

    From the mail from pep.

  12. jonasw


  13. jonasw


  14. jonasw

    now I’m super confused

  15. jonasw

    and I *do* have UTC timestamps in MUCs.

  16. winfried

    so am I

  17. jonasw

    I don’t seem to be awake

  18. Kev

    It's 09:07Z at the moment.

  19. jonasw

    09:06:09 winfried> "Date of Next: 2018/05/04 11:00 UTC" - I am not totally crazy ;-)

  20. jonasw

    so yes, GDPR in 2h

  21. winfried is fixing timezone bug in his mind

  22. jonasw

    echo 'Etc/Utc' | ssh winfried 'sudo tee /etc/localtime'

  23. winfried dives into a mild jetlag, Amsterdam is not in UTC

  24. winfried

    I know where it is coming from: I always regard myself as the center of the world. :-D

  25. winfried

    will be back at 11:00 UTC ;-)

  26. jonasw


  27. winfried

    second attempt ;-)

  28. jonasw

    riiight, and I managed to entirely forget about this in the meantime :)

  29. jonasw

    I’m goood

  30. jonasw

    pep., Ge0rG, GDPR in 0

  31. pep.


  32. pep.

    Same, I did also entirely forget

  33. pep.

    So, what's up for today

  34. winfried

    When updating the WiKi, I came across a question (is MAM 6.1a or 6.1b)

  35. winfried

    I want to discuss briefly how we handle existing specs

  36. pep.

    I think we settled on MAM is opt-in?

  37. pep.

    And that should be fixed in the XEP/clients

  38. jonasw


  39. winfried

    pep.: correct, but, if i recall correctly, the reason for it was that MAM is not 'naturally' part of the package when you are communicating

  40. pep.

    We won't go as far as to prompt the user when he decides to enable MAM right? I mean from the server. « Hey you're enabling MAM, here is what happens no: [..] »

  41. winfried

    pep.: exact

  42. pep.


  43. pep.


  44. pep.

    I'm not sure if we should go this road

  45. winfried

    but just enabling MAM rather is requesting a service in sense of art 6.1b then an opt-in in the sense of art 6.1a

  46. Ge0rG

    sorry I'm late.

  47. winfried

    welcome, Ge0rG

  48. jonasw

    winfried, is it? I’d say it’s kinda 6.1a

  49. jonasw

    is it very relevant?

  50. jonasw

    (which of it it is)

  51. winfried

    yes, 6.1a has quite tight regulations (art. 7)

  52. winfried

    6.1b not

  53. jonasw

    winfried, Art 7 should be no problem for enabling MAM

  54. winfried

    And the server operator should prove the client has asked the question, kind of hard

  55. jonasw

    winfried, that was one of my original questions in the whole GDPR-in-XMPP discussion

  56. jonasw

    who is liable if the client didn’t properly ask?

  57. jonasw

    is it the client developer? or can the server operator rely on the client asking properly and blame the client if it didn’t?

  58. pep.

    yeah and we haven't answered this really. Not that I'm qualified to

  59. winfried

    we can avoid that problem altogether if it is 6.1b, what is rather appropriate IMHO because enabling MAM is requesting a storage service

  60. jonasw

    I’m not convinced though that this is any type of contract

  61. winfried

    jonasw: what is your doubt?

  62. jonasw

    it may be my IANAL, but when I think contract, I think more formal than ticking a box in a UI

  63. jonasw

    with terms & conditions I can read and am aware of etc.

  64. pep.

    jonasw, that's what the EULA XEP is for right

  65. jonasw


  66. pep.

    When I asked above « are we going to prompt the user when he decides to enable MAM, from the server », I had in mind some version of that

  67. winfried

    the eula xep is for the obligation to inform. And because the MAM (in case of a muc) may be hosted on an other server, it may be appropiate to include a link to the EULA in that question to...

  68. pep.

    Like, client issues MAM query, EULA kicks in and requests ticking a box, and MAM gets enabled only if accepted

  69. jonasw

    winfried, and then, wouldn’t the server operator still have to kinda prove that htere’s that contract with the user, in case of doubt?

  70. pep.

    I think the burden of proof is required anyway

  71. winfried

    pep.: using the service is enough burden of proof for a contract, not for 6.1a

  72. pep.

    When the user creates an account, "please read terms & conditions. Here's what going to happen to your data [for X, Y reasons]. Are you ok with it?". This is what I'm picturing

  73. pep.

    I see

  74. winfried

    pep.: when going 6.1b, just informing is enough

  75. pep.

    Shall we allow for both in EULA then? 6.1b only (no ticking box), and 6.1a (ticking box, plus blocking operations)

  76. winfried

    pep.: don't know if that is any help, you still need the infrastructure for the burden of proof of 6.1a

  77. pep.

    I think MAM would fall under 6.1b like jonasw. The operator can state in the terms, "If you enable [MAM], here is what will happen"

  78. winfried

    pep.: exactly

  79. winfried

    Ge0rG: can you give your opinion on this? I propose we move on in the mean time...

  80. pep.


  81. winfried

    We have a list of XEPs that have potential deletion problems, should we check other (all?) XEPs for issues?

  82. jonasw

    winfried, have you followed the discussion on standards@?

  83. pep.


  84. jonasw

    I’d like somebody except me to reply to the last part of the thread.

  85. jonasw


  86. winfried

    nope, didn't will look into it

  87. pep.

    jonasw, the part where people don't want to mix the XEP and laws?

  88. pep.

    protocol / laws*

  89. jonasw

    that, and the part with "better have a separate xep which discusses that"

  90. pep.

    Yeah. well changes are still required in the XEP to allow deletion via the protocol anyway right? This doesn't have to be because of local laws

  91. MattJ

    Right, I think the two things are separate

  92. jonasw

    daniel is against a deletion flow AFAIK

  93. MattJ

    I'm not saying I'm in favour of deletion (or against), I just think it's a separate concern

  94. pep.


  95. MattJ

    An out-of-protocol deletion would work just as well

  96. MattJ

    Meanwhile there may be a non-GDPR case where someone accidentally shares the wrong file/picture

  97. pep.

    Not so long ago a user asked on movim@ for that iirc

  98. jonasw

    hah, just the other day :>

  99. MattJ


  100. jonasw

    and that fun day when somebody posted very ... uhm ... interesting ... drawn content in prosody@

  101. MattJ

    I guess I somehow missed that

  102. winfried

    I will respond in standards and I will need some time here to think it over: there are lots of things at stake in that discussion

  103. pep.

    We'll need to clear this issue while we're asking for changes in lots of other XEPs

  104. Kev

    My uninformed take on this is that the GDPR shouldn't mean any need to change any protocols, but that having notes in specs saying "but consider this" is worthwhile.

  105. pep.

    Because the same question will appear over and over

  106. winfried

    It has also to do a bit with localization of the XMPP network and values around an open internet. And *every* technology is political and XMPP certainly is. But we must take that discussion to the standards list.

  107. Ge0rG

    winfried: sorry, got caught up in a business call

  108. Ge0rG feels ashamed and guilty

  109. pep.

    Ge0rG, pff

  110. winfried

    Ge0rG: expected sth like that

  111. winfried

    We have half an hour left now, can tick Q.2 there?

  112. winfried

    (can we)

  113. pep.

    Can we ?

  114. pep.

    is that Q1.2 rather than Q2?

  115. pep.

    I was still stuck in 1.1e in my minutes..

  116. winfried

    pep.: you are right.

  117. winfried

    I think 1.1e is about done by now

  118. pep.

    k, I'm not really clear on the boundaries of 1.1e, I have also mixed that with 1.2 certainly

  119. winfried

    and the discussion @standards certainly is 1.3 ;-)

  120. pep.


  121. Ge0rG

    winfried: regarding the consent. I think it's technically not feasible (and neither legally reasonable) to ask for explicit consent for passing data from the user to other servers/third parties, for when the user tries to communicate with those third parties

  122. Ge0rG

    So "by using this server to communicate with third parties you agree that data will be passed to third parties" is IMHO a good trade-off

  123. winfried

    Ge0rG: agree

  124. jonasw

    Ge0rG, the consent thing was about local MAM though

  125. winfried

    pep.: plz put that sentence of Ge0rG in the minutes, we need it ;-)

  126. pep.

    winfried, we already had something similar, but yes

  127. Ge0rG

    jonasw: re local MAM the question is interesting.

  128. Ge0rG

    my position is that the client needs to inform the user that by enabling MAM, they will enable MAM.

  129. Ge0rG

    or rather, ask the user for consent to store data on the server.

  130. Ge0rG

    I've called out clients that silently auto-enable MAM before. Without success.

  131. lovetox

    But client doesnt know server policies, so how good is that consent?

  132. Ge0rG

    lovetox: did I hear "data-forms"?

  133. lovetox

    yes good idea, but then its not only the client anymore 🙂

  134. pep.

    Ge0rG, so that's 6.1a realm?

  135. pep.

    And some more XEP (or just EULA?) required for this, as I was asking above

  136. winfried

    pep.: I would say: that is still informing and 6.1b

  137. Ge0rG

    lovetox: the server has a kind of tri-state of MAM of (undefined, enabled, disabled). The client comes and silently enables MAM. Who's at fault?

  138. winfried

    all processing is odne to deliver the service the user requested, nothing more.

  139. lovetox

    What i want to say is, it would make sense for the server to communicate the policy on enable, or a xep that lets us retrieve those

  140. pep.


  141. Ge0rG

    I'm not sure how far we can put MAM in 6.1b land

  142. lovetox

    so we can really inform the user, not just say "we now going to store data somewhere, for some unkown time, and we dont know what will happen with it"

  143. winfried

    lovetox: correct

  144. pep.

    ok, so what I've been asking above :P

  145. pep. slowly filling the gaps in the minutes

  146. winfried

    Ge0rG: what is your doubt? MAM is an archiving service and the user agrees to use that for that service, I would say that is 6.1b

  147. jonasw

    winfried, but the server would still have to prove that hte user agreed to that service, right?

  148. Kev

    jonasw: Surely that's part of the service agreement the user sigs up to?

  149. Kev


  150. winfried

    jonasw: difficult wording there, when you decide yourself to start using a service, then you agree to the data processing that is inherent to that service

  151. pep.

    you have to know what kind of processing though

  152. pep.

    That'd have to be ack-ed before signing in

  153. winfried

    pep.: the information must be available and up to date (art 12 if I recall correctly)

  154. pep.


  155. winfried

    pep.: but for 6.1a it has to be acked on forhand, for 6.1b not

  156. pep.

    So in the IBR processus or similar, "This is what you are signing for. [Create]"

  157. winfried

    pep.: yes

  158. pep.

    hmm, trying to summarize all this..

  159. pep.

    date of next?

  160. winfried

    a hairy issue is what if a client enables MAM by default? And does it make a difference if the UI of the client suggest storage or if it suggests the absence of persistence? And who is liable then?

  161. pep.

    winfried, what jonasw was asking

  162. pep.

    20:10:05 jonasw> winfried, that was one of my original questions in the whole GDPR-in-XMPP discussion 20:10:10 jonasw> who is liable if the client didn’t properly ask? 20:10:23 jonasw> is it the client developer? or can the server operator rely on the client asking properly and blame the client if it didn’t?

  163. winfried

    pep.: translated to what we know now...

  164. MattJ

    What happens if you have a web-based consent form, but the user has some obscure browser that doesn't render the page correctly

  165. MattJ

    and maybe it has a bug that swaps the "I consent" and "I do not consent" button text

  166. winfried

    I think we can argue that if the client suggest immediate deletion but enables MAM silently the client is liable

  167. pep.

    MattJ, that's always been an issue? :x

  168. Kev

    winfried: But that the server presumably still had to say "If you enable MAM, we'll store X"?

  169. pep.

    GDPR is not changing anything here

  170. winfried

    Kev: yes it has to inform

  171. jonasw

    pep., but the analogy help with the "what if the client doesn’t do things right" question

  172. MattJ

    pep., but now the server owner is legally liable? :)

  173. jonasw

    date of next?

  174. winfried

    MattJ: about what consent form are you talking? I am right now trying to circumvent all consent forms!

  175. winfried

    Mo, Tue, Thu & Fri are possible for me

  176. pep.

    Mon/Tue/Wed ok for me, the rest might be more difficult

  177. winfried

    Mon or Tue?

  178. pep.

    Actually.. I'll be in Karlsruhe with some other xsf people, so I can also do it from there :P

  179. pep.

    Assuming it's not *too* early (as I'll be in holidays ><)

  180. jonasw

    Mon is not possible

  181. jonasw

    Tue would work

  182. pep.

    Tue 12:30CEST?

  183. jonasw


  184. pep.

    I'm in CEST next week btw, all week

  185. jonasw


  186. winfried


  187. winfried

    I will have to go, won't be waiting for Ge0rG

  188. pep.


  189. pep.

    The minutes won't appear just right now but I'll try to do that quickly

  190. winfried

    pep.: thanks once more!

  191. winfried bangs a gavel, hoping Ge0rG hears it and confirms tuesday

  192. Ge0rG

    next week I'm completely unavailable

  193. winfried

    :-( is there any way we can still get your input?

  194. moparisthebest

    thanks MattJ ! so XEP-0368 is constructed the same way (same misunderstanding of requirements section) and I copied from there so this has been a long ongoing misunderstanding :)

  195. MattJ

    Heh, so it is... never noticed :)

  196. moparisthebest

    it even got all the way to Draft that way haha

  197. MattJ

    Yeah, surprised nobody else noticed

  198. MattJ

    It's documented here: https://xmpp.org/extensions/xep-0143.html#sections-reqs

  199. jonasw hides

  200. MattJ

    The technical stuff should be in "Use Cases", as e.g. "This is how a client should connect to the server" etc. etc.

  201. moparisthebest

    I *probably* copied an existing XEP back in 2015 but I couldn't even begin to guess

  202. MattJ

    Take a look at https://xmpp.org/extensions/xep-0297.html#requirements for a simple example, or https://xmpp.org/extensions/xep-0313.html#requirements for an example that replaces an existing protocol (and discusses why)

  203. moparisthebest

    https://github.com/xsf/xeps#new-protoxeps should mention XEP-0143 I think

  204. moparisthebest

    again I can't recall but I don't exactly remember reading it

  205. jonasw

    moparisthebest, that README is for editors, not for authors

  206. moparisthebest

    ok, then there should be a readme/section for authors :)

  207. jonasw

    right on the top it says: > To submit a new proposal for consideration as a XEP, please read this page: https://xmpp.org/about/standards-process.html#submitting-a-xep

  208. moparisthebest

    ah yes and then suggests the wrong way to do it

  209. moparisthebest

    (email editors instead of pull request)

  210. jonasw

    that’s not wrong

  211. jonasw

    just old

  212. moparisthebest

    and both links https://xmpp.org/extensions/xep-template.xml and https://xmpp.org/about/xsf/xsf-source-control/ is broken

  213. jonasw

    mailing the editors is still totally a fine thing to do

  214. jonasw

    moparisthebest, PRs against the website welcome

  215. moparisthebest

    I would just put the correct procedure at the top of the readme in the xeps repository

  216. jonasw

    why not both

  217. moparisthebest

    yea and fix the website

  218. jonasw

    PRs welcome

  219. jonasw

    will be happy to review htem

  220. pep.

    "By creating a post, you agree to Imgur's [Terms of Service] and [Privacy Policy]" What imgur.com has btw

  221. jonasw

    wait until May 25th

  222. jonasw

    I’m still getting at least two mails per week from esrvices which have adapted their ToS/Privacy stuff

  223. jonasw

    and imgur didn’t do that yet

  224. jonasw

    so that may still be a WIP

  225. pep.


  226. pep.

    I'm also getting spammed by policy updates

  227. Ge0rG

    There is an easy solution to the GDPR now! https://gdpr-shield.io/

  228. moparisthebest

    ha I love it

  229. Ge0rG

    > We provide you with a JavaScript snippet that you'll paste into your site's existing HTML code > We'll check every user that visits your site and block access to users from the EU. This happens in the background and doesn't affect your site's speed for non-EU users

  230. Ge0rG


  231. MattJ


  232. moparisthebest

    Or just put a "EU citizens not allowed" disclaimer in your TOS, that's what I did in the motd of my IRC server for German citizens

  233. Ge0rG

    moparisthebest: I'd say that doesn't qualify

  234. moparisthebest

    Why not?

  235. moparisthebest

    How could I be liable if you illegally use my service in violation of my terms?

  236. Ge0rG

    moparisthebest: I'd say you need to explicitly block the EU IPs

  237. moparisthebest


  238. Wiktor

    Does it really apply to moparisthebest's IRC server? I guess he doesn't collect any personal info there.

  239. moparisthebest

    I think similar should work everywhere even if you do collect PII

  240. Wiktor

    Yeah but irc doesn't need your personal data and by design it's a public forum.

  241. jonasw

    but most nickservs operate using email adrseses

  242. jonasw

    which are PII

  243. Ge0rG

    And IPs. You need those against spambots!

  244. Wiktor

    A similar thread was recently here https://news.ycombinator.com/item?id=16661323

  245. Wiktor

    > Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR. Source: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en

  246. moparisthebest


  247. Wiktor

    I think a ToS like moparisthebest would strongly signal it does not target EU.

  248. Ge0rG

    Wiktor: I think that "specifically targeting" are weasel words that need to be checked by courts.

  249. Wiktor

    Sure, I'm not your lawyer, but I wouldn't panic if I was moparisthebest :)

  250. Ge0rG

    Why, you can't panic often enough.

  251. moparisthebest

    EU citizens are forbidden from using this IRC server - This is specified so the GDPR does not apply: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en

  252. moparisthebest

    added that to my motd, done and done, GDPR is easy!

  253. MattJ

    I really don't think it works like that :)

  254. Ge0rG

    MattJ: I might have said the same thing before, without convincing anybody.

  255. moparisthebest

    no one is going to sue me for that anyway, but if they do, I think 'they were forbidden from using my server' is a pretty strong argument

  256. moparisthebest

    also 'go *&@! yourself I'm not flying to the EU to appear in court' is pretty good too

  257. pep.

    re gdpr-shield, I was going to ask what if I disable JS, but in that case I probably won't have access to the website anyway :)

  258. Ge0rG

    pep.: websites on .io require JS, didn't you know?

  259. pep.

    yeah I know

  260. pep.

    That's why I corrected myself

  261. Wiktor

    > This won't apply to every U.S. business — just the ones that are knowingly, and actively, conducting business in the EU. In this vein, EU courts have the discretionary ability to determine if a U.S. company was purposely collecting EU resident data and subverting GDPR compliance. So, in some cases, the inadvertent collection of personal data will be forgiven if it is found to have been occasional and "unlikely to result in a risk to the rights and freedoms of natural persons." Source: https://community.spiceworks.com/topic/2007530-how-the-eu-can-fine-us-companies-for-violating-gdpr

  262. moparisthebest

    does anyone know if any servers implement bcc from here? https://xmpp.org/extensions/xep-0033.html#addr-type

  263. Zash


  264. moparisthebest