XSF Discussion - 2018-05-22

  1. la|r|ma has joined
  2. lskdjf has joined
  3. ta has joined
  4. ta has joined
  5. Dave Cridland has left
  6. Dave Cridland has left
  7. lnj has left
  8. dwd has left
  9. j.r has joined
  10. j.r has joined
  11. Dave Cridland has left
  12. Dave Cridland has left
  13. Dave Cridland has left
  14. dwd has left
  15. Chobbes has left
  16. alexis has left
  17. dwd has left
  18. alexis has joined
  19. waqas has left
  20. dwd has left
  21. Dave Cridland has left
  22. Dave Cridland has left
  23. Neustradamus has left
  24. jonasw has left
  25. jonasw has joined
  26. alexis has left
  27. Neustradamus has left
  28. alexis has joined
  29. alexis has left
  30. alexis has joined
  31. Dave Cridland has left
  32. Neustradamus has left
  33. Neustradamus has joined
  34. Dave Cridland has left
  35. waqas has joined
  36. dwd has left
  37. Dave Cridland has left
  38. Dave Cridland has left
  39. dwd has left
  40. Guus has left
  41. j.r has left
  42. j.r has joined
  43. Zash has left
  44. Dave Cridland has left
  45. alexis has left
  46. alexis has joined
  47. efrit has joined
  48. alexis has left
  49. alexis has joined
  50. Dave Cridland has left
  51. dwd has left
  52. Chobbes has joined
  53. alacer has joined
  54. SamWhited has joined
  55. alacer has left
  56. alacer has joined
  57. alacer has left
  58. alacer has joined
  59. SaltyBones has left
  60. alexis has left
  61. alexis has joined
  62. alexis has left
  63. SaltyBones has joined
  64. alexis has joined
  65. alexis has joined
  66. Guus has left
  67. Neustradamus has left
  68. Ge0rG has joined
  69. ta has left
  70. ta has joined
  71. Neustradamus has left
  72. alexis has left
  73. mrdoctorwho has left
  74. alexis has joined
  75. lorddavidiii has joined
  76. efrit has left
  77. SamWhited has left
  78. SaltyBones has left
  79. SaltyBones has joined
  80. Nekit has joined
  81. marmistrz has joined
  82. jere has joined
  83. marmistrz has joined
  84. j.r has joined
  85. j.r has joined
  86. alexis has left
  87. lorddavidiii has left
  88. Tobias has left
  89. Tobias has joined
  90. winfried has joined
  91. winfried has joined
  92. Andrew Nenakhov has left
  93. Andrew Nenakhov has joined
  94. Andrew Nenakhov has left
  95. Andrew Nenakhov has joined
  96. Guus has left
  97. Andrew Nenakhov has left
  98. Andrew Nenakhov has joined
  99. Andrew Nenakhov has left
  100. Andrew Nenakhov has joined
  101. goffi has joined
  102. tux has left
  103. tux has joined
  104. Nekit has left
  105. Nekit has joined
  106. lovetox has joined
  107. bear has left
  108. andy has joined
  109. Seve/SouL has left
  110. Neustradamus has left
  111. Guus has left
  112. lorddavidiii has joined
  113. ralphm has left
  114. Tobias has left
  115. Tobias has joined
  116. bear has joined
  117. Guus has left
  118. mimi89999 has joined
  119. intosi has joined
  120. Guus has left
  121. Guus has left
  122. j.r has joined
  123. SaltyBones has left
  124. SaltyBones has joined
  125. j.r has joined
  126. j.r has joined
  127. j.r has joined
  128. Tobias has joined
  129. daniel has left
  130. SaltyBones has left
  131. SaltyBones has joined
  132. Tobias has joined
  133. SaltyBones has left
  134. Dave Cridland has left
  135. lnj has joined
  136. ralphm has joined
  137. la|r|ma has joined
  138. rtq3 has joined
  139. rtq3 has left
  140. remko has joined
  141. rtq3 has joined
  142. SaltyBones has joined
  143. nyco has left
  144. marmistrz has joined
  145. nyco has joined
  146. marmistrz has left
  147. SaltyBones has left
  148. SaltyBones has joined
  149. SaltyBones has left
  150. SaltyBones has joined
  151. SaltyBones has left
  152. SaltyBones has joined
  153. SaltyBones has left
  154. SaltyBones has joined
  155. Valerian has joined
  156. SaltyBones has left
  157. SaltyBones has joined
  158. Steve Kille has left
  159. Steve Kille has left
  160. Dave Cridland has left
  161. Steve Kille has joined
  162. pep. has left
  163. Valerian has left
  164. Valerian has joined
  165. SaltyBones has left
  166. la|r|ma has joined
  167. rtq3 has left
  168. Dave Cridland has left
  169. flow has left
  170. flow has joined
  171. flow has left
  172. flow has joined
  173. alexis has joined
  174. Steve Kille has left
  175. alexis has left
  176. alexis has joined
  177. blabla has left
  178. blabla has joined
  179. mimi89999 has joined
  180. lskdjf has joined
  181. alexis has joined
  182. rtq3 has joined
  183. alexis has left
  184. daniel has left
  185. daniel has joined
  186. j.r has left
  187. j.r has joined
  188. alexis has joined
  189. marmistrz has joined
  190. ralphm has left
  191. SaltyBones has joined
  192. lumi has joined
  193. jubalh has joined
  194. mimi89999 has left
  195. daniel has left
  196. ibikk has left
  197. ibikk has joined
  198. j.r has joined
  199. j.r has joined
  200. jubalh has joined
  201. jubalh has joined
  202. jubalh has joined
  203. jubalh has joined
  204. daniel has joined
  205. ralphm has joined
  206. edhelas has left
  207. edhelas has joined
  208. SaltyBones has left
  209. SaltyBones has joined
  210. jubalh has left
  211. jubalh has joined
  212. SaltyBones has left
  213. SaltyBones has joined
  214. waqas has left
  215. j.r has joined
  216. j.r has joined
  217. SaltyBones has left
  218. SaltyBones has joined
  219. lskdjf has left
  220. lskdjf has joined
  221. rtq3 has left
  222. rtq3 has joined
  223. andy has left
  224. SaltyBones has left
  225. SaltyBones has joined
  226. ibikk has joined
  227. la|r|ma has left
  228. SaltyBones has left
  229. SaltyBones has joined
  230. nyco has left
  231. nyco has joined
  232. j.r has left
  233. j.r has joined
  234. pep. gdpr meeting in 10?
  235. pep. jonasw, winfried, Ge0rG
  236. SaltyBones has left
  237. SaltyBones has joined
  238. SaltyBones has left
  239. SaltyBones has joined
  240. SaltyBones has left
  241. mimi89999 has joined
  242. SaltyBones has joined
  243. SaltyBones has left
  244. SaltyBones has joined
  245. SaltyBones has left
  246. SaltyBones has joined
  247. Ge0rG pep.: I thought 1230?
  248. Ge0rG But I can do either
  249. pep. Ah fail
  250. pep. 10:30 UTC indeed
  251. jonasw sudo -u pep. sudo apt install tzdata 😸
  252. jonasw a.k.a. timezones are hard
  253. ta has joined
  254. pep. `useradd: invalid user name 'pep.'`
  255. Ge0rG RCE over MUC=
  256. winfried has left
  257. jonasw Ge0rG: only in signal :>
  258. jonasw has left
  259. j.r has left
  260. SaltyBones has left
  261. j.r has joined
  262. Andrew Nenakhov has left
  263. SaltyBones has joined
  264. Andrew Nenakhov has joined
  265. Steve Kille has left
  266. Andrew Nenakhov has left
  267. Andrew Nenakhov has joined
  268. ThibG has joined
  269. ThibG has joined
  270. SaltyBones has left
  271. daniel has left
  272. Steve Kille has joined
  273. ibikk has joined
  274. jonasw GDPR in 9, Ge0rG, winfried, pep.
  275. pep. !
  276. Andrew Nenakhov has joined
  277. Valerian has left
  278. Ge0rG I have prepared temporary ToS and Privacy Policies for yax.im, which I would like to make available as a template for the XSF: https://yaxim.org/yax.im/tos/ and https://yaxim.org/yax.im/privacy/
  279. Valerian has joined
  280. Andrew Nenakhov has left
  281. Valerian has left
  282. daniel has joined
  283. winfried ;-)
  284. jonasw is a recital sufficient? or does it need an actual paragraph which instantiates that recital?
  285. Ge0rG a what?
  286. Valerian has joined
  287. alacer has left
  288. alacer has joined
  289. winfried bangs the gavel and welcomes pep. jonasw and Ge0rG to the GDPR meeting
  290. pep. !
  291. jonasw Ge0rG, your opt-out wording is confusing: > You can opt out from this by unsubscribing these contacts from your contact list. ("what does unsubscribing from a contact list mean?") I’d suggest: > By allowing a user to subscribe (typically this is done when adding to the contact list), you opt into this transfer.
  292. jonasw waves at winfried
  293. winfried jonasw: yes, wording it as an opt-in is better
  294. winfried Agenda for to?
  295. winfried s/to/today/
  296. pep. yeah, opt-in might be better
  297. pep. What do we have on the agenda today? The template?
  298. alacer has left
  299. pep. Not much progress on the EULA XEP. I gathered the requirements here, https://cryptpad.fr/code/#/2/code/edit/IiUC5h-fzN14FAeSdcBoAQgc/ but I haven't started the protocol bits
  300. alacer has joined
  301. winfried I feel like taking a look at the bigger picture: where are we, what is the course of action (looking at the MAM discussion in standards@) what are the todo's and how to do them
  302. jonasw I’d also word the push service paragraph differently: now: > If you enable push notifications (e.g. on a mobile client), the data that is required to perform the push notification (typically a device ID and message meta data) is transmitted to the respective push service provider (Art. 6.1b, Art. 49.1b). my suggestion: > If you enable push notifications (e.g. on a mobile client), the message is transferred (Art. 6.1b, Art. 49.1b) to a server designated by the client application. The processing afterwards is subject to the data protection policies of the applications server and the respective push service provider.
  303. jonasw yeah, sorry about the EULA XEP, I was more busy than I anticipated
  304. pep. jonasw, no worries, I didn't have much time either
  305. jonasw re push paragraph: because technically, you’re transferring the complete message to the applications service and then it’s already out of your control, Ge0rG.
  306. winfried neither did I ;-)
  307. jonasw if my memory of the push protocol is right
  308. winfried jonasw: daniel posted a nice link to the implementation he uses. It reveals minimal data, the push service even doesn't know what application it is pushing to!
  309. pep. winfried, of course it does? How would that work otherwise
  310. jonasw winfried, true, but as an XMPP server provider, you can’t be sure about which app server software is used.
  311. winfried jonasw: correct
  312. jonasw and you transfer at teh very least message body and timestamp to the app server, at which point it’s out of your control
  313. pep. jonasw, "app server"?
  314. pep. the push component?
  315. jonasw pep., the server provided by the client (e.g. Conversations) which transforms the XMPP Pushes (as specified in XEP-0357) to whatever is needed on the provider (google) side.
  316. pep. Right
  317. jonasw pep., cf. https://xmpp.org/extensions/xep-0357.html#sect-idm139090519180208
  318. jonasw "Push Service" and "User Agent" are owned by e.g. google, but the App Server is run by the client application authors, and not by the XMPP server provider
  319. Ge0rG jonasw: I'm not pushing actual message content, just placeholders.
  320. jonasw Ge0rG, is that a modification of mod_cloud_push?
  321. Ge0rG jonasw: no, default behavior with a custom setting.
  322. jonasw in any case, the statement is incorrect insofar that it suggests that (only) google/apple is the nexthop, but there’s the app server inbetween
  323. Ge0rG `push_notification_important_body = "Important message";`
  324. Holger jonasw: The protocol allows for including the sender address and message contents with the push notification, but that's optional and neither Prosody nor ejabberd will do that by default.
  325. Holger jonasw: The notification is not a message stanza but a PubSub-like IQ.
  326. Ge0rG jonasw: updated both places, thanks. Please have a look at the new push wording
  327. Dave Cridland has left
  328. Ge0rG Holger: we are not talking about stanzas but about user content.
  329. Ge0rG Holger: so "message" in this context is rather the <body> element.
  330. jonasw s/opt in into/opt into/?
  331. alacer has left
  332. Ge0rG isn't the verb "opt in"?
  333. Ge0rG maybe "opt in to"?
  334. winfried Ge0rG: I would say so
  335. Ge0rG !summon native speaker
  336. jonasw okay, nits though
  337. jonasw otherwise I think this looks good
  338. jonasw but, IANAL
  339. pep. Ge0rG, can I link to your yax.im URLs or should we move that to the wiki
  340. pep. in the minutes
  341. Ge0rG pep.: They are WIP right now, so I'd rather not have them linked "publically"
  342. jonasw copying would be fine though?
  343. pep. k, so maybe we can copy that to the wiki
  344. rtq3 has left
  345. Ge0rG I'd like to establish some process where we have a master copy and the yax.im ToS are a fork of that.
  346. winfried Ge0rG: git!
  347. Ge0rG so you can fork it yourself and profit from later updates.
  348. jonasw maybe a repository under xsf?
  349. jonasw or xmpp?
  350. Ge0rG markdown + C preprocessor?
  351. Ge0rG jonasw: moving a git is the easiest part.
  352. Ge0rG the hard part is the split of template and specific server content.
  353. jonasw hmm
  354. pep. Right
  355. jonasw jinja is a neat templating language
  356. Ge0rG Or maybe some kind of ToS generator?
  357. jonasw would be trivial to build a generator on top of that
  358. Ge0rG Jinja is Beautiful. {% extends "layout.html" %} {% block body %} <ul> {% for user in users %} <li><a href="{{ user.url }}">{{ user.username }}</a></li> {% endfor ...
  359. Ge0rG They lost me at {%
  360. jonasw they copied that from erb I think
  361. pep. I don't think we should focus on html
  362. Ge0rG Markdown is an ideal language for the content, minus the templating.
  363. jonasw the advantage I see in jinja that its inheritance and block stuff would allow for easy replacement of specific blocks.
  364. jonasw and extension
  365. jonasw that would be cumbersome with C preprocessor
  366. Ge0rG We could also `sed -e s/ZZZservernameZZZ/$SERVERNAME/g`
  367. jonasw those are technicalities
  368. Ge0rG or use bash here-documents.
  369. jonasw let’s focus on what winfried suggested
  370. Ge0rG I don't care. I just don't want to learn a new templating engine language.
  371. Ge0rG git?
  372. jonasw 10:34:00 winfried> I feel like taking a look at the bigger picture: where are we, what
  373. jonasw Ge0rG, ^
  374. Ge0rG :P
  375. Ge0rG Right.
  376. Dave Cridland has left
  377. pep. In the meantime I don't have anything to show for this part of the minutes :x
  378. pep. But we can sort this out later
  379. winfried hey, I am participating again :-P
  380. winfried Big picture: we have some things we want to change on protocol level
  381. winfried EULA-XEP
  382. winfried Deletion
  383. winfried Transfer of data
  384. winfried (any other?)
  385. daniel has left
  386. winfried ah, defaults for MAM
  387. Ge0rG retention times for MAM and HTTP uploads.
  388. Ge0rG Current implementations lack auto-removal of "expired" entries
  389. pep. s/HTTP uploads/server-side file storage/
  390. winfried There was some discussion on the standards@ list about incorporating local laws in standards
  391. Dave Cridland has left
  392. daniel has joined
  393. winfried what is our opinion in that?
  394. pep. Allowing deletion via the protocol has nothing to do with local laws right
  395. winfried I guess some topics are generic and not specifically for one jurisdiction
  396. Ge0rG winfried: the protocol purist in me says we should not encode local laws into our protocols.
  397. Ge0rG OTOH, the pragmatist requests an easy way for server operators to comply with local laws.
  398. pep. Ge0rG, I think I agree with that, but deletion itself is just a technicality and not a law
  399. rtq3 has joined
  400. pep. We might want to have another informational "GDPR compliance" XEP
  401. winfried Ge0rG: and what about an optional extension that describes an action needed in a certain jurisdiction...?
  402. Ge0rG winfried: I'd go with Business Rules paragraphs in relevant XEPs
  403. andy has joined
  404. Ge0rG while true ; do killall -STOP lua5.1 sqlite3 prosody.sqlite 'DELETE FROM prosodyarchive WHERE host="yax.im" AND store="archive2" AND "when" < '$(($(date +%s)-14*24*3600))' LIMIT 5000;' killall -CONT lua5.1 sleep 2 done
  405. Ge0rG This is how I'm doing GDPR compliance right now.
  406. winfried Ge0rG: :-D
  407. Ge0rG And this is not only fugly, it's also killing my availability / latency.
  408. jonasw sleep 2?!
  409. winfried I can imagine you want something more... sophisticated
  410. Ge0rG jonasw: yes. I can't just delete *all* messages at once because there are too many.
  411. Ge0rG deleting 5k takes <10s, so it's just barely bearable.
  412. pep. How many users do you have again?
  413. pep. Active users
  414. Ge0rG ~1k
  415. Ge0rG But I have some active bots, it seems. And for reasons beyond my understanding, those bots are using MAM
  416. winfried So do we agree on: 1) patching XEPs / adding XEPs when generic functionality is needed for compliance 2) adding busisness rule paragraphs to relevant XEPs to explain about local laws?
  417. pep. Ok, so back to XEPs,
  418. winfried 3) informational GDPR XEP?
  419. pep. if 3), is 2) required
  420. pep. We definitely need 1) in any case
  421. alacer has joined
  422. pep. And I don't think anybody will argue this
  423. winfried jonasw: ?
  424. Ge0rG what do we nee 1 for?
  425. Ge0rG patching XEPs is #2, isn't it?
  426. rtq3 has left
  427. winfried New XEP: eula XEP, http storage management
  428. jonasw Ge0rG, (1) is adding functionality, (2) is adding business rules
  429. jonasw those are differences, and (2) can be moved to a generic GDPR XEP, while (1) can’t
  430. jonasw (well, could, but it wouldn’t make sense)
  431. pep. jonasw, 1 could be added to an addon XEP, but :/
  432. pep. Not informal
  433. pep. **informational
  434. Dave Cridland I'd rather not plaster every XEP with detailed GDPR implementation stuff. Rather, at most a pointer to another XEP. Otherwise the conflict between different jurisdictions is going to get very complicated, especially with normative language.
  435. Ge0rG Re EULA XEP: do we need explicit consent?
  436. winfried pep.: think we need to decide on a case to case base if an add on is better of patching the xep
  437. Ge0rG If we need explicit consent, the EULA-on-IBR would be one possible implementation, with a web form based registration another obvious one.
  438. pep. Dave Cridland, 1. above is not "GDPR implementation stuff", right
  439. pep. 2 and 3 are, and I'm also leaning towards 3
  440. pep. rather than 2
  441. winfried I guess Dave Cridland meant the choice between 2 and 3
  442. Ge0rG Dave Cridland: I was thinking along the lines of "A server implementation must provide a way to delete user data by means of X"
  443. valo has joined
  444. Dave Cridland Ge0rG, Yes, but that's not true everywhere. Instead you need a feature to allow users to request deletion, but I'd rather a server in a jurisdiction that mandates retention isn't offering me that feature.
  445. pep. We will need to tell developers though where to find that XEP
  446. pep. XEP discovery is another common issue
  447. winfried pep.: "Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"
  448. pep. winfried, k
  449. alexis has left
  450. Ge0rG I can't see how we can create an (informational or other) GDPR XEP until May 25h.
  451. alexis has joined
  452. j.r has joined
  453. jonasw I agree
  454. j.r has joined
  455. jonasw I wanted to get EULA done by today, but schedules
  456. winfried Ge0rG: Nope, I have to finish a DPIA before then :-D
  457. Ge0rG Dave Cridland: I still think that a mention under Business Rules is required. Even if it says "Depending on local laws, you MUST or MUST NOT provide a way ..."
  458. Dave Cridland Ge0rG, If a XEP has the phrase "MUST or MUST NOT" I will have to nuke it from orbit.
  459. pep. What winfried said above
  460. pep. "Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"
  461. Dave Cridland Ge0rG, Also, "MUST" etc are related to interop, not legal requirements. I suspect that we (the XSF) may need to be careful about appearing to offer legal advice, too.
  462. winfried Ge0rG: can you explain why you think it is required?
  463. Dave Cridland pep., That phrasing works for me.
  464. Ge0rG Dave Cridland: why? It's only self-contradicting if it's "MUST *and* MUST NOT"
  465. rtq3 has joined
  466. Dave Cridland Ge0rG, Because it's meaningless.
  467. Ge0rG "this XEP may have global warming consequences, or may contain traces of nuts"
  468. pep. What doesn't have global warming consequences..
  469. alacer has left
  470. Seve/SouL And doesn't contain traces of nuts
  471. Seve/SouL 0:D
  472. Ge0rG Dave Cridland: but I agree that RFC 2119 language SHOULD NOT be applied to legal requirements.
  473. winfried pep.: the chilling effect (couldn't resist)
  474. jonasw :>
  475. Ge0rG winfried: LOL
  476. pep. :)
  477. pep. Ge0rG, so I read you'd prefer to have GDPR details *in* the XEP?
  478. pep. And not an informational XEP
  479. Andrew Nenakhov has joined
  480. Ge0rG pep.: I don't know. Whatever will make server implementors create compliant implementations works for me
  481. Valerian has left
  482. alexis has left
  483. jonasw I think general "privacy considerations" without mentioning legislation would be a good thing™
  484. pep. I'd see winfried's phrasing above, + informational GDPR xep
  485. Dave Cridland pep., Really don't want to do that. The problem there is that you'd also need to put in Sarbanes-Oxley, for example.
  486. jonasw it would help to create awareness, just like Security Considerations do
  487. jonasw and I think they have a place in the XEP
  488. pep. Dave Cridland, yes I don't want either
  489. Dave Cridland pep., That is, put GDPR sections in every XEP.
  490. pep. hmm
  491. alexis has joined
  492. Dave Cridland pep., Ugh. I'm being really unclear. I do not want GDPR bits in every XEP.
  493. pep. what GDPR bits
  494. pep. You'd be ok with just saying "seealso GDPR XEP"?
  495. Dave Cridland pep., Yes.
  496. jonasw I have something like "The protocol specified herein allows users to store data on storage controlled by the server, so deletion and retention times need to be considered."
  497. pep. Dave Cridland, ok then we agree
  498. jonasw I have something like "The protocol specified herein allows users to store data on storage controlled by the server, so deletion and retention times need to be considered." in mind.
  499. winfried Dave Cridland: if we create an informational XEP about Sarbanes-Oxley, I wouldn't mind other XEPs pointing to it
  500. Ge0rG Maybe the issues is if we actually need *every* *other* XEP to point to the new one?
  501. Dave Cridland It might actually be useful to note what data is retained by each XEP, since that has very wide applicability and use.
  502. jonasw Dave Cridland, that’s what I had in mind for "Privacy Considerations" sections in XEPs
  503. jonasw and a separate GDPR document could point out what to do with specific data.
  504. Dave Cridland jonasw, Right, and I think it also forms very useful input to consent, privacy policy, etc stuff on a more generic level.
  505. jonasw so in general, PCs (Privacy Considerations) would list: - what data is stored - what data is exposed to other servers and users - what is needed for data exposure (know the JID / needs to be subscribed / ...)
  506. pep. jonasw, that still seems GDPR-specific. Some other law might define "private data" entirely differently
  507. winfried Like that idea, but it will be quite a bit of work to update all XEPs
  508. rtq3 has left
  509. jonasw pep., doesn’t matter, I’d consider all user data in that section.
  510. winfried jonasw: +1
  511. Dave Cridland jonasw, +1 from me too, for whatever it's worth.
  512. pep. jonasw, k
  513. winfried and should we also add a paragraph like that to the RFCs?
  514. jonasw I’ll re-word my '363 PR to conform with that.
  515. winfried jonasw: great!
  516. pep. winfried, mined territory I assume :p
  517. Ge0rG Having a "Privacy Considerations" section with that data in all XEPs would be great. We could just link those from the server ToS
  518. winfried Ge0rG: with autodiscovery based on service discovery!
  519. jonasw can we plan for enxt?
  520. pep. Can we define quickly what would go into that informational XEP
  521. pep. So we can start working on it quickly
  522. pep. jonasw, +whatever should work for me. Friday with the small delay as usual
  523. winfried pep.: - steps for compliance - red flags
  524. jonasw I can only make friday I think
  525. alexis has left
  526. jonasw so friday 1230 CEST or 1330 CEST would be good for me
  527. winfried wfm
  528. pep. 1230 CEST worksforme
  529. pep. 1330 as well
  530. winfried 1330 not for me
  531. jonasw 1230 CEST on Friday, 25th it is then, Ge0rG?
  532. Ge0rG either is good
  533. Dave Cridland If someone writes the skeleton and an abstract for this GDPR XEP today, we can give it a number by tomorrow.
  534. winfried D-Day!
  535. alexis has joined
  536. Dave Cridland ... which might help "advertise" what you guys are doing.
  537. Ge0rG next number is 403, right? ;)
  538. Dave Cridland (It'd also give us something to blog about as the XSF)
  539. jonasw Ge0rG, no, next is 409 I think
  540. pep. Ge0rG, no that's MIX?
  541. Ge0rG Oh, wow.
  542. winfried Dave Cridland: good plan, I don't have time :-(
  543. jonasw I’ll try to dedicate my afternoon to the EULA XEP
  544. Ge0rG I'm behind on that thread.
  545. jonasw Ge0rG, cf. https://github.com/xsf/xeps/pulls
  546. Dave Cridland Ge0rG, I think MIX wants that, but I'd love to see the Editor creatively rearrange...
  547. jonasw 409 Conflict is also good ;-)
  548. Ge0rG I would have skipped 403 as well. But meh.
  549. jonasw Ge0rG, 404 isn’t skipped
  550. pep. yeah 409 is also fine :P
  551. jonasw it’s for MIX ANON
  552. jonasw (the order in the PRs is just weird)
  553. Ge0rG jonasw: NOOO!1!!
  554. jonasw gotta go now
  555. Dave Cridland I wondered if MIX Anon was intentionally at 404.
  556. jonasw Dave Cridland, it is
  557. Dave Cridland But yeah, I think we should skip it for amusement's sake.
  558. jonasw I don’t feel like renumbering them ;-)
  559. jonasw MIX anon is a good use for XEP-0404 imo :)
  560. Ge0rG I disagree. But what do I know.
  561. winfried Should I close the GDPR meeting? ;-)
  562. Dave Cridland By the way, huge thanks to you guys for doing this.
  563. pep. winfried, :)
  564. winfried jonasw: do you have time to also submit a skelton and abstract for a GDPR informational XEP?
  565. pep. jonasw, I can have a look at EULA, for the obvious bits? (if there is any)
  566. Dave Cridland wonders if he needed to opt-in to be mentioned in the minutes.
  567. pep. Dave Cridland, I was going to ask
  568. SaltyBones has joined
  569. winfried Dave Cridland: you revealed yourself, so no mercy :-D
  570. pep. But the logs of this room are public anyway, just like the minutes :P
  571. Andrew Nenakhov has joined
  572. jonasw winfried, no, sorry
  573. winfried I shouldn't do it, but I will give it a shot
  574. winfried (then)
  575. jonasw winfried, why shouldn’t you do it?
  576. jonasw if you’re uncomfortable with the markup, you can also just send me a markdown or whatever based document
  577. jonasw and I’ll transform it
  578. winfried time, am already terrible behind on an other GDPR project
  579. jonasw right
  580. winfried but it shouldn't be too much work
  581. jonasw do whatever you need to save time, my issue with the informational is mostly that I don’t have the big picture or anything
  582. jonasw I’m fine with an .odt if that’s what you’re most comfortable writing in
  583. winfried jonasw: k, let you know if I need anything
  584. winfried bangs a gavel and starts writing a XEP
  585. pep. Ge0rG, you're ok if I copy your tos/privacy policy to the wiki with a big "WIP"
  586. pep. And "To be moved to git"
  587. jonasw Dave Cridland, I don’t think I’ll be able to make the 24 hour agenda deadline for the council meeting with the EULA XEP though
  588. Ge0rG pep.: yeah
  589. andy has left
  590. andy has joined
  591. pep. We're still in Q1.1.2 right
  592. pep. or 1.1.3 maybe
  593. pep. Ah no 1.1.2
  594. pep. "consequences for server operators"
  595. pep. *1.2
  596. Valerian has joined
  597. ibikk has joined
  598. rtq3 has joined
  599. ibikk has left
  600. ibikk has joined
  601. Andrew Nenakhov has joined
  602. Andrew Nenakhov has left
  603. Andrew Nenakhov has joined
  604. SaltyBones has left
  605. SaltyBones has joined
  606. lumi has left
  607. pep. winfried, I'm not sure exactly what you meant by "Big picture: we have some things we want to change on protocol level" and "Transfer of data" specifically
  608. rtq3 has left
  609. winfried pep.: timestamp ? loosing my context ;-)
  610. pep. 19:50:33 winfried> Big picture: we have some things we want to change on protocol level 19:50:43 winfried> EULA-XEP 19:50:47 winfried> Deletion 19:50:56 winfried> Transfer of data 19:51:09 winfried> (any other?) 19:51:31 winfried> ah, defaults for MAM
  611. pep. (UTC+9)
  612. winfried ah...
  613. winfried that is the portability thing, download everything so it can be put on an other server
  614. pep. I see
  615. SaltyBones has left
  616. SaltyBones has joined
  617. jere has joined
  618. SaltyBones has left
  619. SaltyBones has joined
  620. ibikk has joined
  621. Holger has left
  622. lorddavidiii has left
  623. lorddavidiii has left
  624. pep. https://cryptpad.fr/code/#/2/code/edit/j5ggWca+SLu32klePWFOeCIK/ winfried, jonasw, Ge0rG if you can have a quick look before I send
  625. Ge0rG pep.: 👍
  626. SaltyBones has left
  627. SaltyBones has joined
  628. rtq3 has joined
  629. ta has joined
  630. winfried (Y)
  631. jonasw wfm
  632. jubalh has joined
  633. edhelas has left
  634. jonasw I’ll now try to merge the MIX PRs and then I’ll start to look at the EULA XEP
  635. edhelas has joined
  636. Steve Kille jonasw: thanks!
  637. Valerian has left
  638. Valerian has joined
  639. jjrh has left
  640. mimi89999 has left
  641. ta has joined
  642. lovetox has left
  643. SaltyBones has left
  644. SaltyBones has joined
  645. jjrh has left
  646. ta has joined
  647. Ge0rG jonasw: But 404!
  648. jonasw yes?
  649. Ge0rG Okay, I didn't do anything when that window of opportunity was open, so I have no right to complain about it.
  650. jonasw Steve Kille, is "RELIABLE-DELIVERY" not there yet or am I missing something?
  651. Ge0rG I'll just pile my sadness on top of the Pidgin-officially-encouraged pile and move on with life.
  652. SaltyBones has left
  653. blabla has left
  654. blabla has joined
  655. Steve Kille RELIABLE-DELIVERY is a piece of MIX that is needed, but it was clear that hte text in MIX was wrong and it might be useful elseowere
  656. SaltyBones has joined
  657. Steve Kille So, I (or someone else) needs to work out exactly what needs doing and write it.
  658. Steve Kille Running without this is probably not going to be a big deal for most deployments
  659. Steve Kille BTW using 404 for MIX-ANON was the choice of my co-author
  660. Steve Kille I think the humour is good
  661. Ge0rG IMHO, that number should have been used for "XEP not found"
  662. Steve Kille Kev got there first
  663. Andrew Nenakhov has left
  664. ThibG has joined
  665. Andrew Nenakhov has joined
  666. lorddavidiii has left
  667. Andrew Nenakhov has joined
  668. Andrew Nenakhov has left
  669. Andrew Nenakhov has joined
  670. SaltyBones has left
  671. SaltyBones has joined
  672. jonasw MIXes merged
  673. jonasw Steve Kille, FWIW, the conflicts were because somebody submitted editorial changes in the meantime (0.10.1 was released), but that was trivial to handle
  674. Steve Kille thanks very much for sorting this out.
  675. lovetox has joined
  676. Steve Kille Meanwhile, I've received some private editorial comments on 1.0.0, whch I will work at soon
  677. jonasw I renumbered it to 0.10.2
  678. lumi has joined
  679. jonasw it is not draft yet, and only draft can have 1.x.x
  680. jonasw and since the split was editorial as discussed, it got 0.10.2
  681. Steve Kille ah - I did not realize this.
  682. Steve Kille Given that over half of the text vanished from 369, this scarecely seems editorial
  683. Steve Kille I'm going to have to confess now that there were some technical changes
  684. Steve Kille Mamking the XEPs independnent needed changes
  685. Steve Kille Making Proxy JIDs work without MIX-ANON needed various changes
  686. jonasw uh
  687. jonasw yeah, I saw a namespace bump in there
  688. jonasw but I think that’s going to be needed either way
  689. jonasw I can’t really fix the version number now anymore, I’m afraid.
  690. jonasw so we’ll have to live with t hat
  691. Steve Kille shall I move to 11.0 when I do the next set of changes?
  692. Steve Kille All the others are at 0.1.0
  693. jonasw increment the last digit (the z in x.y.z) for purely editorial changes, and the second digit (y in x.y.z, reset z to 0) for changes which include non-editorial chnages
  694. Steve Kille I think that the changes since 10.0 deserve a seond digit bump
  695. Steve Kille However, it is just a number, and I am happy with whatever the experts decree
  696. jonasw I agree that a second digit bump would’ve made sense
  697. jonasw but that’s spilled milk
  698. jonasw more or less
  699. Steve Kille I was asking if it makes sense to make the bump as part of the editorial changes I will make soon?
  700. jonasw ah, now I understand
  701. jonasw I’ll abort the build and fix the version number to 0.11.0
  702. Steve Kille if that is not too much trouble, I think that makes most sense
  703. jonasw done
  704. Steve Kille you're a hero
  705. Valerian has left
  706. rtq3 has left
  707. jjrh has left
  708. jubalh has joined
  709. Valerian has joined
  710. j.r has joined
  711. j.r has joined
  712. marmistrz has left
  713. jonasw pep., Ge0rG, what do you think about announcing the TOS version via disco#info *and* stream features? This would allow servers to announce updates via stream features s.t. clients can pick that up
  714. pep. jonasw, sgtm
  715. Ge0rG jonasw: aren't we overloading our caps infra already?
  716. jonasw not sure
  717. jonasw for servers I don’t think so
  718. pep. jonasw, what do you do with it then? the client knows there's a new version, where does it fetch it
  719. jonasw pep., via the in-band protocol
  720. pep. Ok ok
  721. pep. iq or ad-hoc?
  722. jonasw not sure yet
  723. jonasw I think ad-hoc won’t do the trick
  724. Valerian has left
  725. Valerian has joined
  726. Valerian has left
  727. pep. I'd prefer iq I think, but I don't have a strong opinion
  728. rtq3 has joined
  729. SaltyBones has left
  730. pep. All the features a user will opt-in, they also need to be able to opt-out easily btw. Should that also be done via the xep (one place to rule them all, "easy discovery"), or let the client decide where each feature config should go? e.g, Preferences > MAM > [x] Enable; Preferences > Other feature > [ ] Enable
  731. pep. Meh, I don't think the one place to rule them all would work
  732. jonasw yupp
  733. pep. that'd need to fiddle with every other modules
  734. Ge0rG There is one place to rule them all. "Delete account"
  735. jonasw that needs to go into the individual XEPs, just like it’s handled currently
  736. pep. Ge0rG, no
  737. pep. Say I still want to benefit from the services, but I want to opt-out of every consented feature
  738. pep. Doesn't have to be "please delete MAM", just "Please no MAM anymore"
  739. jonasw https://paste.debian.net/hidden/eb963ea8/
  740. jonasw pep., Ge0rG, ^
  741. pep. "The user shall be able to retract consent [..]", I don't have the exact quote
  742. pep. An error occurred during a connection to paste.debian.net. SSL peer rejected your certificate as expired. Error code: SSL_ERROR_EXPIRED_CERT_ALERT :(
  743. jonasw nice
  744. pep. I'll have to change that client cert..
  745. jonasw s/https/http/ will work though
  746. pep. yeah.. unfortunately
  747. Ge0rG "The server subsequently replies with the &tos; payload:" - that sounds like it's a ToS *payload*, but it's merely a ToS *link*
  748. jonasw Ge0rG, it is a payload of the ToS protocol
  749. pep. Ge0rG, I'd like to allow for both
  750. Valerian has joined
  751. pep. If you want to point to an external source, good for you. You might also want to handle this in-band
  752. Ge0rG Let's talk about XHTML-IM ToS payloads.
  753. jonasw pep., it’s not realistic to have the complete document in-band
  754. pep. jonasw, that's fine as long as EULA is only used for c2s
  755. pep. I mean, oob is fine**
  756. jonasw I’m thinking however, if we actually make Ge0rGs thing into a template, that we could use that template and have the server say things like "this is template X version Y, with the following things filled in: MAM retention time = xyz, upload retention time = abc, representative = frank nord"
  757. Ge0rG representative = Jon Snow.
  758. andy has left
  759. pep. jonasw, I'm sure that template will get hairy quickly
  760. jonasw maybe, but maybe not
  761. pep. Plus operators will want to modify more than just placeholders
  762. jonasw pep., in any case, putting the whole ToS in-band won’t work.
  763. pep. won't work how?
  764. jonasw question 1: which markup format to use for formatting?
  765. pep. We don't have anything to do formatted payloads anymore? :)
  766. pep. Too bad
  767. jonasw I would have argued strongly against anything XHTML. way too much, markdown would be sufficient, if it was standardised.
  768. pep. but styling is not markdown.
  769. jonasw styling is not sufficient
  770. pep. Don't tell me
  771. jonasw you need headings in a ToS, and enumerations and lists
  772. jonasw I am confused
  773. Ge0rG Are we talking about Markleft or Markright?
  774. pep. Ge0rG, both
  775. pep. Also Markhtml
  776. jjrh has left
  777. Valerian has left
  778. Valerian has joined
  779. jonasw pep., do you happen ot have a link to your EULA XEP pad at hand?
  780. pep. https://cryptpad.fr/code/#/2/code/edit/IiUC5h-fzN14FAeSdcBoAQgc/
  781. jonasw ty
  782. Andrew Nenakhov has joined
  783. blabla has joined
  784. marmistrz has joined
  785. lovetox has left
  786. jonasw pep., Ge0rG: https://sotecware.net/files/noindex/tos.html
  787. jonasw sorry for the lack of CSS
  788. blabla has left
  789. blabla has joined
  790. jonasw pep., Ge0rG, winfried, here’s a preview version with CSS: https://sotecware.net/files/noindex/xeps/tos.html ; I’d appreciate any early feedback.
  791. jonasw I think this should cover the basic points for now, we can expand on this for including more information about the ToS in the payloads later.
  792. pep. jonasw, example 2 contains </stream:features>
  793. Ge0rG jonasw: the title might better be "ToS Reference" than just "ToS"
  794. jonasw pep., ty
  795. vanitasvitae has left
  796. jonasw Ge0rG, "Terms of Service Agreement"?
  797. jonasw because it also handles ACK-ing the ToS
  798. jonasw I find ToS a good name still.
  799. daniel has left
  800. daniel has joined
  801. pep. jonasw, can we not use oob or sims or something that's already there to give the url?
  802. jonasw pep., what would be the benefit?
  803. pep. Not reinventing the wheel
  804. alexis has left
  805. pep. hmm, oob doesn't allow for MIME, sims does though
  806. Ge0rG Wasn't there an IBR extension by daniel?
  807. winfried jonasw: what when there are several documents like a ToS and a separate Privacy statement?
  808. alacer has joined
  809. jonasw pep., but it wouldn’t be re-usable much except for wire format maybe, and it would tie us to the SIMS namespace
  810. pep. jonasw, I don't know what the convention is, but I'd put <deadline/> inside <tos/> maybe
  811. mhterres has joined
  812. mhterres has left
  813. jonasw pep., but semantically, the deadline is for the change not for the ToS itself
  814. SamWhited has left
  815. winfried Can it also be communicated when it is obliged to agree to the terms or when it should only be available
  816. SamWhited has joined
  817. jonasw winfried, that’s a good question
  818. jonasw winfried, that’s a good question (regarding multiple documents)
  819. pep. jonasw, right.. I'm a bit annoyed at having this directly in <message> for some reason
  820. jonasw winfried, regarding requiring agreement, sure, we can communicate that, but does it make sense?
  821. SaltyBones has joined
  822. jonasw winfried, is there a good reason to separate the documents?
  823. jonasw this will increase the complexity a lot because we either have to put human-readable titles in the wire-format (complexity with i18n) or pre-define the types of documents we want to support
  824. pep. Maybe we can just allow multiple sources of the same type
  825. Guus has left
  826. efrit has joined
  827. jonasw pep., how would that look in a client UI? > you have to agree to the following terms to use the service: > document 1 (link) > document 2 (link) :/ that looks awful
  828. alacer has left
  829. pep. Well.. having both links for plain/text and plain/html, what will clients display anyway?
  830. pep. randomly choose between the two?
  831. jonasw unless you’re poezio, you’d probably link the text/html thing
  832. jonasw and dispatch to a web browser
  833. jonasw poezio might as well show the text/plain version inline
  834. pep. pardon my UX skills, but as a user I'd prefer to have a choice
  835. jonasw most users don’t want to
  836. jonasw they don’t even care about the difference between html and plaintext :)
  837. Guus has left
  838. pep. which is also why I use poezio unlike "most users"
  839. Dave Cridland winfried, You know, you *could* use a SASL2 task for EULA agreement.
  840. pep. jonasw, anyway, I can live with just one document (and optionally multiple types), for the original question
  841. Andrew Nenakhov has joined
  842. jonasw Dave Cridland, i’d love to see a SASL2 task to replace my pre-bind/post-auth hack
  843. jonasw IBR integration is still on the todo
  844. winfried jonasw: communicating the requirement to agree: some documents (like the privacy statement) only need to be available, while some others, like a 6.1a question, need to be agreed upon.
  845. matlag has joined
  846. winfried jonasw: and that is also an answer to the other topic: if you have both, you want to present both with a different status
  847. jonasw winfried, okay, that makes things much more complex.
  848. pep. Right. I've seen services present me multiple ToS I could agree to
  849. jonasw I was operating under the assumption that we have a ToS document (including privacy policy) which needs to be agreed to always and that all 6.1a questions are handled separately already.
  850. jonasw (such as MAM)
  851. winfried pep.: yeah, that is ugly, but there may be good reasons for
  852. jonasw back to the scratchpad then
  853. pep. winfried, I guess we can skip this though, and do as jonasw says, have opt-in features be handled separately
  854. winfried jonasw: in our GDPR route, we avoid asking 6.1a questions, but other setups or other jurisdictions may have different needs
  855. pep. winfried, as in, clients would have UI for this, some configuration somewhere
  856. winfried pep.: IF you offer an 'agree-iq', then you should also communicate if it is mandatory to agree it. Otherwise it is just informational
  857. daniel has left
  858. jonasw my assumption was that it’s always mandatory
  859. winfried jonasw: Nope, misconception #1 about the gdpr ;-)
  860. pep. I don't think it is (always mandatory).
  861. jonasw mmm
  862. jonasw okay, will have to re-do things then
  863. winfried jonasw: sorry...
  864. jonasw no, that’s great, we need a good thing here
  865. jonasw better sort it out before the first implementation comes along :)
  866. winfried Dave Cridland: love that idea, but I am happy you said *could* :-D
  867. pep. Yeah I'd like to see what that looks like as well
  868. lovetox has joined
  869. jonasw winfried, okay, would this work: - we have a list of documents which can be reviewed by the user - we have a list of tickboxes where users can consent to things which aren’t handled elsewhere (e.g. additional content analysis which would go into 9.1 territory or something) - the tickboxes default to false - agreement to individual documents is handled via the tickboxes, if at all. - a service would put the terms for the tickboxes in their privacy policy document by default
  870. daniel has joined
  871. Andrew Nenakhov has left
  872. Andrew Nenakhov has joined
  873. jonasw so the UI would be something like this: +----------------------------------+ | | | Terms of Service | | | | Service xy has the | | following Terms. | | Please review: | | | | - Terms of Service (link) | | - Privacy Policy (link) | | | | [ ] Allow analysis of my | | messages for marketing | | purposes | | (see Privacy Policy §12.3) | | [ ] Allow sharing my contacts | | with Facebook | | | | | +----------------------------------+
  874. Wiktor has left
  875. jonasw + a [Register] or [Continue] button
  876. jonasw the tickboxes would be provided by the service
  877. pep. Also [Cancel], that would close the stream? :-°
  878. jonasw probably
  879. pep. Would MAM go in these [ ], or would it be in client configurations like we said above
  880. jonasw I would put that in client configuration
  881. pep. Because then we're separating stuff that requires consent
  882. pep. I mean there would be stuff all around, not just one place to accept
  883. jonasw if you choose to enable MAM, you have of course already read the privacy policy and thus know the terms for MAM
  884. jonasw yeah
  885. pep. Right
  886. jonasw A service could of course also put the MAM switch in there, but it’s useless if the client doesn’t support MAM, so it would be confusing.
  887. jonasw the tickboxes would be entirely service-define
  888. jonasw the tickboxes would be entirely service-defined
  889. pep. Makes sense
  890. Ge0rG that looks like a data form.
  891. jonasw Ge0rG, the tickboxes will use data form wire format indeed
  892. jonasw Ad-Hoc command wire format even
  893. Ge0rG The issue I have is that yaxim will not connect to the server until you fill out the username + password fields.
  894. jonasw so?
  895. ibikk has joined
  896. pep. Ge0rG, pulling down a XEP because of client implementation? how dare you :o
  897. Ge0rG pep.: I didn't write "The issue this XEP has"
  898. winfried pep.: a [Cancel] would be up to the server to decide, it may only disable certain functionality
  899. pep. Ge0rG, :)
  900. pep. winfried, if a user cancels, what happens legally? they don't agree to the ToS, but they can continue using the service?
  901. pep. I'm a bit confused
  902. Ge0rG I like how you have sorted out race conditions between the user reading and the ToS updating here... `<agree xmlns='urn:xmpp:tos:0'><version>0.1.0</version></agree>`
  903. winfried pep.: depends on the question. If the question is: "i agree to connecting to my facebook account" (or so) then not ticking the box would only stop that part of the processing, not all XMPP service
  904. jonasw is cancel really a thing?
  905. jonasw i mean yeah, cancel would mean that you don’t want to use the sevrice at all because you don’t agree with it’s ToS
  906. pep. jonasw, [disagree], I guess
  907. pep. jonasw, [Disagree], I guess
  908. Alex has joined
  909. jonasw the non-negotiable parts of the ToS, because the negotiable parts are formulated as tickboxes
  910. pep. jonasw, yes
  911. Ge0rG jonasw: I don't like the use of headline messages. With always-on clients, I'd always fear sending a user a message in the middle of the night.
  912. pep. Ge0rG, it's always the night somewhere..
  913. pep. Ge0rG, it's always night somewhere..
  914. Ge0rG pep.: that's exactly my point.
  915. winfried pep.: oops mixing up not ticking a box and [disagree]
  916. pep. Ge0rG, who cares, people should setup notifications properly
  917. Ge0rG pep.: the right thing™ would be to send another kind of notification and let the user agree when they re-open their client
  918. Guus has left
  919. Ge0rG pep.: people are using Jabber for important family notifications. Ringing them up at 3AM is not what I want to do.
  920. jonasw Ge0rG, the notification could be delayed until the next CSI Active if the client is CSI Inactive with a smart implementation :)
  921. Ge0rG jonasw: I don't believe in smart implementations any more.
  922. jonasw (with a delay of a few minutes to allow a client to go CSI Inactive after a reconnect)
  923. jonasw Ge0rG, do you have another idea for the notification?
  924. jonasw I don’t want to use an IQ because that won’t work with legacy clients at all.
  925. jonasw we don’t have a "silent" thing unfortunately
  926. Ge0rG jonasw: you encode the tos-version in the entity caps and push a presence update.
  927. jonasw presence update from whom?
  928. Dave Cridland I'm not convined you want to handle ToS changing mid-stream.
  929. Ge0rG from the server.
  930. jonasw and that won’t work with legacy clients at all.
  931. winfried Dave Cridland: why not?
  932. jonasw Ge0rG, users typically don’t have their server in the roster.
  933. Ge0rG Dave Cridland: what's your counter-proposal? Kick the client?
  934. Ge0rG jonasw: yes.
  935. pep. clients*?
  936. Ge0rG jonasw: this is why it's going to work.
  937. jonasw Ge0rG, you are an evil persion
  938. Ge0rG jonasw: what was discussed last time for mid-stream server-caps updates?
  939. Dave Cridland Ge0rG, Basically. If you're at the point where the ToS update is so pressing you need to get user agreement at that moment, you're going to need to anyway.
  940. jonasw but relatedly, I have an update for XEP-0390 pending which allows servers to push updates to their caps
  941. Guus has left
  942. Guus has left
  943. jonasw Dave Cridland, nobody’s talking about "in that moment"
  944. Guus has joined
  945. Ge0rG jonasw: yes. yes I am.
  946. jonasw the notification is supposed to be sent a few days ahead so that the user has time to review etc.
  947. Ge0rG you kick the user twice. First on the ToS update, second when they failed to accept the update in time.
  948. Ge0rG BTW, what happens if they fail to accept it? They get kicked and can't reconnect? Need to accept the ToS oob?
  949. jonasw Ge0rG, § 4.5 in the draft I linked
  950. jonasw https://sotecware.net/files/noindex/xeps/tos.html#usecase-expired
  951. jonasw ideally, this would be a SASL2 thing as suggested by Dave Cridland, but we don’t have SASL2 yet, and it can easily replaced with SASL2 later.
  952. Ge0rG jonasw: wow, well thought out :)
  953. lnj has left
  954. lnj has joined
  955. winfried Ge0rG: isn't that up to to the server
  956. Ge0rG data-forms in SASL2?
  957. jonasw Ge0rG, sasl2 is like zombo.com -- everything is possible in SASL2
  958. Ge0rG winfried: what that?
  959. SaltyBones has left
  960. SaltyBones has joined
  961. winfried [17:25:29] <Ge0rG> BTW, what happens if they fail to accept it? They get kicked and can't reconnect? Need to accept the ToS oob?
  962. Ge0rG winfried: yeah, but if you lock out the user, they need an oob mechanism to re-agree with the ToS
  963. jonasw (or an in-band mechanism ;-))
  964. Ge0rG an in-band mechanism between auth and bind, yes.
  965. Ge0rG can you 0198 resume such a semi-zombie?
  966. Wiktor has joined
  967. jonasw I was about to add that you’d kill the session completely when they don’t agree to the ToS in time
  968. jonasw you can’t know how long it’ll take for them to ack the new terms and shutting down the session cleanly and completely is probably the best you can do.
  969. Guus has left
  970. alexis has joined
  971. Guus has left
  972. waqas has joined
  973. alexis has left
  974. j.r has joined
  975. alexis has joined
  976. Dave Cridland has left
  977. SaltyBones has left
  978. SaltyBones has joined
  979. Guus has left
  980. Guus has left
  981. Guus has joined
  982. efrit has left
  983. jjrh has left
  984. SaltyBones has left
  985. SaltyBones has joined
  986. alexis has left
  987. alexis has joined
  988. Alex has left
  989. winfried jonasw: can you have a look? https://github.com/winfried/xeps/blob/master/inbox/GDPR.xml
  990. jonasw I would add a paragraph right into the introduction: "This document is not legal advice"
  991. jonasw this is probably a good start
  992. pep. winfried, interoperability*
  993. blabla has left
  994. blabla has joined
  995. Andrew Nenakhov has left
  996. winfried jonasw: thanks, added
  997. winfried pep.: thanks, fixed
  998. jjrh has left
  999. Andrew Nenakhov has joined
  1000. peter has joined
  1001. winfried jonasw: do you want a pull request?
  1002. jonasw winfried, you can do a PR, I’m not 100% convinced that this is enough to pass though.
  1003. jonasw and I’m not 100% sure if this is council or board matter
  1004. jonasw Dave Cridland, do you have an opinion?
  1005. winfried jonasw: we will see ;-)
  1006. Dave Cridland It's not procedural, so probably not Board.
  1007. jonasw it’s informational though
  1008. Dave Cridland Yes, but lots of Informational stuff is processed by Council.
  1009. jonasw winfried, pep., Ge0rG: updated https://sotecware.net/files/noindex/xeps/tos.html
  1010. jonasw Dave Cridland, true
  1011. Dave Cridland Board handle the XEPs that document XSF policy and procedures.
  1012. jonasw okay
  1013. jonasw so council it is
  1014. Dave Cridland (Which are "Procedural")
  1015. jjrh has left
  1016. rtq3 has left
  1017. winfried jonasw: pull request send
  1018. jonasw neat, thanks
  1019. flow has left
  1020. jjrh has left
  1021. flow has joined
  1022. winfried Of to dinner!
  1023. jonasw gl!
  1024. jjrh has left
  1025. jjrh has left
  1026. rion has joined
  1027. j.r has joined
  1028. ibikk has left
  1029. SaltyBones has left
  1030. marc has left
  1031. SaltyBones has joined
  1032. jonasw another update
  1033. blabla has joined
  1034. xnyhps has joined
  1035. xnyhps has joined
  1036. ibikk has joined
  1037. j.r has joined
  1038. winfried has joined
  1039. jjrh has left
  1040. SaltyBones has left
  1041. SaltyBones has joined
  1042. Steve Kille has left
  1043. Steve Kille has left
  1044. tux has left
  1045. SaltyBones has left
  1046. SaltyBones has joined
  1047. Steve Kille has joined
  1048. jubalh has left
  1049. ralphm has left
  1050. marmistrz has joined
  1051. alacer has joined
  1052. Valerian has left
  1053. Valerian has joined
  1054. Valerian has left
  1055. Valerian has joined
  1056. Valerian has left
  1057. marmistrz has joined
  1058. Dave Cridland has left
  1059. Dave Cridland has left
  1060. SamWhited has left
  1061. pep. jonasw, no MIME anymore?
  1062. rion has left
  1063. Valerian has joined
  1064. rtq3 has joined
  1065. pep. meh, nvm. You gave me too much options in the first draft!
  1066. Steve Kille has left
  1067. pep. meh, nvm. You gave me too many options in the first draft!
  1068. pep. Ah wait, there is
  1069. Ge0rG has joined
  1070. Dave Cridland has left
  1071. jjrh has left
  1072. Dave Cridland has left
  1073. Valerian has left
  1074. pep. you say "The data form for legacy clients and additional opt-ins/opt-outs", but even if I'm a client implementing the XEP I'll want all this, no? What exactly can I get rid of in that form, especially when I have to reply with the same fields
  1075. SaltyBones has left
  1076. SaltyBones has joined
  1077. pep. hmm, maybe just to provide alternative versions/urls of the documents
  1078. j.r has left
  1079. Valerian has joined
  1080. marc has left
  1081. jonasw pep., yes, you can only remove the additional elements
  1082. jonasw pep., yes, you can only remove the documents
  1083. jonasw but that is written down there
  1084. pep. nit: "In the future, more children may be added to the <tos/> element. Conforming clients thus MUST ignore all children they do not understand.", I find "conforming" disturbing here, as conforming clients would understand these updates.. But I know you're talking about cases where deployments are not up-to-date
  1085. jonasw pep., it might also be that an additional XEP extends it
  1086. pep. Ok makes more sense in this case
  1087. matlag has joined
  1088. Tobias has joined
  1089. pep. jonasw, "[..] and use a richer representation obtained from the <tos/> element for the same data." you mean HTTP GET on the urls?
  1090. jonasw for example
  1091. pep. Does it have to be a url btw
  1092. jonasw and in the future maybe fancy things like machine-readable MAM retention times etc.
  1093. jonasw yes
  1094. pep. can it be a uri
  1095. lumi has left
  1096. jonasw ugh, I never get the difference
  1097. pep. I'm probably wrong, I mean does it have to be http
  1098. jonasw no
  1099. pep. How would you display a plaintext file retrieved in your client, the question of rich formatting still stands
  1100. jonasw you could also have a text/markdown version.
  1101. jonasw or text/restructuredtext
  1102. ralphm has joined
  1103. pep. Instead of "Duplicate MIME types MUST NOT occur.", can we have "Duplicate url/MIME type pairs MUT NOT occur."
  1104. pep. hmm, I assume the url would use a different protocol though
  1105. Dave Cridland has left
  1106. jonasw pep., duplicate MIME types makes it hard for the client to decide which one ot use
  1107. pep. It can decide based on the protocol _and_ the mime type
  1108. jonasw right
  1109. jonasw might add that later
  1110. jonasw I pushed it into the xeps repo now
  1111. pep. Ok
  1112. rion has left
  1113. pep. What about errors when client submits filled-out form
  1114. pep. "not latest version", "invalid documents", "unknown opt-in feature", etc.
  1115. matlag has joined
  1116. j.r has joined
  1117. jonasw yeah, should probably be defined
  1118. pep. Ah I see you've added a <tos-push/> containe r:)
  1119. jonasw you can send those to the mai3ling list :)
  1120. pep. will do
  1121. jonasw (once the announcement is out)
  1122. jonasw which I’m not 100% sure I’ll get to today because I’m heading out in half an hour and the build takes ages :(
  1123. daniel has left
  1124. pep. :(
  1125. pep. something something incremental builds
  1126. jonasw yeah
  1127. jonasw something something docker sucks
  1128. pep. I'd argue that's up to the CI
  1129. lskdjf has left
  1130. jonasw you can’t do that with docker hub, period.
  1131. pep. Ah, well docker hub != docker
  1132. SaltyBones has left
  1133. SaltyBones has joined
  1134. Valerian has left
  1135. lskdjf has left
  1136. pep. Did we had Privacy Considerations to the template btw
  1137. jonasw no, I didn’t want to do that in the climate after the XEP-0363 debate
  1138. pep. ok
  1139. jonasw and I still need to reword the ideas for that
  1140. blabla has joined
  1141. pep. "The version identifiers generated by servers MUST NOT be longer than 128 characters." a reason for this in particular? (even if unlikely)
  1142. la|r|ma has joined
  1143. pep. "Servers MUST NOT allow entities to query the Terms of Service of another server unless they are authenticated." I'm not sure I get this
  1144. jonasw before you are authenticated, your server MUST NOT allow you to query other servers for their ToS
  1145. pep. But other servers may allow anybody to attempt a connection and query their tos right
  1146. pep. Just like my https://service.example/tos will be public, I don't mind having my xmpp server disclosing them publicly
  1147. jonasw yes
  1148. jonasw but you don’t want to be an open proxy for entities sending IQs towards other servers.
  1149. pep. I see
  1150. pep. Also what about sasl anonymous
  1151. jonasw I don’t see how that’s relevant
  1152. pep. ToS acceptance is required only if there is account creation?
  1153. jonasw dunno
  1154. jonasw IBR integration is still fully missing
  1155. pep. Right
  1156. ludo has joined
  1157. jonasw theoretically, a SASL ANONYMOUS thing could apply § 4.4 Inform client about Terms of Service expiry after authentication
  1158. Dave Cridland has left
  1159. pep. I'll reply to the thread when it's out and ask about all that
  1160. Dave Cridland has left
  1161. waqas has left
  1162. SamWhited has left
  1163. jonasw okay gotta go, build didn’t finish in time :( will send the mail tomorrow or later tonight
  1164. Dave Cridland has left
  1165. SaltyBones has left
  1166. SaltyBones has joined
  1167. Dave Cridland has left
  1168. jubalh has joined
  1169. daniel has joined
  1170. rtq3 has left
  1171. jjrh has left
  1172. bear has left
  1173. bear has joined
  1174. Dave Cridland has left
  1175. Zash has joined
  1176. Tobias has joined
  1177. waqas has joined
  1178. Dave Cridland has left
  1179. SaltyBones has left
  1180. SaltyBones has joined
  1181. Ge0rG has joined
  1182. alacer has left
  1183. alacer has joined
  1184. SaltyBones has left
  1185. SaltyBones has joined
  1186. SaltyBones has left
  1187. SaltyBones has joined
  1188. Tobias has joined
  1189. Valerian has joined
  1190. la|r|ma has joined
  1191. la|r|ma has joined
  1192. Dave Cridland has left
  1193. marmistrz has left
  1194. vanitasvitae has left
  1195. Guus has left
  1196. Valerian has left
  1197. rtq3 has joined
  1198. Guus has left
  1199. Guus has left
  1200. Guus has left
  1201. jjrh has left
  1202. jjrh has left
  1203. alexis has left
  1204. jjrh has left
  1205. Guus has left
  1206. alexis has joined
  1207. jjrh has left
  1208. Ge0rG has left
  1209. rtq3 has left
  1210. jjrh has left
  1211. jjrh has left
  1212. jjrh has left
  1213. jjrh has left
  1214. jjrh has left
  1215. sezuan has joined
  1216. alacer has left
  1217. alacer has joined
  1218. jjrh has left
  1219. matlag has joined
  1220. Dave Cridland has left
  1221. jjrh has left
  1222. rtq3 has joined
  1223. Ge0rG has joined
  1224. alacer has left
  1225. winfried has left
  1226. daniel has left
  1227. ralphm has left
  1228. jjrh has left
  1229. jjrh has left
  1230. jubalh has left
  1231. jjrh has left
  1232. jjrh has left
  1233. jjrh has left
  1234. jubalh has joined
  1235. Valerian has joined
  1236. Guus has left
  1237. jjrh has left
  1238. jjrh has left
  1239. Guus has left
  1240. jjrh has left
  1241. jubalh has left
  1242. jjrh has left
  1243. SamWhited has left
  1244. Ge0rG has left
  1245. jjrh has left
  1246. alacer has joined
  1247. marc has left
  1248. Nekit has left
  1249. Nekit has joined
  1250. jjrh has left
  1251. jjrh has left
  1252. jubalh has joined
  1253. alacer has left
  1254. Kev has joined
  1255. marc has left
  1256. jjrh has left
  1257. jjrh has left
  1258. jjrh has left
  1259. jjrh has left
  1260. jjrh has left
  1261. jjrh has left
  1262. jubalh has left
  1263. jubalh has joined
  1264. Ge0rG speaking of appropriate number mappings... 403 = GDPR Compliance 404 = Terms of Service
  1265. pep. grabs popcorns
  1266. rtq3 has left
  1267. moparisthebest Ge0rG, I think those have been reserved for the mix hatchet job
  1268. Ge0rG moparisthebest: not merely reserved, they are official now.
  1269. pep. moparisthebest, yes, he's been onto it for half a day now, now about this :P
  1270. Zash Popcorn you say?
  1271. moparisthebest ah so they are
  1272. Valerian has left
  1273. Valerian has joined
  1274. jjrh has left
  1275. Valerian has left
  1276. rtq3 has joined
  1277. jjrh has left
  1278. ludo has left
  1279. jjrh has left
  1280. nyco has left
  1281. nyco has joined
  1282. lskdjf has left
  1283. rtq3 has left
  1284. rtq3 has joined
  1285. jubalh has left
  1286. jjrh has left
  1287. Guus has left
  1288. lskdjf has joined
  1289. jjrh has left
  1290. jjrh has left
  1291. Kev has left
  1292. Guus has left
  1293. Wiktor has joined
  1294. jjrh has left
  1295. jjrh has left
  1296. jjrh has left
  1297. jubalh has joined
  1298. rtq3 has left
  1299. goffi has left
  1300. UsL has joined
  1301. Dave Cridland has left
  1302. Tobias has left
  1303. Tobias has joined
  1304. mimi89999 has left
  1305. jjrh has left
  1306. jjrh has left
  1307. lumi has joined
  1308. jjrh has left
  1309. jjrh has left
  1310. jjrh has left
  1311. UsL has joined
  1312. lovetox has joined
  1313. SamWhited has joined
  1314. SamWhited has joined
  1315. daniel has joined
  1316. remko has left
  1317. Dave Cridland has left
  1318. Dave Cridland has left
  1319. Dave Cridland has left
  1320. jjrh has left
  1321. Maranda has joined
  1322. Guus has left
  1323. Guus has left
  1324. Guus has joined
  1325. lorddavidiii has left
  1326. jubalh has left
  1327. jjrh has left
  1328. jjrh has left
  1329. marmistrz has joined
  1330. jjrh has left
  1331. jjrh has left
  1332. jjrh has left
  1333. lnj has left
  1334. vanitasvitae has left
  1335. lorddavidiii has left
  1336. jubalh has joined
  1337. jjrh has left
  1338. jjrh has left
  1339. marmistrz has left
  1340. ta has joined
  1341. jjrh has left
  1342. jjrh has left
  1343. jjrh has left
  1344. blabla has left
  1345. rtq3 has joined
  1346. jjrh has left
  1347. jjrh has left
  1348. Lance has joined
  1349. Maranda has left
  1350. Lance has joined
  1351. jjrh has left
  1352. rtq3 has left
  1353. blabla has joined
  1354. rtq3 has joined
  1355. jjrh has left
  1356. marmistrz has joined
  1357. jjrh has left
  1358. peter has left
  1359. Dave Cridland has left
  1360. sezuan has left
  1361. Dave Cridland has left
  1362. Dave Cridland has left
  1363. jjrh has left
  1364. Dave Cridland has left
  1365. jjrh has left
  1366. rtq3 has left
  1367. Dave Cridland has left
  1368. jere has left
  1369. jere has joined
  1370. Guus has left
  1371. Guus has left
  1372. Guus has left
  1373. Nekit has left
  1374. Guus has left
  1375. lskdjf has left
  1376. Dave Cridland has left
  1377. Dave Cridland has left
  1378. lumi has left
  1379. lumi has joined
  1380. jjrh has left
  1381. jjrh has left
  1382. jjrh has left
  1383. waqas has left
  1384. Dave Cridland has left
  1385. lskdjf has joined
  1386. Dave Cridland has left
  1387. Dave Cridland has left
  1388. lumi has left
  1389. lumi has joined
  1390. Dave Cridland has left
  1391. Dave Cridland has left
  1392. Dave Cridland has left
  1393. SaltyBones has left
  1394. Dave Cridland has left
  1395. SaltyBones has joined
  1396. Dave Cridland has left
  1397. jjrh has left
  1398. jjrh has left
  1399. Dave Cridland has left
  1400. jere has left
  1401. jere has joined
  1402. alexis has left
  1403. Bunneh has left
  1404. Bunneh has joined
  1405. Bunneh has left
  1406. Bunneh has joined
  1407. Bunneh has left
  1408. Bunneh has joined
  1409. Bunneh has left
  1410. Bunneh has joined
  1411. jjrh has left
  1412. jjrh has left
  1413. jjrh has left
  1414. waqas has joined
  1415. Guus has left
  1416. jjrh has left
  1417. Guus has left
  1418. moparisthebest has joined
  1419. Guus has left
  1420. Guus has left
  1421. Guus has joined
  1422. jjrh has left
  1423. jjrh has left
  1424. tux has left
  1425. tux has joined
  1426. SaltyBones has left
  1427. SaltyBones has joined
  1428. alexis has joined
  1429. jjrh has left
  1430. alexis has left
  1431. jjrh has left
  1432. alexis has joined
  1433. jere has left
  1434. Chobbes has joined
  1435. lumi has left
  1436. Guus has left
  1437. jjrh has left
  1438. alexis has left
  1439. alexis has joined