XSF Discussion - 2018-04-26

edhelas, https://edhelas.movim.eu/ certificate expired

damn

just had to restart nginx …

reload*

Don't restart for nothing

yeah that is what I didn't understood

reload didn't worked

I have to check

GDPR meeting?

Give me a minute!

only one?

Do the minutes from the GDPR meetings conform to the GDPR?

!

Dave Cridland, I only report public discussions, so I assume so

Maybe mailman could put a few more disclaimers when subscribing though

Dave Cridland: of course not, the biggest leaks are at the plumbers house!

I’m there, just a sec

.

now I’m there

Ge0rG present?

\o/

okay

We did a splendid job on metadata last time, most of it is 1 to 1 applicable to [stanza|user provided] content too

yep

The only thing that needs a bit of consideration IMHO is MAM

why?

I thought we already settled on that

Apart from the TODO items

all processing is done under article 6.1b / 49.1b except for MAM, when using your own archive, it is 6.1a (consent) and the storage at somebody else should be a case of 6.1f (legitimate interest of third party)

are you still there?

I agree for 6.1a for own archives, and I see the logic for 6.1f, but that goes against what we said no?

I’m still there

That messages sent to a recipient are this under this recipient's consent

I don’t see why other peoples archive isn’t covered by "messages sent to other users are subject to policies those users agreed to"

jonasw: good point

winfried, I fear it's not only MAM we'd have to treat differently if we went that way

that is indeed a result of consciously transfering the data to the other entity

so, indeed skip the 6.1f part (and from the table, plz put it in the minutes)

ok

So, left is: ensure 6.1a is taken care of in MAM, aka, consent and of by default...

... and possibility to withdraw consent

Right

and that one was already on the technical ToDO ;-)

"Right to erasure" is already more or less implemented right?

pep., depends

Maybe I'm skipping steps

there’s no way to truncate MAM via protocol currently.

Holger argued that it’s requested so rarely that it isn’t needed to encode in protocol and manual handling is entirely feasible

jonasw, hmm, ok, I was thinking about the entire account

pep., that’s truncation

or do you mean non-MAM content, too?

everything

right

we don’t have that

but that’s probably okay-ish to defer to manual operator intervention at this stage.

When you request account deletion, what's being deleted?

jonasw: Actually I just mentioned it's requested rarely without argueing for anything :-)

jonasw: I wouldn't mind such a feature at all, esp. if we manage to keep it simple.

Holger, sorry, lost in translation :(

I don't think prosody keeps anything does it?

Truncating an entire account and truncating your MAM should be possible separate form each other

winfried, agreed

winfried, sure

pep., I’m rather sure that prosody won’t delete HTTP upload-ed files

Holger, my idea was something like a disco#info feature + <iq><mam-truncate/></iq>, which simply drops all of your MAM archive.

jonasw: good point

I suggest that we put together a list of user data which is currently commonly held as a guideline for operators

jonasw: yes, can also be an important part for an EULA

jonasw: Sounds good to me. But people *will* want more features for sure, so maybe we should clarify right from the start whether or not we'll resist adding them.

- HTTP Uploaded files - MAM contents - Offline messages (if separate from MAM) - Roster - XML Private Storage - PEP - Ephemerally cached stuff (last presence stanza) ✏

jonasw: Because if we end up with more features anyway, we might want different syntax from the start.

Holger, sure, this isn’t the place for that though :)

Sorry I'm late, had an unexpected appointment

Ge0rG: welcome

Good progress you've made today

There are some other prosody todos like actually deleting MAM after N days even if the user didn't log in

jonasw Holger, the list should be writen as baseline, but if a server operator wishes to do other processings, it should be added to the list (and have its own legal stuff)

And probably also deleting the files from their http upload, both after N days and on account deletion

mod_gdpr_timer anyone?

Lets not focus on one implementation and its bug list ;-)

People doing http-upload usually keep track of who uploads what?

Is this a thing?

pep., no, it’s not :)

and that’s probably the problem :)

hehe

yeah, that one is needed for deleting it....

Another TODO

is there a specified maximum time an operator can take for deleting data after receiving the request?

yes

jonasw, for the "what data do you have on me request" I think it's a month,

I'm not sure about deletion

if it’s like 7 days, operators could just go with the natural http upload expiry they might have

pep.: you can extend the time by sending back a whiny response how hard is it to gather all the data ;)

jonasw, you mean "natural expiry" of "none"?

:)

Ge0rG, but then you'd have to explain that to the ICO? :P

jonasw: what happens with the things the user uploads while their request is pending? ✏

