[jitsi-users] OTR HTML message handling


#1

Hi,

Is there a current bug for Jitsi assuming unspecified OTR messages are
text/plain instead of HTML? I don't see anything in the tracker and the
last message on the subject is this from 2013:
http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

It's annoying to get unparsed tags and entity references in chats and
pretty confusing for less technical users, and assuming the HTML
rendering context is appropriately sane, there should be no additional
risk. At most, one might want to check messages for unrecognized tags
and auto-escape <, >, and & in them, but most clients these
days do seem to emit HTML messages by default.

E.

···

--
Ideas are my favorite toys.


#2

Hi Eleanor,

This was discussed previously. This is basically a limitation of OTR
which forces clients to arbitrarily choose a message format. Jitsi
chooses plain text while some (not all) other clients choose HTML.
Please see (the whole) discussion in thread
http://lists.jitsi.org/pipermail/users/2015-February/008878.html.

Whichever way we choose, we will cause trouble for at least 1 class of
users. And if we decide to switch, then we will have at least one other
class with issues: interop with users of older Jitsi client versions.

Kind regards
Danny

···

On 01-09-15 20:42, Eleanor Saitta wrote:

Hi,

Is there a current bug for Jitsi assuming unspecified OTR messages are
text/plain instead of HTML? I don't see anything in the tracker and the
last message on the subject is this from 2013:
http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

It's annoying to get unparsed tags and entity references in chats and
pretty confusing for less technical users, and assuming the HTML
rendering context is appropriately sane, there should be no additional
risk. At most, one might want to check messages for unrecognized tags
and auto-escape <, >, and & in them, but most clients these
days do seem to emit HTML messages by default.

E.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Is there any technical reason why the format of OTR text messages
could not be made user selectable?

If the format was made user selectable for each session and if the
contact list could be made to support keeping the preference would
that not go a long way towards keeping everyone happy?

···

On Wed, September 2, 2015 09:04, Danny van Heumen wrote:

Hi Eleanor,

This was discussed previously. This is basically a limitation of OTR
which forces clients to arbitrarily choose a message format. Jitsi
chooses plain text while some (not all) other clients choose HTML.
Please see (the whole) discussion in thread
http://lists.jitsi.org/pipermail/users/2015-February/008878.html.

Whichever way we choose, we will cause trouble for at least 1 class of
users. And if we decide to switch, then we will have at least one
other
class with issues: interop with users of older Jitsi client versions.

Kind regards
Danny

On 01-09-15 20:42, Eleanor Saitta wrote:

Hi,

Is there a current bug for Jitsi assuming unspecified OTR messages
are
text/plain instead of HTML? I don't see anything in the tracker and
the
last message on the subject is this from 2013:
http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

It's annoying to get unparsed tags and entity references in chats
and
pretty confusing for less technical users, and assuming the HTML
rendering context is appropriately sane, there should be no
additional
risk. At most, one might want to check messages for unrecognized
tags
and auto-escape <, >, and & in them, but most clients
these
days do seem to emit HTML messages by default.

E.

--
*** e-Mail is NOT a SECURE channel ***
        Do NOT transmit sensitive data via e-Mail
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#4

Hi Eleanor,

This was discussed previously. This is basically a limitation of OTR
which forces clients to arbitrarily choose a message format. Jitsi
chooses plain text while some (not all) other clients choose HTML.
Please see (the whole) discussion in thread
http://lists.jitsi.org/pipermail/users/2015-February/008878.html.

Thanks! Is this listed anywhere as a known open issue? It'd be nice to
have something in the documentation to point folks to that explains why
it's happening.

Whichever way we choose, we will cause trouble for at least 1 class of
users. And if we decide to switch, then we will have at least one other
class with issues: interop with users of older Jitsi client versions.

Given that the specification is inherently ambiguous, it seems that
content snooping to determine the behavior of the other party would be
appropriate. Done correctly, content snooping on a per-session basis
with escaping, as mentioned below, seems like it would provide users
with the behavior they expect without accidentally causing problems for
either HTML-sensitive characters used in plain text messages or
extraneous HTML being printed.

E.

···

