[jitsi-users] Group chat privacy?


#1

I recently installed jitsi to evaluate it as an alternative to skype but I
have run into one serious issue/confusion involving chatrooms. I signed up
using the jit.si service and had a one on one chat going when I clicked the
"invite" icon to invite another person to the chat. This worked as expected
and the person I invited joined the chat. What surprised me was that random
people who I had not invited started joining the chat! Jitsi never warned
me that by adding a person to the chat that I was making it public! I did
not even know that jitsi supported public chatrooms but now this makes me
question what is or isn't private when using jitsi since the application
never warned or was explicit about it.

This experience leads me to a few questions:

Is it possible to have private group chats?
Why didn't jitsi warn me that I was making my conversation public?
Are chats between two people even private?
Are group calls private? Or when I add a third person to a call does the
call become public for anybody to join like the chats?

This experience makes me very unsure about continuing to use jitsi since I
am not sure that I can "trust" it after it silently made my communications
public without warning. Are my misgivings unfounded because I am missing
something about the way jitsi/xmpp is supposed to work? Was my assumption
that adding a person to a chat via the "invite" button would keep the chat
private unreasonable?

Thanks,
Andrew


#2

I recently installed jitsi to evaluate it as an alternative to
skype but I have run into one serious issue/confusion involving
chatrooms. I signed up using the jit.si <http://jit.si> service and
had a one on one chat going when I clicked the "invite" icon to
invite another person to the chat. This worked as expected and the
person I invited joined the chat. What surprised me was that random
people who I had not invited started joining the chat! Jitsi never
warned me that by adding a person to the chat that I was making it
public! I did not even know that jitsi supported public chatrooms
but now this makes me question what is or isn't private when using
jitsi since the application never warned or was explicit about it.

This experience leads me to a few questions:

Is it possible to have private group chats?

Yes, the XMPP specifications allow private group conversations

Why didn't jitsi warn me that I was making my conversation public?
Are chats between two people even private?

Yes they are, and when you click the lock-icon and verify the
fingerprint over a secure channel its even end to end encrypted,
meaning that nobody but you and your partner is able to read the
messages at all (well untill there are quantum computers)

Are group calls private? Or when I add a third person to a call
does the call become public for anybody to join like the chats?

No, they do not becompe public but depending on the exact technology
used they might not be end to end encrypted anymore.

This experience makes me very unsure about continuing to use jitsi
since I am not sure that I can "trust" it after it silently made
my communications public without warning. Are my misgivings
unfounded because I am missing something about the way jitsi/xmpp
is supposed to work? Was my assumption that adding a person to a
chat via the "invite" button would keep the chat private
unreasonable?

This is just a bug in my opinion, XMPP does allow public chatrooms and
chatrooms are public by default but i think jitsi change its behaviour.

Thanks, Andrew

- --
Yannik V�lker

···

Am 18.07.2013 17:49, schrieb Andrew:


#3

Hey Andrew,

It sounds like you created a chat room. Those are public by default and also listed in the director. We've just changed this. I believe what must have happened is that someone just had a look at the global chatroom listing and then went into a room to give it a test.

Again, we've just remove the default listing option so this shouldn't be possible any more.

We'll also improve that chat room settings interface and let you set a password from within Jitsi. We'll probably do this by the end of the summer.

Cheers,
Emil

···

On 18.07.13, 17:49, Andrew wrote:

I recently installed jitsi to evaluate it as an alternative to skype but
I have run into one serious issue/confusion involving chatrooms. I
signed up using the jit.si <http://jit.si> service and had a one on one
chat going when I clicked the "invite" icon to invite another person to
the chat. This worked as expected and the person I invited joined the
chat. What surprised me was that random people who I had not invited
started joining the chat! Jitsi never warned me that by adding a person
to the chat that I was making it public! I did not even know that jitsi
supported public chatrooms but now this makes me question what is or
isn't private when using jitsi since the application never warned or was
explicit about it.

This experience leads me to a few questions:

Is it possible to have private group chats?
Why didn't jitsi warn me that I was making my conversation public?
Are chats between two people even private?
Are group calls private? Or when I add a third person to a call does the
call become public for anybody to join like the chats?

