Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#33700: audio- and video-conferencing considerations
-------------------------------------------------+-------------------------
 Reporter:  anarcat                              |          Owner:  (none)
     Type:  project                              |         Status:
                                                 |  needs_revision
 Priority:  High                                 |      Milestone:
Component:  Internal Services/Services Admin     |        Version:
  Team                                           |
 Severity:  Major                                |     Resolution:
 Keywords:                                       |  Actual Points:
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by anarcat):

 > Maybe I don't understand the goal of this ticket, but: it seems to me
 that our answer for audio / video meetings is: "use one of these external
 jitsi servers if there aren't very many people, use zoom if there are, and
 if the group doing the meeting wants to use something different they can
 do that."

 Well, for the "Zoom" part, there's certainly problems:

  * it's proprietary software - which I try to avoid installing on my
 computers, and I especially try to avoid forcing on my coworkers
  * it has serious privacy issues:
 https://www.vice.com/en_us/article/k7e599/zoom-ios-app-sends-data-to-
 facebook-even-if-you-dont-have-a-facebook-account
 https://www.linkedin.com/pulse/whereby-vs-zoom-transparency-opacity-
 respect-privacy-manuela

 So there is a case to be made that we want to have some alternatives to
 Zoom, specifically...

 >  That is, we've got no business setting up and tweaking our own jitsi
 (or whatever) server when there are already folks in the broader community
 who are doing it.

 ... and "use someone else's Jitsi instance" can certainly be an answer.
 But one of the things I have heard from people running those instances is
 that they need help. The call first came from the Framasoft people, and
 they basically said that organisations should run their own Jitsi
 instances instead of all relying on a central one.

 I'll also note that the last Jitsi call we made wasn't made on some random
 part of the internet: it was made on ahf's instance, who set it up in his
 free time.

 The other thing is that Jitsi does take a surprising amount of bandwidth
 when we're streaming video. It's logical, when you think about it, but
 video scales up quite fast, and it's not unheard of to have those saturate
 gigabit links. If all of TPI starts using Jitsi more intensively, we will
 monopolize that instance and deteriorate the service for smaller, one-time
 users that do not have our resources.

 But sure, we could use someone else's instance. I'll note we need to be
 very careful about this. One of the things Jitsi does, out of the box, is
 that it lists the conferences currently running on the server. If you
 don't set a password, anyone can join in and start listening on the
 conversation, which I find rather strange. If we setup our own instance,
 we could make a better policy. (You can set a password when you're the
 first to join, but I suspect I'm the only one who really does this, and
 it's really easy to forget.)

 Finally, I'll note that I have tried to establish a process by which we
 make this decision here. This ticket is not called "let's install an A/V
 server". The ticket is "audio- and video-conferencing considerations".
 It's explicitly aimed at documenting what are our requirements, the
 possible solutions and how the rate against our requirements.

 Hosting externally has always been an option. I'm just trying to formalize
 the process. If you have a "must have" that is "do not host ourselves"
 then, by all means add it if you think that should be a hard requirement.
 But so far I've gone with "long term maintenance costs covered" instead,
 which seems more in line with what, as an organization, we might be
 worried about.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33700#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs