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/
Valerianhas joined
Andrew Nenakhovhas left
Valerianhas left
danielhas joined
winfried
;-)
jonasw
is a recital sufficient? or does it need an actual paragraph which instantiates that recital?
Ge0rG
a what?
Valerianhas joined
alacerhas left
alacerhas joined
winfriedbangs the gavel and welcomes pep. jonasw and Ge0rG to the GDPR meeting
pep.
!
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.
jonaswwaves at winfried
winfried
jonasw: yes, wording it as an opt-in is better
winfried
Agenda for to?
winfried
s/to/today/
pep.
yeah, opt-in might be better
pep.
What do we have on the agenda today? The template?
alacerhas left
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
alacerhas joined
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
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.
jonasw
yeah, sorry about the EULA XEP, I was more busy than I anticipated
pep.
jonasw, no worries, I didn't have much time either
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.
winfried
neither did I ;-)
jonasw
if my memory of the push protocol is right
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!
pep.
winfried, of course it does? How would that work otherwise
jonasw
winfried, true, but as an XMPP server provider, you can’t be sure about which app server software is used.
winfried
jonasw: correct
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
pep.
jonasw, "app server"?
pep.
the push component?
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.
"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
Ge0rG
jonasw: I'm not pushing actual message content, just placeholders.
jonasw
Ge0rG, is that a modification of mod_cloud_push?
Ge0rG
jonasw: no, default behavior with a custom setting.
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
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.
Holger
jonasw: The notification is not a message stanza but a PubSub-like IQ.
Ge0rG
jonasw: updated both places, thanks. Please have a look at the new push wording
Dave Cridlandhas left
Ge0rG
Holger: we are not talking about stanzas but about user content.
Ge0rG
Holger: so "message" in this context is rather the <body> element.
jonasw
s/opt in into/opt into/?
alacerhas left
Ge0rG
isn't the verb "opt in"?
Ge0rG
maybe "opt in to"?
winfried
Ge0rG: I would say so
Ge0rG
!summon native speaker
jonasw
okay, nits though
jonasw
otherwise I think this looks good
jonasw
but, IANAL
pep.
Ge0rG, can I link to your yax.im URLs or should we move that to the wiki
pep.
in the minutes
Ge0rG
pep.: They are WIP right now, so I'd rather not have them linked "publically"
jonasw
copying would be fine though?
pep.
k, so maybe we can copy that to the wiki
rtq3has left
Ge0rG
I'd like to establish some process where we have a master copy and the yax.im ToS are a fork of that.
winfried
Ge0rG: git!
Ge0rG
so you can fork it yourself and profit from later updates.
jonasw
maybe a repository under xsf?
jonasw
or xmpp?
Ge0rG
markdown + C preprocessor?
Ge0rG
jonasw: moving a git is the easiest part.
Ge0rG
the hard part is the split of template and specific server content.
jonasw
hmm
pep.
Right
jonasw
jinja is a neat templating language
Ge0rG
Or maybe some kind of ToS generator?
jonasw
would be trivial to build a generator on top of that
Ge0rG
Jinja is Beautiful. {% extends "layout.html" %} {% block body %} <ul> {% for user in users %} <li><a href="{{ user.url }}">{{ user.username }}</a></li> {% endfor ...
Ge0rG
They lost me at {%
jonasw
they copied that from erb I think
pep.
I don't think we should focus on html
Ge0rG
Markdown is an ideal language for the content, minus the templating.
jonasw
the advantage I see in jinja that its inheritance and block stuff would allow for easy replacement of specific blocks.
jonasw
and extension
jonasw
that would be cumbersome with C preprocessor
Ge0rG
We could also `sed -e s/ZZZservernameZZZ/$SERVERNAME/g`
jonasw
those are technicalities
Ge0rG
or use bash here-documents.
jonasw
let’s focus on what winfried suggested
Ge0rG
I don't care. I just don't want to learn a new templating engine language.
Ge0rG
git?
jonasw
10:34:00 winfried> I feel like taking a look at the bigger picture: where are we, what
jonasw
Ge0rG, ^
Ge0rG
:P
Ge0rG
Right.
Dave Cridlandhas left
pep.
In the meantime I don't have anything to show for this part of the minutes :x
pep.
But we can sort this out later
winfried
hey, I am participating again :-P
winfried
Big picture: we have some things we want to change on protocol level
winfried
EULA-XEP
winfried
Deletion
winfried
Transfer of data
winfried
(any other?)
danielhas left
winfried
ah, defaults for MAM
Ge0rG
retention times for MAM and HTTP uploads.
Ge0rG
Current implementations lack auto-removal of "expired" entries
pep.
s/HTTP uploads/server-side file storage/
winfried
There was some discussion on the standards@ list about incorporating local laws in standards
Dave Cridlandhas left
danielhas joined
winfried
what is our opinion in that?
pep.
Allowing deletion via the protocol has nothing to do with local laws right
winfried
I guess some topics are generic and not specifically for one jurisdiction
Ge0rG
winfried: the protocol purist in me says we should not encode local laws into our protocols.
Ge0rG
OTOH, the pragmatist requests an easy way for server operators to comply with local laws.
pep.
Ge0rG, I think I agree with that, but deletion itself is just a technicality and not a law
rtq3has joined
pep.
We might want to have another informational "GDPR compliance" XEP
winfried
Ge0rG: and what about an optional extension that describes an action needed in a certain jurisdiction...?
Ge0rG
winfried: I'd go with Business Rules paragraphs in relevant XEPs
andyhas joined
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
Ge0rG
This is how I'm doing GDPR compliance right now.
winfried
Ge0rG: :-D
Ge0rG
And this is not only fugly, it's also killing my availability / latency.
jonasw
sleep 2?!
winfried
I can imagine you want something more... sophisticated
Ge0rG
jonasw: yes. I can't just delete *all* messages at once because there are too many.
Ge0rG
deleting 5k takes <10s, so it's just barely bearable.
pep.
How many users do you have again?
pep.
Active users
Ge0rG
~1k
Ge0rG
But I have some active bots, it seems. And for reasons beyond my understanding, those bots are using MAM
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?
pep.
Ok, so back to XEPs,
winfried
3) informational GDPR XEP?
pep.
if 3), is 2) required
pep.
We definitely need 1) in any case
alacerhas joined
pep.
And I don't think anybody will argue this
winfried
jonasw: ?
Ge0rG
what do we nee 1 for?
Ge0rG
patching XEPs is #2, isn't it?
rtq3has left
winfried
New XEP: eula XEP, http storage management
jonasw
Ge0rG, (1) is adding functionality, (2) is adding business rules
jonasw
those are differences, and (2) can be moved to a generic GDPR XEP, while (1) can’t
jonasw
(well, could, but it wouldn’t make sense)
pep.
jonasw, 1 could be added to an addon XEP, but :/
pep.
Not informal
pep.
**informational
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.
Ge0rG
Re EULA XEP: do we need explicit consent?
winfried
pep.: think we need to decide on a case to case base if an add on is better of patching the xep
Ge0rG
If we need explicit consent, the EULA-on-IBR would be one possible implementation, with a web form based registration another obvious one.
pep.
Dave Cridland, 1. above is not "GDPR implementation stuff", right
pep.
2 and 3 are, and I'm also leaning towards 3
pep.
rather than 2
winfried
I guess Dave Cridland meant the choice between 2 and 3
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"
valohas joined
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.
pep.
We will need to tell developers though where to find that XEP
pep.
XEP discovery is another common issue
winfried
pep.: "Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"
pep.
winfried, k
alexishas left
Ge0rG
I can't see how we can create an (informational or other) GDPR XEP until May 25h.
alexishas joined
j.rhas joined
jonasw
I agree
j.rhas joined
jonasw
I wanted to get EULA done by today, but schedules
winfried
Ge0rG: Nope, I have to finish a DPIA before then :-D
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 ..."
Dave Cridland
Ge0rG, If a XEP has the phrase "MUST or MUST NOT" I will have to nuke it from orbit.
pep.
What winfried said above
pep.
"Privacy considerations: this XEP may have GDPR consequences, please see XEP-GDPR for more information"
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.
winfried
Ge0rG: can you explain why you think it is required?
Dave Cridland
pep., That phrasing works for me.
Ge0rG
Dave Cridland: why? It's only self-contradicting if it's "MUST *and* MUST NOT"
rtq3has joined
Dave Cridland
Ge0rG, Because it's meaningless.
Ge0rG
"this XEP may have global warming consequences, or may contain traces of nuts"
pep.
What doesn't have global warming consequences..
alacerhas left
Seve/SouL
And doesn't contain traces of nuts
Seve/SouL
0:D
Ge0rG
Dave Cridland: but I agree that RFC 2119 language SHOULD NOT be applied to legal requirements.
winfried
pep.: the chilling effect (couldn't resist)
jonasw
:>
Ge0rG
winfried: LOL
pep.
:)
pep.
Ge0rG, so I read you'd prefer to have GDPR details *in* the XEP?
pep.
And not an informational XEP
Andrew Nenakhovhas joined
Ge0rG
pep.: I don't know. Whatever will make server implementors create compliant implementations works for me
Valerianhas left
alexishas left
jonasw
I think general "privacy considerations" without mentioning legislation would be a good thing™
pep.
I'd see winfried's phrasing above, + informational GDPR xep
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.
jonasw
it would help to create awareness, just like Security Considerations do
jonasw
and I think they have a place in the XEP
pep.
Dave Cridland, yes I don't want either
Dave Cridland
pep., That is, put GDPR sections in every XEP.
pep.
hmm
alexishas joined
Dave Cridland
pep., Ugh. I'm being really unclear. I do not want GDPR bits in every XEP.
pep.
what GDPR bits
pep.
You'd be ok with just saying "seealso GDPR XEP"?
Dave Cridland
pep., Yes.
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."✎
pep.
Dave Cridland, ok then we agree
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. ✏
winfried
Dave Cridland: if we create an informational XEP about Sarbanes-Oxley, I wouldn't mind other XEPs pointing to it
Ge0rG
Maybe the issues is if we actually need *every* *other* XEP to point to the new one?
Dave Cridland
It might actually be useful to note what data is retained by each XEP, since that has very wide applicability and use.
jonasw
Dave Cridland, that’s what I had in mind for "Privacy Considerations" sections in XEPs
jonasw
and a separate GDPR document could point out what to do with specific data.
Dave Cridland
jonasw, Right, and I think it also forms very useful input to consent, privacy policy, etc stuff on a more generic level.
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 / ...)
pep.
jonasw, that still seems GDPR-specific. Some other law might define "private data" entirely differently
winfried
Like that idea, but it will be quite a bit of work to update all XEPs
rtq3has left
jonasw
pep., doesn’t matter, I’d consider all user data in that section.
winfried
jonasw: +1
Dave Cridland
jonasw, +1 from me too, for whatever it's worth.
pep.
jonasw, k
winfried
and should we also add a paragraph like that to the RFCs?
jonasw
I’ll re-word my '363 PR to conform with that.
winfried
jonasw: great!
pep.
winfried, mined territory I assume :p
Ge0rG
Having a "Privacy Considerations" section with that data in all XEPs would be great. We could just link those from the server ToS
winfried
Ge0rG: with autodiscovery based on service discovery!
jonasw
can we plan for enxt?
pep.
Can we define quickly what would go into that informational XEP
pep.
So we can start working on it quickly
pep.
jonasw, +whatever should work for me. Friday with the small delay as usual
winfried
pep.:
- steps for compliance
- red flags
jonasw
I can only make friday I think
alexishas left
jonasw
so friday 1230 CEST or 1330 CEST would be good for me
winfried
wfm
pep.
1230 CEST worksforme
pep.
1330 as well
winfried
1330 not for me
jonasw
1230 CEST on Friday, 25th it is then, Ge0rG?
Ge0rG
either is good
Dave Cridland
If someone writes the skeleton and an abstract for this GDPR XEP today, we can give it a number by tomorrow.
winfried
D-Day!
alexishas joined
Dave Cridland
... which might help "advertise" what you guys are doing.
Ge0rG
next number is 403, right? ;)
Dave Cridland
(It'd also give us something to blog about as the XSF)
jonasw
Ge0rG, no, next is 409 I think
pep.
Ge0rG, no that's MIX?
Ge0rG
Oh, wow.
winfried
Dave Cridland: good plan, I don't have time :-(
jonasw
I’ll try to dedicate my afternoon to the EULA XEP
Ge0rG
I'm behind on that thread.
jonasw
Ge0rG, cf. https://github.com/xsf/xeps/pulls
Dave Cridland
Ge0rG, I think MIX wants that, but I'd love to see the Editor creatively rearrange...
jonasw
409 Conflict is also good ;-)
Ge0rG
I would have skipped 403 as well. But meh.
jonasw
Ge0rG, 404 isn’t skipped
pep.
yeah 409 is also fine :P
jonasw
it’s for MIX ANON
jonasw
(the order in the PRs is just weird)
Ge0rG
jonasw: NOOO!1!!
jonasw
gotta go now
Dave Cridland
I wondered if MIX Anon was intentionally at 404.
jonasw
Dave Cridland, it is
Dave Cridland
But yeah, I think we should skip it for amusement's sake.
jonasw
I don’t feel like renumbering them ;-)
jonasw
MIX anon is a good use for XEP-0404 imo :)
Ge0rG
I disagree. But what do I know.
winfried
Should I close the GDPR meeting? ;-)
Dave Cridland
By the way, huge thanks to you guys for doing this.
pep.
winfried, :)
winfried
jonasw: do you have time to also submit a skelton and abstract for a GDPR informational XEP?
pep.
jonasw, I can have a look at EULA, for the obvious bits? (if there is any)
Dave Cridlandwonders if he needed to opt-in to be mentioned in the minutes.
pep.
Dave Cridland, I was going to ask
SaltyBoneshas joined
winfried
Dave Cridland: you revealed yourself, so no mercy :-D
pep.
But the logs of this room are public anyway, just like the minutes :P
Andrew Nenakhovhas joined
jonasw
winfried, no, sorry
winfried
I shouldn't do it, but I will give it a shot
winfried
(then)
jonasw
winfried, why shouldn’t you do it?
jonasw
if you’re uncomfortable with the markup, you can also just send me a markdown or whatever based document
jonasw
and I’ll transform it
winfried
time, am already terrible behind on an other GDPR project
jonasw
right
winfried
but it shouldn't be too much work
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
jonasw
I’m fine with an .odt if that’s what you’re most comfortable writing in
winfried
jonasw: k, let you know if I need anything
winfriedbangs a gavel and starts writing a XEP
pep.
Ge0rG, you're ok if I copy your tos/privacy policy to the wiki with a big "WIP"
pep.
And "To be moved to git"
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
Ge0rG
pep.: yeah
andyhas left
andyhas joined
pep.
We're still in Q1.1.2 right
pep.
or 1.1.3 maybe
pep.
Ah no 1.1.2
pep.
"consequences for server operators"
pep.
*1.2
Valerianhas joined
ibikkhas joined
rtq3has joined
ibikkhas left
ibikkhas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
SaltyBoneshas left
SaltyBoneshas joined
lumihas left
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
rtq3has left
winfried
pep.: timestamp ? loosing my context ;-)
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
pep.
(UTC+9)
winfried
ah...
winfried
that is the portability thing, download everything so it can be put on an other server
pep.
I see
SaltyBoneshas left
SaltyBoneshas joined
jerehas joined
SaltyBoneshas left
SaltyBoneshas joined
ibikkhas joined
Holgerhas left
lorddavidiiihas left
lorddavidiiihas left
pep.
https://cryptpad.fr/code/#/2/code/edit/j5ggWca+SLu32klePWFOeCIK/ winfried, jonasw, Ge0rG if you can have a quick look before I send
Ge0rG
pep.: 👍
SaltyBoneshas left
SaltyBoneshas joined
rtq3has joined
tahas joined
winfried
(Y)
jonasw
wfm
jubalhhas joined
edhelashas left
jonasw
I’ll now try to merge the MIX PRs and then I’ll start to look at the EULA XEP
edhelashas joined
Steve Kille
jonasw: thanks!
Valerianhas left
Valerianhas joined
jjrhhas left
mimi89999has left
tahas joined
lovetoxhas left
SaltyBoneshas left
SaltyBoneshas joined
jjrhhas left
tahas joined
Ge0rG
jonasw: But 404!
jonasw
yes?
Ge0rG
Okay, I didn't do anything when that window of opportunity was open, so I have no right to complain about it.
jonasw
Steve Kille, is "RELIABLE-DELIVERY" not there yet or am I missing something?
Ge0rG
I'll just pile my sadness on top of the Pidgin-officially-encouraged pile and move on with life.
SaltyBoneshas left
blablahas left
blablahas joined
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
SaltyBoneshas joined
Steve Kille
So, I (or someone else) needs to work out exactly what needs doing and write it.
Steve Kille
Running without this is probably not going to be a big deal for most deployments
Steve Kille
BTW using 404 for MIX-ANON was the choice of my co-author
Steve Kille
I think the humour is good
Ge0rG
IMHO, that number should have been used for "XEP not found"
Steve Kille
Kev got there first
Andrew Nenakhovhas left
ThibGhas joined
Andrew Nenakhovhas joined
lorddavidiiihas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
SaltyBoneshas left
SaltyBoneshas joined
jonasw
MIXes merged
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
Steve Kille
thanks very much for sorting this out.
lovetoxhas joined
Steve Kille
Meanwhile, I've received some private editorial comments on 1.0.0, whch I will work at soon
jonasw
I renumbered it to 0.10.2
lumihas joined
jonasw
it is not draft yet, and only draft can have 1.x.x
jonasw
and since the split was editorial as discussed, it got 0.10.2
Steve Kille
ah - I did not realize this.
Steve Kille
Given that over half of the text vanished from 369, this scarecely seems editorial
Steve Kille
I'm going to have to confess now that there were some technical changes
Steve Kille
Mamking the XEPs independnent needed changes
Steve Kille
Making Proxy JIDs work without MIX-ANON needed various changes
jonasw
uh
jonasw
yeah, I saw a namespace bump in there
jonasw
but I think that’s going to be needed either way
jonasw
I can’t really fix the version number now anymore, I’m afraid.
jonasw
so we’ll have to live with t hat
Steve Kille
shall I move to 11.0 when I do the next set of changes?
Steve Kille
All the others are at 0.1.0
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
Steve Kille
I think that the changes since 10.0 deserve a seond digit bump
Steve Kille
However, it is just a number, and I am happy with whatever the experts decree
jonasw
I agree that a second digit bump would’ve made sense
jonasw
but that’s spilled milk
jonasw
more or less
Steve Kille
I was asking if it makes sense to make the bump as part of the editorial changes I will make soon?
jonasw
ah, now I understand
jonasw
I’ll abort the build and fix the version number to 0.11.0
Steve Kille
if that is not too much trouble, I think that makes most sense
jonasw
done
Steve Kille
you're a hero
Valerianhas left
rtq3has left
jjrhhas left
jubalhhas joined
Valerianhas joined
j.rhas joined
j.rhas joined
marmistrzhas left
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
pep.
jonasw, sgtm
Ge0rG
jonasw: aren't we overloading our caps infra already?
jonasw
not sure
jonasw
for servers I don’t think so
pep.
jonasw, what do you do with it then? the client knows there's a new version, where does it fetch it
jonasw
pep., via the in-band protocol
pep.
Ok ok
pep.
iq or ad-hoc?
jonasw
not sure yet
jonasw
I think ad-hoc won’t do the trick
Valerianhas left
Valerianhas joined
Valerianhas left
pep.
I'd prefer iq I think, but I don't have a strong opinion
rtq3has joined
SaltyBoneshas left
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
pep.
Meh, I don't think the one place to rule them all would work
jonasw
yupp
pep.
that'd need to fiddle with every other modules
Ge0rG
There is one place to rule them all. "Delete account"
jonasw
that needs to go into the individual XEPs, just like it’s handled currently
pep.
Ge0rG, no
pep.
Say I still want to benefit from the services, but I want to opt-out of every consented feature
pep.
Doesn't have to be "please delete MAM", just "Please no MAM anymore"
jonasw
https://paste.debian.net/hidden/eb963ea8/
jonasw
pep., Ge0rG, ^
pep.
"The user shall be able to retract consent [..]", I don't have the exact quote
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 :(
jonasw
nice
pep.
I'll have to change that client cert..
jonasw
s/https/http/ will work though
pep.
yeah.. unfortunately
Ge0rG
"The server subsequently replies with the &tos; payload:" - that sounds like it's a ToS *payload*, but it's merely a ToS *link*
jonasw
Ge0rG, it is a payload of the ToS protocol
pep.
Ge0rG, I'd like to allow for both
Valerianhas joined
pep.
If you want to point to an external source, good for you. You might also want to handle this in-band
Ge0rG
Let's talk about XHTML-IM ToS payloads.
jonasw
pep., it’s not realistic to have the complete document in-band
pep.
jonasw, that's fine as long as EULA is only used for c2s
pep.
I mean, oob is fine**
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"
Ge0rG
representative = Jon Snow.
andyhas left
pep.
jonasw, I'm sure that template will get hairy quickly
jonasw
maybe, but maybe not
pep.
Plus operators will want to modify more than just placeholders
jonasw
pep., in any case, putting the whole ToS in-band won’t work.
pep.
won't work how?
jonasw
question 1: which markup format to use for formatting?
pep.
We don't have anything to do formatted payloads anymore? :)
pep.
Too bad
jonasw
I would have argued strongly against anything XHTML. way too much, markdown would be sufficient, if it was standardised.
pep.
but styling is not markdown.
jonasw
styling is not sufficient
pep.
Don't tell me
jonasw
you need headings in a ToS, and enumerations and lists
jonasw
I am confused
Ge0rG
Are we talking about Markleft or Markright?
pep.
Ge0rG, both
pep.
Also Markhtml
jjrhhas left
Valerianhas left
Valerianhas joined
jonasw
pep., do you happen ot have a link to your EULA XEP pad at hand?
winfried, that’s a good question (regarding multiple documents) ✏
pep.
jonasw, right.. I'm a bit annoyed at having this directly in <message> for some reason
jonasw
winfried, regarding requiring agreement, sure, we can communicate that, but does it make sense?
SaltyBoneshas joined
jonasw
winfried, is there a good reason to separate the documents?
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
pep.
Maybe we can just allow multiple sources of the same type
Guushas left
efrithas joined
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
alacerhas left
pep.
Well.. having both links for plain/text and plain/html, what will clients display anyway?
pep.
randomly choose between the two?
jonasw
unless you’re poezio, you’d probably link the text/html thing
jonasw
and dispatch to a web browser
jonasw
poezio might as well show the text/plain version inline
pep.
pardon my UX skills, but as a user I'd prefer to have a choice
jonasw
most users don’t want to
jonasw
they don’t even care about the difference between html and plaintext :)
Guushas left
pep.
which is also why I use poezio unlike "most users"
Dave Cridland
winfried, You know, you *could* use a SASL2 task for EULA agreement.
pep.
jonasw, anyway, I can live with just one document (and optionally multiple types), for the original question
Andrew Nenakhovhas joined
jonasw
Dave Cridland, i’d love to see a SASL2 task to replace my pre-bind/post-auth hack
jonasw
IBR integration is still on the todo
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.
matlaghas joined
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
jonasw
winfried, okay, that makes things much more complex.
pep.
Right. I've seen services present me multiple ToS I could agree to
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.
jonasw
(such as MAM)
winfried
pep.: yeah, that is ugly, but there may be good reasons for
jonasw
back to the scratchpad then
pep.
winfried, I guess we can skip this though, and do as jonasw says, have opt-in features be handled separately
winfried
jonasw: in our GDPR route, we avoid asking 6.1a questions, but other setups or other jurisdictions may have different needs
pep.
winfried, as in, clients would have UI for this, some configuration somewhere
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
danielhas left
jonasw
my assumption was that it’s always mandatory
winfried
jonasw: Nope, misconception #1 about the gdpr ;-)
pep.
I don't think it is (always mandatory).
jonasw
mmm
jonasw
okay, will have to re-do things then
winfried
jonasw: sorry...
jonasw
no, that’s great, we need a good thing here
jonasw
better sort it out before the first implementation comes along :)
winfried
Dave Cridland: love that idea, but I am happy you said *could* :-D
pep.
Yeah I'd like to see what that looks like as well
lovetoxhas joined
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
danielhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
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 |
| |
| |
+----------------------------------+
Wiktorhas left
jonasw
+ a [Register] or [Continue] button
jonasw
the tickboxes would be provided by the service
pep.
Also [Cancel], that would close the stream? :-°
jonasw
probably
pep.
Would MAM go in these [ ], or would it be in client configurations like we said above
jonasw
I would put that in client configuration
pep.
Because then we're separating stuff that requires consent
pep.
I mean there would be stuff all around, not just one place to accept
jonasw
if you choose to enable MAM, you have of course already read the privacy policy and thus know the terms for MAM
jonasw
yeah
pep.
Right
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.
Ge0rG, the tickboxes will use data form wire format indeed
jonasw
Ad-Hoc command wire format even
Ge0rG
The issue I have is that yaxim will not connect to the server until you fill out the username + password fields.
jonasw
so?
ibikkhas joined
pep.
Ge0rG, pulling down a XEP because of client implementation? how dare you :o
Ge0rG
pep.: I didn't write "The issue this XEP has"
winfried
pep.: a [Cancel] would be up to the server to decide, it may only disable certain functionality
pep.
Ge0rG, :)
pep.
winfried, if a user cancels, what happens legally? they don't agree to the ToS, but they can continue using the service?
pep.
I'm a bit confused
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>`
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
jonasw
is cancel really a thing?
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
pep.: oops mixing up not ticking a box and [disagree]
pep.
Ge0rG, who cares, people should setup notifications properly
Ge0rG
pep.: the right thing™ would be to send another kind of notification and let the user agree when they re-open their client
Guushas left
Ge0rG
pep.: people are using Jabber for important family notifications. Ringing them up at 3AM is not what I want to do.
jonasw
Ge0rG, the notification could be delayed until the next CSI Active if the client is CSI Inactive with a smart implementation :)
Ge0rG
jonasw: I don't believe in smart implementations any more.
jonasw
(with a delay of a few minutes to allow a client to go CSI Inactive after a reconnect)
jonasw
Ge0rG, do you have another idea for the notification?
jonasw
I don’t want to use an IQ because that won’t work with legacy clients at all.
jonasw
we don’t have a "silent" thing unfortunately
Ge0rG
jonasw: you encode the tos-version in the entity caps and push a presence update.
jonasw
presence update from whom?
Dave Cridland
I'm not convined you want to handle ToS changing mid-stream.
Ge0rG
from the server.
jonasw
and that won’t work with legacy clients at all.
winfried
Dave Cridland: why not?
jonasw
Ge0rG, users typically don’t have their server in the roster.
Ge0rG
Dave Cridland: what's your counter-proposal? Kick the client?
Ge0rG
jonasw: yes.
pep.
clients*?
Ge0rG
jonasw: this is why it's going to work.
jonasw
Ge0rG, you are an evil persion
Ge0rG
jonasw: what was discussed last time for mid-stream server-caps updates?
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.
jonasw
but relatedly, I have an update for XEP-0390 pending which allows servers to push updates to their caps
Guushas left
Guushas left
jonasw
Dave Cridland, nobody’s talking about "in that moment"
Guushas joined
Ge0rG
jonasw: yes. yes I am.
jonasw
the notification is supposed to be sent a few days ahead so that the user has time to review etc.
Ge0rG
you kick the user twice. First on the ToS update, second when they failed to accept the update in time.
Ge0rG
BTW, what happens if they fail to accept it? They get kicked and can't reconnect? Need to accept the ToS oob?
Board handle the XEPs that document XSF policy and procedures.
jonasw
okay
jonasw
so council it is
Dave Cridland
(Which are "Procedural")
jjrhhas left
rtq3has left
winfried
jonasw: pull request send
jonasw
neat, thanks
flowhas left
jjrhhas left
flowhas joined
winfried
Of to dinner!
jonasw
gl!
jjrhhas left
jjrhhas left
rionhas joined
j.rhas joined
ibikkhas left
SaltyBoneshas left
marchas left
SaltyBoneshas joined
jonasw
another update
blablahas joined
xnyhpshas joined
xnyhpshas joined
ibikkhas joined
j.rhas joined
winfriedhas joined
jjrhhas left
SaltyBoneshas left
SaltyBoneshas joined
Steve Killehas left
Steve Killehas left
tuxhas left
SaltyBoneshas left
SaltyBoneshas joined
Steve Killehas joined
jubalhhas left
ralphmhas left
marmistrzhas joined
alacerhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
marmistrzhas joined
Dave Cridlandhas left
Dave Cridlandhas left
SamWhitedhas left
pep.
jonasw, no MIME anymore?
rionhas left
Valerianhas joined
rtq3has joined
pep.
meh, nvm. You gave me too much options in the first draft!✎
Steve Killehas left
pep.
meh, nvm. You gave me too many options in the first draft! ✏
pep.
Ah wait, there is
Ge0rGhas joined
Dave Cridlandhas left
jjrhhas left
Dave Cridlandhas left
Valerianhas left
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
SaltyBoneshas left
SaltyBoneshas joined
pep.
hmm, maybe just to provide alternative versions/urls of the documents
j.rhas left
Valerianhas joined
marchas left
jonasw
pep., yes, you can only remove the additional elements✎
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
jonasw
pep., it might also be that an additional XEP extends it
pep.
Ok makes more sense in this case
matlaghas joined
Tobiashas joined
pep.
jonasw, "[..] and use a richer representation obtained from the <tos/> element for the same data." you mean HTTP GET on the urls?
jonasw
for example
pep.
Does it have to be a url btw
jonasw
and in the future maybe fancy things like machine-readable MAM retention times etc.
jonasw
yes
pep.
can it be a uri
lumihas left
jonasw
ugh, I never get the difference
pep.
I'm probably wrong, I mean does it have to be http
jonasw
no
pep.
How would you display a plaintext file retrieved in your client, the question of rich formatting still stands
jonasw
you could also have a text/markdown version.
jonasw
or text/restructuredtext
ralphmhas joined
pep.
Instead of "Duplicate MIME types MUST NOT occur.", can we have "Duplicate url/MIME type pairs MUT NOT occur."
pep.
hmm, I assume the url would use a different protocol though
Dave Cridlandhas left
jonasw
pep., duplicate MIME types makes it hard for the client to decide which one ot use
pep.
It can decide based on the protocol _and_ the mime type
jonasw
right
jonasw
might add that later
jonasw
I pushed it into the xeps repo now
pep.
Ok
rionhas left
pep.
What about errors when client submits filled-out form
pep.
"not latest version", "invalid documents", "unknown opt-in feature", etc.
matlaghas joined
j.rhas joined
jonasw
yeah, should probably be defined
pep.
Ah I see you've added a <tos-push/> containe r:)
jonasw
you can send those to the mai3ling list :)
pep.
will do
jonasw
(once the announcement is out)
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 :(
danielhas left
pep.
:(
pep.
something something incremental builds
jonasw
yeah
jonasw
something something docker sucks
pep.
I'd argue that's up to the CI
lskdjfhas left
jonasw
you can’t do that with docker hub, period.
pep.
Ah, well docker hub != docker
SaltyBoneshas left
SaltyBoneshas joined
Valerianhas left
lskdjfhas left
pep.
Did we had Privacy Considerations to the template btw
jonasw
no, I didn’t want to do that in the climate after the XEP-0363 debate
pep.
ok
jonasw
and I still need to reword the ideas for that
blablahas joined
pep.
"The version identifiers generated by servers MUST NOT be longer than 128 characters." a reason for this in particular? (even if unlikely)
la|r|mahas joined
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
jonasw
before you are authenticated, your server MUST NOT allow you to query other servers for their ToS
pep.
But other servers may allow anybody to attempt a connection and query their tos right
pep.
Just like my https://service.example/tos will be public, I don't mind having my xmpp server disclosing them publicly
jonasw
yes
jonasw
but you don’t want to be an open proxy for entities sending IQs towards other servers.
pep.
I see
pep.
Also what about sasl anonymous
jonasw
I don’t see how that’s relevant
pep.
ToS acceptance is required only if there is account creation?
jonasw
dunno
jonasw
IBR integration is still fully missing
pep.
Right
ludohas joined
jonasw
theoretically, a SASL ANONYMOUS thing could apply § 4.4 Inform client about Terms of Service expiry after authentication
Dave Cridlandhas left
pep.
I'll reply to the thread when it's out and ask about all that
Dave Cridlandhas left
waqashas left
SamWhitedhas left
jonasw
okay gotta go, build didn’t finish in time :( will send the mail tomorrow or later tonight
Dave Cridlandhas left
SaltyBoneshas left
SaltyBoneshas joined
Dave Cridlandhas left
jubalhhas joined
danielhas joined
rtq3has left
jjrhhas left
bearhas left
bearhas joined
Dave Cridlandhas left
Zashhas joined
Tobiashas joined
waqashas joined
Dave Cridlandhas left
SaltyBoneshas left
SaltyBoneshas joined
Ge0rGhas joined
alacerhas left
alacerhas joined
SaltyBoneshas left
SaltyBoneshas joined
SaltyBoneshas left
SaltyBoneshas joined
Tobiashas joined
Valerianhas joined
la|r|mahas joined
la|r|mahas joined
Dave Cridlandhas left
marmistrzhas left
vanitasvitaehas left
Guushas left
Valerianhas left
rtq3has joined
Guushas left
Guushas left
Guushas left
jjrhhas left
jjrhhas left
alexishas left
jjrhhas left
Guushas left
alexishas joined
jjrhhas left
Ge0rGhas left
rtq3has left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
sezuanhas joined
alacerhas left
alacerhas joined
jjrhhas left
matlaghas joined
Dave Cridlandhas left
jjrhhas left
rtq3has joined
Ge0rGhas joined
alacerhas left
winfriedhas left
danielhas left
ralphmhas left
jjrhhas left
jjrhhas left
jubalhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jubalhhas joined
Valerianhas joined
Guushas left
jjrhhas left
jjrhhas left
Guushas left
jjrhhas left
jubalhhas left
jjrhhas left
SamWhitedhas left
Ge0rGhas left
jjrhhas left
alacerhas joined
marchas left
Nekithas left
Nekithas joined
jjrhhas left
jjrhhas left
jubalhhas joined
alacerhas left
Kevhas joined
marchas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jubalhhas left
jubalhhas joined
Ge0rG
speaking of appropriate number mappings...
403 = GDPR Compliance
404 = Terms of Service
pep.grabs popcorns
rtq3has left
moparisthebest
Ge0rG, I think those have been reserved for the mix hatchet job
Ge0rG
moparisthebest: not merely reserved, they are official now.
pep.
moparisthebest, yes, he's been onto it for half a day now, now about this :P