XSF Discussion - 2021-04-14

when confronted with a too-big stanza as a server, what would the implications be if the server just silently dropped the stanza and carried on instead of terminating the stream with an error ?

maybe this answer is different for s2s vs c2s

moparisthebest, if it can do that, it should instead bounce the stanza properly

then there are no (new) implications, beyond what you already get when servers make decisions about which stanzas to deliver

what if it can drop it, but can't parse it

unlikely, I think

to bounce a stanza, you only need the startElement SAX event

(or equivalent)

I think you already need that + endElement + magic to determine the stanza boundaries anyway

I guess dropping would be similar to s2s-closing (without stream management), so there’s not much of a difference there, except that deliverability of other stanzas will be improved (as they don’t get lost in s2s TCP buffers when the stream is killed)

I'm determining stanza boundaries by counting tags and don't have an XML parser

how are you counting tags?

(to count tags, you already need something like an XML parser ;))

enough of an XML parser to add only a shim layer to extract the attributes out of the attributes needed for bouncing anyway ✏

roughly, incrementing on < and decrementing on /> or </ so a stanza boundary is when the counter hits 0

<![CDATA[ < ]]>?

hopefully no one sends that :D seems to have worked so far

it is valid though

and: what stops you from catching the slice from the first < to the first > and parsing that as attributes? you can drop all namespace-related stuff as that’s not needed on stanzas anyway, just plain key/value

hrm maybe, so you think that'd be valid? sending an error response on too-big-stanzas and just skipping them otherwise? but not terminating the stream?

yes

<policy-violation/> would be an appropriate stanza error I think

or maybe <resource-constraint/>

https://tools.ietf.org/html/rfc6120#section-4.9.3.14

look at that, policy-violation has stanza size limit as an example

oh, that’s the stream error, sorry

antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance

but I think the stanza error is as valid

and bouncing individual stanzas with whatever errors you feel like is the right of a server; clients need to cope with that

dropping on the other hand is tricky because it may be seen as violation of the "MUST reply to IQ requests" clause of RFC 6120

> moparisthebest> antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance One of the reasons that make me believe that servers should be very conservative about the sizes of stanzas they accept. Someting in the range of 10 KiB to 64 KiB seems appropriate

I also think that with larger stanza sizes you get easily into scheduling issues, as in, a single stanza can dominate the link while it is transferred

This is turn means, that you should probably bounce too big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached ✏

good point about hogging the link

Unfortunately, I believe that the major parts of the ecosystem would break if we do that

But I really hope that we get the ecosystem towards a reasonable sized stanza limit in the future

Of course, this requires things like RSM on disco#(info|item) responses ✏

servers already do that :(

I wonder if MAM-like responses on disco might make more sense. Or additional sense.

;)

Furthermore, if we talk about techniques that split large content into multiple stanzas, then we have to be aware that it's not easy for the generating entity to assess the resulting stanza size

just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53-R59 ✏

But probably a pramgatic approach like, "aim for 10KiB stanzas, but limit at 32KiB" is good enough here

jonas’, is https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53 fixed today?

I did not check again since that commit

it's ok I'm 99% sure I found an ejabberd bug while looking at this too, are `<features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features>` and `<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>` the same or not?

prosody, dino, gajim, and conversations are ok with either, ejabberd requires the second

they are the same in XML 1.0 with Namespaces

but yeah, ejabberd is picky

odd failure mode too, it just hangs for 90 seconds and then sends `<stream:error><connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Idle connection</text></stream:error>` and hangs up

yep, probably the parser doesn’t read it as belonging to the stream namespace and then drops it

moparisthebest, but note the interop note in https://tools.ietf.org/html/rfc6120#section-4.8.5

> Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems.

ah, nice

moparisthebest, sounds like you have a new(?) project, what is it? :)

flow, reverse proxy https://github.com/moparisthebest/xmpp-proxy still super early, just started dogfooding it on my server recently :)

moparisthebest, so you are competing with dwd now? :)

Competition always welcome.

Especially as I've not had any time for Metre recently.

I think metre doesn’t do c2s, does it?

It does not, no.