This experience makes me very unsure about continuing to use jitsi since
I am not sure that I can "trust" it after it silently made my
communications public without warning. Are my misgivings unfounded
because I am missing something about the way jitsi/xmpp is supposed to
work? Was my assumption that adding a person to a chat via the "invite"
button would keep the chat private unreasonable?

Thanks,
Andrew

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

--
https://jitsi.org


#4

The other day I tried to communicate jit.si to jit.si and we were not
successful. What are the recommended sound and video encodings, and in
what order?

Pablo


#5

Emil,

Even if the chat room list is removed from the interface won't people still
be able to enter a chatroom by knowing/guessing its name? That does not
sound very private. Is it possible to have "invite only" chat rooms?

Also is it intended behavior that if I have a one on one chat and then
invite another person that it automatically becomes a chatroom? That is the
behavior that I had a problem with. What I expected was that a private one
on one conversation would turn into a private 3 person conversation. What
actually happened was a private one on one conversation became a public 3
person conversation without any warning to me or the other participants.

Thanks,
Andrew

···

On Thu, Jul 18, 2013 at 4:12 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Andrew,

It sounds like you created a chat room. Those are public by default and
also listed in the director. We've just changed this. I believe what must
have happened is that someone just had a look at the global chatroom
listing and then went into a room to give it a test.

Again, we've just remove the default listing option so this shouldn't be
possible any more.

We'll also improve that chat room settings interface and let you set a
password from within Jitsi. We'll probably do this by the end of the summer.

Cheers,
Emil

On 18.07.13, 17:49, Andrew wrote:

I recently installed jitsi to evaluate it as an alternative to skype but
I have run into one serious issue/confusion involving chatrooms. I
signed up using the jit.si <http://jit.si> service and had a one on one

chat going when I clicked the "invite" icon to invite another person to
the chat. This worked as expected and the person I invited joined the
chat. What surprised me was that random people who I had not invited
started joining the chat! Jitsi never warned me that by adding a person
to the chat that I was making it public! I did not even know that jitsi
supported public chatrooms but now this makes me question what is or
isn't private when using jitsi since the application never warned or was
explicit about it.

This experience leads me to a few questions:

Is it possible to have private group chats?
Why didn't jitsi warn me that I was making my conversation public?
Are chats between two people even private?
Are group calls private? Or when I add a third person to a call does the
call become public for anybody to join like the chats?

This experience makes me very unsure about continuing to use jitsi since
I am not sure that I can "trust" it after it silently made my
communications public without warning. Are my misgivings unfounded
because I am missing something about the way jitsi/xmpp is supposed to
work? Was my assumption that adding a person to a chat via the "invite"
button would keep the chat private unreasonable?

Thanks,
Andrew

______________________________**_________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/users<http://lists.jitsi.org/mailman/listinfo/users>

--
https://jitsi.org


#6

Default is generally the best. Did you change anything?

Emil

···

On Fri, Jul 19, 2013 at 10:44 PM, Carola y Pablo <stuckybyler2@yahoo.es> wrote:

The other day I tried to communicate jit.si to jit.si and we were not
successful. What are the recommended sound and video encodings, and in
what order?

Pablo

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#7

Yes, some time back I changed the default settings, because with SIP
accounts it seemed like nondefault settings worked best, so I thought
that applied to jit.si as well. How do I go back to default settings?
Pressing the reset button doesn't seem to do it, right?
Pablo

···

El vie, 19-07-2013 a las 22:52 +0200, Emil Ivov escribió:

Default is generally the best. Did you change anything?

Emil

On Fri, Jul 19, 2013 at 10:44 PM, Carola y Pablo <stuckybyler2@yahoo.es> wrote:
>
> The other day I tried to communicate jit.si to jit.si and we were not
> successful. What are the recommended sound and video encodings, and in
> what order?
>
> Pablo
>
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users


#8

I agree that it sounds bad if I'm in a private, encrypted chat with
one person and then invite another that this creates a public
chatroom.

If there's any way to instead make it a private 3 (or more) way
conference, that would be preferable, although I don't pretend to
understand the logistics of having multiple people needing to send
their messages encoded to multiple recipients (each with a separate
key) simultaneously, or if that's even possible.

If not and the best we can do is a private, passworded, chatroom, then
somehow we'd need to send the password when we invite people, so that
they can join and I guess the one person we're already chatting with
would have to disconnect from that chat and re-connect to the chatroom
with the password, the same as the other recipients, so it wouldn't
exactly be transparent or simple. I'd also be interested to know what
encryption, if any, this chatroom would be using.

Regards
Derek

···

On 19 July 2013 16:53, Andrew <attunezero@gmail.com> wrote:

Emil,

Even if the chat room list is removed from the interface won't people still
be able to enter a chatroom by knowing/guessing its name? That does not
sound very private. Is it possible to have "invite only" chat rooms?

Also is it intended behavior that if I have a one on one chat and then
invite another person that it automatically becomes a chatroom? That is the
behavior that I had a problem with. What I expected was that a private one
on one conversation would turn into a private 3 person conversation. What
actually happened was a private one on one conversation became a public 3
person conversation without any warning to me or the other participants.

Thanks,
Andrew

On Thu, Jul 18, 2013 at 4:12 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Andrew,

It sounds like you created a chat room. Those are public by default and
also listed in the director. We've just changed this. I believe what must
have happened is that someone just had a look at the global chatroom listing
and then went into a room to give it a test.

Again, we've just remove the default listing option so this shouldn't be
possible any more.

We'll also improve that chat room settings interface and let you set a
password from within Jitsi. We'll probably do this by the end of the summer.

Cheers,
Emil

On 18.07.13, 17:49, Andrew wrote:

I recently installed jitsi to evaluate it as an alternative to skype but
I have run into one serious issue/confusion involving chatrooms. I
signed up using the jit.si <http://jit.si> service and had a one on one

chat going when I clicked the "invite" icon to invite another person to
the chat. This worked as expected and the person I invited joined the
chat. What surprised me was that random people who I had not invited
started joining the chat! Jitsi never warned me that by adding a person
to the chat that I was making it public! I did not even know that jitsi
supported public chatrooms but now this makes me question what is or
isn't private when using jitsi since the application never warned or was
explicit about it.

This experience leads me to a few questions:

Is it possible to have private group chats?
Why didn't jitsi warn me that I was making my conversation public?
Are chats between two people even private?
Are group calls private? Or when I add a third person to a call does the
call become public for anybody to join like the chats?

This experience makes me very unsure about continuing to use jitsi since
I am not sure that I can "trust" it after it silently made my
communications public without warning. Are my misgivings unfounded
because I am missing something about the way jitsi/xmpp is supposed to
work? Was my assumption that adding a person to a chat via the "invite"
button would keep the chat private unreasonable?

Thanks,
Andrew

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

--
https://jitsi.org

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


#9

Hello,

Yes, some time back I changed the default settings, because with SIP
accounts it seemed like nondefault settings worked best, so I thought
that applied to jit.si as well. How do I go back to default settings?
Pressing the reset button doesn't seem to do it, right?
Pablo

Pressing the reset button resets the per-account configuration to the global one. Currently there is no way easy way to reset to the defaults. You can either edit your config file, or restore them manually in the client (see screenshot attached for the default values for audio, video defaults to h264 only)

I guess we need to add a proper way to do this. Would a "reset to default" button in the global configuration make sense?

Regards,
Boris

···

On 7/20/13 2:15 AM, Carola y Pablo wrote:


#10

Hey Derek,

I agree that it sounds bad if I'm in a private, encrypted chat with
one person and then invite another that this creates a public
chatroom.

It does sound bad. Fortunately this can't happen with Jitsi.

If there's any way to instead make it a private 3 (or more) way
conference, that would be preferable, although I don't pretend to
understand the logistics of having multiple people needing to send
their messages encoded to multiple recipients (each with a separate
key) simultaneously, or if that's even possible.

We support end-to-end encryption only for one-to-one chats in Jitsi.
Multi-User Chats (MUCs) only rely on whatever protection the transport
channel provides (typicall client-to-server TLS).

If not and the best we can do is a private, passworded, chatroom, then
somehow we'd need to send the password when we invite people, so that
they can join and I guess the one person we're already chatting with
would have to disconnect from that chat and re-connect to the chatroom
with the password, the same as the other recipients, so it wouldn't
exactly be transparent or simple. I'd also be interested to know what
encryption, if any, this chatroom would be using.

That's pretty how a Jitsi user would currently handle this.

Emil

···

On Fri, Jul 19, 2013 at 8:10 PM, Derek Moss <dmts@stoptheviolence.co.uk> wrote:


#11

Thank you.

I set the audio codecs in the default order you described. I ordered the
video codecs H264 followed by H263-1998. Then I called one jit.si
account to another, from Jitsi nightly build 2.3.4740 on Ubuntu 13-04 to
stable version 2.2. 4603.9615 on Windows 7, within a LAN network. The
sound was unintelligible. So, I still think there must be some order
of audio encodings that I haven't discovered and that give good results
straight off. Would it help if I sent logs?

Thank you for your help. With SIP and chat, Jitsi is working great.

Pablo

···

El sáb, 20-07-2013 a las 10:00 +0300, Boris Grozev escribió:

Hello,

On 7/20/13 2:15 AM, Carola y Pablo wrote:
> Yes, some time back I changed the default settings, because with SIP
> accounts it seemed like nondefault settings worked best, so I thought
> that applied to jit.si as well. How do I go back to default settings?
> Pressing the reset button doesn't seem to do it, right?
> Pablo

Pressing the reset button resets the per-account configuration to the
global one. Currently there is no way easy way to reset to the defaults.
You can either edit your config file, or restore them manually in the
client (see screenshot attached for the default values for audio, video
defaults to h264 only)

I guess we need to add a proper way to do this. Would a "reset to
default" button in the global configuration make sense?

Regards,
Boris


#12

I agree that it sounds bad if I'm in a private, encrypted chat with
one person and then invite another that this creates a public
chatroom.

It does sound bad. Fortunately this can't happen with Jitsi.

I am confused now. This is exactly what happened to me with jitsi when I
had a one on one chat and invited another person. Is there a feature for
private multi user chats that I am missing?

···

On Fri, Jul 19, 2013 at 5:01 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Derek,

On Fri, Jul 19, 2013 at 8:10 PM, Derek Moss <dmts@stoptheviolence.co.uk> > wrote:
> I agree that it sounds bad if I'm in a private, encrypted chat with
> one person and then invite another that this creates a public
> chatroom.

It does sound bad. Fortunately this can't happen with Jitsi.

> If there's any way to instead make it a private 3 (or more) way
> conference, that would be preferable, although I don't pretend to
> understand the logistics of having multiple people needing to send
> their messages encoded to multiple recipients (each with a separate
> key) simultaneously, or if that's even possible.

We support end-to-end encryption only for one-to-one chats in Jitsi.
Multi-User Chats (MUCs) only rely on whatever protection the transport
channel provides (typicall client-to-server TLS).

> If not and the best we can do is a private, passworded, chatroom, then
> somehow we'd need to send the password when we invite people, so that
> they can join and I guess the one person we're already chatting with
> would have to disconnect from that chat and re-connect to the chatroom
> with the password, the same as the other recipients, so it wouldn't
> exactly be transparent or simple. I'd also be interested to know what
> encryption, if any, this chatroom would be using.

That's pretty how a Jitsi user would currently handle this.

Emil

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


#13

> I agree that it sounds bad if I'm in a private, encrypted chat with
> one person and then invite another that this creates a public
> chatroom.

> It does sound bad. Fortunately this can't happen with Jitsi.

I am confused now. This is exactly what happened to me with jitsi when I
had a one on one chat and invited another person.

This can't happen with XMPP in Jitsi. It wouldn't even work on the interface level. My guess is that you simply started a chatroom where you were only talking to one person and then another one joined. (But it uwas a Multi-User chat from the start).

A one-to-one XMPP chat in Jitsi cannot become a multi-user one.

Is there a feature for private multi user chats that I am missing?

Just to confirm: your question is about chatrooms right? Not about one-to-one chats, correct? If so, then privacy is a property that you can set on a chatroom by configuring a password. This is not currently possible because the config form in Jitsi is broken.

We will soon fix it.

Even without that though. chat rooms were previously listed on the server so it was easy for anyone to join any chat room. This is no longer the case.

Cheers,
Emil

···

On 19.07.13, 23:31, Andrew wrote:

On Fri, Jul 19, 2013 at 5:01 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    Hey Derek,

    On Fri, Jul 19, 2013 at 8:10 PM, Derek Moss > <dmts@stoptheviolence.co.uk <mailto:dmts@stoptheviolence.co.uk>> wrote:
     > I agree that it sounds bad if I'm in a private, encrypted chat with
     > one person and then invite another that this creates a public
     > chatroom.

    It does sound bad. Fortunately this can't happen with Jitsi.

     > If there's any way to instead make it a private 3 (or more) way
     > conference, that would be preferable, although I don't pretend to
     > understand the logistics of having multiple people needing to send
     > their messages encoded to multiple recipients (each with a separate
     > key) simultaneously, or if that's even possible.

    We support end-to-end encryption only for one-to-one chats in Jitsi.
    Multi-User Chats (MUCs) only rely on whatever protection the transport
    channel provides (typicall client-to-server TLS).

     > If not and the best we can do is a private, passworded, chatroom,
    then
     > somehow we'd need to send the password when we invite people, so that
     > they can join and I guess the one person we're already chatting with
     > would have to disconnect from that chat and re-connect to the
    chatroom
     > with the password, the same as the other recipients, so it wouldn't
     > exactly be transparent or simple. I'd also be interested to know what
     > encryption, if any, this chatroom would be using.

    That's pretty how a Jitsi user would currently handle this.

    Emil

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

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

--
https://jitsi.org


#14

It doesn't sound like an issue with encodings -- if everything else is working correctly, you shouldn't have unintelligible sound with any of the codecs. And since there is at least some sound, then codec selection worked. The problem must be somewhere else

By the way, codec selection works in the following very simple way:
the caller sends a list of codecs, the responder selects the first codec in the list, which it supports. So with Jitsi on both ends and with default configuration, the first codec in the list (opus) will be used.

Normally, at least for XMPP, you don't need to play around with codec settings.

Oh, and, yes -- logs will help.

Regards,
Boris

···

On 7/20/13 11:19 PM, Carola y Pablo wrote:

Thank you.

I set the audio codecs in the default order you described. I ordered the
video codecs H264 followed by H263-1998. Then I called one jit.si
account to another, from Jitsi nightly build 2.3.4740 on Ubuntu 13-04 to
stable version 2.2. 4603.9615 on Windows 7, within a LAN network. The
sound was unintelligible. So, I still think there must be some order
of audio encodings that I haven't discovered and that give good results
straight off. Would it help if I sent logs?


#15

My confusion is due to the user interface in jisti. In the latest nightly
for windows that I downloaded if I am in a one on one chat then there is a
button on the top left of the window widow with the tooltip "invite".
Clicking on this button brings up a dialog titled "Invite contacts to chat"
in which it says "Select the names of the contacts you would like to add to
this conversation and then click Invite". Upon inviting somebody using
that dialog my one on one chat is transformed into a public chatroom.

The effect of the "invite" button on a one on one chat is to transform the
one on one chat into a public chatroom. The "invite" button interface or
chat interface never warned me that this was happening. I think this
behavior is unexpected/dangerous. I did not even know that there was such
a thing as a "chatroom" that was different from a one on one chat. I only
realized that my chat was now public (instead of between 3 people) when a
random person joined!

I think that if you are in a one on one chat and use the "invite" button
you should be warned that you are creating a chat room.

Thanks,
Andrew

···

On Fri, Jul 19, 2013 at 5:47 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 19.07.13, 23:31, Andrew wrote:

> I agree that it sounds bad if I'm in a private, encrypted chat with
> one person and then invite another that this creates a public
> chatroom.

> It does sound bad. Fortunately this can't happen with Jitsi.

I am confused now. This is exactly what happened to me with jitsi when I
had a one on one chat and invited another person.

This can't happen with XMPP in Jitsi. It wouldn't even work on the
interface level. My guess is that you simply started a chatroom where you
were only talking to one person and then another one joined. (But it uwas a
Multi-User chat from the start).

A one-to-one XMPP chat in Jitsi cannot become a multi-user one.

Is there a feature for private multi user chats that I am missing?

Just to confirm: your question is about chatrooms right? Not about
one-to-one chats, correct? If so, then privacy is a property that you can
set on a chatroom by configuring a password. This is not currently possible
because the config form in Jitsi is broken.

We will soon fix it.

Even without that though. chat rooms were previously listed on the server
so it was easy for anyone to join any chat room. This is no longer the case.

