XSF Discussion - 2018-04-18

Do we actually have someone administering xmpp.net? All tests appear to have been failing for the last few minutes and there appear to be random PHP errors showing up on pages.

Hmm, at least one of them started working. Still, seems like something is going on.

SamWhited, that PHP error is known-ish and we could use somebody with PHP and docker knowledge to look into it.

I have both, but I am short on time right now and PHP isn’t anything I do for fun.

Uh-oh. https://news.ycombinator.com/item?id=16863675 > Zulip 1.8: Free software Slack alternative with email-style threading

re GDPR: https://www.theregister.co.uk/2018/04/14/whois_icann_gdpr_europe/

RIP WHOIS

RIP EU

RIP everything.

Editors: how is XEP-0380 deferred after 12 months of inactivity, when it says the last update was January this year?

on it

MattJ, that update was the deferral

Ah :)

Thanks, makes sense (I guess)

Sounds confusing

yeah

but kinda required for consistency in the attic I think, because attic file names are xep-$number-$version.html

I dunno

not sure if we want deferral to be reflected in the attic

I need to write a few guidelines I have in mind down and run them by the editors for these things.

Hmmmm

Is it fair to say that there is currently no recommended way to format messages in XMPP?

With XHTML-IM killed and two new proposals, yeah, that sounds about right.

I'm making a note here... huge success

https://xmpp.org/extensions/xep-0393.html vs https://xmpp.org/extensions/xep-0394.html ... Fight!

Zash, I don't think they are in conflict with each other

Technically? No, I suppose not.

But mindshare and > I have to read *TWO* XEPs just to implement styling? No way, I'll just implement generic inferior protocol instead.

0393 needs a big scary warning not to use an off-the-shelf Markdown processor

Zash: I don't think it would work if you tried to use one, it's not actually compatible with markdown, but having a warning couldn't hurt either.

la|r|ma: As for process, both of those are Experimental. Ie not recommended.

I'll add one at some point.

SamWhited: Are you sure? It's exacly like the stuff I feed into pandoc.

s/is/looks/ maybe

the only thing i am missing in 394 is a hide feature, so I can send a star in body for 393 and backwards compat and remove the star in with 394.

Zash, most markdown processors allow html injection

Zash: I'm pretty sure markdown uses * or _ for strong and ** or __ for emphasis (or something similar). We use * for strong and _ for emphasis.

SamWhited: Right. Close tho.

> `this tho`

I suppose it's possible someone could use one anyways, not notice that bold/italics was broken, and call it good enough. Either way, a warning seems sane.

la|r|ma: Yes. Which is Very Bad. And why we need to prevent anyone from even thinking about using one.

Zash, > With XHTML-IM killed and two new proposals, yeah, that sounds about right. Motivation to kill xhtml is very sloppy.

-xep xhtml-im

bunnnnnnnope

> XHTML-IM (Standards Track, Deprecated, 2018-03-08) https://xmpp.org/extensions/xep-0071.html

Just checking whether it's really been killed already.

Andrew Nenakhov: What do you mean?

Andrew Nenakhov, the summary was every client that has ever implemented xhtml-im has implemented it in a way as to have fatal security flaws

it'd be different if any client ever didn't have fatal security flaws because of implementing it

Standard could be reduced to just html, throwing away all css crap that made it hard to implement.

Instant messengers don't really need much more than bold, italic and underline text

Isn't HTML massive overkill if you just need bold, italic and underline?

Andrew Nenakhov, the css wasn't where the vulnerabilities were, it was just using an html engine that allowed javascript and various other things

So standard is bad because html engine allowed JavaScript?

That's flawed thinking

What if markdown engine will have flaws, you'll deprecate those 393/4 standards too?

We couldn't do that either way because it was in draft. A new spec could still be written to do it that way, but I suspect that the exact same security issues would result.

Andrew Nenakhov, I agree on principle it's a dumb reason, but if in practice 100% of implementations are vulnerable, that's a problem

With xhtml IM the easiest way to implement it was vulnerable, so that's what everybody did. Hopefully whatever emerges as,a replacement won't have that problem. It's as simple as that.

Sorry for bringing it up, I was just trying to document an objective "today in XMPP, formatting should be done by [...]"

and realised I didn't quite know what to say

clearly it depends who you ask :)

I don't have a solution to offer, but we're just obviously not in a good place right now

also, what kind of formatting you want/need

That's not a good answer :)

for instant messaging, 393 provides everything everyone has already implemented for decades

clearly it's *good enough*

poezio didn't show that as bold ^

or should that be italic?

Nobody uses poezio.

either way you got the point, I actually did it manually out of habit so :/

Make no sense to alter human text just to make a word bold

Everyone uses Conversations, and it does 393 or something like it.

I think that's what I like so much about 393, whether you implement it or not, it still mostly works

we've been doing this in email/irc/forum posts for years anyway

In Microsoft MSN, I think you could select text and select formatting.

Nothing about typing special characters my mom does not know.

, oO(I've now implemented message expiry about five times. At some point I might as well specify that. All the implementations I've done over the years are compatible with each other anyway. Even though they are of course implemented in systems that don't federate)

daniel, you mean the infamous 'please delete this message kind remote client I have no control over' ?

Yed

'self destructible messages'

people do ask for that alot even though it's really naive usually, it'd be worth some interop though

people clearly don't care that it's a technical impossibility even on proprietary walled gardens ¯\_(ツ)_/¯

To be fair it is a relatively decent counter measure to a pretty narrow attack vector.

It just has a stupid name

Like Teslas auto pilot

daniel, so, do you negotiate caps with remote clients and only send if they support self destructible messages? or do you just send with a <please-delete-me-after/> tag

hmm, and carbons and multi-client...

and archives

yea I initially assumed you'd add the don't archive tags, but that wouldn't work so well for push and such maybe?

is it delete after X time even if they haven't seen it? or delete after having read it or something?

moparisthebest: I think it can only work in homogenous environments. Not necessarily in 'Jabber'. So specifying it would only serve 'proprietary' systems.

But those use xmpp too

We do have security labels in xmpp as well even though those only work in homogenous environments as well

people seem to want it in conversations too, but it's not even enforceable in proprietary systems unless they also ban cameras and such

moparisthebest: the recipient is not the attacker. The police who get their hands on the recipients phone after they have been arrested is

This delete this message thing - is like I say delete this, then on my screen and your screen that message no longer shows up and in theory on the server they have deleted it from the database?

jjrh: this might not matter because just because the police has access to the phone doesn't mean they have access to the server

Plus you would usually combine this with e2ee

fair, that's one less reason for people to say 'xmpp sucks' :P

I always thought the use case wasn't for evading the police or the black helicopters but more for telling a friend something and not wanting a easily accessible record of it. Aka telling a friend you cheated on your wife last night, and deleting the message after to avoid accidents like your wife scrolling up your chat, your friend betraying you and showing the message, etc.

I guess it depends if you are a secret agent or a cheating husband

or both!

It doesn't really matter what the use case is, it doesn't protect against any of them.

What's this, thinking about threat models?

I like to live my life like everyone is out to get me even though no one is remotely interested >:)

actual actual reality: nobody cares about your secrets

except facebook

facebook is out to get you !!!! ... to buy stuff

or something

It's a false sense of security because of course they can take a screenshot, or have clientside logs, etc. But it's not easily visible and it's a way of indicating you told the person this in context or regretted saying it.

jjrh: again. The attacker is not the recipient

Social problem. Technical solution?

It's just a stand in for when the intended recipient is too stupid to use fde et al

Even in that case I'm not convinced that it's worth the false sense of security it gives people. Regardless of what actual threat model it's intended for, everyone thinks of it in the way jjrh is asying.

but they think of it that way in proprietary walled gardens too, when the same things apply

I said before "people clearly don't care that it's a technical impossibility even on proprietary walled gardens ¯\_(ツ)_/¯"

They dodn't even know it's a technical impossibility; it's no better or worse in a walled garden than in XMPP. It's just a problem in either place.

right

Maybe we should just view this a sa technical half-solution that's actually just a social signal.

Like locked doors.

I just always saw this as avoiding accidents, not someone actually intending to spy. You can't protect someone from taking a screenshot or if it's a appliance taking a picture of the screen

they only know xmpp sucks because PROPRIETARY_MESSENGER has this feature and xmpp does not

the question is does it matter? because people will build something like that regardless of *we* think. and my original question was just whether there is some value and having a XEP and library support for that

If you wanna codify a protocol for saying "please don't share this private message that we exchanged in confidence with anyone else" then why not

daniel: indeed; I think the answer is "no", personally, in fact I think it has negative value. Zash's locked oors analogy is pretty good, except that with a locked door it deters some minor forms of problem, but also people expect that anyone who really wants to get in can smash a window or pick the lock. Here I'm pretty sure most people assume that the locked door is actually going to protect them from all forms of home invasion.

It's a matter of user expectations, and I'm fairly convinced that user expectations are wrong here, so we shouldn't encourage it. But I don't know how to find out if that's correct or not.

people (morons) want the feature, it's as useless on xmpp as it is on any other app, they still want it

I know. Sometimes you have to protect the user from themselves, even if they complain a lot. Not always, but I think this is one of those times personally.

SamWhited: Something something XSF neutrality mumble or something ...

Maybe don't call it 'delete' call it 'hide' and flag it as 'don't archive' and the server may or may not respect that.

Zash: Yah, as nice as that sounds in theory I don't think we have the luxury of remaining neutral.

"Ask receiver to forget this afterwards"

SamWhited, well usually in that scenario you are not dealing with end users but with customers. and the customer will always get that feature from me (and/or other xmpp developers). it's not my responsibility to protect my customers users

That being said, I like where this is going. I've never seen it done, but maybe it's just a UI issue and it can be solved?

daniel: yah, fair enough, I can't blame you for not saying no to someone who's paying you for it.

There's also nothing preventing anyone from just writing stuff down and publishing it under their own namespace.

