XSF Discussion - 2017-10-20

When are we going to get out of the loop :(

pep.: *Never* muhuhahaha

When are we going to get out of the loop :(

Just deprecate XML, it's insecure

along with Javascript and SQL

that would be great

And x86

And neurons

Link Mauve, my issue with colors is that they are not portable at all. your choice of colors may be badly readable on my background

since people tend to forget that I had to block inbound colors on my desktop client.

I’m not against a color support, but we need to define a way (Ge0rG suggested to support a palette of XEP-0392 colors which applications can then adapt according to XEP-0392 to their backgrounds) which allows to play nice with themes.

jonasw: just set a background color as well

daniel, yes, that makes things *so* much better :P

Xhtml is perfect. People are just using it wrong

It's the people. Not the protocol

Link Mauve, re JSON based protocol-break: I think it can be done in a way which makes arbitrary XHTML injection much harder to let happen than with XHTML-Im.

jonasw: so you think it's worth redoing everything just because the new format will possess less issues? Not everyone agrees with it, that's why this discussion is not going to stop

zinid, *shrug*. I’d still be okay with the "provide an audited reference implementation for XHTML-IM solution", but I feel that won’t get past SamWhited. I’m trying to compromise here without losing what we can do today.

if SamWhited doesn't pass it that would mean nothing will ever happen

and we're back to the beginning

Wow, that discussion.

It seems to be so fundamental, maybe we should question the use of XML as well...

Ge0rG, you love to pour oil into fires, don’t you?

jonasw: okay, that was a bit harsh. Let's only question session binding and message routing.

Ge0rG, that sounds good.

didn’t we do that already?

jonasw: or maybe we need a different approach to the 'database synchronization" thought: XMPP 2.0 is an HTML document that's slowly loading from the server as new messages arrive.

That way we can implement dumb clients in Electron.

Ge0rG, you’re describing Comet

jonasw: Pouring oil? More like feeding it an optimally mixed solution of pure oxygen and aerosolized oil

Because the server is trustworthy by default, there is no need to cover XSS

Zash, :)

Yes, trust in the server. We're all trustworthy people making them.

Well, problem solved. Back to real work.

Ge0rG: or course we can question the use of XML, because it's shit

now we need to rewrite everything?

Yeah, starting over from scratch is so much fun!

Why dont we use http and json already

Wait, there is a ready-made solution already. Matrix!

Ge0rG, I think we came to the same conclusion

pep.: because jabber was initially designed with flaws: there is no separation between encoding rules and data types, so we cannot simply change encoding rules

I'm talking about it since 2004

zinid: that was sarcastic

If it wasn't obvious enough :)

pep.: right, but that would be possible if xmpp wasn't designed the way it was

Sure, but who would do that :x

matrix has exactly the same problem btw, when json is no longer modern and fancy it will be abandoned

Obviously

So we need to use an established standard that won't vanish. ASN.1!

YES

AaaaaaaaAAAAAaaaaaAAAaaaaaaaa

I always get attacks of pain when I read ASN.1, and I don’t even know why.

So recently I started reading that old "Easy introduction into the subset of ASN.1 relevant for [application]", and I gave up after twenty pages.

lol

jonasw: Spend some time with it. It should turn into a mild itch eventually.

I hope you all read x509guide.txt

ASN.1 is wonderful. MUCH easier to write specs in than XML and compact on the wire

Steve Kille: Which encoding rules? ;)

Steve Kille: the learning curve is too high, that's why they are crying :)

Steve Kille, reminds me, I (with my editor hat on) would like to fix some XML issues in the MIX XEP at some point. Let me know when that’d work for you so that we don’t produce conflicts.

Zash: why encoding rules would boher an application programmer? You don't need to deal with them directly

jonasw: now would be an excellent time for you to do this. I do not have MIX XEP checked out.

Steve Kille, mhm, right, now won’t work for me though :-). I’ll ask you again when I’m ready (I expected a reply along the lines of "I have some update prepared which I’ll push at some point")

jonasw: you could ask for a time window as well ;)

There are various changes I want to make, but they all need discussion with my co-author

Ge0rG, indeed; I’m away for a week now though

so this was probably not the smartest time for me to ask :)

jonasw: you could ask something like "is it okay if I do it in a week" :P

Ge0rG, in two weeks rather

I have one editorial task, which you are welcome to take on (but I can also do easily) which is to ensure that ALL of the examples use .example (following IETF guidelines)

I got editorial changes forced for:

https://datatracker.ietf.org/doc/draft-kille-ldap-xmpp-schema/

jonasw: ping me on MIX editing. I am not expecting to make changes over the next few weeks

Steve Kille, okay thanks

(What is a white page service?)

pep.: a public phone book?

Ohh

That

I think there is one very important twist missing from the current XHTML-IM vs. markdown vs. body-hints debate: We also need an explicit encoding for Emoji in ASCII form. Some clients will parse `(c)` as a mug of coffee, others as ©. We should standardize how Emoji are to be transmitted and translated.

As unicode. Job done.

Ge0rG, A good point to raise, and also Kev's right.

I suggest <no-emoticons xmlns='...'/> as a child element of the message.

in Unicode � trust

So that recipients know that the sending client doesn't use text emoticons, only unicode emoji.

Kev: in theory, you are right. In practice, it is impossible for a client implementation to figure out which subset of Unicode is supported by its platform.

That's ok, in a sense. Clients can e.g. swap out unicode emoji for images locally.

Kev: we could of course define entity caps for a client to show which subset it supports.

I think (much as I hate it) that that's what Swift's going to have to do on Linux, at least, and probably Windows.

I'm also a proponent of emoji hugification in IM. Because you can't read them at 8x16 pixels.

TIL about emoji CLDR short names: "The CLDR short name for the character or sequence. Short names vary by language, and are from the CLDR data."

😄 = :glimlaggende_gesig_met_oop_mond_en_glimlaggende_oë:

Or "Bob", to his friends.

(I really like the Slack notation used for Emoji, where you use `:short_name:`)

until you start to use things like jabber:x:data namespace in your message

aaand we’re back to the plain text markup story

personnaly, I think that this discussion is pointless

edhelas, note though that emoji names are (a) always surrounded by whitespace and (b) not to be used in transport, only in display when no emoji capability is there by the rendering engine

Ge0rG: That's great, but that's a client-side thing, no reason for us not to then transmit as unicode.

Are we going in circles or some kind of 5-dimentional figure 8?

jonasw, What? No, :stuff: is a client-side thing, surely?

if we have XHTML-IM security issues, we open tickets in the bugtrackers of the buggy clients, and that's it, end of story

dwd, I sure hope so! ✏

Actually, Kev is right. Unicode should be the default transport format for Emoji. However, it would be great to have input conversion from ":)" to "😀" etc.

I agree wholeheartedly with that.

:)

it’s also lovely how this discussion messes with poezio

Client UX/UI issue?

remember the Carbons security issue ? did we removed Carbons ? no

Kev: that also means that clients without Emoji support need to keep a mapping table of all Emoji symbols to some other representation, like ASCII

edhelas, one could argue that the vulnerability produced by XSS in XHTML-IM-Web-Clients is worse

Ge0rG: ugly, but sadly true.

(up to stealing your password)

we just added a small paragraph, released a security message, fixed all the buggy clients, and that was it

I'm actually tempted to write a XEP, given otherwise I'm busy setting up an AD this morning.

Kev, oh the pain.

jonasw define "worse"

Kev: or we use client caps to indicate emoji support, and then the server can automagically translate unicode into :ascii: in outgoing messages!

setting up LDAP is fun already, I don’t want to know how AD is like

Kev, You need some solid displacement activity.

edhelas, stealing your password is arguably worse than being able to impersonate peers.

Kev: write an XEP for what?

<no-emoticons xmlns='...'/>

it's the responsibility of clients and servers devloppers to sanitize properly their I/O

edhelas, yes, but do we need to make it hard for them?

Kev: how would you handle ":)" with such an XEP marker?

Ge0rG: By rendering ":)"

it's not "hard" to sanitize, most of those clients didn't even had any kind of security layer

Kev: but that's not what people expect.

Ge0rG, on the UI input or when received over the network?

edhelas, source?

jonasw: in both situations, because backward compatibility!11!

I personally find @style hard to sanitize. You can’t do that with regexes alone.

Ge0rG: It's the sending client saying to the recipient "I have already done emoji conversion locally, so if there's something that looks like an ASCII emoticon in here, just render it as-is, because it's what the sender intended".

(I’m pretty sure that the subset of CSS allowed by @style is not regular)

jonasw if you code a client and simply do .innerHTML = message.body, well you should serously go take some Web dev courses again

Kev: that makes sense to me.

edhelas, and what if I don’t, but @style contains a background-image with a URL which makes the browser execute javascript?

it’s a thing.

seriously you want to reinvent your own markup ?

edhelas, actually, I’m replaying the arguments of others here.

looks like some JS hipster project

my primary goal in this situation is to retain the capability for well-defined rich markup. If that’s by inventing our own rich markup or by providing a solid reference sanitizer for XHTML-IM, I don’t care.

edhelas, Most (decent) frameworks make that hard, but possible. The problem is that none of them make santizing HTML easy. The correct colution for embedding unknown-origin HTML is to enclose it in an iframe, but the problem there si that UX takes a hit.

dwd: is copy&paste of message histories the only UX problem with iframes?

Ge0rG, scrolling, sizing the iframe, …

(but copy&paste is the worst, I think)

and also iframes make me furious, I have to be able to select all the text!

scrolling. ewwww.

(I don’t think that you can tell an iframe to behave like a <div/> regarding layout, so that’s a whole can of worms there)

(but maybe it’s possible I haven’t checked)

personnally I just find XHTML-IM not great for users in general

edhelas, why?

and as I said, you'll have the exact same problem when users will use Atom in Pubsub

for atom in pubsub, using an iframe is probably more realitsic

I have to deeply sanitize Atom content to ensure that I don't have JS/CSS/iframe injections in it

Ge0rG, and I’m not sure you can access the dom of an iframe from the outside

no, hell no

just sanitize things, you have nice libs for that

edhelas, where are those nice libs, and why doesn’t the XHTML-IM XEP mention them?

https://github.com/ezyang/htmlpurifier for PHP

for JS that is

because we’re talking about actual web clients

things running in HTML+JS

https://github.com/movim/movim/blob/e30f6f59cdb10ab697629a455d7cbfb8ff316773/src/Movim/Daemon/Api.php#L101

jonasw https://code.google.com/archive/p/google-caja/wikis/JsHtmlSanitizer.wiki ?

There was an error obtaining wiki data: {"data":{"text":null},"status":-1,"config":{"method":"GET","transformRequest":[null],"jsonpCallbackParam":"callback","url":"https://www.googleapis.com/storage/v1/b/google-code-archive/o/v2%2Fcode.google.com%2Fgoogle-caja%2Fwiki%2FJsHtmlSanitizer.wiki?alt=media","headers":{"Accept":"application/json, text/plain, */*"}},"statusText":""}

edhelas, did you just google that or is that a library with a good security track record?

just googling around

yeah, that’s not how this will work

Wow. a11n for Emoji is a black art on its own: http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-general.html#SynthesizingNames

but as I said, more than XHTML, I prefer to strip more of the tags and style, because I don't want my client discussion UI to look ugly

Ge0rG, a11y for unicode is a black art on its own

edhelas, we agree on burning @style with fire, right?

I just agree to stop trying to fix a problem by bringing another one

we have XHTML-IM, just bring good practice and fix those clients

convince council :-)

deep inside I’m still thinking that XHTML-IM can be "fixed" to the extent that developers are well-aware that it is tricky to get right and they’re also given the tools to do it right.

web developers don't give a shit. They wouldn't be web developers otherwise.

that’s a bit harsh

Ge0rG, I don't think that's true. I'm on a call with one now.

Ge0rG thanks, much appreciated <3

Ge0rG, I think there are web developers out there who actually want to make a good thing and who actually care. It’s not the majority though.

(from what I feel when using web applications)

edhelas: sorry. That was not intended to insult you. You are doing great work, actually.

Oh my. They even distinguish AE and BE in the CLDR annotations: "😋" = "face savoring food" = "face savouring food"

excellent

"🥖" = "baguette bread" = "French stick" = "baguette" in English, depending on your locale.

en_GB everywhere!

An i18n a11y nightmare in five Emojis!

(not that you could conclusively count the number of Emojis in a given UTF8 string)

lovely

why can’t we have nice things :(

jonasw: because 🤦🏿🤖💩🤰

what

I wonder if "🤰♂" will be translated into "Arnold Schwarzenegger"

I might have persuaded our FE dev to wade in on the XHTML issue.

dwd, in which way "wade in"?

jonasw, State his opinion. Given that he's a web/js developer first and foremost, it might be a useful perspective.

mhm

edhelas also a web dev ;)

damn, you unveiled me

cue dramatic fanfare

my evil plan of deploying broken XHTML-IM everywhere is falling appart

world domination through XMPP XSS

zinid, It is possible there is more than just one web dev indeed.

dwd: so we need moar opinions? we don't get enough yet? :)

zinid, We don't need opinions, so much as a consensus.

“10:17:01 jonasw> I personally find @style hard to sanitize. You can’t do that with regexes alone.”, indeed, you first have to split on “;” and then to split each value on “:” and then to pick only the elements you want to support from the left part. I would assume there is no language in which this is any difficult, though.

background-image is explicitly not allowed by XHTML-IM, you wouldn’t allow it.

Link Mauve: couldn't you still inject function calls into the right part?

Ge0rG, none of the allowed properties support any URI or function call, I checked that the other day.

Link Mauve: does that guarantee that browsers won't execute function calls / URIs when encountered there?

I’ve found that browsers take security issue seriously, if the specification doesn’t allow such things and a bug is found in a browser, I’d expect it to be fixed very quickly.

XHTML-IM it is, then!

https://www.zash.se/xep-0071-4177863-security.html

Zash: it looks like the only item on the https://xmpp.org/extensions/xep-0038.html#sect-idm139548995353376 list that can't be mapped to Unicode is :jabber:. What an irony.

💡 doesn't quite cut it, does it?

Throw in some zwj stuff and call it a day

💡 + Variant Selector 16.

So I've written a poezio plugin that replaces all incoming Emojis with their respective :alias:. And now I see how ugly it looks and that I still need to look on my phone to see if it was an Emoji originally.

but markup in <body> is bad, someone said

Unicode isn't markup

moparisthebest: yes, and what I wrote underscores that point

Ge0rG‎: I still need to look on my phone to see if it was an Emoji originally

my question is, why do you care

@nickname is markup, right?

Yeah.

yep that's bad too, need a fancy UI and protocol established for highlighting someone

moparisthebest, mentions already got a XEP.

Did it?

Link please!

moparisthebest: I don't know why I care, but it turned out I do

I don’t think it was this one I was thinking about: https://xmpp.org/extensions/inbox/jid-mention.html

Maybe references?

Heh, Link

Yes? :p

Ge0rG, sounds like a personal problem vs a protocol problem :)

*snort* I didn't mean to do that.

I'd forgotten about this one, thanks

Can {xep attention} be directed at a MUC participant?

Zash: XEP-0224: Attention (Standards Track, Draft, 2008-11-13) See: https://xmpp.org/extensions/xep-0224.html

jid-mention looks like a great way to spam more, that looks like about all it's useful for

Zash, sadly no.

Link Mauve: jid-mention has been vetoed in favor of reference

Ok.

Just got kicked from mucs on this server when I joined in another client. No idea why.

SamWhited, a lot of people just left with “Kicked: remote server not found: Server-to-server connection failed: DNS resolution failed” as their status.

The same second as yours.

ah, maybe my joining from another client was a red herring

In terms of "marking up" a mention, XEP-0372 is the best thinking we have currently.

References seems nice, but I wish the bit that reads "TODO: define character appropriately" were expanded. I don't think it could be implemented as-is in an interoperable manner without that bit being expanded.