On 2015.09.02 15.04, Danny van Heumen wrote:

On 01-09-15 20:42, Eleanor Saitta wrote:

At most, one might want to check messages for unrecognized tags
and auto-escape <, >, and & in them, but most clients these
days do seem to emit HTML messages by default.

--
Ideas are my favorite toys.


#5

Content sniffing seems a bit more desirable than another setting to me
-- easier for novice users.

E.

···

On 2015.09.02 20.45, James B. Byrne wrote:

Is there any technical reason why the format of OTR text messages
could not be made user selectable?

If the format was made user selectable for each session and if the
contact list could be made to support keeping the preference would
that not go a long way towards keeping everyone happy?

--
Ideas are my favorite toys.


#6

Hi James,

Hi Eleanor,

This was discussed previously. This is basically a limitation of OTR
which forces clients to arbitrarily choose a message format. Jitsi
chooses plain text while some (not all) other clients choose HTML.
Please see (the whole) discussion in thread
http://lists.jitsi.org/pipermail/users/2015-February/008878.html.

Whichever way we choose, we will cause trouble for at least 1 class of
users. And if we decide to switch, then we will have at least one
other
class with issues: interop with users of older Jitsi client versions.

Kind regards
Danny

Hi,

Is there a current bug for Jitsi assuming unspecified OTR messages
are
text/plain instead of HTML? I don't see anything in the tracker and
the
last message on the subject is this from 2013:
http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

It's annoying to get unparsed tags and entity references in chats
and
pretty confusing for less technical users, and assuming the HTML
rendering context is appropriately sane, there should be no
additional
risk. At most, one might want to check messages for unrecognized
tags
and auto-escape <, >, and & in them, but most clients
these
days do seem to emit HTML messages by default.

E.

Is there any technical reason why the format of OTR text messages
could not be made user selectable?

Well, you can always make something selectable. You would be storing
these settings per user, not per user's client, so even then you may
encounter issues. The other issue is that this would mean yet another
option to configure in order to use the client.

As far as possible solutions go, I tend to go with Eleanor's suggestion
of analyzing messages. You could, as soon as you encounter one of a
number of known html tags, "upgrade" the format to HTML, assuming that
clients sending HTML also know how to read it.
You could do this in every session, so you would only need a llittle
moment to "warm" up the client to the appropriate situation w.r.t. other
client's capabilities.

···

On 02-09-15 20:45, James B. Byrne wrote:

On Wed, September 2, 2015 09:04, Danny van Heumen wrote:

On 01-09-15 20:42, Eleanor Saitta wrote:

If the format was made user selectable for each session and if the
contact list could be made to support keeping the preference would
that not go a long way towards keeping everyone happy?


#7

As far as possible solutions go, I tend to go with Eleanor's suggestion
of analyzing messages. You could, as soon as you encounter one of a
number of known html tags, "upgrade" the format to HTML, assuming that
clients sending HTML also know how to read it.
You could do this in every session, so you would only need a llittle
moment to "warm" up the client to the appropriate situation w.r.t. other
client's capabilities.

How are other plain-text clients dealing with this?

Ingo


#8

Automagical reconfiguration is always better from the POV of the
novice user. For the experienced user I find it not so much a benefit
as a constant pain point. One can consider the case of Gnome 2 vs.
Gnome 3 as an example. In any case it seems that providing user
contact settings would likely be considerably easier to implement
reliably.

Also there is the issue of user control of their software. If one has
a switch and the switch says plain text enabled / html disabled then
one can generally proceed on the basis that plain text is in use.
With automagical configuration what happens happens when one sends
quoted html code snippets as part of a plain text OTR chat is entirely
dependent on how the content sniffing is programmed.

I suspect that getting the content detection algorithm to work
reliably for the corner cases might prove a little more difficult than
one might first imagine.

···

On Thu, September 3, 2015 06:07, Danny van Heumen wrote:

Hi James,

On 02-09-15 20:45, James B. Byrne wrote:

On Wed, September 2, 2015 09:04, Danny van Heumen wrote:

Hi Eleanor,

This was discussed previously. This is basically a limitation of
OTR
which forces clients to arbitrarily choose a message format. Jitsi
chooses plain text while some (not all) other clients choose HTML.
Please see (the whole) discussion in thread
http://lists.jitsi.org/pipermail/users/2015-February/008878.html.

Whichever way we choose, we will cause trouble for at least 1 class
of
users. And if we decide to switch, then we will have at least one
other
class with issues: interop with users of older Jitsi client
versions.

Kind regards
Danny

On 01-09-15 20:42, Eleanor Saitta wrote:

Hi,

Is there a current bug for Jitsi assuming unspecified OTR messages
are
text/plain instead of HTML? I don't see anything in the tracker
and
the
last message on the subject is this from 2013:
http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

It's annoying to get unparsed tags and entity references in chats
and
pretty confusing for less technical users, and assuming the HTML
rendering context is appropriately sane, there should be no
additional
risk. At most, one might want to check messages for unrecognized
tags
and auto-escape <, >, and & in them, but most clients
these
days do seem to emit HTML messages by default.

E.

Is there any technical reason why the format of OTR text messages
could not be made user selectable?

Well, you can always make something selectable. You would be storing
these settings per user, not per user's client, so even then you may
encounter issues. The other issue is that this would mean yet another
option to configure in order to use the client.

As far as possible solutions go, I tend to go with Eleanor's
suggestion
of analyzing messages. You could, as soon as you encounter one of a
number of known html tags, "upgrade" the format to HTML, assuming that
clients sending HTML also know how to read it.
You could do this in every session, so you would only need a llittle
moment to "warm" up the client to the appropriate situation w.r.t.
other
client's capabilities.

If the format was made user selectable for each session and if the
contact list could be made to support keeping the preference would
that not go a long way towards keeping everyone happy?

--
*** e-Mail is NOT a SECURE channel ***
        Do NOT transmit sensitive data via e-Mail
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3


#9

As far as possible solutions go, I tend to go with Eleanor's suggestion
of analyzing messages. You could, as soon as you encounter one of a
number of known html tags, "upgrade" the format to HTML, assuming that
clients sending HTML also know how to read it.
You could do this in every session, so you would only need a llittle
moment to "warm" up the client to the appropriate situation w.r.t. other
client's capabilities.

How are other plain-text clients dealing with this?

So far I have only heard of clients having (non-configurable?) defaults
for either one or the other. I think I've heard for both options that
there are clients defaulting to it. (That is, apart from Jitsi.)

I would be interested to know if there are other "smart" solutions in use.

Danny

···

On 09/03/2015 12:16 PM, Ingo Bauersachs wrote:

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#10

Automagical reconfiguration is always better from the POV of the
novice user. For the experienced user I find it not so much a benefit
as a constant pain point. One can consider the case of Gnome 2 vs.
Gnome 3 as an example. In any case it seems that providing user
contact settings would likely be considerably easier to implement
reliably.

We're talking about something much simpler here.

Putting in a checkbox that says "never autodetect HTML in OTR messages"
in the config that maintains the existing behavior seems like it would
deal with that.

Adding a configuration option for every host identifier we've seen from
every user we've ever talked to seems like it would be really very
annoying and not what any user wants.

Providing an experience that's optimized for experienced users and
hostile to novices is a good way to ensure OTR adoption continues to be
all-but-nonexistent. Jitsi is currently a tool that's frankly marginal
for me to get new users to us; I'd love to see speedbumps like this one
get smoothed out so more people can start using OTR.

I suspect that getting the content detection algorithm to work
reliably for the corner cases might prove a little more difficult than
one might first imagine.

No, detecting if a message contains valid HTML tags is not difficult.

E.

···

On 2015.09.03 18.21, James B. Byrne wrote:

--
Ideas are my favorite toys.


#11

Isn't the core problem here that some clients "do not send the
xhtml-in extension"? Shouldn't the answer be have these other clients
patched to fix their code? To hack around this seems like it will
only encourage others to not follow standards. Why bother including
the proper extensions if the other clients will just deal with it?
Then we risk getting into a race-to-the-bottom where any software
which enforces the standards is seen as inferior (e.g. PDF viewers).

I've heard of serious security vulnerabilities because of content
sniffing was introduced, which is why most browsers don't do it
anymore.[1] IE still does, but I'd argue that is not a good thing[2].

Between wanting to encourage that people follow standards and security
concerns (and I could imagine the content sniffing feature scope
creeping to include more risky things), I am against content sniffing.

If content sniffing is implemented, this[3] is the latest research I
know of on the topic.

My argument against content sniffing may just be a difference in
opinion/philosophy. At the end of the day, I can certainly tolerate
sniffing being implemented, and even being on by default. The only
thing I'd ask is that there be a way to disable it at run time.
Perhaps some option buried deep in the preferences?

[1] https://en.wikipedia.org/wiki/Content_sniffing
[2] http://blog.fox-it.com/2012/05/08/mime-sniffing-feature-or-vulnerability/
[3] https://mimesniff.spec.whatwg.org/

···

On 9/3/15, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

On 09/03/2015 12:16 PM, Ingo Bauersachs wrote:

As far as possible solutions go, I tend to go with Eleanor's suggestion
of analyzing messages. You could, as soon as you encounter one of a
number of known html tags, "upgrade" the format to HTML, assuming that
clients sending HTML also know how to read it.
You could do this in every session, so you would only need a llittle
moment to "warm" up the client to the appropriate situation w.r.t. other
client's capabilities.

How are other plain-text clients dealing with this?

So far I have only heard of clients having (non-configurable?) defaults
for either one or the other. I think I've heard for both options that
there are clients defaulting to it. (That is, apart from Jitsi.)

I would be interested to know if there are other "smart" solutions in use.

Danny

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#12

Isn't the core problem here that some clients "do not send the
xhtml-in extension"? Shouldn't the answer be have these other clients
patched to fix their code? To hack around this seems like it will
only encourage others to not follow standards. Why bother including
the proper extensions if the other clients will just deal with it?
Then we risk getting into a race-to-the-bottom where any software
which enforces the standards is seen as inferior (e.g. PDF viewers).

No, the core problem is that the OTR specification itself does not
specify whether the content of a message includes HTML or not and does
not include a mechanism to tell the remote client whether or not the
message includes HTML. Different clients have (legitimately and
entirely within the spec) decided differently here, and until the spec
is corrected, incompatibilities will continue. The OTR spec isn't
great, but it's what we have right now. Not handling HTML in messages
reasonably is non-compliant behavior.

I've heard of serious security vulnerabilities because of content
sniffing was introduced, which is why most browsers don't do it
anymore.[1] IE still does, but I'd argue that is not a good thing[2].

Hi! I'm a security engineer who's worked in the industry for a decade
-- so you know where this is coming from -- and while yes, content
sniffing has caused vulnerabilities in some cases, it's simply not a
concern here. Jitsi already has to deal with receiving and rendering
HTML in messages from untrusted remote sources. Rendering HTML here
does not increase the system's attack surface. The vulnerabilities that
have shown up in other browsers are coming from javascript being served
from places where js was absolutely not expected to be coming, such as
image files. The vulnerabilities it caused were mostly XSS in sites
that allowed image upload. Jitsi should never execute js regardless of
context, so this simply isn't an issue.

Between wanting to encourage that people follow standards and security
concerns (and I could imagine the content sniffing feature scope
creeping to include more risky things), I am against content sniffing.

Standard correctness requires handling HTML in OTR messages.
Content sniffing will not increase the attack surface of the system.
There is no reason to do any other content sniffing that I know of.

The only
thing I'd ask is that there be a way to disable it at run time.
Perhaps some option buried deep in the preferences?

Having a checkbox to disable it seems entirely reasonable; see my
previous message.

E.

···

On 2015.09.03 18.30, :biohazard:Adam wrote:

--
Ideas are my favorite toys.


#13

Isn't the core problem here that some clients "do not send the
xhtml-in extension"? Shouldn't the answer be have these other clients
patched to fix their code? To hack around this seems like it will
only encourage others to not follow standards. Why bother including
the proper extensions if the other clients will just deal with it?
Then we risk getting into a race-to-the-bottom where any software
which enforces the standards is seen as inferior (e.g. PDF viewers).

