debaclethere seems to be a long queue now at the design booth, most of them seem to be XMPP developers
debaclecan someone fix the year in https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ please?
jonas’will take 5 to 10 minutes to appear on the website
MattJjonas’: er, but now the URL is broken
MattJAnd it was linked to from various places
TobiasWhy does the web need to be so complicated
jonas’MattJ, I don’t know of a way to fix that
jonas’but I’ll see what I can do
MattJnginx redirect I guess
jonas’I reverted the URL to the old version, but kept the title in tact
jonas’that should minimize the impact for now
Seve/SouLAppreciated jonas’ :)
KevTalking about compression, as we were, I wonder what would happen if we were to (per-hop) introduce a <c /> stream element, whose job would be to hold attributes for a dictionary that you could later inject into stanza headers.
mathieuidebacle, but 2018 works with the correct title
mathieuiit will probably require a small nginx trick to have 2019 and 2018 work at the same time
jonas’debacle, where did you get that link?
TobiasZash: it's probably less training, rather seeing how good it works
debaclejonas' from https://xmpp.org/blog.html
jonas’I hate this hacked pelican
debaclewhat is the difference to the non-hacked one?
jonas’a non-hacked one wouldn’t be so awful to use
jonas’and I can’t really test locally because we need an awfully old version due to hacks we do
jjrhIs there a fosdem xmpp channel?
ZashTobias: Building the dictionary needs data
jonas’use base64 of randomness as a start
KevRandom data are known to compress very well.
jonas’Kev, base64 of random data
jonas’compresses fairly well, actually, approximately 3/4 ratio
ZashExtract the xep examples
KevIt's not giving any value to know how an xmpp-specific compression mechanism would compress non-xmpp data, is it?
jonas’that will probably make 'romeo' and 'juliet' compress to one bit or something ;)
jonas’Kev, given that OMEMO, Avatars and other things are b64-encoded, I think it’s pretty XMPP-related actually.
KevYou need real streams for it to be of any significant value, I think.
ZashWe don't want JIDs and user entered data to compress well, that's what leaks the worst
jonas’start with base64 of random data, add in some xmpp keywords, see what happens
MattJjjrh: this room is generally the FOSDEM XMPP channel
TobiasWell. If you use zlib or zstandard with dict, common XMPP terms will compress everywhere
ZashCa zlib do a fixed dictionary? Don't think I've seen support for that
jonas’> zdict is a predefined compression dictionary. This is a sequence of bytes (such as a bytes object) containing subsequences that are expected to occur frequently in the data that is to be compressed. Those subsequences that are expected to be most common should come at the end of the dictionary.
jonas’(argument description in python zlib library)
jonas’you’d still have to reset the dictionary after each stanza
TobiasZash, Kev, if you want some secure compression for XML it has to be XML aware, so it only compresses outer levels of stanzas
ZashFixed compression dictionary avoids most of the compression related attacks AFAIK
TobiasWith that would still compress dictionary terms in the bodys and inner stanzas, not?
ZashI'm not sure if proper XML aware compression would be better enough to be worth the complexity
ZashEg EXI needs schemas right?
jonas’Zash, EXI works better with schemas, but it doesn’t reqiure them
ZashOr something that points out what's data and what's structure
TobiasYou can do something more stupid than EXI
KevI have no doubt I could manage more stupid than most things.
TobiasLike only ompress at level 1 and leave the body levels alone
jonas’compressing the body with a fixed dictionary isn’t a problem, I think
TobiasIf you compress strict you might leak in band SVG
debaclejonas' Now the link works. It looks strange, that the URL says "2018". But whatever. This is XMPP. We are pragmatic.
jonas’debacle, as the link with 2018 was out in the wild already when we spotted the mistake, we had to roll with that
debacleyou could have a forward from 2018 to 2019
debacleyou can have a forward from 2018 to 2019
debacleonly ten lines in Apache (or a half in Nginx)
debacleonly ten lines in Apache (or a half in Nginx)
jonas’debacle, yes, if I had +w to the nginx config, I could do that
vanitasvitaeInteresting, the Matrix guys also had issues with message ids. They solved their problems by using the hash of a message as the id.
debaclejonas' I know that problem. I partly responsible for a Prosody server where I cannot write.
jonas’vanitasvitae, I bet they had a lot of fun with that
debacleIf I send ten times "yes" to different questions...
ZashOh glob. Shall we tell them about c14n?
jonas’(and we’d be totally lost because to hash XML you need to canonicalize it, which is a non-trivial operation)
Zash"You don't need C14N with JSON!!!!" ?
vanitasvitaedebacle: not sure what'd happen then
KevI think possibly that stanzas are mutable is more of an issue there than normalisation.
debacleare both id and content encrypted? if only the content is enrypted, the id leaks the content.
jonas’Kev, yes, that too
debacleare both id and content encrypted? if only the content is encrypted, the id leaks the content.
vanitasvitaeMaybe they added some random seed?
jonas’if you add a nonce, you can also simply use a random ID.
jonas’although, arguably, the hash makes it harder to deliberately create a collision that way