Smack v4.4.0-alpha3 (20200404): Does OmemoMessage#buildMessage() support encryption of XHTML extension?

[cmeng]

In the latest release of Smack v4.4.0-alpha3 (20200404), I see that the OmemoMessage method

public Message asMessage(Jid recipient)

has been changed to i.e.

public Message buildMessage(MessageBuilder messageBuilder, Jid recipient)

Is there a reason to expose messageBuilder parameter?
Does the new method buildMessage() support also the encryption of XHTML extension?
e.g. using messageBuilder.addExtension(xhtmlExtension)?

aTalk supports XHTML standards, currently it uses the below steps to encrypt the xhtml extension i.e.

    public void sendInstantMessage(Contact to, IMessage message, OmemoManager omemoManager)
    {
        Jid jid = to.getJid();
        String msgContent = message.getContent();

        try {
            OmemoMessage.Sent encryptedMessage = omemoManager.encrypt(jid.asBareJid(), msgContent);

            MessageBuilder messageBuilder = StanzaBuilder.buildMessage();
            Message sendMessage = encryptedMessage.buildMessage(messageBuilder, jid);

            if (IMessage.ENCODE_HTML == message.getMimeType()) {
                String xhtmlBody = encryptedMessage.getElement().toXML().toString();
                XHTMLText htmlBody = new XHTMLText("", "us").append(xhtmlBody).appendCloseBodyTag();

                // OMEMO body message content will strip off any html tags info
                msgContent = Html.fromHtml(msgContent).toString();
                encryptedMessage = omemoManager.encrypt(jid.asBareJid(), msgContent);
                sendMessage = encryptedMessage.buildMessage(messageBuilder, jid);

                // Add the XHTML text to the message
                XHTMLManager.addBody(sendMessage, htmlBody);
            }

            sendMessage.setStanzaId(message.getMessageUID());
            mChat = mChatManager.chatWith(jid.asEntityBareJidIfPossible());
            mChat.send(sendMessage);
        ....
    }

[Flow]

@cmeng

Does the new method buildMessage() support also the encryption of XHTML extension?
e.g. using messageBuilder.addExtension(xhtmlExtension)?

No. The old but widely deployed OMEMO specification of the eu.siacs.conversations.axolotl namespace does only support one human readable encrypted and signed String!

@cmeng

Is there a reason to expose messageBuilder parameter?

Yes. This is the builder used to build the message which will carry the OMEMO payload, i.e. the encrypted and signed String.

@cmeng

aTalk supports XHTML standards, currently it uses the below steps to encrypt the xhtml extension i.e.

This will send the XHTML payload in plain text, not encrypted. With the old but widely deployed OMEMO specification based on the eu.siacs.conversations.axolotl namespace, you can not protected, i.e. sign and encrypt, arbitrary extension elements.

[Paul_Schaub]

This behaviour is not standards conformant.
Eventually Smack will add support for version 0.4+ of the OMEMO XEP which will enable encryption of XHTML payloads, but until then this is not possible.

[cmeng]

Thanks for the the update. aTalk shall just keep the crude method to encrypt xhtml ext until the support is made available.

[Flow]

@Paul_Schaub

This behaviour is not standards conformant.

I’d argue it does adhere tot he standard. It just follows an old version of the specification.

[Paul_Schaub]

The use of XHTML-IM in conjunction with OMEMO was never specified, so imho it would be non-standard behaviour.

[Flow]

That is correct. I mistook you for referring to OMEMO just protecting human-readable strings not being standards complaint.

[cmeng]

Actually I do not quite like the new xhtml specifications. It seems the new standard is not a simple implementation from developer point of view.

Currently aTalk supports xhtml message, with user just input xhtml text as it; aTalk will place the original xhtml text in the extensions, and extract html body info and place them in message body.

However the new xhtml standard seems to require quite a complex pre-process in phrasing the input xhtml text to confirm to the new format before sending. I cannot see how the new standard has added value. This is just a cent of my view.

[Paul_Schaub]

What new version of XHTML are you talking about btw? XEP-0071 is being deprecated as of 2018.

[Flow]

@cmeng

xhtml text to confirm to the new format before sending

XHTML-IM requires you to sanitize upon reception. If this is what you are talking about.

@cmeng

I cannot see how the new standard has added value.

There have been serious security issues in the past because implementations would basically simply feed XHTML-IM into a webview without sanitation. Those kind of stuff is easy exploitable. I hope you are aware of that.

[cmeng]

Thanks for the info. Need to read up more to have better understanding of the implications.