XSF Discussion - 2018-05-22

gdpr meeting in 10?

jonasw, winfried, Ge0rG

pep.: I thought 1230?

But I can do either

Ah fail

10:30 UTC indeed

sudo -u pep. sudo apt install tzdata 😸

a.k.a. timezones are hard

`useradd: invalid user name 'pep.'`

RCE over MUC=

Ge0rG: only in signal :>

GDPR in 9, Ge0rG, winfried, pep.

!

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/

;-)

is a recital sufficient? or does it need an actual paragraph which instantiates that recital?

a what?

!

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.

jonasw: yes, wording it as an opt-in is better

Agenda for to?

s/to/today/

yeah, opt-in might be better

What do we have on the agenda today? The template?

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

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

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.

yeah, sorry about the EULA XEP, I was more busy than I anticipated

jonasw, no worries, I didn't have much time either

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.

neither did I ;-)

if my memory of the push protocol is right

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!

winfried, of course it does? How would that work otherwise

winfried, true, but as an XMPP server provider, you can’t be sure about which app server software is used.

jonasw: correct

and you transfer at teh very least message body and timestamp to the app server, at which point it’s out of your control

jonasw, "app server"?

the push component?

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.

Right

pep., cf. https://xmpp.org/extensions/xep-0357.html#sect-idm139090519180208

"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

jonasw: I'm not pushing actual message content, just placeholders.

Ge0rG, is that a modification of mod_cloud_push?

jonasw: no, default behavior with a custom setting.

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

`push_notification_important_body = "Important message";`

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.

jonasw: The notification is not a message stanza but a PubSub-like IQ.

jonasw: updated both places, thanks. Please have a look at the new push wording

Holger: we are not talking about stanzas but about user content.

Holger: so "message" in this context is rather the <body> element.

s/opt in into/opt into/?

isn't the verb "opt in"?

maybe "opt in to"?

Ge0rG: I would say so

!summon native speaker

okay, nits though

otherwise I think this looks good

but, IANAL

Ge0rG, can I link to your yax.im URLs or should we move that to the wiki

in the minutes

pep.: They are WIP right now, so I'd rather not have them linked "publically"

copying would be fine though?

k, so maybe we can copy that to the wiki

I'd like to establish some process where we have a master copy and the yax.im ToS are a fork of that.

Ge0rG: git!

so you can fork it yourself and profit from later updates.

maybe a repository under xsf?

or xmpp?

markdown + C preprocessor?

jonasw: moving a git is the easiest part.

the hard part is the split of template and specific server content.

hmm

Right

jinja is a neat templating language

Or maybe some kind of ToS generator?

would be trivial to build a generator on top of that

Jinja is Beautiful. {% extends "layout.html" %} {% block body %} <ul> {% for user in users %} <li><a href="{{ user.url }}">{{ user.username }}</a></li> {% endfor ...

They lost me at {%

they copied that from erb I think

I don't think we should focus on html

Markdown is an ideal language for the content, minus the templating.

the advantage I see in jinja that its inheritance and block stuff would allow for easy replacement of specific blocks.

and extension

that would be cumbersome with C preprocessor

We could also `sed -e s/ZZZservernameZZZ/$SERVERNAME/g`

those are technicalities

or use bash here-documents.

let’s focus on what winfried suggested

I don't care. I just don't want to learn a new templating engine language.

git?

10:34:00 winfried> I feel like taking a look at the bigger picture: where are we, what

Ge0rG, ^

:P

Right.

In the meantime I don't have anything to show for this part of the minutes :x

But we can sort this out later

hey, I am participating again :-P

Big picture: we have some things we want to change on protocol level

EULA-XEP

Deletion

Transfer of data

(any other?)

ah, defaults for MAM

retention times for MAM and HTTP uploads.

Current implementations lack auto-removal of "expired" entries

s/HTTP uploads/server-side file storage/

There was some discussion on the standards@ list about incorporating local laws in standards

what is our opinion in that?

Allowing deletion via the protocol has nothing to do with local laws right

I guess some topics are generic and not specifically for one jurisdiction

winfried: the protocol purist in me says we should not encode local laws into our protocols.

OTOH, the pragmatist requests an easy way for server operators to comply with local laws.

Ge0rG, I think I agree with that, but deletion itself is just a technicality and not a law

We might want to have another informational "GDPR compliance" XEP

Ge0rG: and what about an optional extension that describes an action needed in a certain jurisdiction...?

winfried: I'd go with Business Rules paragraphs in relevant XEPs

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

This is how I'm doing GDPR compliance right now.

Ge0rG: :-D

And this is not only fugly, it's also killing my availability / latency.

sleep 2?!

I can imagine you want something more... sophisticated

jonasw: yes. I can't just delete *all* messages at once because there are too many.

deleting 5k takes <10s, so it's just barely bearable.

How many users do you have again?

Active users

~1k

But I have some active bots, it seems. And for reasons beyond my understanding, those bots are using MAM

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?

Ok, so back to XEPs,

3) informational GDPR XEP?

if 3), is 2) required

We definitely need 1) in any case

And I don't think anybody will argue this

jonasw: ?

what do we nee 1 for?

patching XEPs is #2, isn't it?

New XEP: eula XEP, http storage management

Ge0rG, (1) is adding functionality, (2) is adding business rules

those are differences, and (2) can be moved to a generic GDPR XEP, while (1) can’t

(well, could, but it wouldn’t make sense)

jonasw, 1 could be added to an addon XEP, but :/

Not informal

**informational

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.

Re EULA XEP: do we need explicit consent?

pep.: think we need to decide on a case to case base if an add on is better of patching the xep

If we need explicit consent, the EULA-on-IBR would be one possible implementation, with a web form based registration another obvious one.

Dave Cridland, 1. above is not "GDPR implementation stuff", right

2 and 3 are, and I'm also leaning towards 3

rather than 2

I guess Dave Cridland meant the choice between 2 and 3

Dave Cridland: I was thinking along the lines of "A server implementation must provide a way to delete user data by means of X"

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.

We will need to tell developers though where to find that XEP

XEP discovery is another common issue

pep.: "Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"

winfried, k

I can't see how we can create an (informational or other) GDPR XEP until May 25h.

I agree

I wanted to get EULA done by today, but schedules

Ge0rG: Nope, I have to finish a DPIA before then :-D

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 ..."

Ge0rG, If a XEP has the phrase "MUST or MUST NOT" I will have to nuke it from orbit.

What winfried said above

"Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"

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.

Ge0rG: can you explain why you think it is required?

pep., That phrasing works for me.

Dave Cridland: why? It's only self-contradicting if it's "MUST *and* MUST NOT"

Ge0rG, Because it's meaningless.

"this XEP may have global warming consequences, or may contain traces of nuts"

What doesn't have global warming consequences..

And doesn't contain traces of nuts

0:D

Dave Cridland: but I agree that RFC 2119 language SHOULD NOT be applied to legal requirements.

pep.: the chilling effect (couldn't resist)

:>

winfried: LOL

:)

Ge0rG, so I read you'd prefer to have GDPR details *in* the XEP?

And not an informational XEP

pep.: I don't know. Whatever will make server implementors create compliant implementations works for me

I think general "privacy considerations" without mentioning legislation would be a good thing™

I'd see winfried's phrasing above, + informational GDPR xep

pep., Really don't want to do that. The problem there is that you'd also need to put in Sarbanes-Oxley, for example.

it would help to create awareness, just like Security Considerations do

and I think they have a place in the XEP

Dave Cridland, yes I don't want either

pep., That is, put GDPR sections in every XEP.

hmm

pep., Ugh. I'm being really unclear. I do not want GDPR bits in every XEP.

what GDPR bits

You'd be ok with just saying "seealso GDPR XEP"?