Cheers,
Emil

On Fri, Jul 19, 2013 at 5:01 PM, Emil Ivov <emcho@jitsi.org >> <mailto:emcho@jitsi.org>> wrote:

    Hey Derek,

    On Fri, Jul 19, 2013 at 8:10 PM, Derek Moss >> <dmts@stoptheviolence.co.uk <mailto:dmts@stoptheviolence.**co.uk<dmts@stoptheviolence.co.uk>>> >> wrote:
     > I agree that it sounds bad if I'm in a private, encrypted chat with
     > one person and then invite another that this creates a public
     > chatroom.

    It does sound bad. Fortunately this can't happen with Jitsi.

     > If there's any way to instead make it a private 3 (or more) way
     > conference, that would be preferable, although I don't pretend to
     > understand the logistics of having multiple people needing to send
     > their messages encoded to multiple recipients (each with a separate
     > key) simultaneously, or if that's even possible.

    We support end-to-end encryption only for one-to-one chats in Jitsi.
    Multi-User Chats (MUCs) only rely on whatever protection the transport
    channel provides (typicall client-to-server TLS).

     > If not and the best we can do is a private, passworded, chatroom,
    then
     > somehow we'd need to send the password when we invite people, so
that
     > they can join and I guess the one person we're already chatting
with
     > would have to disconnect from that chat and re-connect to the
    chatroom
     > with the password, the same as the other recipients, so it wouldn't
     > exactly be transparent or simple. I'd also be interested to know
