[kopete-devel] Enable OTR plugin by default?

Hello everyone,

We have 2 whishes in bko [1][2] for enabling the OTR plugin by default in
kopete. As I use it anyways I would obviously support this.

What is your opinion? Am I allowed to enable it or should I close the whishes
as WONTFIX?

Cheers,
Michael

[1] https://bugs.kde.org/show_bug.cgi?id=188121
[2] https://bugs.kde.org/show_bug.cgi?id=202899




_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Sunday 27 September 2009 14:26:55 Michael Zanetti wrote:

> Hello everyone,
>
> We have 2 whishes in bko [1][2] for enabling the OTR plugin by default in
> kopete. As I use it anyways I would obviously support this.
>
> What is your opinion? Am I allowed to enable it or should I close the
>  whishes as WONTFIX?
>
> Cheers,
> Michael
>
> [1] https://bugs.kde.org/show_bug.cgi?id=188121
> [2] https://bugs.kde.org/show_bug.cgi?id=202899
>

If enabled by default, what sort of ramifications does this have for the
"normal" user (aka one that doesn't use OTR)
--
Matt


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Sunday 27 September 2009 21:40:07 Matt Rogers wrote:
> If enabled by default, what sort of ramifications does this have for the
> "normal" user (aka one that doesn't use OTR)
>

Visually the plugin adds a toolbar icon for starting/ending encrypted
sessions.

The default behaviour of the plugin is to auto-detect the other ends OTR
capabilities and encrypt chat-sessions if possible. That means, a user will
see internal messages telling him about the encryption state of the chat
session as soon he talks to someone using OTR too. He won't see that if none
of his contacts is capable or OTR encryption.

There are little 2 caveats though.
- The first time an encrypted session is established a key needs to be
generated. The plugin does this on his own but the user will be faced with a
popup telling him to wait until the process is finished (10 - 40 sec).
- If the other end terminates the encrypted session the local user needs to
end or refresh the session manually (2 clicks) before he is able to send
messages to that user again.

In short, if a user has no contacts using OTR he won't notice the plugin at
all except for the icon in the toolbar. If a user has contacts using OTR he
most likely needs to interact with the plugin sooner or later.


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

> - If the other end terminates the encrypted session the local user needs to
> end or refresh the session manually (2 clicks) before he is able to send
> messages to that user again.

I think this is pretty bad, is there any reason why the user needs to
end/refresh the session manually aside from it being not implemented
as an automated thing?
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

Am Sonntag, 27. September 2009 21:26:55 schrieb Michael Zanetti:

> What is your opinion? Am I allowed to enable it or should I close the
>  whishes as WONTFIX?

You should first make the second one a dupe of the first one. :-)
I fully support activating the plugin by default, provided that a) sessions
end automatically (as requested by another person) and b) IMHO key generation
should happen in the background after a new account has been created.
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Sunday 27 September 2009 22:17:34 Benson Tsai wrote:
> > - If the other end terminates the encrypted session the local user needs
> > to end or refresh the session manually (2 clicks) before he is able to
> > send messages to that user again.
>
> I think this is pretty bad, is there any reason why the user needs to
> end/refresh the session manually aside from it being not implemented
> as an automated thing?


Ending a session automatically would result in a security risk. Immagine you
are chatting to someone in an encrypted session and write some private content
which you do not want to be sent in clear-text over the network. If the other
end terminates the encrypted session just before you are hitting enter your
text would be sent out unencrypted over the network. That means you are no
longer in full control over the encryption status of the messages.

Automatically ending encrypted sessions is not intended by the OTR protocol
specification and I strongly advice to not change that.


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Sunday 27 September 2009 22:32:39 Markus wrote:
> Am Sonntag, 27. September 2009 21:26:55 schrieb Michael Zanetti:
> > What is your opinion? Am I allowed to enable it or should I close the
> >  whishes as WONTFIX?
>
> You should first make the second one a dupe of the first one. :-)

Of course. I just wanted to leave them open both until this discussion is over
to show that there is actually more than one person requesting this :)