pep., Yes.

Dave Cridland, ok then we agree

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. ✏

Dave Cridland: if we create an informational XEP about Sarbanes-Oxley, I wouldn't mind other XEPs pointing to it

Maybe the issues is if we actually need *every* *other* XEP to point to the new one?

It might actually be useful to note what data is retained by each XEP, since that has very wide applicability and use.

Dave Cridland, that’s what I had in mind for "Privacy Considerations" sections in XEPs

and a separate GDPR document could point out what to do with specific data.

jonasw, Right, and I think it also forms very useful input to consent, privacy policy, etc stuff on a more generic level.

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 / ...)

jonasw, that still seems GDPR-specific. Some other law might define "private data" entirely differently

Like that idea, but it will be quite a bit of work to update all XEPs

pep., doesn’t matter, I’d consider all user data in that section.

jonasw: +1

jonasw, +1 from me too, for whatever it's worth.

jonasw, k

and should we also add a paragraph like that to the RFCs?

I’ll re-word my '363 PR to conform with that.

jonasw: great!

winfried, mined territory I assume :p

Having a "Privacy Considerations" section with that data in all XEPs would be great. We could just link those from the server ToS

Ge0rG: with autodiscovery based on service discovery!

can we plan for enxt?

Can we define quickly what would go into that informational XEP

So we can start working on it quickly

jonasw, +whatever should work for me. Friday with the small delay as usual

pep.: - steps for compliance - red flags

I can only make friday I think

so friday 1230 CEST or 1330 CEST would be good for me

wfm

1230 CEST worksforme

1330 as well

1330 not for me

1230 CEST on Friday, 25th it is then, Ge0rG?

either is good

If someone writes the skeleton and an abstract for this GDPR XEP today, we can give it a number by tomorrow.

D-Day!

... which might help "advertise" what you guys are doing.

next number is 403, right? ;)

(It'd also give us something to blog about as the XSF)

Ge0rG, no, next is 409 I think

Ge0rG, no that's MIX?

Oh, wow.

Dave Cridland: good plan, I don't have time :-(

I’ll try to dedicate my afternoon to the EULA XEP

I'm behind on that thread.

Ge0rG, cf. https://github.com/xsf/xeps/pulls

Ge0rG, I think MIX wants that, but I'd love to see the Editor creatively rearrange...

409 Conflict is also good ;-)

I would have skipped 403 as well. But meh.

Ge0rG, 404 isn’t skipped

yeah 409 is also fine :P

it’s for MIX ANON

(the order in the PRs is just weird)

jonasw: NOOO!1!!

gotta go now

I wondered if MIX Anon was intentionally at 404.

Dave Cridland, it is

But yeah, I think we should skip it for amusement's sake.

I don’t feel like renumbering them ;-)

MIX anon is a good use for XEP-0404 imo :)

I disagree. But what do I know.

Should I close the GDPR meeting? ;-)

By the way, huge thanks to you guys for doing this.

winfried, :)

jonasw: do you have time to also submit a skelton and abstract for a GDPR informational XEP?

jonasw, I can have a look at EULA, for the obvious bits? (if there is any)

Dave Cridland, I was going to ask

Dave Cridland: you revealed yourself, so no mercy :-D

But the logs of this room are public anyway, just like the minutes :P

winfried, no, sorry

I shouldn't do it, but I will give it a shot

(then)

winfried, why shouldn’t you do it?

if you’re uncomfortable with the markup, you can also just send me a markdown or whatever based document

and I’ll transform it

time, am already terrible behind on an other GDPR project

right

but it shouldn't be too much work

do whatever you need to save time, my issue with the informational is mostly that I don’t have the big picture or anything

I’m fine with an .odt if that’s what you’re most comfortable writing in

jonasw: k, let you know if I need anything

Ge0rG, you're ok if I copy your tos/privacy policy to the wiki with a big "WIP"

And "To be moved to git"

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