'Ask contact nicely to remove this message after they read it, may or may not happen'

> There's also nothing preventing anyone from just writing stuff down and publishing it under their own namespace. of course not. that's what I (and probably others) have been doing

isn't there a messenger who's entire feature set is just this single feature?

but creating a XEP will maybe get you library support and then make our lives easier

SnapChat?

I feel like I've seen it before but can't remember

is it? maybe

Or well, that's with pictures and stuff

That was the idea with snapchat originally, wasn't it? I don't know if that's still their main selling point.

People defeated that pretty easily, but the point was that the receiver had to make a premeditated effort to do that.

like with locks

which deterred the majority of people from you know saving pictures they shouldn't and sharing them.

probably a better analogy is a letter - someone can steam it open and read it - but that's a lot of work with many chances to change your mind. If it was a postcard it's something you might do impulsively

pretty good

it also might just get accidentally shredded in a mail sorting machine and exposed to the world too :P

It's more: make it impossible for stupid people to do, hard/tedious for malicious people.

The hard part with technology is conveying that defeating it is possible. I mean it took a while before people realized that people take screenshots of tweets and that deleting them isn't purging them from the world.

Asking remote server and remote client to kindly delete message is stupid.

What can kinda work in controlled service like Facebook can't be done in federated environment.

Kinda work - because messages can be screenshoted, or photographed by another device right from screen like this

https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f16a0abdf3f7ff84d/qAjq7PRHPlRmYRReKjx7yJRiOd5ojiPfkzzpvA9c/IMG_20180418_193744633.jpg

What are the two random strings in your upload URL?

Something that mod_upload have me, I guess

ejabberd?

Of course

MattJ, one is the username me thinks.

Aha, you're probably right indeed

It's the SHA1 of the bare JID, indeed

In the case of facebook if you use a gateway the deleted messages aren't going to work either it would also be trivial (and someone probably has already) write a browser plugin to archive everything. If this is a feature people want and folks are implementing it in a non standard way I don't see the harm in writing a spec

I can see it being handy in certain situations where you don't really care if it's deleted or archived you just don't want it to be displayed in the client.

Reading poezio logs to make the minutes for the gdpr meeting, I see lots of people put whitespace at the end of their messages :P

isn’t that the poezio logger bug that always puts a space at the end of the line?

Single whitespace or a bunch of spaces and tabs?

mathieui, no it looks different

Just a single whitespace

mobile autocomplete adding it maybe?

mathieui, now that you say it, I also see this bug

Ah, well, actually, most of it _is_ the bug.

obligatory link on why that's useless https://www.moparisthebest.com/phonehash/#80808080ccdd107488bad45a74b3c5755c4bd108

although, JID search space is certainly much larger than phone number search space so

*slightly* better than useless maybe

Dat subset space of sane usernames one can actually type and remember tho

So regarding gdpr, it seems Whois is dead

https://www.theregister.co.uk/2018/04/14/whois_icann_gdpr_europe/

Interesting the fact that you can’t make a tos that will eliminate gdpr restrictions essentially kills Whois

moparisthebest: What's useless?

Holger, sha1 hash of jid to 'hide' jid

moparisthebest: In the upload URL? The goal wasn't hiding a JID.

what's the goal?

increase the length of the URL to annoy text-mode client users.

then clearly you should be using sha512

s/to annoy .*/ to annoy Ge0rG in particular/

Zash: goal accomplished

moparisthebest: Initially my goal was backwards compat with daniel's initial upload component, and I liked how this would avoid any issues with weird characters or overlong JIDs or whatever without me having to think about it.

(But the format is somewhat configurable.)

I just went with /uuid/original filename

Zash: ^ to anny Ge0rG.

Ge0rG: Shush you, they are more compact now.

Zash: I wanted per-user quotas, and I didn't want to keep track of who uploaded what.

(That's what God created directories for!)

what about hmac(userjid) then

Holger, but you could mix a random server-side salt in there and accomplish the same thing

If I had a different goal then I could do that, yes :-)

Holger: I'm sure someone would come up with some requirement that breaks that too.

moparisthebest: the salt needs to be stored then

just on the server doing the hashing Ge0rG yes

"just"

that would let you do per-user quotas with only directories, server would know who uploaded what, and no one else could reverse the hash

moparisthebest: what if it's a cluster.

There might be multiple nodes involved.

Right.

ok, then just on each node :)

is the salt sensitive information according to GDPR?

the nodes do share some type of database or configuration right?

Holger: just store the salt as a docker secret.

moparisthebest: Sure.

the salt has nothing to do with GDPR

Ge0rG: I'm convinced!

moparisthebest: technically it's not a salt but a pepper anyway.

actually it could still be per-server, no reason they have to share it

moparisthebest: the right question to ask Holger would be how the nodes are going to synchronize quota usage.

right, that's why they don't need to share the salt, each would have to calculate total usage themselves anyway :)

There's no clustering support in the current module for the stored data (so you'd solve this outside ejabberd or use just a single node for this), but any node in the cluster may generate the upload URLs.