On Wed, Sep 4, 2013 at 2:00 PM, Dominik George <email@example.com> >wrote:
I strongly object to the conclusion you came to.
Indeed. There seems to be a misconception among some users that
"secure" actually means "volatile". Worse, it is often assumed as a
result that "volatile" means "secure". This can have grave
Remember how Adium, ignoring Cyberpunk's recommendation to turn off
logging for OTR sessions, helped incriminating Bradley Manning
he was used to sane security settings from other clients ?
I guess the main problem I see with this whole thing is the
amalgamation of two separate things:
1. The readability of your messages over the network
2. Their availability for later reading by potentially non-trusted
They are separate things and any combination of them is possible in
1. When you talk to your bank you you'd care about the network
protection of your messages but you wouldn't necessarily be protecting
from a judiciary search warrant. In that case you may have good
reasons to want to preserve the content of the conversations (and you
may also want to additionally encrypt your drive).
2. When you are talking to your secret lover secretly from your
spouse, you'd likely prefer for history not to be stored but you
wouldn't necessarily care about network encryption. As a matter of
fact you might explicitly prefer it to be off so that you could also
follow the conversation from a different client (e.g. facebook).
3. When you are whistle-blowing on your government you are very likely
to want your chats encrypted. You are also likely to want to remove
history logs ... at some point. Not necessarily immediately though.
So again, there are different configurations possible out there and it
is important that users can easily navigate through them. I have
repeatedly said that we are going to work on improving the indication
of the fact that history is on (don't count on a big red warning
though) and the possibility to turn it off.
As far as the default is concerned, it currently represents what we
believe to be the best compromise.
I have personally seen a lot more evidence of the opposite problem.
Users are quite frustrated when a few minutes after a window was
closed they needed to get back to the content of their conversation
(e.g. to retrieve a phone number or other information that was
exchanged during the chat) but only found out that it was no longer
Please understand that this is an *very* common case and that it
happens *substantially* more often than security compromises.
And has it ever appearead to you that 1 serious security compromise
have a far bigger impact than 100 lost chat histories? Seriously,
loosing a chat history might upset a single user, but it does not
any purpose apart from adding to the user's convenience.
Losing information can have consequences that are just as dire and
undesirable as failing to protect it. In this case for example, I
really don't care how many people get to read this message before it
hits your mailbox. However I wouldn't like it to be lost in the
If someone sends me important information over OTR, chances that I'd
need that information later are a lot higher than the chances that
this information may become the reason for a search warrant.
Finally, to end on an example of a Bradley-Manning scale,
pharmaceutical researchers that have a discussion which leads to the
discovery of a cancer-curing molecule are extremely likely to want to
keep their discussion logged for later (and potentially so would
humanity) even if they wanted to keep the communication private at the
time it took place.
So again, these are two different things and they should be controlled
and indicated separately.
I am absolutely sure that Bradley Manning would have happily
reconstructed his chats from his mind should that be necessary than
being incriminated by accidentally created chatllogs.
As a security provider, you are taking responsibility for users to
good decisions. Auto-enabling logging is not a good decision.
> Therefore, I would like to make the point (and plea) to switch
> chat history"-setting off by default, or at least make it
> on for unencrypted chats, default off for OTR.
We are not going to do this.
I kindly request
Kind request? Where?
I've only seen an angry demand. Rather offensive actually.
you to hand this decision to the community.
I will happily create a vote somewhere.
That could be very useful if we ever had a way of making sure that a
majority or at least a very representative minority of Jitsi's
potential and current users would take part. I don't see how this
But IMHO this is not a decision you
should make on your own.
The very fact that we are having this discussion and that changes to
Jitsi will happen as a result is a good indication of an open process.
However people have different lives and different priorities and at
some point someone (or something) needs to call a decision. For
various reasons, in the Jitsi instance hosted by jitsi.org this
happens to be me.
If you feel that you or a different entity would do better at this
process (and I generally don't consider this possibility unlikely at
all) then forking Jitsi is a matter of a button click on GitHub.
* It is always possible to delete a chat after a user accidentally
neglected to turn off history
Will you educate the users about how to securely erase data from
machines, and will you do so in a prominent enough way?
No, I was thinking that we could simply add an option in the newly
added chat button/menu that would allow users to erase history from
within the chat window.
* it is impossible to restore a chat after a user accidentally
neglected to turn on history
Keep it in memory until Jitsi is quit.
You seem to be comfortable handing tasks our way (... or should I
say my way?)
* jitsi is a rich client. It is not a cloud service. Your chats are
kept only on your local device
I hope so. When implementing XEP-0136, please do NOT ignore section
When and if we choose to implement XEP-0136 we will take this into
the way you are ignoring this issue .
We are disagreeing, not ignoring. Given your strong accusations about
my "exaggerations", I would have expected you to be more careful with
So once again: not keeping a log does not in any way imply security
lack thereof and claiming the opposite could be quite dangerous.
Didn't you just revert your point above? Didn't you just say that
the record" means "not logged"?
No I don't think I have contradicted my point above. What I was saying
was that the presence or absence of logs is not imply a secure
context. It would all depend on the use case and we have chosen a
policy that we believe would be the best compromise for the use cases
we are encountering.
We have also agreed to work on improving general awareness.
> Granted, it's not OTR's business to take care of what happens to
> securely transmitted messages.
Indeed, it is not.
Beat me if I'm wrong,
Why would I want to do that?
but I am absolutely certain that some document
over at Cyberpunks actually recommends that OTR chats are not logged
clients, I readthat some time ago. I couldn't find that document when
looked for it, however.
That's OK. I can see how there could be recommendations for
considering this option (which is what we are doing).
In order to make this less of a problem, we are going to make it
visible when chats are logged so that users can turn history off. We
would be happy to have a discussion on the best ways of doing this
this is the only direction we are willing to take.
Again, please do not say "we" when you really mean "I".
I actually do mean "we". It happens that I am the lead of the project
and I do believe I speak for most of the developers that actively work
on it. (Those who do not agree are of course welcome to speak up)
Of course this "we" does not mean "you" so I don't think you need to
worry that I am misrepresenting your opinion.
If Jitsi is your
project and you alone decide where it goes,
Already answered this above.
please do not call it free
Linus Torvalds is known for saying that "open source is not a
democracy". Meritocracy is often used instead but even this is not
I do believe that we are being open about this. We are having this
discussion and we have accepted to do something about the problem.
I don't believe your accusations are fair.
I suggest implementing it the other way round:
When OTR is enabled, auto-disable logging and place a prominent note
about that in the chat window.
Moreover, when OTR is enabled *and* the other chat party re-enables
logging, place a *VERY* prominent warning about that in the chat
Having the other party log an encrypted chat is a privacy and
breach that has to be clearly visible!
That would have been extremely neat if only there was a *reliable* way
of always telling when the remote party is recording something.
Hope this clarifies things a bit.
It does, but not in the way you intended.
Or did you mean: not in the way you would have liked it?
* concerning Mozilla code leaking assertion failures to tty without
<mirabilos> That means, D-BUS is a tool that makes software look
than it actually is.
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
users mailing list
Unsubscribe instructions and other list options:
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
firstname.lastname@example.org PHONE: +188.8.131.52.43.30
https://jitsi.org FAX: +184.108.40.206.47.31
users mailing list
Unsubscribe instructions and other list options: