XSF Discussion - 2019-10-08

I nominate dwd to be our new department of sarcastic(?) marketing. ✏

at least he doesn’t repost the same joke 5 times in a span of a week. scnr :-)

Daniel: that was mean(ingful)!

Does anyone have a link documenting the numerous vulns clients had relating to xhtml-im ?

I was hoping for a mailing list post or wiki page...

There was Waqas's presentation about a decade back. (Maybe more recent than that, I forget).

Also, can someone explain to me how Matrix and Mastodon and pretty much everything else gets away with sending actual HTML in JSON but we can't send a sane subset of HTML in XML?

Single implementation probably helps.

Because it's better to mix input and wire format, and users do it anyway

Implementation details should not block standards

Bring back XHTML-IM!

Bring back XHTML-IM!

Ropen skalla, XHTML-IM åt alla!

Bring back XHTML-IM!

Bring back GC1.0!

U wut m8?

Bring back XHTML-IM!

how about we put this on the next all-member meeting agenda?

yes, all-member meetings are a thing ;)

jonas’, or just council

pep., I can predict the answer

wait for next council?

it has to do with XEP-0001 not having a transition from state_of(xep_number("XHTML-IM")) -> {Experimental,Draft,Final}

Yeah I was wondering about that

so it’d defer to Board

since Board owns XEP-0001

That's a more generic question then

Not just 0071

then Board may or may not define such a state transition and defer back to Council

pep., although somebody floated the idea of re-defining XHTML-IM from scratch anyways

which I support, actually

I could get along with that I guess

with more clearly-defined use-case profiles

and without @style

Yes.

If someone can show that HTML within messages has a solution, I'm all for it. But last time we were here, it seemed that every implementation had suffered serious security problems.

Should we call it xhtml-im2

This time it's for real

FWIW, if there were some solution that meant we should shift around PWAs in messages that'd be awesome.

dwd: modern web applications can be made secure with a global switch instead of having to sanitize every individual string, AFAICT

dwd, I’ve been back and forth on this, and I think some standards simply require a basic level of intelligence, and if you cannot read Security Considerations, you maybe should not implement standards. or anything.

dwd, my observation is that any alternative will be equally terrible.

dwd, PWA?

jonas’, A single-page web app.

jonas’, I mean, if we could safely ship aorund CSS and Javascript, that'd be amazingly amaing.

Not Progressive Web App?

dwd, would it be?

dwd, I think that sounds terrible ;)

I thought those are SPAs

but I hate the current web, so...

jonas’, Sure. Apps in messages, what's not to like?

dwd, everything?

dwd, I hate everything about that

waqas created a sanitizer for xhtml-im, it works... what else is there to debate?

MattJ, does it sanitize @style?

`tag.attr.style = nil`

MattJ: is it written in JavaScript that can be bundled within an XHTML-IM message?

A Message Web App that sanitizes itself?

Zash, It'd sanitize the messages it sent to other people. I detect a flaw here.

jonas’, it does

dwd: you encountered sarcasm.

Can't we just define a flag that clients need to send if their xhtml-im payload is malicious?

Lighter than including a full sanitizer with every message

that ^

Oh wait, XEP-0076

woo, we already have all the tools

MattJ: but it's using an insecure xmlns :(

MattJ, Needs to be updated in line with XEP-0419.

Nice, solutions right away

Ge0rG, btw, you should push for 419 to go draft, there's already an implementation!!

pep.: which one?

poezio's rot13 and b64 plugins

pep.: but 419 is for XEPs, not for .py's

:(

pep., Is it doing whole stanza encryption (example 1)?

dwd, no but it should indeed

dwd: I still think full-stanza-encryption would've been much funnier with rot13.

pep., Sorry, not Example 1, Example 2. I ask because most implementations seem to be mistakenly doing Example 3.

right

Ge0rG, Really? I rather enjoyed the deadpan comparison between the examples.

dwd: must be an instance of British Humour, then

I note that XEP-0419 is the latest e2e encryption method in XMPP, too.

latest and greatest.

I wonder if people will appreciate if I announce that yaxim has had it from day 0.

now that I think of it, yaxim implements it for ten years already.

I just didn't have the feature namespace.

Seve: so can we just have a xep that says "execute this binary code as x86 instructions, but just the safe parts" ? If implementation details shouldn't block standards that is >:)

moparisthebest, I think the cool guys use webassembly for this nowadays

moparisthebest, I just think we should go as fast as the smartest in class, not the dumbest. ✏

Sure, we can all use one client and server and not even bother writing standards

That is easiest and fastest

moparisthebest, that’s not the same thing

and you’re being needlessly hyperbolic

is it possible to add a line break inside a <td> in XEPs?

jonas’: I've got https://github.com/xsf/xeps/pull/841 but I'm most probably not ready yet and I would like to have one history/revision block for all that's different from CS-2019

Ge0rG: That description seems a bit redundant, don't you think?

Zash: I didn't want to leave it empty

Seve, jonas’ , yea sorry, mainly just pointing out that while I agree in principle that xeps shouldn't depend on implementations, if in practice 100% of implementations have security problems, that's probably a root issue that needs to be solved/defined/something by the xep

other people have worded that way better in the past so just ignore me :)

better specs help.

I think it's possible to have a "secure" spec that, in practice, is impossible to implement securely, which I'd then argue is a bad spec

moparisthebest: which XHTML-IM is a prime example of

Is it impossible?

I think waqas proved the opposite.

Isn't it just that it's too convenient to do the wrong thing

and once you drop @style, I’d say it’s very trivially possible to implement securely

what Zash says

Which 393 for example doesn't help with

are you going to write your own HTML/CSS engine, or fork chrome/firefox's and try to disable javascript but still keep up on other security issues, or ?

"Oh this looks like Markdown, I'll just take this markdown library and forgot to disable HTML pass trough"

yes, in theory those things are possible, in practice, no one is going to do them

No one is going to do what?

moparisthebest, bugs in the rendering engine are not in scope for XMPP software, unless XMPP software writes their own engine.

why would you fork a rendering engine for this?

why would you write your own?

both don’t make sense

Just bundle an old version of Electron with your chat app

both Qt and Gtk support a subset of HTML in any widget (which surprisingly is a superset of what XHTML-IM), so they’re covered. If you’re using a web browser (natievly or via widget) to render/execute your app, you have a rendering engine right there.

you just need to do the fing sanitisation, which is fing trivial if we omit @style for a second

jonas’, and @on*

just have a whitelist of elements, and everything which isn’t that is replaced by its children.

Zash, those are forbidden anyways

in XHTML-IM

whitelist elements and attributes (@style excluded)

s/elements/elements and attributes/

yes

it’s not hard in any way

it’s written in the security considerations (more clearly than it was back then, admittedly)

if you can’t read security considerations, maybe you shouldn’t be implement standards

if you can’t comprehend the security considerations of a specific standard, get help and get the standard clarified

Ge0rG, any reason you make that a PR?

Ge0rG, mark it WIP in the title at least

jonas’, you don't happen to have a nice short rationale for why @style needs to gtfo?

Zash, requires an extra parser

aside from that, allows stuff which probably only works on your machine

(colors and things)

jonas’, that's the theory, in practice, a developer reads a much simpler spec like 393, writes a few regexes, gives up and just passes it to a markdown processor

(this just happend earlier today, hence my question)

moparisthebest, oh, so exactly the thing happened everyone said it would?

It also almost happened in Converse.js

yes and also we brought up all this as soon as he suggested the markdown processor, so it hasn't *actually* happened yet, but it would have

moparisthebest, can’t blame them, XEP-0393 doesn’t mention that as a problem

I was trying to find links about why this was a terrible idea

so how about we all just implement 394?

jonas’: I made it a PR because I wanted to discuss the content changes in Council tomorrow

Ge0rG, you can do that in your own fork instead

larma, I’d like to burn XEP-0394

jonas’: good point

jonas’, why? IMO it's superior to 393, it just has the flaw that it doesn't work well with legacy fallbacks (because you can't hide any chars that are only for fallback)

larma, but it’s not superior to XEP-0071

(or a slightly saner redefinition of XEP-0071)

Well, it only has a subset of the features, but also is less likely to be accidentally use a HTML rendering engine

I’m pretty sure it’s also harder to implement, and will be fun especially in memory-unsafe languages with all that string slicing involved.

If I'd want to do it right, as a client developer I would probably convert all 3 versions into some data structure that is approximately 394

Then I can convert that into any format required for my rendering engine

except that you’d normally mix the text with that data structure

not like '394 does

so if I'm understanding this correctly, there is a scale of difficulty-to-implement vs security-of-implementation, ranging from so hard to implement no one will bother, making it secure, all the way to so easy to implement wrongly everyone implements it but it's totally insecure

something like that

jonas’, do you? HTML does, but other might not. It's actually a bad idea because it creates the requirement of escaping the actual text to ensure it's not considered markup

larma, only if your data structure is a string

394 makes you write your own parser and rendering engine, no one does it, xhtml-im is easiest to implement by just slapping it into a DOM, everyone does it, is insecure

which I’d consider a terrible idea to start with :)

moparisthebest, nobody forces you to write a rendering engine for '394

moparisthebest, you can convert '394 to Qt text styles, to Gtk whatevers, and to HTML

that’s not the issue ✏

but you have to write your own parser, and perhaps harder, "reverse parser"

it’s just a painful thing to do

yeah

how do you get from input format to 394

moparisthebest, if you’re using Qt or Gtk, you can probably more or less directly convert the respective datastructures to '394

(the QTextDocument stuff for example)

from HTML, it’s a bit trickier, but also possible.

- 71 is not directly compatible with many non-complex renderers. Input needs to be sanitized before being used in complex renderers. - 393 is not directly compatible with any markdown parser known to me, even though some might choose to use a incompatible markdown parser to implement it. If a markdown parser is used to generate HTML, same issue as with 71 might come up. - 394 can be sanitized rather easily (check there is no overlap) and then can be used securely and without tons of efforts in most environment including HTML renderers

I think implementing 394 securely in a browser might actually be easier than implementing 71 securely in a browser, where browsers should be *the* example of allowing easy implementation of 71...

larma, '71 is directly compatible with GTK and Qt, without the need for sanitisation (if you ignore @style).

or do you consider those "complex"?

otherwise, which other non-complex renderers are there?

jonas’, it's not. Pango makup used by GTK only supports very few tags and actually uses CSS-like style for most stuff

https://developer.gnome.org/pygtk/stable/pango-markup-language.html

Not sure about Qt

ugh, it’s still at <i/>

It also doesn't do blockquote or body or img or any of the enumerations (it doesn't support such at all, as it's a text markup only thing). The "correct" way to use it is <span>s

pity

not great for accessibility either

how is it related to accessibility?

larma, <em/> for example to mark up emphasis

enumerations and stuff, blockquotes

all that’s relevant to screenreaders

I don't think GTK wants you to provide screenreader annotations through display/styling markup

how else does it work with Gtk then?

seems odd to me to have that redundant

Well Pango is a text rendering engine, it does only that single job of using font data and input text to generate an image. You also use it when drawing text on images, so it makes little sense to have accessibility markup at that point

yeah, I was talking about Gtk for a reason and am looking at GtkTextBuffer instead

(and GtkTextView)

using plain pango to render text is bound to be a PITA

BTGNT

Dino uses GtkLabel which only supports pango markup for all message rendering 😉

that won’t be enough for stuff like blockquote anyways

I’m also not sure how you’d mark up a GtkLabel itself for screenreaders to understand what’s going on

I think you do all this stuff with ATK, but haven't tried yet

Also doing screen readers right for IM is probably not easy and won't work out of the box no matter which toolkit...

very true

nice to see there are 0 open source XMPP mac apps but a ton of matrix/telegram/other ones :'( https://github.com/serhii-londar/open-source-mac-os-apps#chat

Most of these are electron apps no?

Does padé not work there?

no idea, was just pointing out that someone seeing this list doesn't even see xmpp listed at all

I know Monal for instance should be there, probably gajim ? what about dino? surely there are a TON of open source XMPP apps that run on MacOS

Go PR! :)

Is there a list of list page on the wiki or sth?

That needs to be updated every so often

probably most of the command line clients work on mac too right?

I'll friggin put in a PR adding 50 XMPP clients that run on mac if I can find them :D

https://github.com/xsf/xmpp.org/blob/master/data/clients.json

"Awesome" here means "List of stuff" these days?

Monal is probably the only one that qualifies as a Mac app

yea it's a thing now, no idea where it started

Adium?

It's been a thing for quite a while

It's not maintained anymore is it

pep.: ten years ago, like everything in xmpp

right

maybe it's just because we aren't on these awesome lists

Yet another hierarchical oooooooooosomething

moparisthebest, basically ^C^V https://xmpp.org/software/clients.html ?

| grep macos

I think I was able to install psi or psi+

curl https://raw.githubusercontent.com/xsf/xmpp.org/master/data/clients.json | jq '.[] | select(.platforms | index("macOS")) | "[" + .name + "]" + "(" + .url + ")"' | sort -u | tr -d '"'

got to learn some jq today, I'll put in the PR later... gotta figure out what language they are each written in manually, guess that's important for mac users somehow?

Myeah, I'm not sure what's up with that.

Maybe it's aimed at developers?

good news is we have 24 different macOS clients though

moparisthebest, I hope you don't want to try and add all of those clients to that "awsome" repo, though. Abandoned clients probably don't shed a good light on XMPP. Maybe pick the most reasonable 2/3 instead.

Maybe pick the only one that's a Mac app.

How's the Tigase one, Beagle?

lskdjf: why not? It has telegram clients marked abandoned too

moparisthebest, I already gave my reasoning: because bothering people with bad clients sheds a bad light on xmpp. Something is not good just because telegram people do it.

I don't have a Mac and no way to pick the best couple

then maybe you are either not the best person to do the PR or need more information first 🤷️

Well no one else seems interested in doing it

Besides that list is like "all open source Mac software" not just good ones

moparisthebest: Make an "Awesome XMPP clients" list and get it into the Awesome hierarchical directory that's totally not like early Yahoo! at all.

There was some XMPP stuff under "ChatOps" but I didn't look further

I was thinking about making an awesome awesome list of all the awesome lists

That exists already

too late, that already exists https://github.com/sindresorhus/awesome

Damnit, just like all my good ideas

We're not listed in Decentralized!!1 Mastodon is!

pep., no the awsome list about mastodon is :p we first need an "awsome xmpp" list 🙂

pep.: There are only 3 XMPP services¹ ¹ according to https://the-federation.info/ ✏

Yeah.. I know that one..

Wanna help with my WIP mod_nodeinfo2.lua?

I want to help with lots of things. Now how do I prioritize all that

"Awesome TODO"

:D

“15:38:27 flow> Link Mauve, +1, is the list public somewhere? Maybe even in the wiki?”, only on a WIP branch from years ago, which will need a namespace bump: https://github.com/linkmauve/xeps/tree/xep-0234