No, the core problem is that the OTR specification itself does not
specify whether the content of a message includes HTML or not and does
not include a mechanism to tell the remote client whether or not the
message includes HTML.

The message linked to earlier[1] indicates that there is a way to
indicate when a message contains HTML: "...the xhtml-in extension which
indicates that the message contains html..."[1] It may not be in the
official spec, but if clients compiled with this, it may get adopted
into the spec, which would actually solve the problem of ambiguity.

[1] http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

Between wanting to encourage that people follow standards and security
concerns (and I could imagine the content sniffing feature scope
creeping to include more risky things), I am against content sniffing.

Standard correctness requires handling HTML in OTR messages.
Content sniffing will not increase the attack surface of the system.
There is no reason to do any other content sniffing that I know of.

I wasn't suggesting that HTML not be handled, I was suggesting that if
there is HTML content, than it be labeled as such, and to do so using
the existing solution (the xhtml-in extension), even if it hasn't yet
been adopted into the official spec.

I think the right answer is to label the content appropriately rather
than making an educated guess, but if we're going the content sniffing
route, how content sniffing should be implemented should be specified
precisely. Otherwise we'll run into this same problem later where each
client implements it differently.

···

On 09/04/2015 05:41 AM, Eleanor Saitta wrote:

On 2015.09.03 18.30, :biohazard:Adam wrote:


#14

I took some extra time to think about this and you've convinced me
that as long as there's a way to opt out of the content sniffing (and
it's properly implemented), that the attack surface isn't increased.
I'd argue that adding code which processes untrusted input is
increasing the attack surface, which is why I think the ability to
turn it off is so important.

