Adium

Opened 13 years ago

Closed 8 years ago

Last modified 6 years ago

#6901 closed defect (fixed)

HTML tags on outbound OTR messages

Reported by: CrazyToad Owned by: nobody
Milestone: Component: Adium Core
Version: Severity: normal
Keywords: html outgoing messages otr Cc:
Patch Status:

Description

As of version 1.0.3, all of my OTR contacts have been receiving my messages with visible HTML tags making it difficult to read my message. I confirmed this is happening on OTR messages sent to Trillian using OTR Proxy 0.3.1 and Miranda IM using the OTR plugin.

Adium to Adium OTR chats do not display this behavior.

Attachments (1)

Screen shot 2010-10-07 at 17.17.11.png (29.9 KB) - added by tipsy 9 years ago.
OTR->Miranda. Before signin off - 1.3.10. After signin on: 1.4b19

Download all attachments as: .zip

Change History (50)

comment:1 Changed 13 years ago by Evan Schoenberg

Milestone: Adium X 1.1

Sigh. Doing OTR in Adium and then passing it to libpurple means that libpurple can't strip HTML tags, which needs to be done if sending ICQ to ICQ. This problem would exist using the OTR libpurple plugin, too, because the hooks aren't being used appropriately. We need to (1) have Adium utilize libpurple's hooks for message processing where appropriate and (2) have libpurple's oscar implementation do the HTML stripping and whatnot before the last step, such that we can pass the text in, get it processed, then do the OTR encoding.

This is nontrivial but important. :\

comment:2 Changed 13 years ago by Evan Schoenberg

Resolution: fixed
Status: newclosed

(In [20005]) For an ICQ to ICQ conversation over OTR, do our own plain text conversion since libpurple doesn't get to see the original text for stripping. Fixes #6901

comment:3 Changed 13 years ago by Evan Schoenberg

(In [20044]) Merged [20005]: For an ICQ to ICQ conversation over OTR, do our own plain text conversion since libpurple doesn't get to see the original text for stripping. Fixes #6901

comment:4 Changed 13 years ago by Evan Schoenberg

Milestone: Adium X 1.1Adium X 1.0.5
pending: 0

comment:5 Changed 11 years ago by Zachary West

Component: OTRAdium Core

Removing 'OTR' component.

comment:6 Changed 10 years ago by Kenyon Ralph

This bug still happens when sending from Adium Google Talk accounts.

comment:7 in reply to:  6 Changed 10 years ago by mathuaerknedam

Resolution: fixed
Status: closednew

Replying to kenyon:

This bug still happens when sending from Adium Google Talk accounts.

Did you try the TroubleshootingTips? What version of OS X are you using? What version of Adium are you using? What client is the other side (that sees the HTML) using? What protocol/service is the other side using?

comment:8 Changed 10 years ago by mathuaerknedam

Status: newpending

comment:9 Changed 10 years ago by Kenyon Ralph

Using Adium 1.4b17.

Sending to a BitlBee client on the receiving side.

I'm not sure if Adium's behavior is incorrect for encrypting HTML in OTR Jabber (Google Talk) messages, or if BitlBee is incorrect for not stripping them. However, Adium seems to not send HTML when not doing encrypted OTR over Jabber, which is why I think it's incorrect for it to happen with OTR. Characters are also replaced by HTML entities.

The messages look like this on the receiving side (after decryption, of course): <FONT FACE="DejaVu Sans" ABSZ=10 SIZE=2>test</FONT> <FONT FACE="DejaVu Sans" ABSZ=10 SIZE=2>&amp;&amp;</FONT>

comment:10 Changed 10 years ago by trac-robot

Status: pendingclosed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:11 Changed 10 years ago by Jeffrey Paul

Why is this bug closed? It's still outstanding in 1.3.10, haven't tested the beta.

comment:12 Changed 10 years ago by Sven Schober

+1

Adium 1.3.10 Mac OS X 1.6.3

Seeing this with a Jabber Buddy using bitlbee over an OTR encrypted connection.

comment:13 Changed 10 years ago by Robert

Status: closednew
Version: 1.0.31.4b17

comment:14 Changed 10 years ago by Robert

Milestone: Adium X 1.0.5

comment:15 Changed 10 years ago by Tolga

I have the same problem with my Adium (1.3.10) at my mini Mac (10.6.3).

In my case I have a gtalk account and when I chat with a friend who is using gtalk at windows, everything i send appears in HTML tags. I can read what they send clearly.

I have seen this before when i was using meebo.com. Again windows gtalk users had trouble reading what i sent. So I am not sure but it looks like a problem of the sender not sending the message in correct tags so that the receiver client can not parse it and shows everything instead of the message itself?

I think this bug's severity should be higher than normal because it really prevents me using Adium as a gtalk client.

Hope you guys find a solution.

Thanks, Tolga.

comment:16 Changed 10 years ago by Tolga

this is a sample that my friend received from me at his MS Windows GTalk software:

<html xmlns="http://jabber.org/protocol/xhtml-im"><body xmlns="http://www.w3.org/1999/xhtml"><span style="font-family: Tahoma; font-size: medium; background: #ffffff;">I like to move it move it</span></body></html>

I tried changing font type, size etc. no help I tried creating jabber account instead of gtalk account. no help

Btw, iChat works fine, no html tags in the messages...

comment:17 Changed 10 years ago by Tolga

I just installed 1.4b18 and the problem does not exist for me anymore.

comment:18 Changed 10 years ago by Moses Lei

TeTrA, the bug you found is unrelated. This one is about encrypted messages. And since it's fixed in beta, no need to report it.

comment:19 Changed 9 years ago by Robert

Resolution: fixed
Status: newclosed

comment:20 Changed 9 years ago by Arif Amirani

I still see this issue with 1.4b19. I am using OTR on both sides and Adium is definitely sending out <FONT> tags. Can someone please verify the following?

User types "A" -> Adium converts to "<FONT>A</FONT>" -> OTR encrypts "<FONT>A</FONT>" -> Adium while sending can't parse and hence sends encrypted text to other user.

Is the above issue cause OTR is happening before the parsing by libpurple?

Thanks, Arif Amirani

Changed 9 years ago by tipsy

OTR->Miranda. Before signin off - 1.3.10. After signin on: 1.4b19

comment:21 Changed 9 years ago by tipsy

I've added a screenshot of adium->miranda message with OTR on. Before signin off - 1.3.10. After signin on: 1.4b19.

Please reopen this ticket.

comment:22 Changed 9 years ago by Robert

Resolution: fixed
Status: closednew

comment:23 Changed 9 years ago by Kenyon Ralph

This bug is still present in Adium 1.4.1.

comment:24 Changed 9 years ago by David Munch

Milestone: Adium bugs

comment:25 Changed 9 years ago by Robert

Version: 1.4b171.4.1

comment:26 Changed 9 years ago by pesco

we're investigating the issue from the other side in BitlBee, receiving OTR messages that contain unexpected HTML markup. i think i've traced the cause to the fact that XMPP messages contain both the plain text and the HTML representation but the libpurple API doesn't expose that. here's our discussion:

http://bugs.bitlbee.org/bitlbee/ticket/690#comment:19

maybe it helps to shed some light.

comment:27 Changed 8 years ago by Martin

Adium 1.4.3 ... problem still prevalent.

I verified it when talking to Pidgin and Miranda.

