Adium

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#15722 closed defect (wontfix)

Disable OTR chat logging by default

Reported by: kaepora Owned by:
Milestone: Component: Adium Core
Version: 1.5b8 Severity: normal
Keywords: Cc:
Patch Status:

Description

Summary

Adium potentially damages the privacy of thousands of people by enabling logging on OTR chats by default. This needs to be fixed immediately. It's as easy as making this checkbox unchecked by default: http://i.imgur.com/LsE3x.png

I'm not overstating the seriousness of this issue. Bradley Manning, accused of leaking classified documents to WikiLeaks, is being prosecuted because of the automatic logging of his alleged Adium OTR chats: http://www.bradleymanning.org/updates/day-four-of-the-bradley-manning-trial-in-depth-notes-from-a-courtroom-viewer-in-bradley-mannings-article-32-hearing

Enough is enough. Security is not a game.

Change History (22)

comment:1 follow-ups: Changed 3 years ago by hellais

I also believe this ticket is of great importance and I think the checkbox idea is nice, though maybe it should just not be possible to log OTR chats.

By design OTR supports Perfect Forward secrecy, by logging OTR enabled chats you are violating one of the design goals of OTR, so I would even go as far as removing the logging feature in OTR enabled chats altogether.

comment:2 in reply to: ↑ 1 Changed 3 years ago by mathuaerknedam

Most people don't *need* OTR, and Adium's defaults should server the majority of users, not the a minority with special needs.
I believe that as long as Adium enables OTR by default and enables logging by default, the logging of OTR messages should be enabled by default. Otherwise users who never modify their preferences will later discover that they are missing important logs.

comment:3 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by mathuaerknedam

Replying to hellais:

By design OTR supports Perfect Forward secrecy, by logging OTR enabled chats you are violating one of the design goals of OTR, so I would even go as far as removing the logging feature in OTR enabled chats altogether.

You seem to be indicating that OTR is worthless if message logging is enabled. If that's the case, then the question becomes one of value to the majority of users: OTR or logging. Whichever is of greater value should be enabled, and the other disabled. I suspect that logging is the greater value to most users. On the other hand, if OTR does have value even when logging is enabled, then the current settings would seem to be the ones that best serves the greater number of users.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by hellais

Replying to mathuaerknedam:

Replying to hellais:

By design OTR supports Perfect Forward secrecy, by logging OTR enabled chats you are violating one of the design goals of OTR, so I would even go as far as removing the logging feature in OTR enabled chats altogether.

You seem to be indicating that OTR is worthless if message logging is enabled. If that's the case, then the question becomes one of value to the majority of users: OTR or logging. Whichever is of greater value should be enabled, and the other disabled. I suspect that logging is the greater value to most users. On the other hand, if OTR does have value even when logging is enabled, then the current settings would seem to be the ones that best serves the greater number of users.

I believe you misinterpreted me. OTR encrypts your data across the network, so it still effective at providing end-to-end chat encryption for the network part, however it is designed in a way that the encryption keys used to decrypt your messages cannot be recovered from your device. However if you do enable logging this principle is broken because the cleartext of the messages is available therefore the perfect-forward-secrecy principle is violated.

I believe there is no value lost in disabling logging for OTR, if the normal user engages in an OTR chat he knowns that what is happening should not be logged. It is like when I talk to a person IRL, I don't expect that person to record my conversation because that is good manners. In the same way the implementation of OTR should follow these basic social rules.

So I would go for logging for all chats, except the OTR ones.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by mathuaerknedam

Replying to hellais:

...if the normal user engages in an OTR chat he knowns that what is happening should not be logged.

You make a few (probably incorrect) assumptions here.

  1. that a normal user chooses to use OTR.
  2. that a normal user has any idea what OTR is.
  3. that a normal user knows (or cares) when OTR is working in any way (completely or partially).

The parallel to silently recording a message IRL isn't logging OTR messages, it's using OTR protect the conversation. A normal user does not know that it's happening, and will assume that all messages are the same and should all be logged the same.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 3 years ago by hellais

Replying to mathuaerknedam:

Replying to hellais:

...if the normal user engages in an OTR chat he knowns that what is happening should not be logged.

You make a few (probably incorrect) assumptions here.

  1. that a normal user chooses to use OTR.
  2. that a normal user has any idea what OTR is.
  3. that a normal user knows (or cares) when OTR is working in any way (completely or partially).

These three points are exactly why I think this behavior should be implemented. Since the normal user does not know what OTR is and how it works, when he engages in an OTR protected chat (because the other party requested it), it should not log. It's as simple as that.

Maybe it's not the most common use case, but I know a *lot* of people that depend on this technology daily to stay alive. Remember that in the world there are a lot of differently-democratic countries where it's not uncommon to have your laptop seized and be prosecuted for unjust causes. Do you not wish to help these people?

The parallel to silently recording a message IRL isn't logging OTR messages, it's using OTR protect the conversation. A normal user does not know that it's happening, and will assume that all messages are the same and should all be logged the same.

OTR stands for Off The Record messaging so the parallel is fitting (it's actually Ian Golberg himself that does this parallel in the paper describing OTR [1][2]). He will assume that they are logged, but they will not be logged because it is right that they shouldn't. When I talk to another person with OTR he should not log my conversation, it's that simple. If he assumes that it is logged he assumed wrongly and it's right that it shouldn't.

[1] http://en.wikipedia.org/wiki/Off-the-Record_Messaging

[2] http://www.cypherpunks.ca/otr/otr-wpes.pdf

Last edited 3 years ago by hellais (previous) (diff)

comment:7 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by mathuaerknedam

Replying to hellais:

Replying to mathuaerknedam:

Replying to hellais:

...if the normal user engages in an OTR chat he knowns that what is happening should not be logged.

You make a few (probably incorrect) assumptions here.

  1. that a normal user chooses to use OTR.
  2. that a normal user has any idea what OTR is.
  3. that a normal user knows (or cares) when OTR is working in any way (completely or partially).

These three points are exactly why I think this behavior should be implemented. Since the normal user does not know what OTR is and how it works, when he engages in an OTR protected chat (because the other party requested it), it should not log. It's as simple as that.

No, it's not that simple.

Maybe it's not the most common use case, but I know a *lot* of people that depend on this technology daily to stay alive. Remember that in the world there are a lot of differently-democratic countries where it's not uncommon to have your laptop seized and be prosecuted for unjust causes. Do you not wish to help these people?

Exactly. Adium strives to have defaults that serves the common case. Adium already has an option to help the special case, it's a checkbox that they can use to disable logging on their computer. The onus to ensure security is on the person who needs it.


The parallel to silently recording a message IRL isn't logging OTR messages, it's using OTR protect the conversation. A normal user does not know that it's happening, and will assume that all messages are the same and should all be logged the same.

OTR stands for Off The Record messaging so the parallel is fitting (it's actually Ian Golberg himself that does this parallel in the paper describing OTR [1][2]). He will assume that they are logged, but they will not be logged because it is right that they shouldn't. When I talk to another person with OTR he should not log my conversation, it's that simple. If he assumes that it is logged he assumed wrongly and it's right that it shouldn't.

Adium's default settings should serve the normal user. The parallel you describe is fine for for someone concerned about security, but not for a normal user. if you're suggesting changes to Adium, you need to make the changes serve the normal user. If the needs of the normal user and the special user conflict, its the special user that has to make special accommodations.

If Adium wouldn't log OTR messages, we'd probably see a lot of people disabling OTR, because they don't need OTR, and logging is more important to them. if that's the case, the reasonable default would be for Adium to have OTR disabled, but as you confirmed earlier, that reduces the default level of security for everyone. That's hardly a noble accomplishment.

Adium isn't designed to be as secure as possible. Feel free to search through our old tickets to see numerous denied request for log encryption or additional passwords. It's not useful for to argue that OTR messages simple should not be logged, and ignore that this is a disservice to the normal user. If you have ideas about how to improve security in Adium while providing defaults that serve the most common use cases, we'd love to hear them. Someone who needs more security than Adium can provide without causing problems for normal users should probably create a plugin, or perhaps a complete fork.

comment:8 Changed 3 years ago by hellais

I would also like to point to ticket #94 that described exactly this same issue, however the resolution is not congruent with the requirements:

"Perhaps there could be an option (enabled by default) to not log encrypted conversations?"

whereas what was implemented is:

"Add "Log only certain accounts", which lets you log only certain accounts, and add "Log secure chats" which (enabled by default) logs secure chats."

Also, this issue was also raised in Pidgin: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549431

Last edited 3 years ago by hellais (previous) (diff)

comment:9 in reply to: ↑ 7 Changed 3 years ago by mathuaerknedam

  • Resolution set to wontfix
  • Status changed from new to closed

Replying to mathuaerknedam:

If you have ideas about how to improve security in Adium while providing defaults that serve the most common use cases, we'd love to hear them.

The original request is being closed as wontfix, but feel free to make a ticket with suggestions under the guidelines above. Alternatively, read up on the documention for Adium's code and plugin creation. and stop by IRC if you need any help.

comment:10 follow-ups: Changed 3 years ago by kaepora

mathuaerknedam, I can't believe the level of irresponsibility you allow yourself. Your insistence on keeping an insecure-by-default option regarding a protocol built from the ground up for security is absolutely ridiculous.

OTR doesn't utilize AES-256 just so that chats can be logged insecurely by default. OTR stands for Off the Record, and the whole point of the protocol is to make chats deniable and hard to trace. Have you even read the specification? Do you have any credentials as a security researcher?

It doesn't matter if Adium is designed with security in mind or not - you are implementing a feature that centers entirely around security, and you are doing so irresponsibility and without a proper understanding of the security architecture. Bradley Manning has OTR logs testifying against him because of people with your lacking and irresponsible mindset: http://www.bradleymanning.org/updates/day-four-of-the-bradley-manning-trial-in-depth-notes-from-a-courtroom-viewer-in-bradley-mannings-article-32-hearing

You are making a huge mistake.

Last edited 3 years ago by kaepora (previous) (diff)

comment:11 in reply to: ↑ 10 Changed 3 years ago by kbotc

Replying to kaepora:

mathuaerknedam, I can't believe the level of irresponsibility you allow yourself. Your insistence on keeping an insecure-by-default option regarding a protocol built from the ground up for security is absolutely ridiculous.

OTR doesn't utilize AES-256 just so that chats can be logged insecurely by default. OTR stands for Off the Record, and the whole point of the protocol is to make chats deniable and hard to trace. Have you even read the specification? Do you have any credentials as a security researcher?

It doesn't matter if Adium is designed with security in mind or not - you are implementing a feature that centers entirely around security, and you are doing so irresponsibility and without a proper understanding of the security architecture. Bradley Manning has OTR logs testifying against him because of people with your lacking and irresponsible mindset: http://www.bradleymanning.org/updates/day-four-of-the-bradley-manning-trial-in-depth-notes-from-a-courtroom-viewer-in-bradley-mannings-article-32-hearing

You are making a huge mistake.

Fork the project and implement the changes. We base our decision on previous contact with users, and our own personal preference. OTR is useful for securing the transmission on the wire and it's quite good at that. On the other hand, we can not ever guarantee that your messages are not going to be written to disk once we decrypt them. We add it to a webkit view for goodness sake; It's going to get paged to the hard drive somewhere at some point. Security through obscurity does not make true security. If you want secure communication, you should try something written from the ground up for security.

In summary: we are not interested in implementing this bug request, and it's not a huge mistake. Please keep politics and ongoing court cases out of the bug tracker.

comment:12 in reply to: ↑ 10 ; follow-up: Changed 3 years ago by zx

Replying to kaepora:

mathuaerknedam, I can't believe the level of irresponsibility you allow yourself. Your insistence on keeping an insecure-by-default option regarding a protocol built from the ground up for security is absolutely ridiculous.

OTR doesn't utilize AES-256 just so that chats can be logged insecurely by default. OTR stands for Off the Record, and the whole point of the protocol is to make chats deniable and hard to trace. Have you even read the specification? Do you have any credentials as a security researcher?

It doesn't matter if Adium is designed with security in mind or not - you are implementing a feature that centers entirely around security, and you are doing so irresponsibility and without a proper understanding of the security architecture. Bradley Manning has OTR logs testifying against him because of people with your lacking and irresponsible mindset: http://www.bradleymanning.org/updates/day-four-of-the-bradley-manning-trial-in-depth-notes-from-a-courtroom-viewer-in-bradley-mannings-article-32-hearing

You are making a huge mistake.

kaepora, I understand where you're coming from - however to quote hellais's link (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549431)

That's not the whole point of OTR. See http://www.cypherpunks.ca/otr/
and http://www.cypherpunks.ca/otr/otr-codecon.pdf
It's perfectly valid to log OTR conversations since whatever is logged can be denied.

More discussion on this matter here: http://cryptome.org/0005/lamo-brad-otr.htm

To the majority of people, this isn't a issue. However, you can very easily just symlink your Adium Logs to a AES-256 encrypted image that de-mounts upon logging out.

Last edited 3 years ago by zx (previous) (diff)

comment:13 in reply to: ↑ 12 ; follow-up: Changed 3 years ago by kaepora

Replying to zx:

kaepora, I understand where you're coming from - however to quote hellais's link (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549431)

That's not the whole point of OTR. See http://www.cypherpunks.ca/otr/
and http://www.cypherpunks.ca/otr/otr-codecon.pdf
It's perfectly valid to log OTR conversations since whatever is logged can be denied.

This isn't about deniability - this is about sensitive and private information that warranted encryption in the first place being logged by default''

More discussion on this matter here: http://cryptome.org/0005/lamo-brad-otr.htm

To the majority of people, this isn't a issue. However, you can very easily just symlink your Adium Logs to a AES-256 encrypted image that de-mounts upon logging out.

Yeah, symlinking encrypted disk images is so much a more elegant solution than unchecking a check-box by default!

Last edited 3 years ago by kaepora (previous) (diff)

comment:14 Changed 3 years ago by akuckartz

I am not a user of Adium (and having seen the "closed defect: wontfix" I certainly will warn against using it) but I have a question:

Does it log what the other side has transmitted?

If yes I suggest that you read this:
http://xmpp.org/extensions/xep-0136.html#otr-nego
and this:
http://xmpp.org/extensions/xep-0136.html#security-autoon

BTW: OTR stands for "Off-the-Record" and logs obviously are some kind of record.

comment:15 in reply to: ↑ 13 Changed 3 years ago by zx

Replying to kaepora:

Replying to zx:

kaepora, I understand where you're coming from - however to quote hellais's link (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549431)

That's not the whole point of OTR. See http://www.cypherpunks.ca/otr/
and http://www.cypherpunks.ca/otr/otr-codecon.pdf
It's perfectly valid to log OTR conversations since whatever is logged can be denied.

This isn't about deniability - this is about sensitive and private information that warranted encryption in the first place being logged by default''

More discussion on this matter here: http://cryptome.org/0005/lamo-brad-otr.htm

To the majority of people, this isn't a issue. However, you can very easily just symlink your Adium Logs to a AES-256 encrypted image that de-mounts upon logging out.

Yeah, symlinking encrypted disk images is so much a more elegant solution than unchecking a check-box by default!

Your argument is invalid. Enabling it by default only applies to a *very* small percentage of Adium users, such as activists (or in this case Bradley Manning). If the end user was transmitting data that was deemed 'sensitive and private information', they should already be looking out for their best interest, and taking the correct steps to protect this information (by enabling this option manually).

Your traditional user has no reason to worry about OTR conversations storing logs, as they are not transferring information that could land them in indefinite detention.

Practical OTR usage: I prefer not to have my conversations logged on AOL servers, however I still like to reference previous convos that are stored on my *own* hard drive.

comment:16 Changed 3 years ago by sphynx

Replying to akuckartz:

I am not a user of Adium (and having seen the "closed defect: wontfix" I certainly will warn against using it) but I have a question:

Does it log what the other side has transmitted?

If yes I suggest that you read this:
http://xmpp.org/extensions/xep-0136.html#otr-nego
and this:
http://xmpp.org/extensions/xep-0136.html#security-autoon

BTW: OTR stands for "Off-the-Record" and logs obviously are some kind of record.

This has been an interesting discussion to read, though I agree with mathuaerknedam that we should not change the default. But you're confusing two things here: XEP-0136 has nothing to do with the end-to-end encryption that's called "OTR".

From that site:

  1. The "OTR" mode for message archiving is not to be confused with the "OTR" technology for "off-the-record communications" described at <http://www.cypherpunks.ca/otr/>.

I could see Adium adoption a protocol that requests the other side not to log a conversation (as is kind of done in that XEP), and I could see that coupled with end-to-end encryption ("start a private chat and ask other party not to log it", or something shorter). But right now, users are in control of what is logged for them, and changing that is going to piss off a lot of people.

Last edited 3 years ago by sphynx (previous) (diff)

comment:17 Changed 3 years ago by kbotc

Replying to akuckartz:

I am not a user of Adium (and having seen the "closed defect: wontfix" I certainly will warn against using it) but I have a question:

Does it log what the other side has transmitted?

If yes I suggest that you read this:
http://xmpp.org/extensions/xep-0136.html#otr-nego
and this:
http://xmpp.org/extensions/xep-0136.html#security-autoon

BTW: OTR stands for "Off-the-Record" and logs obviously are some kind of record.

That's an entirely separate issue, and one that should go in a separate ticket. This is about encryption and logging, that's about supporting an XMPP extension. You also have to consider that not every client will respect your desire to turn off logging if we support XEP-0136.

comment:18 follow-up: Changed 3 years ago by dtauerbach

Logging need not be either on or off by default. There is a useful alternative that is worthwhile to explore: the first time a user uses OTR, the user could be forced to affirmatively choose either to log or not to log the conversation. No default, users' education about OTR is increased, everybody wins. If you could re-open this ticket to explore this avenue, that'd be great, or I can open a new ticket. If there is no response I will do the latter.

comment:19 Changed 3 years ago by akuckartz

Replying to kbotc:

You also have to consider that not every client will respect your desire to turn off logging if we support XEP-0136.

Well, my conclusion from this discussion and the bug "resolution" is that Adium can not be trusted. Other XMPP clients should try to warn users when they detect that they are communicating with Adium clients.

comment:20 Changed 3 years ago by kbotc

*sigh* I'm just going to copy and paste this: "normal users don't engage in OTR. OTR happens to their chat." This is why we're going to use the default setting (Log messages) whenever OTR pops on for the time being. This ticket is not productive. dtauerbach has a reasonable idea and may be pursued further, but the ticket is closed with this resolution because we do not intend on changing the setting as requested by the original poster.

comment:21 in reply to: ↑ 18 Changed 3 years ago by theresaanna

Replying to dtauerbach:

Logging need not be either on or off by default. There is a useful alternative that is worthwhile to explore: the first time a user uses OTR, the user could be forced to affirmatively choose either to log or not to log the conversation. No default, users' education about OTR is increased, everybody wins. If you could re-open this ticket to explore this avenue, that'd be great, or I can open a new ticket. If there is no response I will do the latter.

IIRC, you receive a notification each time you enable/disable OTR. A first time use force set of the option makes sense, but why not also simply display a message each time the feature is enabled? "OTR chat is enabled. Chat logging of OTR conversations is [off/on]. To switch it [off/on]..."

Most people will ignore it, but those who need ultimate privacy will be alerted to the existence of the feature regardless of whether another user had enabled OTR chat prior on the Adium instance in question, therefore passing the first time use alert. It will also remind the user to make sure it fits their current needs. Discussion about edge cases is premature when I'd bet the vast majority of users aren't even aware of this setting in the first place.

comment:22 Changed 3 years ago by dtauerbach

I have opened a new ticket here, for those who want to follow: #15729. I hope the discussion stays civil, and we can come to a consensus that makes everyone happy.

Note: See TracTickets for help on using tickets.