pep.: yeah

We're still in Q1.1.2 right

or 1.1.3 maybe

Ah no 1.1.2

"consequences for server operators"

*1.2

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

pep.: timestamp ? loosing my context ;-)

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

(UTC+9)

ah...

that is the portability thing, download everything so it can be put on an other server

I see

https://cryptpad.fr/code/#/2/code/edit/j5ggWca+SLu32klePWFOeCIK/ winfried, jonasw, Ge0rG if you can have a quick look before I send

pep.: 👍

(Y)

wfm

I’ll now try to merge the MIX PRs and then I’ll start to look at the EULA XEP

jonasw: thanks!

jonasw: But 404!

yes?

Okay, I didn't do anything when that window of opportunity was open, so I have no right to complain about it.

Steve Kille, is "RELIABLE-DELIVERY" not there yet or am I missing something?

I'll just pile my sadness on top of the Pidgin-officially-encouraged pile and move on with life.

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

So, I (or someone else) needs to work out exactly what needs doing and write it.

Running without this is probably not going to be a big deal for most deployments

BTW using 404 for MIX-ANON was the choice of my co-author

I think the humour is good

IMHO, that number should have been used for "XEP not found"

Kev got there first

MIXes merged

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

thanks very much for sorting this out.

Meanwhile, I've received some private editorial comments on 1.0.0, whch I will work at soon

I renumbered it to 0.10.2

it is not draft yet, and only draft can have 1.x.x

and since the split was editorial as discussed, it got 0.10.2

ah - I did not realize this.

Given that over half of the text vanished from 369, this scarecely seems editorial

I'm going to have to confess now that there were some technical changes

Mamking the XEPs independnent needed changes

Making Proxy JIDs work without MIX-ANON needed various changes

uh

yeah, I saw a namespace bump in there

but I think that’s going to be needed either way

I can’t really fix the version number now anymore, I’m afraid.

so we’ll have to live with t hat

shall I move to 11.0 when I do the next set of changes?

All the others are at 0.1.0

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

I think that the changes since 10.0 deserve a seond digit bump

However, it is just a number, and I am happy with whatever the experts decree

I agree that a second digit bump would’ve made sense

but that’s spilled milk

more or less

I was asking if it makes sense to make the bump as part of the editorial changes I will make soon?

ah, now I understand

I’ll abort the build and fix the version number to 0.11.0

if that is not too much trouble, I think that makes most sense

done

you're a hero

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

jonasw, sgtm

jonasw: aren't we overloading our caps infra already?

not sure

for servers I don’t think so

jonasw, what do you do with it then? the client knows there's a new version, where does it fetch it

pep., via the in-band protocol

Ok ok

iq or ad-hoc?

not sure yet

I think ad-hoc won’t do the trick

I'd prefer iq I think, but I don't have a strong opinion

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

Meh, I don't think the one place to rule them all would work

yupp

that'd need to fiddle with every other modules

There is one place to rule them all. "Delete account"

that needs to go into the individual XEPs, just like it’s handled currently

Ge0rG, no

Say I still want to benefit from the services, but I want to opt-out of every consented feature

Doesn't have to be "please delete MAM", just "Please no MAM anymore"

https://paste.debian.net/hidden/eb963ea8/

pep., Ge0rG, ^

"The user shall be able to retract consent [..]", I don't have the exact quote