my bible says: "deletion without unreasonable delay", at least within a month :-D

is "uh, we don’t track who owns which file so we have to rely on normal expiry" a reasonable delay? :)

:P

jonasw: LOL! I guess not

In doubt, ask for consent!

jonasw: just replace all http uploaded files with a goatse overlayed with "no consent"

*all*?

even those of other users?

yeah, you can't know for sure

todo: write a XEP that asks all other users on consent when one user requests deletion of HTTP-upload content :-D

winfried: sounds like the blockchain approach

What was that potential XEP again? http-uplod slot that wouldn't expire

For avatars and whatnots

But HTTP-upload deletion needs to be covered too, unfortunately

jonasw: to return to the question if expiry will be enough here: only if it expires *fast*

what’s "fast"?

1h? 1d? 7d? 30d?

jonasw: I would say 7d

ok

But from a legal point of view, real deletion would be better (and more flexible)

yes

So do we want to add deletion to HTTP-file upload?

Also prevent trolls from uploading stuff when they've requested deletion

winfried, I’m not sure if it should be added to the protocol.

winfried, where does it say "deletion without unreasonable delay" exactly?

Do we want an EULA XEP + informational GDPR XEP?

art 17.1

Or do we want to change others

and if so, it needs to be thought out because the HTTP server and the XMPP server may not be the same entity. but it should be mentioned in the HTTP Upload XEP that implementations must allow the operator to delete all files of an individual user as well as individual files.

pep., it’s safer to include such information in the relevant XEPs than having a another XEP which people must play attention to.

jonasw, hah, good point

(for both)

maybe add a "Privacy Considerations" section.

Right

Maybe that could be added into the template now

pep.: +1

I think historically we had this in the Security Considerations

but this is a separate thing IMO

jonasw: +1

Even if both are entangled, they're not exactly the same :x

should that section be REQUIRED or RECOMMENDED?

I think having it REQUIRED is sane.

jonasw: yes, and maybe add some items to the template that help structuring and analyzing it

winfried, would be glad to do that if I get input on that

I would say RECOMMENDED, but I could see both

jonasw: I can help there

jonasw, oh, that's for the template, so XEP authors?

pep., I think REQUIRED makes sense. Even if the section is just "no user data is collected, thus there are no considerations".

Then REQUIRED

pep., yes.

jonasw: can we return to the HTTP upload for a moment? We should not change that XEP?

winfried, I’m pretty sure we should change it

change what

exactly

at least it should get a note that operators MUST have a way to delete all files of a user.

Can we not just update it

winfried, extending it with a flow which allows a user to IQ-request a URL where they can issue an HTTP DELETE to delete a file is another step I can see happening.

pep., I’m not sure I understand

ok I'm just confused, nvm

jonasw, yes we'd need both I think

jonasw: should we open this discussion in the standards list?

winfried, yes

winfried, seems ok

I’ll write the mail right now.

We'll need to open a few threads anyway :P

jonasw: thanks!

See TODOs

jonasw, PR then thread maybe?

Unless it's not exactly clear yet

damn, I’m getting pulled away

will do

cool

cool +1 ;-)

I brought right to erasure to the table, but is it ok? What else is there to do on 1.1e

pep.: it is totally ok

We haven't done server logs? remote components?

correct

but server logs is clear cut: recommendation for server operators

remote components is covered by 6.1b and no need for extra measures (in line with the earlier decisions)

winfried, "recommendation for server operators", what do you mea

mean

pep.: we should mention to server operators what they should and should not do with the logs to stay within the GDPR

Ok, subject for next time then?

We should probably start opening threads for the TODOs and Technical TODOs

so we can see results quick

yes

But I believe we have covered 1 by now!

I want a bit more details for server logs, for the minutes/wiki, but yeah

Lots of things to act on now

See we can see for the XSF.

I guess it'll benefit from all we do for the other operators anyway. And then the wiki, maybe we just need to state during registration that it's all public?

as PII, only keep email addresses are stored?

pep.: Ge0rG mentioned this one http://www.privacy-regulation.eu/en/r49.htm

winfried, yeah but I thought maybe we can dillute that a bit in guidelines

pep.: yes, agreed

Date of next maybe?

Looking at the time: ...

we need to check if 1 covers 2 fully

and then start all over again for 3 :-D

no as it's not only XMPP, for 2

wiki, mailing lists

Ah wait

That's 3

;-)

And we need to polish the list of tasks and put names under it...

Right

and report to the board

(and council)

re

sorry, I had to let an ISP technician in

