Re: Privacy, outages, and plenary

[Simon Pietro Romano <spromano@xxxxxxxx>]

Hello John,

first of all let me apologize for today’s issues. We’re still investigating the situation, but we have most probably identified its root cause.

I’ll try to briefly explain what happened (by avoiding useless technicalities as much as possible) and I hope that this will both clarify the issue and reassure you a  bit with respect to the privacy issues you are raising.

Actually, we misconfigured the virtual queuing server, due to the need to have both moderated participants (the ones who ask for the floor and

subsequently enter the queue) and one un-moderated participant (i.e., a user who is allowed to enter the conversation without being moderated). The latter was needed

for the event we had right before the plenary’s start time. When the plenary started, we failed to reboot the virtual server and, for an incredibly unfortunate combination of events

we got things messed up in the moderation system. This ended up with both an inconsistent behavior and a hanging communication thread between the queuing system and the Meetecho server (which brought the system close to starvation for more than 10 minutes). When such a thread finally crashed, controls were disabled for a while, which resulted in the crazy behavior you mention in your mail. Believe me if I tell you that this should definitely never happen and had never happened before. The virtual queue, though experimental, has proved to work smoothly until today and it did fail at the plenary just because of a misconfiguration form our side.

This said, I personally totally agree with your proposal of defining privacy auditing procedures for all the tools we make use of at the IETF. We are obviously open to not only subject ourselves to this process, but also actively contribute to the design of the entire auditing cycle. 

Hope this helps shed some light on this regrettable episode and believe me if I say that I appreciate your feedback, as usual. I know you’ve been one of the most active remotees so far and

I would like to be sure that you’ll keep on helping us improve our service.

Cheers,

Simon

On 04/nov/2015, at 09:02, John C Klensin <john-ietf@xxxxxxx> wrote:

Hi.

First, in case anyone doesn't know, at least from Yokohama to
Cambridge, MA, USA, Meetecho announced problems and forced
logging in again three times so far during the plenary.  I just
got an "Internal Server Error" box during Brian Trammel's talk
and then the video froze and audio dropped, so that is probably
a fourth.  These were in addition to the audio going out for
some time during Harald's talk.  After that fourth time, I seem
to be unable to log back in -- two freeze-ups in the login
process and now waiting to connect (little rotating icon for an
extended period.  Finally got another "Internet server error"
and have just given up on Meetecho for the plenary. Not good.

This version of Meetecho with two-way capability also poses a
huge privacy problem.   If I enable active, rather than passive,
participation, I apparently have to agree to give Meetecho
control of both my microphone and webcam in order to get into
the session.  Audio is fine, but I need to be able to mute it
and need onscreen control and verification that it is muted (for
me to have to un-mute _and_ the Meetecho program or controller
to un-mute/authorize me to talk from that end would be fine, but
to have the mic completely under remote control with no
indication to me as to whether it is transmitting or not is
not).    

Video is much worse because, having forced me to enable it if I
may want to make comments, Meetecho insists in turning on my
camera and broadcasting whatever it sees.  That is a nasty
invasion of privacy, especially in the context of participants
in many different time zones.  Based on what one participant
broadcast for a while, apparently before realizing the camera is
on, I'm not the only person who doesn't normally feel a need for
formal dress when participating in a meeting at 3AM my time.

Based on the accumulation of essentially black video frames,
several (or most) remote participants basically put a sock on
the webcam, but that can be hard for laptops with built-in
cameras.  Allowing the Meetecho application to find and enable
the camera is fine, but having it on has got to be under the
control of the user-participant and, IMO, that setting should
start out set off by default.

YMMD, but I consider this so important that I believe the IETF
should insist that Meetecho disable remote live group video
participation in meetings (not remote presentations, assuming
that is a separate function) until this is straightened up.  To
the extent to which the current generation of remote
participation tools is capable of taking over the remote
participant's machine, I also think that IAOC should insist in a
privacy audit of whatever tools are being used before each IETF
meeting.

   john

                             _\\|//_

                                  ( O-O )

   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~

                     Simon Pietro Romano

               Universita' di Napoli Federico II

                      Computer Engineering Department 

             Phone: +39 081 7683823 -- Fax: +39 081 7683816

                                           e-mail: spromano@xxxxxxxx

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 

    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.

                                     oooO

  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

                 \ (            (   )

                                  \_)          ) /

                                                                       (_/