Would be sooo great if someone could fix it. Unfortunately it seems there is currently no work in progress? :-(

comment:28 Changed 8 years ago by Kenyon Ralph

At least I can report that on recent versions of bitlbee (I'm using bitlbee-3.0.3+devel+811-1), no HTML tags appear when talking to someone using Adium.

comment:29 Changed 8 years ago by David Munch

Version: 1.4.11.4.3

comment:30 Changed 8 years ago by David Munch

Keywords: otr added

comment:31 Changed 8 years ago by Martin

Version 1.4.4: Problem does still exist. Doesn't seem theres anybody even considering working on this..?! Should be more people facing that problem?

comment:32 Changed 8 years ago by David Munch

Try the 1.5 beta and see if that fixes the problem. Otherwise, no, I don't believe anyone is currently working on OTR.

comment:33 Changed 8 years ago by Thijs Alkemade

Resolution: fixed
Status: newclosed

Adium's behavior here is correct: OTR messages have to be encoded with UTF-8 and may contain HTML markup. If other clients show these tags literally, then those clients need to be fixed.

comment:34 Changed 8 years ago by Robert

Milestone: Adium bugs

comment:35 Changed 7 years ago by Johannes

Sorry guys, but please reopen this ticket. There is no reason that Adium should send < font > tags when using OTR while it does not when chatting without OTR. This behaviour is just annoying for all parties that do not support html tags (for security reasons f.e.).

comment:36 Changed 7 years ago by Thijs Alkemade

Any client which supports OTR has to be able to decode or at least strip HTML tags. So there's no reason Adium should not use HTML-tags when using OTR, even when the underlying protocol doesn't support it.

comment:37 Changed 7 years ago by rtud

I can confirm it's still an issue, and I don' understand why it's still marked as fixed.

comment:38 Changed 7 years ago by Robert

Please read the previous comments.

comment:39 Changed 6 years ago by Robert

Ticket #16507 has been marked as a duplicate of this ticket.

comment:40 Changed 6 years ago by Kenyon Ralph

This behavior is clearly incorrect, even if it's OK to have HTML tags generally. What's the purpose of surrounding every message with empty FONT tags, and doing that only for OTR sessions, not plaintext sessions?

comment:41 Changed 6 years ago by FelixAkk

Could we at least have a checkbox so we can force Adium NOT to send HTML but plain text in stead? I can't remember anywhere that it's obligatory in OTR to send HTML instead of plain text. This is really driving me and my friends drink.

comment:42 Changed 6 years ago by Robert

Why don't you ask the developers of your friend's chat client to do something about it?

comment:43 Changed 6 years ago by FelixAkk

Because of this: http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

And because it sure is a lot easier to just make a switch on Adium's side and recognize that at the moment other clients do not support HTML yet, instead of ignoring it and expecting all of them to have it fixed in no time.

I agree that they should support HTML, but at the moment they don't, and it would save a lot of days of headaches on the side of the users if Adium would be so "friendly" to make a one step to allow useful communication with these clients untill they have their HTML parsers set straight.

Last edited 6 years ago by FelixAkk (previous) (diff)

comment:44 in reply to:  41 Changed 6 years ago by Thijs Alkemade

Replying to FelixAkk:

Could we at least have a checkbox so we can force Adium NOT to send HTML but plain text in stead? I can't remember anywhere that it's obligatory in OTR to send HTML instead of plain text. This is really driving me and my friends drink.

https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html:

The plaintext message (either before encryption, or after decryption) consists of a human-readable message (encoded in UTF-8, optionally with HTML markup)[...]

comment:45 Changed 6 years ago by FelixAkk

"optionally with HTML markup", it's not required right? So it's also allowed to be just plain text. Would sure be nice if I could switch to plain text with those that don't support HTML yet.

comment:46 in reply to:  45 Changed 6 years ago by Thijs Alkemade

Replying to FelixAkk:

"optionally with HTML markup", it's not required right? So it's also allowed to be just plain text. Would sure be nice if I could switch to plain text with those that don't support HTML yet.

HTML tags are optional. That doesn't mean that you can send "just plain" instead, it still needs to be HTML encoded: If you want to send "<3", then that needs to be encoded as "&lt;3".

I disagree with adding a "just send plain" checkbox, because it will mean any message containing "<" or other invalid HTML will be dropped by the receiver if they're using a client which has implemented OTR properly.

comment:47 Changed 6 years ago by FelixAkk

Fair point I suppose. But then perhaps we could implement setting the right content type in the headers so that clients that rely on this will actually be triggered to parse the HTML?

comment:48 Changed 6 years ago by FelixAkk

Also, I guess the situation for clients that don't support HTML parsing would already be quite workable if unstyled text isn't wrapped in a superfluous <FONT> tag by default. I'd be willing to look into fixing this if someone can give me a hint of direction where this is implemented.

Last edited 6 years ago by FelixAkk (previous) (diff)

comment:49 Changed 6 years ago by Nobu

Please fix this.. still broken.

Note: See TracTickets for help on using tickets.