An error occurred during a connection to paste.debian.net. SSL peer rejected your certificate as expired. Error code: SSL_ERROR_EXPIRED_CERT_ALERT :(

nice

I'll have to change that client cert..

s/https/http/ will work though

yeah.. unfortunately

"The server subsequently replies with the &tos; payload:" - that sounds like it's a ToS *payload*, but it's merely a ToS *link*

Ge0rG, it is a payload of the ToS protocol

Ge0rG, I'd like to allow for both

If you want to point to an external source, good for you. You might also want to handle this in-band

Let's talk about XHTML-IM ToS payloads.

pep., it’s not realistic to have the complete document in-band

jonasw, that's fine as long as EULA is only used for c2s

I mean, oob is fine**

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"

representative = Jon Snow.

jonasw, I'm sure that template will get hairy quickly

maybe, but maybe not

Plus operators will want to modify more than just placeholders

pep., in any case, putting the whole ToS in-band won’t work.

won't work how?

question 1: which markup format to use for formatting?

We don't have anything to do formatted payloads anymore? :)

Too bad

I would have argued strongly against anything XHTML. way too much, markdown would be sufficient, if it was standardised.

but styling is not markdown.

styling is not sufficient

Don't tell me

you need headings in a ToS, and enumerations and lists

I am confused

Are we talking about Markleft or Markright?

Ge0rG, both

Also Markhtml

pep., do you happen ot have a link to your EULA XEP pad at hand?

https://cryptpad.fr/code/#/2/code/edit/IiUC5h-fzN14FAeSdcBoAQgc/

ty

pep., Ge0rG: https://sotecware.net/files/noindex/tos.html

sorry for the lack of CSS

pep., Ge0rG, winfried, here’s a preview version with CSS: https://sotecware.net/files/noindex/xeps/tos.html ; I’d appreciate any early feedback.

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.

jonasw, example 2 contains </stream:features>

jonasw: the title might better be "ToS Reference" than just "ToS"

pep., ty

Ge0rG, "Terms of Service Agreement"?

because it also handles ACK-ing the ToS

I find ToS a good name still.

jonasw, can we not use oob or sims or something that's already there to give the url?

pep., what would be the benefit?

Not reinventing the wheel

hmm, oob doesn't allow for MIME, sims does though

Wasn't there an IBR extension by daniel?

jonasw: what when there are several documents like a ToS and a separate Privacy statement?

pep., but it wouldn’t be re-usable much except for wire format maybe, and it would tie us to the SIMS namespace

jonasw, I don't know what the convention is, but I'd put <deadline/> inside <tos/> maybe

pep., but semantically, the deadline is for the change not for the ToS itself

Can it also be communicated when it is obliged to agree to the terms or when it should only be available

winfried, that’s a good question (regarding multiple documents) ✏

jonasw, right.. I'm a bit annoyed at having this directly in <message> for some reason

winfried, regarding requiring agreement, sure, we can communicate that, but does it make sense?

winfried, is there a good reason to separate the documents?

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

Maybe we can just allow multiple sources of the same type

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

Well.. having both links for plain/text and plain/html, what will clients display anyway?

randomly choose between the two?

unless you’re poezio, you’d probably link the text/html thing

and dispatch to a web browser

poezio might as well show the text/plain version inline

pardon my UX skills, but as a user I'd prefer to have a choice

most users don’t want to

they don’t even care about the difference between html and plaintext :)

which is also why I use poezio unlike "most users"

winfried, You know, you *could* use a SASL2 task for EULA agreement.

jonasw, anyway, I can live with just one document (and optionally multiple types), for the original question

Dave Cridland, i’d love to see a SASL2 task to replace my pre-bind/post-auth hack

IBR integration is still on the todo

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.

jonasw: and that is also an answer to the other topic: if you have both, you want to present both with a different status

winfried, okay, that makes things much more complex.

Right. I've seen services present me multiple ToS I could agree to

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.

(such as MAM)

pep.: yeah, that is ugly, but there may be good reasons for

back to the scratchpad then

winfried, I guess we can skip this though, and do as jonasw says, have opt-in features be handled separately

jonasw: in our GDPR route, we avoid asking 6.1a questions, but other setups or other jurisdictions may have different needs

winfried, as in, clients would have UI for this, some configuration somewhere

pep.: IF you offer an 'agree-iq', then you should also communicate if it is mandatory to agree it. Otherwise it is just informational

my assumption was that it’s always mandatory

jonasw: Nope, misconception #1 about the gdpr ;-)