what
     > encryption, if any, this chatroom would be using.

    That's pretty how a Jitsi user would currently handle this.

    Emil

    ______________________________**_________________
    users mailing list
    users@jitsi.org <mailto:users@jitsi.org>

    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/**mailman/listinfo/users<http://lists.jitsi.org/mailman/listinfo/users>

______________________________**_________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/**mailman/listinfo/users<http://lists.jitsi.org/mailman/listinfo/users>

--
https://jitsi.org


#16

Hi Emil

This can't happen with XMPP in Jitsi. It wouldn't even work on the interface
level. My guess is that you simply started a chatroom where you were only
talking to one person and then another one joined. (But it uwas a Multi-User
chat from the start).

A one-to-one XMPP chat in Jitsi cannot become a multi-user one.

Actually, Andrew appears to be right, as I see the Invite button in
the one-on-one chat window which opens a windows which says "Select
the contacts you would like to invite to this conversation". There's
also a Create a Conference Call option under Tools which brings up the
same window. Neither indicate that the security will be lost and a
possibly unencrypted chatroom will be created and suggest that
invitees will be invited to join "this" conversation. It also only
seems to list contacts associated with the profile being used for the
one-on-one chat, so with my gmail account which I have two contacts
under (one jit.si and one gmail) they're listed, whereas with my
jit.si account which only has one contact, only that is listed, which
doesn't seem to make much sense if I'm creating a public, unencrypted
chatroom which anyone can join.

    We support end-to-end encryption only for one-to-one chats in Jitsi.
    Multi-User Chats (MUCs) only rely on whatever protection the transport
    channel provides (typicall client-to-server TLS).

I'm not really sure what that means, so can you clarify please? If I
create a MUC using my gmail account and invite a gmail contact and a
jit.si contact, what encryption will be used? Likewise, if I create a
MUC using my jitsi account and invite the same contacts, what
encryption will be used.

    That's pretty how a Jitsi user would currently handle this.

As I understand it though, the MUC password feature isn't currently
operational, so they couldn't handle it this way but to be clear, are
you saying that when it is operational, that on inviting contacts to a
password-protected MUC, a new window will open and any contacts
already in one-on-one chat that have been invited to the MUC will have
to join this manually using the password, whilst the one-on-one chat
window/conversation will remain active?

Regards
Derek


#17

Thank you for your help.

I am attaching logs from both computers. One is labeled "Jitsi log on
Windows", the other log is from Jitsi on Ubuntu 13.04. When I dialed
from jit.si on Ubuntu to jit.si on Windows, as soon as I answered on
Windows, Jitsi crashed. When I dial from Windows to Ubuntu, the
connection is established but the sound is unintelligible. When I
disable the Video (in which H264 is the first option) then the sound
become intelligible, but still choppy and not clear or adequate.

I am trying this on two computers within the same wireless network.

Thank you for your help.

Pablo

2013-07-21@07.41.42-logs.zip (397 KB)

jitsi log on Windows.zip (110 KB)

···

El dom, 21-07-2013 a las 00:35 +0300, Boris Grozev escribió:

On 7/20/13 11:19 PM, Carola y Pablo wrote:
> Thank you.
>
> I set the audio codecs in the default order you described. I ordered the
> video codecs H264 followed by H263-1998. Then I called one jit.si
> account to another, from Jitsi nightly build 2.3.4740 on Ubuntu 13-04 to
> stable version 2.2. 4603.9615 on Windows 7, within a LAN network. The
> sound was unintelligible. So, I still think there must be some order
> of audio encodings that I haven't discovered and that give good results
> straight off. Would it help if I sent logs?

It doesn't sound like an issue with encodings -- if everything else is
working correctly, you shouldn't have unintelligible sound with any of
the codecs. And since there is at least some sound, then codec selection
worked. The problem must be somewhere else

By the way, codec selection works in the following very simple way:
the caller sends a list of codecs, the responder selects the first codec
in the list, which it supports. So with Jitsi on both ends and with
default configuration, the first codec in the list (opus) will be used.

Normally, at least for XMPP, you don't need to play around with codec
settings.

Oh, and, yes -- logs will help.

Regards,
Boris


#18

Thank you for your help.

I am sending two mails so I can attach logs from both computers with
which I am attempting a jit.si to jit.si connection. With this mail I
am sending a log from Jitsi on Ubuntu 13.04. With the other mail I
attach the log "Jitsi log on Windows".

When I dialed from jit.si on Ubuntu to jit.si on Windows, as soon as I
answered on Windows, Jitsi on Windows crashed. When I dial from
Windows to Ubuntu, the connection is established but the sound is
unintelligible. When I disable the Video (in which H264 is the first
option) then the sound become intelligible, but still choppy and not
clear or adequate.

I am trying this on two computers within the same wireless network. Is
it simply a matter of insufficient bandwidth? Why the crash?

Thank you for your help.

Pablo

2013-07-21@07.41.42-logs.zip (397 KB)

···

El dom, 21-07-2013 a las 00:35 +0300, Boris Grozev escribió:

On 7/20/13 11:19 PM, Carola y Pablo wrote:
> Thank you.
>
> I set the audio codecs in the default order you described. I ordered the
> video codecs H264 followed by H263-1998. Then I called one jit.si
> account to another, from Jitsi nightly build 2.3.4740 on Ubuntu 13-04 to
> stable version 2.2. 4603.9615 on Windows 7, within a LAN network. The
> sound was unintelligible. So, I still think there must be some order
> of audio encodings that I haven't discovered and that give good results
> straight off. Would it help if I sent logs?

It doesn't sound like an issue with encodings -- if everything else is
working correctly, you shouldn't have unintelligible sound with any of
the codecs. And since there is at least some sound, then codec selection
worked. The problem must be somewhere else

By the way, codec selection works in the following very simple way:
the caller sends a list of codecs, the responder selects the first codec
in the list, which it supports. So with Jitsi on both ends and with
default configuration, the first codec in the list (opus) will be used.

Normally, at least for XMPP, you don't need to play around with codec
settings.

Oh, and, yes -- logs will help.

Regards,
Boris


#19

Thank you for your help.

I am sending two mails so I can attach logs from both computers with
which I am attempting a jit.si to jit.si connection. With this mail I
am sending a log labeled "Jitsi log on Windows". With the other mail I
attach the log from Jitsi on Ubuntu 13.04.

When I dialed from jit.si on Ubuntu to jit.si on Windows, as soon as I
answered on Windows, Jitsi on Windows crashed. When I dial from
Windows to Ubuntu, the connection is established but the sound is
unintelligible. When I disable the Video (in which H264 is the first
option) then the sound become intelligible, but still choppy and not
clear or adequate.

I am trying this on two computers within the same wireless network. Is
it simply a matter of insufficient bandwidth? Why the crash?

Thank you for your help.

Pablo

jitsi log on Windows.zip (110 KB)

···

El dom, 21-07-2013 a las 00:35 +0300, Boris Grozev escribió:

On 7/20/13 11:19 PM, Carola y Pablo wrote:
> Thank you.
>
> I set the audio codecs in the default order you described. I ordered the
> video codecs H264 followed by H263-1998. Then I called one jit.si
> account to another, from Jitsi nightly build 2.3.4740 on Ubuntu 13-04 to
> stable version 2.2. 4603.9615 on Windows 7, within a LAN network. The
> sound was unintelligible. So, I still think there must be some order
> of audio encodings that I haven't discovered and that give good results
> straight off. Would it help if I sent logs?

It doesn't sound like an issue with encodings -- if everything else is
working correctly, you shouldn't have unintelligible sound with any of
the codecs. And since there is at least some sound, then codec selection
worked. The problem must be somewhere else

By the way, codec selection works in the following very simple way:
the caller sends a list of codecs, the responder selects the first codec
in the list, which it supports. So with Jitsi on both ends and with
default configuration, the first codec in the list (opus) will be used.

Normally, at least for XMPP, you don't need to play around with codec
settings.

Oh, and, yes -- logs will help.

Regards,
Boris


#20

Hey Derek, Andrew,

Hi Emil

This can't happen with XMPP in Jitsi. It wouldn't even work on the interface
level. My guess is that you simply started a chatroom where you were only
talking to one person and then another one joined. (But it uwas a Multi-User
chat from the start).

A one-to-one XMPP chat in Jitsi cannot become a multi-user one.

Actually, Andrew appears to be right, as I see the Invite button in
the one-on-one chat window which opens a windows which says "Select
the contacts you would like to invite to this conversation".

Guys, you are right. Indeed, inviting a third person to a chat will indeed lead to the problems Andrew described. I am not sure exactly what I was thinking. I apologise!

We need to make these rooms invitation-only by default and then we need to fix room configuration, so that the organiser can further transform them if necessary.

Could you guys please open a ticket?

There's
also a Create a Conference Call option under Tools which brings up the
same window.

The Conference Call option does not use MUCs in any way so this is quite different. Security for conference calls is indicated separately so I don't believe the problem applies there.

Neither indicate that the security will be lost and a
possibly unencrypted chatroom will be created and suggest that
invitees will be invited to join "this" conversation. It also only
seems to list contacts associated with the profile being used for the
one-on-one chat, so with my gmail account which I have two contacts
under (one jit.si and one gmail) they're listed, whereas with my
jit.si account which only has one contact, only that is listed, which
doesn't seem to make much sense if I'm creating a public, unencrypted
chatroom which anyone can join.

Regardless of the privacy settings for a room, you can only send invitations to people that are part of your account roster. There's no way around this.

     We support end-to-end encryption only for one-to-one chats in Jitsi.
     Multi-User Chats (MUCs) only rely on whatever protection the transport
     channel provides (typicall client-to-server TLS).

I'm not really sure what that means, so can you clarify please? If I
create a MUC using my gmail account and invite a gmail contact and a
jit.si contact, what encryption will be used?

The connection between you and your server will be protected by TLS. The connection between your peer and their server will be protected by TLS.
The administrators of both servers will be able read your messages.
Gmail does not support TLS for server-to-server connections so the communication between the two servers will not be protected.

TLS only encrypts between you and your next hop. It tells you nothing about what the situation for the rest of the route is. That's where an end-to-end encryption mechanism such as OTR is different.

We don't support end-to-end encryption for chat rooms.

Does this make things clearer?

Likewise, if I create a
MUC using my jitsi account and invite the same contacts, what
encryption will be used.

     That's pretty how a Jitsi user would currently handle this.

As I understand it though, the MUC password feature isn't currently
operational,

It is operational and you can join password protected MUCs. I do this every day. What isn't operational is the MUC configuration form that allows you to set a password on a MUC. We'll fix this.

so they couldn't handle it this way but to be clear, are
you saying that when it is operational, that on inviting contacts to a
password-protected MUC, a new window will open and any contacts
already in one-on-one chat that have been invited to the MUC will have
to join this manually using the password, whilst the one-on-one chat
window/conversation will remain active?

No, there would be no passwords in the auto-upgrade case. The MUC will be invitation-only.

Cheers,
Emil

···

On 20.07.13, 13:40, Derek Moss wrote:

--
https://jitsi.org