on macOS I'm using BeagleIM but I'm developer of BeagleIM so I may be biased
Steve Killehas left
goffihas left
Kev
I use Swift, obviously ;)
Kev
Although I'm using 5.0previews rather than 4.0.
Steve Killehas joined
lovetoxhas joined
jonas’has left
jonas’has joined
lskdjfhas joined
Guus
I'm starting to see the flaw in my approach.
goffihas joined
krauqhas left
Sevehas left
Sevehas joined
Mikaelahas left
Mikaelahas joined
Dele Olajidehas joined
lovetoxhas left
neshtaxmpphas joined
mathieui
Guus, :D
emushas left
emushas joined
karoshihas left
mukt2has left
!XSF_Martinhas left
!XSF_Martinhas joined
Mikaelahas left
mukt2has joined
Shellhas joined
lovetoxhas joined
karoshihas joined
mukt2has left
debaclehas left
Dele Olajidehas left
mukt2has joined
Dele Olajidehas joined
Dele Olajidehas left
alameyohas left
neshtaxmpphas left
LNJhas left
werdanhas left
LNJhas joined
calvinhas joined
karoshihas left
karoshihas joined
lovetoxhas left
lovetoxhas joined
Tobiashas left
Tobiashas joined
krauqhas joined
neshtaxmpphas joined
Zash
Why doesn't xep-0084 use "current" or something as item id for the metadata node?
Shellhas left
Shellhas joined
krauqhas left
Mikaelahas joined
govanifyhas left
govanifyhas joined
neshtaxmpphas left
karoshihas left
alameyohas joined
krauqhas joined
Yagiza
Zash, I guess authors just forgot about it.
Yagiza
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?
Andrzej
Zash: I think that section 7.1. will answer that https://xmpp.org/extensions/xep-0084.html#impl-resources
alameyohas left
Zash
Ugh
alameyohas joined
Kev
Yagiza: PRs
Yagiza
Kev, IC, thanx.
Mikaelahas left
Yagiza
Kev, once I publish a PR for a deffered XEP, should I change its status back to experimental in that PR?
Half-Shothas left
Half-Shothas joined
Kev
Maybe submit the PR without it, and ask what the Editors would like you to do.
Kev
I don't know if jonas’ normally asks authors to do that bump, or not.
govanifyhas left
govanifyhas joined
Yagiza
Kev, so, I have to ask him first?
Kev
I would. But if you don't do what he wants, he'll let you know anyway :)
jonas’
Yagiza, feel free to change back to Experimental in the same commit you add the <revision/> lbock
Kev
There we go :)
jonas’
if you don’t add a <revision/> block but want the Editors to do that, then please also don’t change the status
Yagiza
jonas’, ok, thanx!
karoshihas joined
neshtaxmpphas joined
krauqhas left
Mikaelahas joined
Dele Olajidehas joined
Shellhas left
Shellhas joined
karoshihas left
andrey.ghas left
karoshihas joined
calvinhas left
Shellhas left
Shellhas joined
Dele Olajidehas left
wurstsalathas left
neshtaxmpphas left
wurstsalathas joined
lovetoxhas left
jnaeffhas joined
jnaeffhas left
emushas left
jnaeffhas joined
emushas joined
Shellhas left
calvinhas joined
Mikaelahas left
emushas left
emushas joined
Yagiza
I wonder...
Mikaelahas joined
Yagiza
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?
Zash
🔒️💔️🤷♀️️
pep.
OMEMO < 0.4?
werdanhas joined
Yagiza
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.
What do you do if you receive LMC and fail to encrypt body?✎
Yagiza
pep., right now I'm working on OMEMO v5.0, but I'm asking in general.
pep.
What do you do if you receive LMC and fail to decrypt body? ✏
Zash
What do you do if something fails for any reason?
Yagiza
pep., LMC is not supported right now.
Yagiza
Zash, it depends.
pep.
Replace "LMC" with anything that you support that's not stuffed in <body/>
andyhas left
vanitasvitae
Yagiza: I'd argue that with OMEMO:1 the <attention> would probably also be part of the <encrypted> element, no?
Yagiza
vanitasvitae, I don't think so. <attention/> element contains no sensitive information to encrypt it.
vanitasvitae
But I admit that such error cases are not yet well covered.
vanitasvitae
Mostly due to lack of experience.
vanitasvitae
Well, having it plain leaks that there is an attention in the first place
pep.
this ^
Yagiza
So, let's suppose we use some type of old encryption, which do not support SCE.
andyhas joined
vanitasvitae
Yeah in that case there is no way to not leak the exiatence of the <attention>
pep.
There is a way, just don't send it :P
vanitasvitae
Haha :D
Yagiza
Encrypting <attention/> element or not is up to implementation right now, 'cause it is not regulated by any XEP.
vanitasvitae
Yeah, sce should be more precise in that
Yagiza
So, let's get back to the initial question: what to do, if only <body/> was encrypted and we failed to decrypt it?
pep.
In poezio I'm filtering out everything that doesn't go in <body/> when doing OMEMO, because of this limitation
vanitasvitae
I'd say simply encrypt anything that doesnt need to be read by the server.
vanitasvitae
(As a rule of thumb)
vanitasvitae
> 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 :(
vanitasvitae
Probably discard the attention?
pep.
Yagiza, tell both to your user? "Somebody is requiring your attention but we don't know what for"
vanitasvitae
Or that
pep.
I don't know what poezio does. "Attention" is not something I see everyday :x
Zash
print \a ?
pep.
Zash, in the case it can't decrypt body?
Zash
Dunno?
Yagiza
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.
Zash
Show what you know? "Couldn't decrypt message. Extra stuff: attention"
pep.
Yagiza, it's critical to annoy the user more? :P
Yagiza
pep., it's critical to annoy user with suspicious attempt to attract his attention, or not.
karoshihas left
j.rhas left
j.rhas joined
Andrzejhas left
waqashas joined
govanifyhas left
govanifyhas joined
neshtaxmpphas joined
karoshihas joined
mukt2has left
dwd
Anyone know where the slixmpp devs hang out? Poezio MUC perhaps?
pep.
Poezio MUC works, you might have more people there, but otherwise it's xmpp:slixmpp@muc.poez.io?join
neshtaxmpphas left
pep.
or jdev
Danielhas left
Danielhas joined
adiaholic_has left
adiaholic_has joined
Bezihas left
Bezihas joined
karoshihas left
karoshihas joined
neshtaxmpphas joined
mukt2has joined
Andrzejhas joined
adiaholic_has left
alexishas left
alexishas joined
karoshihas left
karoshihas joined
werdanhas left
Wojtekhas joined
Bluehas left
Bluehas joined
neshtaxmpphas left
andyhas left
karoshihas left
karoshihas joined
mukt2has left
mukt2has joined
eevvoorhas joined
andyhas joined
adiaholic_has joined
adiaholic_has left
adiaholic_has joined
lovetoxhas joined
stpeterhas joined
lovetox
Yagiza, simple, you display the omemo fallback message like you always do when you cant decrypt it
eevvoorhas left
lovetox
and then additionally run the attention code, whatever that is
lovetox
i dont know why you are spending much more thought on that
lovetox
and of course with omemo:1 it should be encrypted
lovetox
you should not get into the fallacy to decide yourself what stuff seems important to *you* and needs to be encrypted
Yagiza
lovetox, well... when I run Attention code, do I have to display "Failed to decrypt" fallback message, or just no message at all?
lovetox
full stanza encryption means, encrypt the full stanza, except stuff that is added for partys that cannot decrypt (like the server)
lovetox, "fallback body" and "fallback message" are different things.
lovetox
how are they different?
lovetox
inside the fallback body is the fallback message
lovetox
except you mean something different
Steve Killehas left
lovetox
but the question really is, why would you want to treat this non-decryptable message differently because it has an attention attached
lovetox
do whatever you do when a message fails to decrypt without attention
Nekithas left
Steve Killehas joined
Yagiza
"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.
krauqhas joined
xeckshas left
jonas’
lovetox, though, maybe <attention/> is important for the server? thinking push & stuff
pep.
Maybe there should be a systematic study of all new XEPs wrt. SCE. That is, should they be in or out :x
krauqhas left
pep.
But what about the 400 previous XEPs..
Zash
Didn't we start an E2EE WG?
pep.
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
Zash
When I looked at MAM, Carbons and CSI code recently, I started with the ones in the latest compliance suite.
Zash
+ >= Draft maybe
adiaholic_has left
xeckshas joined
adiaholic_has joined
moparisthebest
> "Decryption failure fallback message" - is a message, which client, which supports encryption displays, when it failed do decrypt encrypted content.
moparisthebest
the SENDING client gets to decide this????
Zash
Planning for failure eh?
moparisthebest
my knee-jerk reaction is that is wrong and maybe exploitable, but I'll have to think about it harder
pep.
I don't understand the sentence enough to react this way :x
lovetox
Yagiza, but for your question its irrelevant if fallback body, or your custom failure message
lovetox
moparisthebest, i think you misunderstanding something
moparisthebest
very likely, the only context I have is that right there
lovetox
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
lovetox
yes thats possible
lovetox
but 1. the message would show as unencrypted
Yagiza
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).
lovetox
2. only clients that dont support encryption at all, should use the fallback body
lovetox
let me rephrase this
lovetox
2. only client that are legacy and not updated anymore use the fallback body
lovetox
every maintained client should depend on the <eme> attribute, and display his own failure messages, not depending on the fallback body
Yagiza
moparisthebest, why sending? Sending client cannot know if receiving client will successfully decrypt message content or something will go wrong.
lovetox
but yeah thats definitly an attack vector against clients that simply always display fallback body without an additional hint
lovetox
of course Yagiza, the sending client can always know when you cant decrypt the messge
lovetox
because the sending client can simply encrypt it wrong
lovetox
and for a server its even more simple
lovetox
just cut some bytes of the encrypted payload
lovetox
and i can make sure you cannot decrypt it anymore
alexishas left
lovetox
then i add my own body
lovetox
you should never trust the fallback body
krauqhas joined
Yagiza
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.
lovetox
fallback body is for legacy clients
lovetox
pidgin and stuff
lovetox
i just thought about what i said
lovetox
this is no attack vector at all
lovetox
the server can send the client messages all day
lovetox
manipulating an encrypted message into non-decryptable is only more work
Wojtekhas left
adiaholic_has left
adiaholic_has joined
Bezihas left
Bezihas joined
moparisthebest
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?