I don't think it is (always mandatory).

mmm

okay, will have to re-do things then

jonasw: sorry...

no, that’s great, we need a good thing here

better sort it out before the first implementation comes along :)

Dave Cridland: love that idea, but I am happy you said *could* :-D

Yeah I'd like to see what that looks like as well

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

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 | | | | | +----------------------------------+

+ a [Register] or [Continue] button

the tickboxes would be provided by the service

Also [Cancel], that would close the stream? :-°

probably

Would MAM go in these [ ], or would it be in client configurations like we said above

I would put that in client configuration

Because then we're separating stuff that requires consent

I mean there would be stuff all around, not just one place to accept

if you choose to enable MAM, you have of course already read the privacy policy and thus know the terms for MAM

yeah

Right

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.

the tickboxes would be entirely service-defined ✏

Makes sense

that looks like a data form.

Ge0rG, the tickboxes will use data form wire format indeed

Ad-Hoc command wire format even

The issue I have is that yaxim will not connect to the server until you fill out the username + password fields.

so?

Ge0rG, pulling down a XEP because of client implementation? how dare you :o

pep.: I didn't write "The issue this XEP has"

pep.: a [Cancel] would be up to the server to decide, it may only disable certain functionality

Ge0rG, :)

winfried, if a user cancels, what happens legally? they don't agree to the ToS, but they can continue using the service?