> I fully support activating the plugin by default, provided that a) sessions
> end automatically (as requested by another person) and b) IMHO key
>  generation should happen in the background after a new account has been
>  created.

Generating the key in the background is actually a good idea. I will have a
look at this...

Please see my other mail explaining why automatically ending chat session is a
bad thing.


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Sun, 27 Sep 2009 21:26:55 +0200, Michael Zanetti  
<michael_zanetti@...> wrote:

> Hello everyone,

Hi,

> We have 2 whishes in bko [1][2] for enabling the OTR plugin by default in
> kopete. As I use it anyways I would obviously support this.
>
> What is your opinion? Am I allowed to enable it or should I close the  
> whishes
> as WONTFIX?
>
> Cheers,
> Michael
>
> [1] https://bugs.kde.org/show_bug.cgi?id=188121
> [2] https://bugs.kde.org/show_bug.cgi?id=202899
>

there's bug in OTR plugin which removes all rich text styles when OTR  
plugin is enabled
but the session isn't encrypted. So until that isn't fixed I'm against  
enabling it by default.

Regards,
Roman





_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

Michael Zanetti wrote:

> On Sunday 27 September 2009 22:17:34 Benson Tsai wrote:
>> > - If the other end terminates the encrypted session the local user
>> > needs to end or refresh the session manually (2 clicks) before he is
>> > able to send messages to that user again.
>>
>> I think this is pretty bad, is there any reason why the user needs to
>> end/refresh the session manually aside from it being not implemented
>> as an automated thing?
>
>
> Ending a session automatically would result in a security risk. Immagine
> you are chatting to someone in an encrypted session and write some private
> content which you do not want to be sent in clear-text over the network.
> If the other end terminates the encrypted session just before you are
> hitting enter your text would be sent out unencrypted over the network.
> That means you are no longer in full control over the encryption status of
> the messages.
>
> Automatically ending encrypted sessions is not intended by the OTR
> protocol specification and I strongly advice to not change that.

Automatically ending encrypted sessions might be a security risk as long as
the user is still online. But the OTR session should be definitely be ended
as soon as the other contact or me goes offline. I'm quite often confronted
with that situation that i don't remember to quit the OTR session after
another contact went offline or to restart it after i went offline and
connected again, which leads to undecryptable messages.


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Monday 28 September 2009 11:58:40 Roman Jarosz wrote:
> On Sun, 27 Sep 2009 21:26:55 +0200, Michael Zanetti
> there's bug in OTR plugin which removes all rich text styles when OTR
> plugin is enabled
> but the session isn't encrypted. So until that isn't fixed I'm against
> enabling it by default.
>

Hmmm... I thought I'd fixed that one... Will check again...


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Monday 28 September 2009 15:18:57 Michael Zanetti wrote:
> On Monday 28 September 2009 11:58:40 Roman Jarosz wrote:
> > On Sun, 27 Sep 2009 21:26:55 +0200, Michael Zanetti
> > there's bug in OTR plugin which removes all rich text styles when OTR
> > plugin is enabled
> > but the session isn't encrypted. So until that isn't fixed I'm against
> > enabling it by default.
>
> Hmmm... I thought I'd fixed that one... Will check again...
>

OK... I think I have really fixed that now. It should now be possible to send
rich text regardless of the state of the OTR plugin, even through encrypted
sessions.

It would be nice if some of you could test the otr plugin from latest trunk in
terms of rich text handling as it is not really easy to fully test this with
all the different clients and protocols for a single person. I have tested it
successfully with XMPP and ICQ so far.

During testing I noticed that I the jabber protocol (with OTR-plugin disabled)
doesn't seem to be able to send rich text. (It is now possible through
encrypted sessions though :)


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Monday 28 September 2009 14:26:15 Florian Reinhard wrote:

> Michael Zanetti wrote:
> > On Sunday 27 September 2009 22:17:34 Benson Tsai wrote:
> >> > - If the other end terminates the encrypted session the local user
> >> > needs to end or refresh the session manually (2 clicks) before he is
> >> > able to send messages to that user again.
> >>
> >> I think this is pretty bad, is there any reason why the user needs to
> >> end/refresh the session manually aside from it being not implemented
> >> as an automated thing?
> >
> > Ending a session automatically would result in a security risk. Immagine
> > you are chatting to someone in an encrypted session and write some
> > private content which you do not want to be sent in clear-text over the
> > network. If the other end terminates the encrypted session just before
> > you are hitting enter your text would be sent out unencrypted over the
> > network. That means you are no longer in full control over the encryption
> > status of the messages.
> >
> > Automatically ending encrypted sessions is not intended by the OTR
> > protocol specification and I strongly advice to not change that.
>
> Automatically ending encrypted sessions might be a security risk as long as
> the user is still online. But the OTR session should be definitely be ended
> as soon as the other contact or me goes offline. I'm quite often confronted
> with that situation that i don't remember to quit the OTR session after
> another contact went offline or to restart it after i went offline and
> connected again, which leads to undecryptable messages.
>

I, on the other hand, am often faced to the situation tha a user goes offline
and comes back online immediately. For example he had a temporary disconnect
because of poor WLAN reception or suspended the laptop to move to another
room. If the otr session gets terminated we a) still have the security issue
as you might not realize the session was ended in the meantime and b) it would
be really annoying because the session has to be refreshed while it wouldn't
be neccessary because both parts still have a valid key.

I do not really understand what it's the problem with manually
ending/refreshing the otr session. It's 2 clicks once in a while. Other IM's
also discard the message you were typing in an ended OTR session. In Kopete's
OTR plugin I already addressed this annoyance by keeping the message in the
input area in case it couldn't be sent. And It doesn't really happen that
often that one has to refresh the session manually.

All other solutions really decrease security. There IS a reason why the OTR
protocol was specified that way. And I won't change that just to save 2 klicks
while decreasing security.

And in terms of undecrytable messages. OTR plugins recognize undecryptable
messages and request a retransmission immediately after automatically
refreshing the session. It really happens rarely that a message is
undecryptable and not recoverable.
Oh, and automatically ending the session when a user goes offline would make
this exact problem worse instead of better. Because when you end a session
when the other user is offline, the other one doesn't realize that the session
was endet and will 100% sure send you an undecryptable message next time if he
hadn't closed his IM client in the meantime.


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

Am Dienstag, 29. September 2009 11:07:42 schrieb Michael Zanetti:

> I do not really understand what it's the problem with manually
> ending/refreshing the otr session. It's 2 clicks once in a while.

May I clarify the issue:
While indeed just 2 clicks away, those two clicks are anything but obvious.
IIRC the printed message just says: "OTR session closed. You should close it
as well."
I'm hardly a novice user, but after I read that message for the first time, I
actually thought that means close the window.
Then I tried to figure out where to close the OTR session and it took me a
while to find it.

IMHO there are two approaches how to make it more easy -- one probably easier
to implement way and one IMHO more elegant way:

Easy way: A dialog window that pops up after my peer ended the OTR chat and I
close the chat window that asks me to end the OTR session as well.
Similarly, a dialog window could pop up to ask for renewing a session.

Elegant way: Dialog windows are evil, usability-wise. I once saw an instant
messenger (forgot which one it was) that displayed buttons inside the
conversation area. That was pretty neat. Those buttons were in that IM's case
only used for file transfer requests, but the idea can be used for OTR as well
(behold my horrible ascii art skills):


_____________________________________________________
| Buddy: Hey, I need to go off now. Bye!
|
| Me: Alright, cya.
|
| "Buddy" ended the encrypted chat session.
| You should end it as well...._____________
|........................................ | End Session | <-- This is a button
|_______________________----------------------- ________________|
| [ Text input area ]
|____________________________________________________|
|____________________________________________| Send |__|

