XSF Discussion - 2020-06-01

what's the better client on Mac these days?

on macOS I'm using BeagleIM but I'm developer of BeagleIM so I may be biased

I use Swift, obviously ;)

Although I'm using 5.0previews rather than 4.0.

I'm starting to see the flaw in my approach.

Guus, :D

Why doesn't xep-0084 use "current" or something as item id for the metadata node?

Zash, I guess authors just forgot about it.

If I adopted a XEP and now is an author of, may I commit my changes directly to XEP repo, or I must do it via PRs?

Zash: I think that section 7.1. will answer that https://xmpp.org/extensions/xep-0084.html#impl-resources

Ugh

Yagiza: PRs

Kev, IC, thanx.

Kev, once I publish a PR for a deffered XEP, should I change its status back to experimental in that PR?

Maybe submit the PR without it, and ask what the Editors would like you to do.

I don't know if jonas’ normally asks authors to do that bump, or not.

Kev, so, I have to ask him first?

I would. But if you don't do what he wants, he'll let you know anyway :)

Yagiza, feel free to change back to Experimental in the same commit you add the <revision/> lbock

There we go :)

if you don’t add a <revision/> block but want the Editors to do that, then please also don’t change the status

jonas’, ok, thanx!

I wonder...

If I receive a <message/> with <attention/> element and it with an encrypted <body/> element, which I failed to decrypt, what client shoftware should display?

🔒️💔️🤷‍♀️️

OMEMO < 0.4?

Should it display Attention, notifying user, that it had message text, which it failed to decrypt, or just notify user about it failed failed to decrypt message, without trying to attract his attention?

pep., right now I'm working on OMEMO v5.0, but I'm asking in general.

What do you do if you receive LMC and fail to decrypt body? ✏

What do you do if something fails for any reason?

pep., LMC is not supported right now.

Zash, it depends.

Replace "LMC" with anything that you support that's not stuffed in <body/>

Yagiza: I'd argue that with OMEMO:1 the <attention> would probably also be part of the <encrypted> element, no?

vanitasvitae, I don't think so. <attention/> element contains no sensitive information to encrypt it.

But I admit that such error cases are not yet well covered.

Mostly due to lack of experience.

Well, having it plain leaks that there is an attention in the first place

this ^

So, let's suppose we use some type of old encryption, which do not support SCE.

Yeah in that case there is no way to not leak the exiatence of the <attention>

There is a way, just don't send it :P

Haha :D

Encrypting <attention/> element or not is up to implementation right now, 'cause it is not regulated by any XEP.

Yeah, sce should be more precise in that

So, let's get back to the initial question: what to do, if only <body/> was encrypted and we failed to decrypt it?

In poezio I'm filtering out everything that doesn't go in <body/> when doing OMEMO, because of this limitation

I'd say simply encrypt anything that doesnt need to be read by the server.

(As a rule of thumb)

> So, let's get back to the initial question: what to do, if only <body/> was encrypted and we failed to decrypt it? I'd say there is no ideal way to recover :(

Probably discard the attention?

Yagiza, tell both to your user? "Somebody is requiring your attention but we don't know what for"

Or that

I don't know what poezio does. "Attention" is not something I see everyday :x

print \a ?

Zash, in the case it can't decrypt body?

Dunno?

pep., eyeCU is a GUI cliant, so it does a lot of annoying things to attract user's attention. That's why it's critical what to do in such case.

Show what you know? "Couldn't decrypt message. Extra stuff: attention"

Yagiza, it's critical to annoy the user more? :P

pep., it's critical to annoy user with suspicious attempt to attract his attention, or not.

Anyone know where the slixmpp devs hang out? Poezio MUC perhaps?

Poezio MUC works, you might have more people there, but otherwise it's xmpp:slixmpp@muc.poez.io?join

or jdev

Yagiza, simple, you display the omemo fallback message like you always do when you cant decrypt it

and then additionally run the attention code, whatever that is

i dont know why you are spending much more thought on that

and of course with omemo:1 it should be encrypted

you should not get into the fallacy to decide yourself what stuff seems important to *you* and needs to be encrypted

lovetox, well... when I run Attention code, do I have to display "Failed to decrypt" fallback message, or just no message at all?

full stanza encryption means, encrypt the full stanza, except stuff that is added for partys that cannot decrypt (like the server)

Yagiza, i remember you argued the other day

to have a fallback body

and now you think about not displaying it?! ✏

lovetox, "fallback body" and "fallback message" are different things.

how are they different?

inside the fallback body is the fallback message

except you mean something different

but the question really is, why would you want to treat this non-decryptable message differently because it has an attention attached

do whatever you do when a message fails to decrypt without attention

"fallback body" is a <body/> element of stanza with <encrypted/> element, to be shown by clients, which know nothing about encryption. "Decryption failure fallback message" - is a message, which client, which supports encryption displays, when it failed do decrypt encrypted content.

lovetox, though, maybe <attention/> is important for the server? thinking push & stuff

Maybe there should be a systematic study of all new XEPs wrt. SCE. That is, should they be in or out :x

But what about the 400 previous XEPs..

Didn't we start an E2EE WG?

I don't think going through all previous XEPs is doable anyway. I think general definitions like vanitasvitae or lovetox gave here are good, with maybe a few explicit exceptions / examples

When I looked at MAM, Carbons and CSI code recently, I started with the ones in the latest compliance suite.

+ >= Draft maybe

> "Decryption failure fallback message" - is a message, which client, which supports encryption displays, when it failed do decrypt encrypted content.

the SENDING client gets to decide this????

Planning for failure eh?

my knee-jerk reaction is that is wrong and maybe exploitable, but I'll have to think about it harder

I don't understand the sentence enough to react this way :x

Yagiza, but for your question its irrelevant if fallback body, or your custom failure message

moparisthebest, i think you misunderstanding something

very likely, the only context I have is that right there

if you mean the server could manipulate the encrypted content so its not decryptable anymore, then exchange the fallback body with a message of his choice

yes thats possible

but 1. the message would show as unencrypted

lovetox, for me that's important. In this case I have to display decryption failure message. And I want to know, if I have to display it as Attention message, or should I display Attention with no message, and display decryption failure message as a separate message (not Attention).

2. only clients that dont support encryption at all, should use the fallback body

let me rephrase this

2. only client that are legacy and not updated anymore use the fallback body

every maintained client should depend on the <eme> attribute, and display his own failure messages, not depending on the fallback body

moparisthebest, why sending? Sending client cannot know if receiving client will successfully decrypt message content or something will go wrong.

but yeah thats definitly an attack vector against clients that simply always display fallback body without an additional hint

of course Yagiza, the sending client can always know when you cant decrypt the messge

because the sending client can simply encrypt it wrong

and for a server its even more simple

just cut some bytes of the encrypted payload

and i can make sure you cannot decrypt it anymore

then i add my own body

you should never trust the fallback body

lovetox, yes. So, sending client MUST NOT decide, which message will be displayed in case of failure. Only receiving client should display correct message to notify user about an error.

fallback body is for legacy clients

pidgin and stuff

i just thought about what i said

this is no attack vector at all

the server can send the client messages all day

manipulating an encrypted message into non-decryptable is only more work

But why add another payload to worry about, if a client capable of decryption can't decrypt something, it should display it's own message in it's own language, not something the sending client said, no?

we do that moparisthebest

we add a message for legacy clients

that dont know anything about encryption

https://medium.com/tenable-techblog/turning-signal-app-into-a-coarse-tracking-device-643eb4298447