I'm a bit confused

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>`

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

is cancel really a thing?

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

jonasw, [Disagree], I guess ✏

the non-negotiable parts of the ToS, because the negotiable parts are formulated as tickboxes

jonasw, yes

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.

Ge0rG, it's always night somewhere.. ✏

pep.: that's exactly my point.

pep.: oops mixing up not ticking a box and [disagree]

Ge0rG, who cares, people should setup notifications properly

pep.: the right thing™ would be to send another kind of notification and let the user agree when they re-open their client

pep.: people are using Jabber for important family notifications. Ringing them up at 3AM is not what I want to do.

Ge0rG, the notification could be delayed until the next CSI Active if the client is CSI Inactive with a smart implementation :)

jonasw: I don't believe in smart implementations any more.

(with a delay of a few minutes to allow a client to go CSI Inactive after a reconnect)

Ge0rG, do you have another idea for the notification?

I don’t want to use an IQ because that won’t work with legacy clients at all.

we don’t have a "silent" thing unfortunately

jonasw: you encode the tos-version in the entity caps and push a presence update.

presence update from whom?

I'm not convined you want to handle ToS changing mid-stream.

from the server.

and that won’t work with legacy clients at all.

Dave Cridland: why not?

Ge0rG, users typically don’t have their server in the roster.

Dave Cridland: what's your counter-proposal? Kick the client?

jonasw: yes.

clients*?

jonasw: this is why it's going to work.

Ge0rG, you are an evil persion

jonasw: what was discussed last time for mid-stream server-caps updates?

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.

but relatedly, I have an update for XEP-0390 pending which allows servers to push updates to their caps

Dave Cridland, nobody’s talking about "in that moment"

jonasw: yes. yes I am.

the notification is supposed to be sent a few days ahead so that the user has time to review etc.

you kick the user twice. First on the ToS update, second when they failed to accept the update in time.

BTW, what happens if they fail to accept it? They get kicked and can't reconnect? Need to accept the ToS oob?

Ge0rG, § 4.5 in the draft I linked

https://sotecware.net/files/noindex/xeps/tos.html#usecase-expired

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.

jonasw: wow, well thought out :)

Ge0rG: isn't that up to to the server

data-forms in SASL2?

Ge0rG, sasl2 is like zombo.com -- everything is possible in SASL2

winfried: what that?

[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?

winfried: yeah, but if you lock out the user, they need an oob mechanism to re-agree with the ToS

(or an in-band mechanism ;-))

an in-band mechanism between auth and bind, yes.

can you 0198 resume such a semi-zombie?

I was about to add that you’d kill the session completely when they don’t agree to the ToS in time

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.

jonasw: can you have a look? https://github.com/winfried/xeps/blob/master/inbox/GDPR.xml

I would add a paragraph right into the introduction: "This document is not legal advice"

this is probably a good start

winfried, interoperability*

jonasw: thanks, added

pep.: thanks, fixed

jonasw: do you want a pull request?

winfried, you can do a PR, I’m not 100% convinced that this is enough to pass though.

and I’m not 100% sure if this is council or board matter

Dave Cridland, do you have an opinion?

jonasw: we will see ;-)

It's not procedural, so probably not Board.

it’s informational though

Yes, but lots of Informational stuff is processed by Council.

winfried, pep., Ge0rG: updated https://sotecware.net/files/noindex/xeps/tos.html

Dave Cridland, true

Board handle the XEPs that document XSF policy and procedures.

okay

so council it is

(Which are "Procedural")

jonasw: pull request send

neat, thanks

Of to dinner!

gl!

another update

jonasw, no MIME anymore?

meh, nvm. You gave me too many options in the first draft! ✏

Ah wait, there is

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

hmm, maybe just to provide alternative versions/urls of the documents

pep., yes, you can only remove the documents ✏

but that is written down there

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

pep., it might also be that an additional XEP extends it

Ok makes more sense in this case

jonasw, "[..] and use a richer representation obtained from the <tos/> element for the same data." you mean HTTP GET on the urls?

for example

Does it have to be a url btw

and in the future maybe fancy things like machine-readable MAM retention times etc.

yes

can it be a uri

ugh, I never get the difference

I'm probably wrong, I mean does it have to be http

no

How would you display a plaintext file retrieved in your client, the question of rich formatting still stands

you could also have a text/markdown version.

or text/restructuredtext

Instead of "Duplicate MIME types MUST NOT occur.", can we have "Duplicate url/MIME type pairs MUT NOT occur."

hmm, I assume the url would use a different protocol though

pep., duplicate MIME types makes it hard for the client to decide which one ot use

It can decide based on the protocol _and_ the mime type

right

might add that later

I pushed it into the xeps repo now

Ok

What about errors when client submits filled-out form

"not latest version", "invalid documents", "unknown opt-in feature", etc.

yeah, should probably be defined

Ah I see you've added a <tos-push/> containe r:)

you can send those to the mai3ling list :)

will do

(once the announcement is out)

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 :(

:(

something something incremental builds

yeah

something something docker sucks

I'd argue that's up to the CI

you can’t do that with docker hub, period.

Ah, well docker hub != docker

Did we had Privacy Considerations to the template btw

no, I didn’t want to do that in the climate after the XEP-0363 debate

ok

and I still need to reword the ideas for that

"The version identifiers generated by servers MUST NOT be longer than 128 characters." a reason for this in particular? (even if unlikely)

"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

before you are authenticated, your server MUST NOT allow you to query other servers for their ToS

But other servers may allow anybody to attempt a connection and query their tos right

Just like my https://service.example/tos will be public, I don't mind having my xmpp server disclosing them publicly

yes

but you don’t want to be an open proxy for entities sending IQs towards other servers.

I see

Also what about sasl anonymous

I don’t see how that’s relevant

ToS acceptance is required only if there is account creation?

dunno

IBR integration is still fully missing

Right

theoretically, a SASL ANONYMOUS thing could apply § 4.4 Inform client about Terms of Service expiry after authentication

I'll reply to the thread when it's out and ask about all that

okay gotta go, build didn’t finish in time :( will send the mail tomorrow or later tonight

speaking of appropriate number mappings... 403 = GDPR Compliance 404 = Terms of Service

Ge0rG, I think those have been reserved for the mix hatchet job

moparisthebest: not merely reserved, they are official now.

moparisthebest, yes, he's been onto it for half a day now, now about this :P

Popcorn you say?

ah so they are