I don't know if that's currently even possible without too much trouble, but I
think that could be a good approach without compromising security (by doing
things automatically that shouldn't be done automatically) and easy
discoverable security measures.


Markus

_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Tuesday 29 September 2009 13:33:11 Markus wrote:

> Am Dienstag, 29. September 2009 11:07:42 schrieb Michael Zanetti:
> > I do not really understand what it's the problem with manually
> > ending/refreshing the otr session. It's 2 clicks once in a while.
>
> May I clarify the issue:
> While indeed just 2 clicks away, those two clicks are anything but obvious.
> IIRC the printed message just says: "OTR session closed. You should close
>  it as well."
> I'm hardly a novice user, but after I read that message for the first time,
>  I actually thought that means close the window.
> Then I tried to figure out where to close the OTR session and it took me a
> while to find it.
>

OK. I agree that could take some seconds on the first time.

> IMHO there are two approaches how to make it more easy -- one probably
>  easier to implement way and one IMHO more elegant way:
>
> Easy way: A dialog window that pops up after my peer ended the OTR chat and
>  I close the chat window that asks me to end the OTR session as well.
>  Similarly, a dialog window could pop up to ask for renewing a session.
>

Popups... No way! However, the overall idea is quite good...

> Elegant way: Dialog windows are evil, usability-wise. I once saw an instant
> messenger (forgot which one it was) that displayed buttons inside the
> conversation area. That was pretty neat. Those buttons were in that IM's
>  case only used for file transfer requests, but the idea can be used for
>  OTR as well (behold my horrible ascii art skills):
>
>
> _____________________________________________________
>
> | Buddy: Hey, I need to go off now. Bye!
> |
> | Me: Alright, cya.
> |
> | "Buddy" ended the encrypted chat session.
> | You should end it as well...._____________
> |........................................ | End Session | <-- This is a
> | button _______________________----------------------- ________________|
> | [ Text input area ]
> |____________________________________________________|
> |____________________________________________| Send |__|
>
> I don't know if that's currently even possible without too much trouble,
>  but I think that could be a good approach without compromising security
>  (by doing things automatically that shouldn't be done automatically) and
>  easy discoverable security measures.
>
>

Very nice proposal! Kopete also uses buttons in the chat-window for file
transfers. I think it souldn't be too hard to adapt that for the OTR plugin.
I'll check that out in detail and come to you.

Thanks,
Michael



_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

Hi,

During the discussion if it is a good idea to enable the OTR plugin by default
Markus came up with the suggestion that instead of just displaying a message
that one should end or refresh the session we could offer two buttons directly
in the message. This way, the user doesn't have to search for the ToolBar ->
OTR -> End/Refresh session button.

On Tuesday 29 September 2009 13:33:11 Markus wrote:

>
> Elegant way: Dialog windows are evil, usability-wise. I once saw an instant
> messenger (forgot which one it was) that displayed buttons inside the
> conversation area. That was pretty neat. Those buttons were in that IM's
>  case only used for file transfer requests, but the idea can be used for
>  OTR as well (behold my horrible ascii art skills):
>
>
> _____________________________________________________
>
> | Buddy: Hey, I need to go off now. Bye!
> |
> | Me: Alright, cya.
> |
> | "Buddy" ended the encrypted chat session.
> | You should end it as well...._____________
> |........................................ | End Session | <-- This is a
> | button _______________________----------------------- ________________|
> | [ Text input area ]
> |____________________________________________________|
> |____________________________________________| Send |__|
>
> I don't know if that's currently even possible without too much trouble,
>  but I think that could be a good approach without compromising security
>  (by doing things automatically that shouldn't be done automatically) and
>  easy discoverable security measures.
>
>

I have checked that out now... It is not possible right now for a plugin to
display PushButtons in the chatwindow other than FileTransfers and VoiceClips.

AFAICS we would need the following changes to make that possible:
- Introduce a new MessageType "CustomQuestion" or something like that.
- Extend Kopete::Message to be able to transport button names
- Make ChatWindowPart and KopeteChatWindowStyle capable to display those
questions (including reading Theme files etc.)
- emit a signal containing the Message::id() and the selected answer from the
ChatWindowPart through the current ChatSession and connect it to the plugins
slot

A plugin could then create an incoming message of Type CustomQuestion and
custom buttons (Yes/No or End/Refresh) and handle the result in a slot.

Would this be possible to realize or am I missing something? And would such a
mechanism be desired/accepted in kopete? I think I could implement this with
some little help/feedback from people deeper involved into kopete's
development.

Cheers
Michael


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

Am Dienstag, 29. September 2009 18:16:57 schrieb Michael Zanetti:

> I have checked that out now... It is not possible right now for a plugin to
> display PushButtons in the chatwindow other than FileTransfers and
>  VoiceClips.

Hmmm.... I believe plugins are capable to modify the HTML source code of the
chat windows (how else would e.g. the Image Preview plugin work?) so I guess
adding a HTML-based button should also work.
No idea if Kopete can interpret those button clicks, though...
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

[Olivier Goffart]

Le Tuesday 29 September 2009, Michael Zanetti a écrit :
> Hi,
>
> During the discussion if it is a good idea to enable the OTR plugin by
>  default Markus came up with the suggestion that instead of just displaying
>  a message that one should end or refresh the session we could offer two
>  buttons directly in the message. This way, the user doesn't have to search
>  for the ToolBar -> OTR -> End/Refresh session button.
[...]
> I have checked that out now... It is not possible right now for a plugin to
> display PushButtons in the chatwindow other than FileTransfers and
>  VoiceClips.
>
> AFAICS we would need the following changes to make that possible:
> - Introduce a new MessageType "CustomQuestion" or something like that.

Internal message type should work.

> - Extend Kopete::Message to be able to transport button names

Some special HTML tag with given class could do the job.

> - Make ChatWindowPart and KopeteChatWindowStyle capable to display those
> questions (including reading Theme files etc.)

Indeed, buttons should be stylable. (CSS should help)

> - emit a signal containing the Message::id() and the selected answer from
>  the ChatWindowPart through the current ChatSession and connect it to the
>  plugins slot

Yes, thats the most important missing part.

> A plugin could then create an incoming message of Type CustomQuestion and
> custom buttons (Yes/No or End/Refresh) and handle the result in a slot.
>
> Would this be possible to realize or am I missing something? And would such
>  a mechanism be desired/accepted in kopete? I think I could implement this
>  with some little help/feedback from people deeper involved into kopete's
>  development.

I think this is a great idea and that you should do it.
Having interaction dirrectly on the chatwindow is probably better than popup
for many things.

--
Gof
_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel

On Wednesday 30 September 2009 00:15:40 Olivier Goffart wrote:
> Le Tuesday 29 September 2009, Michael Zanetti a écrit :

> > AFAICS we would need the following changes to make that possible:
> > - Introduce a new MessageType "CustomQuestion" or something like that.
>
> Internal message type should work.

Do you mean the existing MessageDirection::Internal or a newly defined
MessageType::TypeInternal ?

It seems both would be possible. So perhaps it would be better to stick with
MessageDirection::Internal, right?

>
> > - Extend Kopete::Message to be able to transport button names
>
> Some special HTML tag with given class could do the job.
>

I'm having trouble with this one. All tags like <input>, <button> etc are
discarded when calling msg.setHtmlBody().

Any hints how to inject something like <input type=\"button\" id=\"foo\"
value=\"bar\">?

> > - Make ChatWindowPart and KopeteChatWindowStyle capable to display those
> > questions (including reading Theme files etc.)
>
> Indeed, buttons should be stylable. (CSS should help)
>
> > - emit a signal containing the Message::id() and the selected answer from
> >  the ChatWindowPart through the current ChatSession and connect it to the
> >  plugins slot
>
> Yes, thats the most important missing part.
>

Yep... I think no problems here...

> > A plugin could then create an incoming message of Type CustomQuestion and
> > custom buttons (Yes/No or End/Refresh) and handle the result in a slot.
> >
> > Would this be possible to realize or am I missing something? And would
> > such a mechanism be desired/accepted in kopete? I think I could implement
> > this with some little help/feedback from people deeper involved into
> > kopete's development.
>
> I think this is a great idea and that you should do it.
> Having interaction dirrectly on the chatwindow is probably better than
>  popup for many things.
>

Thanks,
Michael


_______________________________________________
kopete-devel mailing list
kopete-devel@...
https://mail.kde.org/mailman/listinfo/kopete-devel