Going to go out on a limb and suggest that xmpp-proxy doesn't do S2S, it's just a connection proxy, too.

https://github.com/surevine/Metre ? quite a bit different I guess

xmpp-proxy does c2s and s2s, and multiplexes both along with starttls + direct tls all on the same port(s), but also limits stanza sizes

But inbound only if I follow this right?

correct, inbound only, and provides TLS

And that StanzaFilter looks scary. :-)

How does it cope with presenting the client cert to the server?

Or is there a ‘I have verified trust, just do external’ flag being passed to the server-proper somehow?

Kev, Yeah, doesn't seem to be any support for that.

Probably more applicable to C2S where client certs are uncommon than to S2S then, I guess?

no support for client cert auth, server just trusts connections from it is encrypted implicitly (also for the PROXY header)

Although I guess it probably gets in the way of -PLUS too?

It'd break channel bindings, yes. Also I think the start-tls handling makes me cry.

yes I agree the StanzaFilter is scary haha

these are all correct reactions I think

I keep getting tempted to write one of these for M-Link, but I keep deciding it needs to be more than a naive proxy because of the interactions between TLS and auth.

(Also because I’d like to use it as a mechanism for seamless upgrades).

(personal opinion for my use-cases only incoming) interactions between TLS and auth are dead, let them lie

Funnily enough, I thought about adapting the Metre code into an Openfire C2S connection manager.

moparisthebest, I think that's not true given channel bindings especially.

do they work with TLS 1.3 yet ?

moparisthebest: You might not like channel binding, but surely you’re not opposed to S2S strong auth?

moparisthebest, Thanks to Sam, yes.

will they work with QUIC

moparisthebest, Your xmpp-proxy doesn't work with QUIC, so somewhat irrelevant, but I think they should given they're simply based on an exported key.

unfortunately if the web doesn't use them, we can't rely on them being supported anywhere

moparisthebest, Except key exports *are* used and seem well supported, so Sam's approach seems much more likely to be generally available.

and QUIC is the future so I wouldn't call it irrelevant, still a hair early though, we'll see

moparisthebest, Sure. I expect we'll have XMPP over QUIC at some point. But I don't think key exporting is affected by QUIC versus TLS/TCP, so everything should "just work".

moparisthebest, Obviously there's very much a place for xmpp-proxy as a bridge to uplift existing servers and services with QUIC etc support though.

moparisthebest, so that effectively forces use of dialback? or what?

moparisthebest, I think your StanzaFilter works for idiomatic XMPP XML, but I'm not entirely sure it'll work correctly in some edge cases. I suspect if I'm sufficiently abusive I can at least sneak a closing stream tag past it.

I’ll just say CDATA

jonas’, Oh, yeah, good point, that too.

also '< stream:stream' and a few other things, probably ok, it accomplishes it's goal

moparisthebest, And '<str:stream', and all sorts. Likely it'll work in all non-abusive cases. But yeah, I can get it to terminate the session without the XMPP server thinking its over, and I can get the XMPP server to close it without xmpp-proxy to work. And any server advertising -PLUS basically won't allow auth. Hopefully. But as I say, it'll mostly work and it's a useful tool for a number of cases.

dwd: The server needs to know there’s a TLS terminator in the way anyway, so presumably should not present any auth mechs that don’t proxy in any case.

yep I agree, it was written in a bit of a hurry for one specific use-case which it accomplishes, I'll elaborate more later, and in the meanwhile think about if it can support CDATA sanely without bringing in an XML parser :/

I would be inclined to bring in an XML parser, personally.

Well, let me rephrase that.

If I wanted this to be generally useful, I would bring in an XML parser.

Kev, Oh, I think it *is* generally useful, but possibly limited to testing out deployment strategies you'd then incorporate into server mainline code.

If it just needs to meet a use case and it meets it, *shrug*.

I only hesitate because historically XML parsers have been known to have worse bugs than "closes connection wrongly sometimes"

That is not unfair.

moparisthebest, This is true, but I can smell the faint odour of a DoS attack there somewhere.

I think yes, but only in terms of killing s2s connections ?

Killing S2S is probably less bad than *not* killing S2S

(I have no idea if such an issue can present)

moparisthebest, jxmpp has a XmlSplitter, which probably does something similar to yours. It doess not contain a full blown XML parser, but is a little bit more robust as yoursI think

I guess what I am trying to say is, that there exists probably a middle ground between having a full blown XML parser and too trivial parsing for things like that

flow, thanks, I'll have a look https://github.com/igniterealtime/jxmpp/blob/master/jxmpp-core/src/main/java/org/jxmpp/xml/splitter/XmlSplitter.java

So… it has come to my attention that profanity is essentially using 140-chars ids for every stanza

was there any rationale for not limiting the length of the id attributes? we do cap the size of JID, afair

mathieui, sadly the length restriction of JID parts is the

exeception, not the rule

we do not limit pubsub IDs either

indeed :/

but as far as I understand it, the only properties we want for identifiers is "we can fit something non-guessabled and non-bruteforceable in it, and all the better if we can write some arbitrary data for testing"

but going over 30 or 50 characters seems overkill in every case

https://modules.prosody.im/mod_client_proxy.html would like to have a word with you ;)

mathieui, yes, I think you are mixing two aspects here: the missing length restriction for many ID things in XMPP *and* the question what a sufficiently long ID is

that said, 140 chars is way to long

flow: true, but one could influence the other

not really

just because a random ID can be shorter, there may be very well use cases for long IDs which carry some semantics

arguably, this may not be likely for stanza IDs, but very true for e.g. pubsub IDs

and I am not sure if it isn't true in some case for stanza IDs

in any way, we should point the profanity guys to https://www.grc.com/haystack.htm

Every now and then, I wonder about translation to a UUID in all cases. Mostly for the database efficiency.

dwd +1

36 octets for 122(?) bits of entropy feels inefficient, plus they don't help with sort order

Yes, you need both a sequential id and a uuid in the database. But cheap to lookup a 128 bit number in an index.

Also UUIDs can be compressed on wire if octet optimization is what you aim for

something about https://github.com/ulid/spec

I mean, if we wer etalking XMPP 2.0, I'd be saying stanza ids are alwasys UUIDv4 and any duplications detected cause immediate session termination.

Of course, even a 128bit integer in string form is less than 140 characters :D

Profanity with their signed IDs?

the worst part of the profanity thing is that the id is a base64 of some form of humongous uuid in string form

so it’s like thrice the size for no entropy gain

Uuid + hmac(key, uuid) IIRC

but why

So you can detect forged responses and bounces, I imagine.

Except nobody does it.

I've looked into that source code before. But then I erased my memories with alcohol.

But it seems to me that the most interesting attacks based around forging responses would be based around witnessing an existing outbound and just copying the ID, which isn't affected by whether or not the id is signed.

Yeah.

IIRC I did a benchmark of "who does the longest message IDs" on my server, and #1 was bifrost, which stuck whole XMPP messages into the ID, for reasons nobody can anticipate, and #2 was profanity

what

time to to XMPP stanza over XMPP messages ids

*do

Years ago, a security audit on some stuff I did decided the id space was a side-channel attack. (As were arbitrary XML attributes etc).

I mean, it's fair enough, but in cases where that matters you need a protocol break anyway.

https://github.com/profanity-im/profanity/issues/1520

> Our brilliant plan to make Profanity famous among the XMPP community was a huge success. > Profanity became a constant hit for discussions in the community. Everybody was and is talking about its huge IDs. > Now that we have achieved making people aware of Profanitys existence it's time to make them love Profanity. > So let's have shorter IDs.

"If you want an answer on the Internet, post the wrong answer first."

the community manager of Profanity Inc. is a genius

i propose that the XSF hire him

#1520 \o/ We will be seen by movim :-)

Certainly the best issue I’ve read today.

Another one for XMPP2

Hi guys

👋️

Profanity actually used UUIDs before. We later added an identifier (instance id + barejid) and hashed that together with an uuid and take a base64 from it. The reason for this was that we didn't have any database and we used this to filter messages in MUCs.

that sounds like insanity

And yeah I just used a UUID instead of a shorter value to hash together because I was lazy and the XEP didn't forbid it :)

The XEP‽

I mean no rfc or XEP said anything (to my knowledge) about the length of an ID

Maybe every RFC and XEP should have the text "Use your common sense." somewhere.

jubalh, I am curious though, apart from the hack with the hmac, what is the base64 for?

mathieui: because base-16 is not sufficiently inefficient

so it needs to be wrapped

Zash: it was not about common sense. It was about having few time and solving an issue quickly ;)

mathieui: I don't remember right now. Maybe it had to do with using barejid or something and the allowed values? Not sure anymore.

I'll read the code in the next days and change that. We also have a DB now so we could actually check in there if we send the message ourselves.

And the part about making Profanity famous is half-true too :) Because I knew (and more people brought it to my attention) pretty long value and devs will notice ;)

I noticed.

Hahaha

Other people noticed too.

I love you too Ge0rG :)

Ge0rG, you did not complain hard enough!

I even spent ~half an hour trying to understand what devil has ridden you for doing it this way

> Zash: it was not about common sense. It was about having few time and solving an issue quickly ;) amen brother

mathieui: I did, but probably in the wrong place

But having the messages not display in movim because the DB field for the ID is too short was certainly more fun

Don't trust remote IDs?

Isn't having a limit length for IDs in the DB even more wrong? :) There is no max length defined AFAIK

a way to send messages that only display in certain clients you say mathieui ? nice attack

jubalh, edhelas trusted "common sense", and having an index on a TEXT column is meh

also relevant here: https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html#:~:text=The%20index%20key%20prefix%20length,REDUNDANT%20or%20COMPACT%20row%20format.

i never trust common sense. I have seen all kinds of IDs so our DB doesnt limit it for example. There are some clients that start from 1 and increase their IDs upon each message. If you restart they start from 1 again. I think Pidgin did something funny too (at one point)

jubalh, is it still the case though? (for the increasing onces) I though every client switched to some kind of uuid

jubalh: yeah, that was funny.

mathieui: BWAHAHAHA

sorry.

let me dream Ge0rG

you evil man

Why did I even click a link to MySQL docs‽

mathieui: I'm not sure. I just remember seeing it. And I think Profanity was using the increasing IDs too. And one of my first contributions was to switch it to UUIDs if I remember correctly.

there was a "nice" bug in bifröst, where its xmpp backend de-duplicated stanzas based on their ID, and presence stanzas that didn't have an ID got into the same deduplication slot and were dropped

smack will use $random_prfix-$autoincrement

ids do have a max length, BTW.

Kev, ~10MB?

Kev: where is it defined? In XML?

Kev: which is? And where is it written?

Because a stanza is allowed to have a max length of anything down to 10k, it means an id can’t be longer than that, less the rest of the stanza ;)

you see guys. So Profanity is all good. Maybe we should stay as is then :)

I’d say you had a bit more room to play with, even.

I'll think of something

(unique stream-id + counter), Ge0rG? Like the thing we keep mentioning as The Best Thing? 🙂

Kev: there is no upper limit on the upper limit for stanza sizes, so technically it's unbounded.

hmac(base64(stanza))?

Zash: not quite.

jubalh, tbh if you get the binary uuid & hash and encode it in ascii85 (instead of picking the ascii repr and growing it with base64) you would fit easily into most lower limits without losing information :p

Almost

Zash: https://github.com/igniterealtime/Smack/blob/48f5e349b9a318ba2a1d82aef9fa069e62da10bb/smack-core/src/main/java/org/jivesoftware/smack/packet/id/StandardStanzaIdSource.java#L30

Ge0rG, so, per process?

Zash: yes

Perhaps the there can/should be an XEP that provides some sort of best practice for ID generation? There's been a number of advances over UUID algorithms that avoid clashes while retaining sortability.

deuill, are you volunteering? 😉

Twitter Snowflake IDs were, I think, the first of their kind, but others have emerged since.

deuill: yes, and that XEP should be RFC6120'

I looked at those. Also LUID and various variants of concat(timestamp, random)

ITYM ULID

[IDLU]{4} 🤷️

IIII

Actually, maybe that's a good way for me to contribute. What I can't tell is why the original RFC says stanzas SHOULD have a unique ID assigned (not MUST?). I need to re-read those passages.

For fire-and-forget, who cares what the ID is

I think some of these algorithms assume Infinite computational power as well, or at least cycles to spare.

Conversations apparently tries to de-dup based on ID (even empty IDs)? People's definition of fire-and-forget may vary lol

Here's a start: ``` xeps$ pandoc -t ./tools/2xep.lua >inbox/best-id.xml <<. > % Best practices for stanza IDs > > Use UUIDv4. > . ```

Co-Authored-By: Alex P

Thanks Zash

jonas’: I didn't make a github PR for the CVE formatting back then, but I'd still love to move forward with it.

jonas’: with your Editor hat on, what do you suggest me to do next?

Ge0rG, remove the background color, make a PR?

jonas’: but I like the background color!

Does anyone know offhand where it says that 128 bit IDs should be enough until the end of time, for use as reference?

(UUID is less because version numbers and stuff tho)

Ge0rG, I don’t, it makes for a lack of contrast. And if even *I* find the contrast lacking, any a11y tool will throw it in your face.

Zash, we use 128 bit strength for cryptography, suggesting that you cannot reasonably brute-force a 128 bit thing

jonas’, cargo cult?

(Tangentially related but this was an interesting comparison of GUID algorithms, albeit all implemented in Go: https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html)

Zash, https://crypto.stackexchange.com/a/48669/16902

jonas’: you only disliked the contrast to the links, right? Can I make the links red-colored in the cve box to satisfy you?

Ge0rG, no

also the text<->background was lacking IMO

but I may be misremembering

you could refresh my memory with a screenshot

jonas’: https://op-co.de/tmp/xep-template.html#example-1

so red-on-red would definitely make this worse

and yeah, weave is contrast-error marking all of that

ok, the black-on-red not, but green-on-red it doesn’t like

jonas’: I've reduced contrast of the red, can you shift+reload

maybe you still have my old version cached

Ge0rG, same

jonas’, IIRC even counting to 2⁶⁴ is boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope. ✏

Zash, https://en.wikipedia.org/wiki/Birthday_attack#Mathematics ✏

jonas’: maybe it's because the default text color is #444

Oh look, it has a table

Ge0rG, it’s complaining about the coloured text, not about the grayscale text

jonas’: another shift-reload?

I don’t see the link as link anymore

looks black to me

(but weave is happy about the contrast… which is pointless though)

welcome to the world of making an accessible thing.

jonas’: is your monitor calibrated?

do I need a calibrated monitor to read XEPs?

jonas’: you need a calibrated monitor to complain about lack of contrast ;)

no, I don’t

jonas’: I *really* want that reddish background, because without it just looks naked

sorry for your loss

I won’t accept a reddish background just because you prefer it if it renders XEPs less readable for people with visual deficiencies or under bad lighting conditions or whatever

I took great care during the XEP redesign to avoid such pitfalls, I’m not going to let you ruin that ;P

said the person who uses #444 instead of black for text.

jonas’: shift-reload again for the naked box.

> said the person who uses #444 instead of black for text. That's better than #666

Ge0rG, LGTM

Le Sigh.

now how do I add a huge red warning sign there?

but I knew that already, I tested your design with background-color disabled and was immediately happy

so we can't both be happy, right?

yes

well, I can be happy if that box has a huge red ⚠️ in the left, but I don't know how to make it

Ge0rG, you need to do something with <img/> or background-image

Why should we be making these things prominent anyway?

to get a warning sign without disturbing a11y tools

Security considerations aren’t, for example.

Yah, this seems like something to be aware of but not something that you absolutely definitely must see at all costs (as opposed to security considerations which are that)

These are just non-normative examples of what can go wrong.

and examples of where the security considerations have been ignored, so placing them really prominently is something I’d deem useful

What jonas’ said

Prominent placement is fine, but it's not important to specifically draw the users attention to them over other things like the security considerations

let's add a red background to the security considerations then!

and make them blinking /s

jonas’: at least it won't complain about contrast then!

`<blink><marquee>🚨️ ⚠️ ACHTUNG!</blink></marquee>`

so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.

This is not a hill for me to die on, but I don’t understand why we would say the most important thing about a XEP is a section saying someone once got it wrong.

+1 ^

do you have other proposals to improve the situation that people clearly ignore security considerations?

Accept that it’s not the spec author’s responsibility, nor is it within their ability, to make implementors read the spec?

write shorter specs.

also: write specs that are harder to implement in insecure ways.

Focus on writing clear specs that are easy to get right.

Kev, that’s not an improvement to the situation, only to your (our) perception of it

What Ge0rG said.

but we can’t fix e.g. carbons and such

XMPP 2.0!

I don't think this will do what you think you're doing either though. This is just a distraction that may or may not actually have anything to do with the security considerations and may or may not actually contain anything of value that's likely to be repeated.

It's a nice thing to have, it just doesn't seem like the thing we want to drag users eyes to (and possibly away from other important normative things like security considerations)

Everyone only reads the examples and not the normative text, let's not also make them only read the CVEs and not the security considerations.

Sam, but they’re *already* not reading the security considerations.

So don't make it worse.

It's a separate problem is what I'm saying

I don't have full context here, and don't have time to review the entire conversation, but if this is about relevant CVEs being highlighted in XEPs, that's definitely a thing we should do

Add CVEs, that's a good idea I think. If you want to make people read the security considerations, highlight that, not the new non-normative may or may not exist or be relevant examples.

MattJ: it's about the format of that: https://op-co.de/tmp/xep-0280.html#security

I have no strong feelings about how this should be formatted, FWIW, I just want to suggest that adding more and more stuff isn't doing what you think it's doing.

On first impressions the one Ge0rG just linked looks great to me and is enough extra formatting.

Especially without context.

Ok, if it's just about bikeshed formatting, I definitely have other things to do... :)

Oh no, but I can't help it... FWIW I would group all the CVEs into a single box with "The following security vulnabilities have previously been found in some implementations of this specification:"

MattJ: that can be achieved by different XSLT, I'm sure.

MattJ: This isn’t all CVEs though, Jonas’ said it’s only those that were widely applicable.

"worth highlighting" for whatever definition of that

I didn't say "all", did I?

Oh, and exploited widely, in fact.

You didn’t, but just saying “here are some CVEs” implies it’s somewhat more exhaustive than CVEs that have been widely exploited.

Then insert "notable" somewhere, or something. Or don't :)

Anyway, if we’re only talking about vulnerabilities that were widely exploited (which has been precisely 0 vulneralibilities that I can remember), my concerns about them being overemphasised are probably overblown.

Kev, sorry, I didn’t mean to say "exploited"

but widely exploitable with simple-enough PoCs

but I am also fine with less strict constraints

listing related CVEs is probably fine, but not like https://op-co.de/tmp/xep-0280.html#security please

the text of the security considerations is more improtant than the related CVEs. but the currently proposed visualization puts the focus on the CVEs

flow, see above for my rationale for that

jonas’, not sure if I looked at the right rationale, at least I fail to see how this counters my argument

> so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.

that is what I read. But I don't interpret this as something that argues in favor of making the CVEs visually more prominent than the security considerations

if anything, be sparse with visual effects

-ENOTIME

It feels like Ge0rG had the changelog of a software in mind when he designed this

What flow says. I don't have strong feelings about the current formatting, but we definitely shouldn't do much more than this (stop signs and big red backgrounds and whatever was being discussed before). And even as is now I still think it will be just like examples where users automatically read the shiny things and ignore the text assuming the examples (or CVEs) cover all the things they need to know.

Sam: if the people read the CVE, that's a huge win already.

I kind of doubt it in most cases, especially if it comes at the cost of ignoring the text, but maybe.

Sam: as jonas’ said before, the text is already being ignored

I am not sure if adding big red boxes under the text being ignored helps with that

Ge0rG: right, and this won't fix it and could make it worse.

And now the only thing they maybe look at is some random examples that may or may not actually be a good representation of the actual problems and weren't actually a part of the XEP process.

If anything, a short, potentially visually featured, sentence at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO ✏

well, if they read the CVE text, the chances are higher that they'll come to the same conclusion that's implied in the security considerations

I doubt it. I'd bet most of them end up with one or two things that are mostly unrelated, or only cover one tiny part of the security considerations.

Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then

If that's actually the problem you're trying to solve, flow's alternative seems better.

A/B tests \o/

(FWIW if we had a way to actually A/B test this that would be great, but I don't think we do)

let's bikeshed A/B testing infrastructure then!

> Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then Do we have evidence that the clients effected by the CVE ever read the xeps?

how would the know how to enable carbons if not?

The developers of those clients

Daniel: are you saying that you can implement a XEP without reading it?

jonas’: gajim XML console

Daniel, please no

Looking at other implementations

please no.

I’m going to get dinner now

reading the xeps don't even matter, what clients/servers send/accept in practice is what matters :D

because I can’t take that

I'm fairly convinced that this is how a lot of those clients were developed

ahh, the thought of XMPP devs not even looking briefly at XEPs when implementing them

enough xsf@ for today

I *know* there have been implementations of features done by looking at sent/received protocol, and not the XEPs.

That’s not even hypothetical :)

That's how I implemented <session/>

aren't there plenty of things that are well known not to even be implementable looking at XEPs ? just "shared knowledge" stuff ?

Didn't know what it was. Just knew that sending this magic made things work

I'd be willing to be that between what Daniel said, looking at the XEP but only at the examples, and copy/paste from Stack Overflow you'd cover over 99% of all XMPP development. I don't think I'm joking when I say that I'd put money on this.

if a client dev implemented OMEMO from the XEP today they'd probably be pretty sad when they couldn't interop with a single other client ?

*bet

And I'd bet that the other <1% are 99% people in this room :)

there is a massive difference between what client/servers *should* accept/handle and what they actually *will* accept/handle in practice, you can't get that from looking at XEPs

moparisthebest: that's actually also a statement about the horrible state of the OMEMO XEP

same situation with RFCs, and everything in web-land too

computers: they bad

Sam, knowing ex-coworkers who have worked on XMPP for a client website project, that probably sums up 99% of all private-sector XMPP development for people not familiar with standards, yes

"I just loaded xmpp.js, why doesn’t it work!"

when I implemented XEP-0368 in Conversations I didn't know the XSF or XEPs existed

mathieui: indeed, I was specifically thinking of a colleague at HipChat who asked me a question about the protocol and I wasn't sure off the top of my head so I said "Here, pull up RFC 6120" and their response was "wait, you actually read these things?"

Although as far as libraries go, "I just loaded <library>, it should work" seems reasonable.

my reasoning was roughly: email clients are fine doing direct-tls instead of starttls without any formal specification, why not XMPP

I mean, assuming they actually called it somehow, you know what I mea.n

Sam, well, except you need to at least know some part of the semantics and how they relate with what you want to do

I think there’s multiple things here. * People understanding how they should learn what to do * People being willing to do stuff properly * People being competent to do stuff properly * Doing stuff properly being possible to do * Doing stuff properly being easy to do

And probably others.

Most certainly others, yes.

mathieui: yah, I feel like that's a library design problem though. For most people I suspect they want to call conn = xmpp.Connect("domain.com"); conn.SendMessage("Hi") or something. I really want to eventually get my own stuff to that point

Do we need to stick "The Official XMPP $Language SDK" sticker on some libraries?

I think it’s unduly naive to think we can have much influence over some of those, and showing that people aren’t getting it Right doesn’t, in itself, mean that if we just shout at them louder it’ll get better.

What Kev said.

OTOH, some of them (particularly the last two, but also the first) are entirely within our remit.

Sam, well, if I remember correctly it was something like they did not expose bosh or websocket in their ejabberd container

Fair; ops is hard no matter what.

and don't get me wrong XEPs are super valuable and we should cram all the relevant info needed in them, if only for a place to point to other than "look what client X does" which sucks

still, many times you have to dig into what X does, and assume many/most people use this instead of XEPs on how to learn it

TLS had the same problem with people hardcoding version numbers right?

"it works for the current input" not realizing it'd break on 1.3, 1.3 ended up working around it entirely

https://mastodon.xyz/@nextcloud/106058947562901204 :)