On a separate, but related, note, what should be done when a user
sends HTML messages to a client which doesn't have an HTML parser (or
the user disabled it to avoid bugs in XML parsing, image formats, font
processing, etc.)? E-mail deals with this by sending the entire
message twice, once in plaintext and once with HTML formatting and
then the recipient decides which one to render. I don't like the
extra overhead, but seeing as how IMs can be delivered offline, and to
multiple clients, negotiating the format seems like it would be
difficult. It could also be confusing to users since sometimes the
software would appear to be broken (e.g. "Why can't I make the text
bold? It's not working.").

···

On 9/4/15, Eleanor Saitta <ella@dymaxion.org> wrote:

On 2015.09.03 18.30, :biohazard:Adam wrote:
Hi! I'm a security engineer who's worked in the industry for a decade
-- so you know where this is coming from -- and while yes, content
sniffing has caused vulnerabilities in some cases, it's simply not a
concern here. Jitsi already has to deal with receiving and rendering
HTML in messages from untrusted remote sources. Rendering HTML here
does not increase the system's attack surface. The vulnerabilities that
have shown up in other browsers are coming from javascript being served
from places where js was absolutely not expected to be coming, such as
image files. The vulnerabilities it caused were mostly XSS in sites
that allowed image upload. Jitsi should never execute js regardless of
context, so this simply isn't an issue.


#15

Hi,

Isn't the core problem here that some clients "do not send the
xhtml-in extension"? Shouldn't the answer be have these other clients
patched to fix their code? To hack around this seems like it will
only encourage others to not follow standards. Why bother including
the proper extensions if the other clients will just deal with it?
Then we risk getting into a race-to-the-bottom where any software
which enforces the standards is seen as inferior (e.g. PDF viewers).

No, the core problem is that the OTR specification itself does not
specify whether the content of a message includes HTML or not and does
not include a mechanism to tell the remote client whether or not the
message includes HTML.

The message linked to earlier[1] indicates that there is a way to
indicate when a message contains HTML: "...the xhtml-in extension which
indicates that the message contains html..."[1] It may not be in the
official spec, but if clients compiled with this, it may get adopted
into the spec, which would actually solve the problem of ambiguity.

[1] http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

Are you referring to HTML-IM (note the M not N) extension for XMPP?
(http://www.xmpp.org/extensions/xep-0071.html)
If so, this is the wrong layer. The XMPP message contains the
base64-encoded encrypted OTR message. Base64 fits in the plain text
range of characters, so it doesn't make sense to declare this as HTML.
Note that technically, it is feasible to declare this as HTML, but it
doesn't make sense since the content contained in the message payload
isn't HTML.

The issue is that you need to express a content-type *inside* the
OTR-encrypted message. There is no mechanism for that AFAIK.

Danny

···

On 08-09-15 00:55, Adam wrote:

On 09/04/2015 05:41 AM, Eleanor Saitta wrote:

On 2015.09.03 18.30, :biohazard:Adam wrote:

Between wanting to encourage that people follow standards and security
concerns (and I could imagine the content sniffing feature scope
creeping to include more risky things), I am against content sniffing.

Standard correctness requires handling HTML in OTR messages.
Content sniffing will not increase the attack surface of the system.
There is no reason to do any other content sniffing that I know of.

I wasn't suggesting that HTML not be handled, I was suggesting that if
there is HTML content, than it be labeled as such, and to do so using
the existing solution (the xhtml-in extension), even if it hasn't yet
been adopted into the official spec.

I think the right answer is to label the content appropriately rather
than making an educated guess, but if we're going the content sniffing
route, how content sniffing should be implemented should be specified
precisely. Otherwise we'll run into this same problem later where each
client implements it differently.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#16

That's an interesting question which should definitely be taken up with
the authors of the relevant protocol specifications, as there should
clearly be some standard mechanism.

E.

···

On 2015.09.09 15.42, :biohazard:Adam wrote:

On a separate, but related, note, what should be done when a user
sends HTML messages to a client which doesn't have an HTML parser (or
the user disabled it to avoid bugs in XML parsing, image formats, font
processing, etc.)?

--
Ideas are my favorite toys.


#17

Yes. This is exactly why I'm suggesting that minimal content sniffing,
in addition to reducing user confusion as a default option, is actually
the standards compliant way to handle this situation. Normally I'm
entirely against such things, but there does not appear to be a way to
manage interactions between the current spec and installed client base.

E.

···

On 2015.09.08 19.32, Danny van Heumen wrote:

On 08-09-15 00:55, Adam wrote:

The message linked to earlier[1] indicates that there is a way to
indicate when a message contains HTML: "...the xhtml-in extension which
indicates that the message contains html..."[1] It may not be in the
official spec, but if clients compiled with this, it may get adopted
into the spec, which would actually solve the problem of ambiguity.

[1] http://lists.jitsi.org/pipermail/dev/2013-July/017713.html

Are you referring to HTML-IM (note the M not N) extension for XMPP?
(http://www.xmpp.org/extensions/xep-0071.html)
If so, this is the wrong layer. The XMPP message contains the
base64-encoded encrypted OTR message. Base64 fits in the plain text
range of characters, so it doesn't make sense to declare this as HTML.
Note that technically, it is feasible to declare this as HTML, but it
doesn't make sense since the content contained in the message payload
isn't HTML.

The issue is that you need to express a content-type *inside* the
OTR-encrypted message. There is no mechanism for that AFAIK.

--
Ideas are my favorite toys.


#18

On a separate, but related, note, what should be done when a user
sends HTML messages to a client which doesn't have an HTML parser (or
the user disabled it to avoid bugs in XML parsing, image formats, font
processing, etc.)?

That's an interesting question which should definitely be taken up with
the authors of the relevant protocol specifications, as there should
clearly be some standard mechanism.

This is clearly something that must be supported in/by OTR. OTRv3 does
allow for special "TLV"s to be defined. TLV = type-length-value - a sort
of key-value entry that can be sent with (or without) an OTR message.
TLVs are so far used for managing the authentication process and for
signaling the use of the extra symmetric key (which AFAIK was never
really used/implemented anywhere).

We *could* (I'm not an expert and this is just an arbitrary idea, by no
means "the best one of X possible options") have a TLV that signifies
metadata that contains both the key, e.g. Content-Type (symbolic
suggestion, we may want something with specific properties in practice)
and its value.

So far, though, I don't think anything like this was suggested. And
AFAIK there are no other solutions for our specific problem.

Danny

···

On 09-09-15 14:50, Eleanor Saitta wrote:

On 2015.09.09 15.42, :biohazard:Adam wrote:

E.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users