Date of next? +1 no good for me

Next week I should be able to do any

next week has my usual constraints

apr 30 12:30 CEST?

worksforme

should be able to

Ge0rG ^^^

pep.: I was still in the process op updating the table and processing your previous minutes.. will continue with that

Guess Ge0rG is afk again...

If write it down, pending objections from Ge0rG

yeah

thanks all :)

we’re doing good progress here

jonasw: yeah, thank you too!

the pieces are falling together nicely

I'm running away, will confirm date of next if Ge0rG can't do, it should work for me anyway

yes, plz!

winfried, will you provide me with a list of guiding questions I can put into the Privacy Considerations template section? ✏

jonasw: the bottom line is we want to know if anything is done that is not covered by 6.1b or 6.1a

lets try to make that one not too bureaucratic

Does the extension describe any processing that is not obvious to the user?

If so, does the extension mandate consent for it?

And if so, can the consent be retracted?

Sorry folks. I *think* I can make 30th 12:30

and also: are there any additional risks, like profiling, analyzing sensitive data or automated decisions? If so, what measures are taken against that?

Ge0rG: then you will be with us at least in thought ;-)

Ge0rG: plz drop a not when you know more

s/not/note/

jonasw: enough to get started like this?

winfried: I'll have to decide on short notice. The next week will be rather rough, I'm finally moving to the new house

Ge0rG: congrats!

let us know, plz give us feedback in other ways otherwise!

winfried: don't make it depend on me; ping me when you start and I'll try to be here

Do HTTP uploads count as message content?

Zash: yes, user provided content to be precise

I saw mention of "legitimate interest" for the message receiver, I wondered if that covers uploaded content as well

Zash: I think so, yes

Zash: we decided to abandon that line of thought, sending a message / file is just a transfer

The (currently at least) technical difference is that files are still hosted at the sender

Zash: yes, good point. But from a legal perspective there is no need to give the receiver based on 'legitimate interest' any rights to that. That would just open a legal minefield

It touches on a recent discussion about possibly re-hosting files at the receivers server, or providing a HTTP proxy, to provide some privacy protection to the receiver

Zash: the issue is the 'right to be forgotten': transferring data to a proxy or re-hosting it at the receivers server doesn't change that right, neither does the legitimate interest argument

So if it wasn't hosted at the receiver's server, but the receiver downloaded it and kept it on their PC...?

I'm not sure what 'right to be forgotten' means exactly. I assume you can't ask service provider A to forget something and have provider B also forget about it.

MattJ: then it is transferred to the intended user, demanding deletion depends on the use of it by the receiver, personal use is not regulated, other use is subject to right to be forgotten

Zash: no, you have to ask both

winfried: Sounds like fun if you'd dropped something into a large groupchat :D

That is my job, and I love my work :-P

.. to get more coffee

https://twitter.com/leinweber/status/989267343002951680

We need that too!

test

Test

(it works)

congrats on the new job, Nyco!

congrats on the new lap around the sun, Dave

I'm all out of congrats now.

I feel I deserve a congrats just for getting out of bed in the morning, frankly.

Kev, you did not get my card?

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

Lost in the post, I fear.

0. Welcome and Agenda

Bastards. It was not easy to find an appropriate one. Hallmark apparently does not have a card for every occasion after all...

Hi! Who do we have, and do you have something for the agenda?

I'm here, nothing new for the agenda.

Also congrats to all around.

well, we can revive cafepress? take a decision?

Hey

nyco: that's already on the agenda

Anyway, Martin sent apologies.

1. Minute taker

Who?

I'll do them

(I'm again pressed for time, sorry)

tx

2. Topics for Decisions

I'll pull the Swag one here.

nyco

so what's our decision I'd go for a try, let's say a few months, see how much time we spend, how much money we get, how good/bad press we have

I'm good with that

what does that look like?

Who'd "manage" the "shop", including providing designs?

I have never done something like this

I can lead, or someone does in which case I can help

the designs would only be the logo for the beginning

And what is the Royalties thing?

I sent an email around that, could you read it?

I think we have an option to either pay upfront, or have a percentage deduced from our earnings (but not have upfront costs).

I'd prefer the latter for now, while we're experimenting. If only because it reduces the complexity of setting things up, I imagine.

nyco: I did, and I didn't understand

I have various chunks of artwork around in EPS/SVG if anyone needs them.

sure

(cause if I didn't read it, how would I know about Royalties?)

right ;-)

Dave Cridland: same here

]

I think until a certain threshold, it is a % fee

