Code Monkey home page Code Monkey logo

Comments (6)

mar-v-in avatar mar-v-in commented on June 12, 2024

The error message you see is not an error message. It is the fallback message sent by the other client (probably Conversations in this case, but could also be a fork) that is displayed in case the message is not targeting the recipient device.
OMEMO is a forward-secure, device-to-device message encryption system. As such, if you have a new device, it will not be a recipient of any previous messages (as it was not a known device before it is first used). This is why you see the fallback displayed instead.
If you think the fallback is confusing or could be more helpful, you need to report this to the sending client, not the receiving client.

from dino.

CouldBeThis avatar CouldBeThis commented on June 12, 2024

hmmm thanks for taking the time to explain to me; this protocol is quite the learning curve.

Do I understand correctly? You are saying that this specific wording comes from some outside source? Not this project.

If correct, how do I determine where it comes from?

I did a general web search for the message and found issues in several xmpp client repos. They seem to be largely opened by confused people like myself. Or are related to general implementation of OMEMO. I was unable to glean any useful information from them.

from dino.

licaon-kter avatar licaon-kter commented on June 12, 2024

The message will come with an encrypted part, if your client can't decrypt it (for some reason) the message also has a clear text part that your client can show to you. And that tries to explain to you a bit about the issue.

Eg. You joined an encrypted group or an 1:1 chat with a client that can't do OMEMO.

Now, if you use Dino, hope you are up to date and everything :), but Dino supports encryption, so it signals that your chat partner didn't encrypt with your key for some reason.

from dino.

hrxi avatar hrxi commented on June 12, 2024

The error message you see is not an error message. It is the fallback message sent by the other client (probably Conversations in this case, but could also be a fork) that is displayed in case the message is not targeting the recipient device.
OMEMO is a forward-secure, device-to-device message encryption system. As such, if you have a new device, it will not be a recipient of any previous messages (as it was not a known device before it is first used). This is why you see the fallback displayed instead.
If you think the fallback is confusing or could be more helpful, you need to report this to the sending client, not the receiving client.

Since Dino can recognize that this is an OMEMO message that it cannot decrypt, maybe it should render something other than the fallback text? E.g. "this message is encrypted, but not to this device".

from dino.

licaon-kter avatar licaon-kter commented on June 12, 2024

Conversations has Message was not encrypted for this device.

from dino.

mar-v-in avatar mar-v-in commented on June 12, 2024

The fallback body is generated here: https://codeberg.org/iNPUTmice/Conversations/src/branch/master/src/main/java/eu/siacs/conversations/generator/MessageGenerator.java#L27
If you have ideas for improving the text, feel free to open an issue at https://codeberg.org/iNPUTmice/Conversations/issues

Since Dino can recognize that this is an OMEMO message that it cannot decrypt, maybe it should render something other than the fallback text?

While technically possible, it would be non-compliant behavior

from XEP-0384 (v0.3.0) § 4.7

When an OMEMO element is received, the client MUST check whether there is a element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded.

Although I'm not aware of such a deployment in practice, one might want to use OMEMO only for optional authenticity validation and not for encryption. In such a case, the <body> of the message would contain the original plain text of the message and discarding it would be counterproductive.

There are also valid reasons to send OMEMO messages to only a subset of recipient devices (e.g. to finish a session setup). Those messages would not have a <body> and thus currently wouldn't be displayed in Dino.

As the messages from Conversations also have a XEP-0380 tag, we could support that as an indicator for incoming messages to actually be encrypted and thus to not display the <body> as sent from the remote entity, but instead show a more helpful error messages.

from dino.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.