Dave Cridland: like the little design I did for a potential Summit shirt. I also have the correct fonts

the markup is big, as always (like AppStores at 30%)

nyco, oh, I thought from the email it was 10%?

Note that it is 10% of the _royalties_, which is _not_ equal to the sales volume.

So like a t-shirt (tri-blend) seems to sell for $29.99. How much would we gain from this?

I don't know what amount of royalties we get for a sale.

Guus: right, that's why I want to know what Royalties means

all right, so I thought I understood, which does not seem true anymore

From what I understood from that site (I browsed a little)

they have a base price for items

I understand we need to know+understand more about royalties before taking a decision, is that correct?

you can add your own markup

that's what you receive as 'royalties', and from which their fee is deduced.

It seems that this is more informative: https://www.cafepress.com/cp/info/help/shop_services.aspx

https://www.cafepress.com/cp/info/sell/index.aspx?area=intro_money&page=intro_money

So, for this meeting, I think we need to agree at least if we'd like to do something like this, and then evaluate which actual shop we'd like to use.

https://www.cafepress.com/p/help-creating-selling-earning-money and https://www.cafepress.com/cp/info/help/pricing_policy.aspx seem to explain it.

Ralph, to be honest, as long as we're not spending money, I don't mind to much.

E.g. I'm wary of this part: “n order to keep designs fresh and of high quality as we launch new products, styles, and printing technologies, solely for designs that you are selling through the CafePress Marketplace: (i) CafePress may automatically add your designs to additional products in the CafePress Marketplace; and (ii) in order to improve the printing quality, CafePress may automatically modify your designs (e.g., cleaning up JPG artifacting, adjusting colors for different printers and products, and adjusting design placement on products).”

that's correct, not only cafepress offers those kind of services

Ralphm: I see no problem with that text you just quoted.

"CafePress may automatically add your designs to additional products in the CafePress Marketplace", what does this mean?

"if we sell new types of swag, we might automatically add these with your branding on it."

When they add a new product (now they sell garden fences), they can add your logo to garden fences and sell XSF garden fences.

nyco, You make a t-shirt, they do a mug.

I'm guessing (but don't know) that it means you opt to sell a t-shirt, but they also offer a mug

I'll have to jump on another meeting at 16:00

So let's separate this: do we want to sell swag in a shop "like cafepress"?

yes

I'm +1.

+1

+1

Sounds at worst harmless to me, from the peanut gallery, too.

Ok, decided we'd like to do this.

so I'll find alternatives to caferpress

Then the second part is which shop. I read something about Cafepress "mailing checks". We don't have checks anymore in .nl, so I don't know how this works, but given that we are incorporated, I suppose that could still work?

I think we should OK whatever choice we make with our Treasurer.

to verify that we can facilitate the way money exchanges, I mean.

Ok, nyco to find out. Let me know when I can help with designs

now...

:-D

3.

send me what you got?

3. AOB

(no AOBs from me)

We've got 4 minutes. Anything we need to do now?

Survey

the next newsletter is getting readier everyday

A couple of brief questions:

nyco: yay

we need to agree on the scope - should it be members-only, or open?

currently, as it is today, the members

I have no strong preference there.

Oh, I can report we gained github.com/xmpp. I've given control to intosi and Kev, and we can figure out what to do with this

MattJ: let's go with members for now

Ok

if we want to go broader, then we should grow our ambitions, make it wider, obey all the surveying rules, promote it in a proper way, have time to interpret and analyse the results, report to the board and members

I'd like we do such a survey soon

Feel free to draft and prepare such :)

Did you have more questions, MattJ?

exactly

Guus, I think that's it for now

Should I just send it this week?

to members@

Yes

go for it.

Ok!

yes, please, and thanks for this

Thanks!

4. Date of Next

Then that's all

+1W

wfm

wfm

yep

thx all!

5. Close

Thanks

Thanks!

And more congrats were due.

congrats!

Now I want to have an "XSF" shaped garden fence

I trust that you will appropriately motivate CafePress.com to add that to their collection.

Ah, the times when laser-cut XMPP stickers were the cool stuff.

... showing your age ...

Who needs laser-cut stickers if you can 3D printed garden fences.

I think we should do A/B testing of our brand by offering "Jabber" everything that we also offer "XMPP" of

I don't know if we can use the Jabber trademark for swag.

I wonder if the XSF needs a permission from the XSF to use the trademar. Peter will love the idea.

> Otherwise, the fee is $250.00 for use of the mark in connection with Jabber accessories or any use other than software or computer hardware

I can't even find a mention of the 250$ fee in the license agreement.

But I should stop now. I think everybody still remembers my contempt for the license situation from the last time I tried to fix it.

where’s the license agreement?

I thought we only had that declaration of intent

jonasw: https://xmpp.org/about/xsf/jabber-trademark/trademark-license-agreement.html

> The <tt>url</tt> attribute of the <tt>delete-slot</tt> element must refer to the GET URL for the file. The server replies with a URL which can be used by the client to delete the file Wait. What?

jonasw: is there a reason why the server shouldn't just immediately delete?

Ge0rG, the XMPP server and the HTTP server might be on different machines.

I can also imagine that we leave it up to the server whether the client has to DELETE or whether it deletes right away (indicated by lack of the <delete/> child). but I’m not sure there are use-cases for that.

(it might be that it’s required to do that in some circumstances though, where DELETE can’t be authorized properly with a token; not sure if such scenarios exist)

I can see how off-loading PUT makes sense, but what's wrong with having the XMPP server do whatever HTTP request?

I can see why XMPP servers might not want to have an HTTP client.

jonasw: Can you have anything without a HTTP client these days? :/

Zash, :(

Does sed have an HTTP client?

Or bash?

jonasw: did you submit the bot to HN already?

bash, it would be trivial to do one (sockets)

sed, not

I've written a web *server* in bash, some twenty years ago.

Ge0rG, too lazy to get an account etc.

okay, maybe not quite 20. But it was at a time when dialup was the thing in Germany

jonasw: I'd create one for you, but I'm sure it'll be tainted as a sock puppet

Somebody wrote an HTTP server in PostScript

It's what's running on HP LaserJets, right?

Not sure

haha

jonasw: http://www.pugo.org/project/pshttpd/

That's horrifying…

you are aware of the atrocity I did? https://github.com/horazont/xmpp-echo-bot/

(it’s not as harmless as it looks like from the URL…)

jonasw: I am simultaneously appalled and in awe. wow

same Lance , nice work jonasw :)

thanks :D

that was the kind of reaction I was going for, Lance

Lance: that'd be a great testimony for the README, if you are okay with it

of course :)

I'd do a PR, but I don't know the Canonical Order of Testimonials

good point

Lance, where, if any, should I link to at your name?

That, too.

jonasw didn't ask me that question...

github.com/legastero works

https://lance.im/ looks like a prosody 404

Neat

as it should

Ge0rG, sure, but I knew where I could link, I don’t know for Lance

published

It's behind joo.

did anyone post this before? ew https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app/

it's amazing what millions of dollars of investor money can buy

Geez

sad..

I mean I guess good for them.

Is the matrix standard even finalized yet?

nah guess not - it's r0.3.0 and it's a 'living standard'

interesting comments w.r.t. Matrix as a standard: https://news.ycombinator.com/item?id=16933736

Define interesting

Zash: adj. Arousing or holding the attention; absorbing

: D

this comment seems to claim the protocol is highly unstable: https://news.ycombinator.com/item?id=16935012

who cares if the protocol is unstable if 1 company is producing all the servers and clients?

Their spec pages do too

moparisthebest: I guess not the French government ;)

also, no way anyone in france's govt even knows what a 'protocol' is

all they know is they want a fancy chat app

*encrypted* fancy chat app

encrypted sells nowadays ;)

They know enough to be willing to put spyware in your router firmware to satisfy music recording firms against piracy.

🤨

that sounds horrifying

but I'm guessing they still don't know, only that music industry said it will 'save the music industry'

moparisthebest: Yeah, they'll be in exactly the situation they claim to have avoided once another implementation becomes popular enoguh.

Zash, well worse if there are no standardized protocols or consensus, but yes

> Alternatives like Prosody's XMPP server implementation dropped websocket support in favor of BOSH years ago I don't even.

:O

:O

where is that from?

Second-to-top comment on that HN thread

https://news.ycombinator.com/item?id=16933736

I should find myself something costructive to do.

Maybe going to bed falls in that department.

:P

Agh, all links go to the top post! This one https://news.ycombinator.com/item?id=16935094

zash: lets blame lance for that!

I mean in theory going with at open protocol with a open client/server is better than paying IBM or whoever a bunch of money for a solution that sucks and can't be improved internally.

On the other hand if they went with XMPP they would have multiple vendors who would compete on RFP's

Huh?

Isn't the point of RFPs to draft them tailored to a specific vendor?

er probably used that wrong - I mean when the government wants a new feature or whatever multiple companies are going to be sending in bids.