Re: Zoom- best practice?

[Ryan Nowakowski]

On Fri, Jun 05, 2020 at 09:28:21AM -0700, Peter Ehlert wrote:
> Family is using Zoom, International.
> They will use Zoom, and I need to participate.
> 
> I use Debian Mate Stable, and Firefox ESR
> 
> I am concerned about security, duh!
> Looking for ideas.
> 
> my current thoughts, in order of preference:
> 
> 2. Sandbox? (but how can I do that?)

You might consider installing zoom as a snap package[1] instead of a deb.
Snaps provide some confinement that, in theory, provide some extra level
of security(harder for zoom to spread files all over your system, etc)

Alternatively, install the zoom deb package in a chroot[2].  I like to
use schroot to help with this kind of thing.

Then create a separate dedicated user just for running zoom.  That will
help limit zoom's access to your normal user's data.

[1] https://snapcraft.io/install/zoom-client/debian
[2] https://wiki.debian.org/chroot

Re: Reply semantics, yet again (was Re: Zoom- best practice?)

[Nicolas George]

[ It comes back to Jitsi and its license after a few paragraphs. And it
is appalling. ]

The Wanderer (12020-06-10):
> What's with the stray 1, here?

We are in 12020 HE = 2020 CE, HE stands for Holocene Era, or possibly
Human Era, it is just shifted by 1 from the Common Era. As a
consequence, all interesting dates are positive, since there was not
much going on earlier than 12000 years ago that would warrant an
accurate date.

https://www.youtube.com/watch?v=czgOWmtGVGs

> Not so much so; when not replying to a message received through a
> mailing list, the button is grayed out and unavailable, because there is
> no address for it to use.
> 
> So still "notice", to some degree, but not "remember", because the
> software handles that for me.

This proves my point: this is bad UI design. Instead of disabling the
button, it should revert to the non-list behavior. That would allow you
to click on it always, without having to take notice.

> Don't get me wrong; my original position on this, which I'd still prefer
> a solution that makes possible, is that the basic Reply function should
> do "smart" detection of the default reply target in all cases. I have
> rants written up about what the logic for determining the default should
> be, and I suspect that you'd agree with their results.

Probably. What I observe is with maling-lists that set the reply-to for
subscribers, I can use the G group-reply command and it does what I want
more than nine times out of ten.

> But I've seen persuasive argument that there's no way to make such
> "smart" reply direction detection smart enough that you don't need to
> override it in some cases, and that the number of different UI

Ah, the classic "we can't make it perfect, let's not make it at all"
fallacy.

> elements which would be needed to for all the different possible
> override types (reply respecting Reply-To, reply to sender, reply to
> list, reply-all, reply to list and sender, reply respecting Reply-To
> except also include list, ...) would very quickly proliferate to the
> point of unwieldiness.

This too is quite a fallacy.

> FWIW, since I wrote that I've looked at things a bit deeper. (Though not
> much.)
> 
> They do, apparently, update the JARs (lib/installer-exclude/) on a
> somewhat regular basis; there is a commit under that directory every few
> months or so, and most of them involve a commit message which looks
> related to updating from upstream.
> 
> The SOs (and DLLs, and .dylib / .jnilib files), on the other hand... the
> most recent log entry for the lib/native/ directory is from 2017, and
> the ones before that quickly go to 2016 and 2015 and on earlier. These
> appear to be mostly put in place and ignored, except when something
> breaks. (On the Linux side, only one of the .so files - libunix-java.so
> - appears to exist in current Debian testing / stable; that does not
> speak well for the possibility of being able to identify the appropriate
> upstreams.)

Oh, thanks for finding these. It is so much worse than I thought. They
are playing fast-and-loose not only with their build process, they are
playing fast-and-loose with the licenses of the dependencies and with
security.

I can even say: they are violating my copyright.

They distribute binaries of projects that are distributed under the
terms of the GPL, but nowhere have I found the corresponding source
code, nor a written offer for it, as specified in article 6 “Conveying
Non-Source Forms” of the GPL.

I will grant you that they do not do so out of nefarious intent, only
negligence. But that negligence shows that they do not understand a
significant part of what Libre Software is about.

And they are shipping a five-years old FFmpeg binary. In the last five
years, a few security-relevant bugs have been fixed in FFmpeg.

People, take notice: this is one of the reasons we insist on proper
packaging and being able to rebuild from source entirely: to allow
security upgrades for the included libraries.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Reply semantics, yet again (was Re: Zoom- best practice?)

[The Wanderer]

On 2020-06-10 at 09:27, Nicolas George wrote:

> The Wanderer (12020-06-09):

What's with the stray 1, here?

>> I subscribe to probably dozens of mailing lists, and I don't know
>> of any way to configure things to add that header with a proper
>> value automatically on a per-mailing-list basis. Otherwise, I'd
>> probably have done this years ago, unless other considerations
>> (e.g., UI for when I want to do this vs. when I really do want to
>> reply to the sender or to all recipients) took precedence.
> 
> With Mutt, I use this:
> 
> send-hook ~cdebian-u...@lists.debian.org my_hdr "Reply-To: 
> debian-user@lists.debian.org"
> 
> There is certainly an extension to Mozilla to do the same thing with
> a few dozen clics.

I haven't found one to date, but I'll look again.

>> For myself, I use the "Reply to List" button in (a now-old version
>> of) Thunderbird, and avoid the issue of Reply-To settings entirely
>> unless I actually do want to reply to something other than just the
>> list.
> 
> That means you need to remember and take notice, each time you reply
> to a mail, whether you are replying to a list or not.

Not so much so; when not replying to a message received through a
mailing list, the button is grayed out and unavailable, because there is
no address for it to use.

So still "notice", to some degree, but not "remember", because the
software handles that for me.

> I personally reject any solution with that requirement, since there
> are solutions without.

Don't get me wrong; my original position on this, which I'd still prefer
a solution that makes possible, is that the basic Reply function should
do "smart" detection of the default reply target in all cases. I have
rants written up about what the logic for determining the default should
be, and I suspect that you'd agree with their results.

But I've seen persuasive argument that there's no way to make such
"smart" reply direction detection smart enough that you don't need to
override it in some cases, and that the number of different UI
elements which would be needed to for all the different possible
override types (reply respecting Reply-To, reply to sender, reply to
list, reply-all, reply to list and sender, reply respecting Reply-To
except also include list, ...) would very quickly proliferate to the
point of unwieldiness.

Imperfect though it is, he use of a separate "reply to list" button is
the least problematic option that's close to a general "usable across
all scenarios" solution that I've seen actually get implemented so far.

That said, as I said above, I'll look into the type of hook you
mentioned, and see whether it produces better results for my particular
case and sensibilities.

>> While I wouldn't necessarily take the argument as far as you appear
>> to, I am inclined to agree in principle.
>> 
>> That said, while this is an important aspect of the situation,
>> it's technically a tangent from the question of whether people
>> other than the developers can build the program and have the result
>> be usable. If we assume that the developers don't routinely update
>> or replace these prebuilt objects, and don't hack these objects
>> themselves as part of working on the project, then the tree we have
>> is the tree the developers build from - and if we can build a
>> working program from it, then that narrower question is answered
>> "yes".
> 
> These thoughts caused me to consider an even scarier hypothesis:
> 
> It's entirely possible that the authors of Jitsi themselves would not
> be able to build it from sources.

FWIW, since I wrote that I've looked at things a bit deeper. (Though not
much.)

They do, apparently, update the JARs (lib/installer-exclude/) on a
somewhat regular basis; there is a commit under that directory every few
months or so, and most of them involve a commit message which looks
related to updating from upstream.

The SOs (and DLLs, and .dylib / .jnilib files), on the other hand... the
most recent log entry for the lib/native/ directory is from 2017, and
the ones before that quickly go to 2016 and 2015 and on earlier. These
appear to be mostly put in place and ignored, except when something
breaks. (On the Linux side, only one of the .so files - libunix-java.so
- appears to exist in current Debian testing / stable; that does not
speak well for the possibility of being able to identify the appropriate
upstreams.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Paul Johnson]

On Wed, Jun 10, 2020 at 8:17 AM Nicolas George  wrote:

> Michael Stone (12020-06-10):
> > Properly configured mailing list software does no such thing, since it's
> a
> > misuse of the reply-to header.
>
> A misuse that works, compared to non-misuses that regularly bring back
> "don't cc me" subthreads. At some points, the religion of "properly"
> using headers need to cede to the pragmatism.
>
> You need to realize that a solution that requires the user to use a
> different key/command if they are replying to a list than if they are
> not is inferior to a solution that works with always the same key.
>
> >A better solution is to use a better
> program
> > to read mail.
>
> You mean I should use Mutt, like you?
>

Or literally any modern mail reader, all of which implement "reply to
list".  It's not like the mailing list isn't publishing list-id headers.

Re: Zoom- best practice?

[Nicolas George]

The Wanderer (12020-06-09):
> I subscribe to probably dozens of mailing lists, and I don't know of any
> way to configure things to add that header with a proper value
> automatically on a per-mailing-list basis. Otherwise, I'd probably have
> done this years ago, unless other considerations (e.g., UI for when I
> want to do this vs. when I really do want to reply to the sender or to
> all recipients) took precedence.

With Mutt, I use this:

send-hook ~cdebian-u...@lists.debian.org my_hdr "Reply-To: 
debian-user@lists.debian.org"

There is certainly an extension to Mozilla to do the same thing with a
few dozen clics.

> For myself, I use the "Reply to List" button in (a now-old version of)
> Thunderbird, and avoid the issue of Reply-To settings entirely unless I
> actually do want to reply to something other than just the list.

That means you need to remember and take notice, each time you reply to
a mail, whether you are replying to a list or not. I personally reject
any solution with that requirement, since there are solutions without.

> While I wouldn't necessarily take the argument as far as you appear to,
> I am inclined to agree in principle.
> 
> That said, while this is an important aspect of the situation, it's
> technically a tangent from the question of whether people other than the
> developers can build the program and have the result be usable. If we
> assume that the developers don't routinely update or replace these
> prebuilt objects, and don't hack these objects themselves as part of
> working on the project, then the tree we have is the tree the developers
> build from - and if we can build a working program from it, then that
> narrower question is answered "yes".

These thoughts caused me to consider an even scarier hypothesis:

It's entirely possible that the authors of Jitsi themselves would not be
able to build it from sources.

> I just don't care to bother with doing that myself at present. Which, to
> an extent, turns things back to Tomas' point.

Tomas's point is "give the benefit of the doubt", but at this point
there is not much doubt left.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[Michael Stone]

On Wed, Jun 10, 2020 at 03:17:34PM +0200, Nicolas George wrote:

Michael Stone (12020-06-10):

Properly configured mailing list software does no such thing, since it's a
misuse of the reply-to header.


A misuse that works, 


Except for the things that it breaks, and the cases for which it doesn't 
work. So, no.

Re: Zoom- best practice?

[Nicolas George]

Michael Stone (12020-06-10):
> Properly configured mailing list software does no such thing, since it's a
> misuse of the reply-to header.

A misuse that works, compared to non-misuses that regularly bring back
"don't cc me" subthreads. At some points, the religion of "properly"
using headers need to cede to the pragmatism.

You need to realize that a solution that requires the user to use a
different key/command if they are replying to a list than if they are
not is inferior to a solution that works with always the same key.

>A better solution is to use a better program
> to read mail.

You mean I should use Mutt, like you?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[Michael Stone]

On Tue, Jun 09, 2020 at 12:51:00PM +0200, Nicolas George wrote:

Instead of writing this periodically, you could include:
Reply-To: debian-user@lists.debian.org
in your headers just like I did. Properly configured mailing-list
software does it by default for subscribed users, but Debian is an
exception. It fixes the issue of annoying ccs once and for all.


Properly configured mailing list software does no such thing, since it's 
a misuse of the reply-to header. A better solution is to use a better 
program to read mail.

Re: Zoom- best practice?

[Peter Ehlert]

Original post: family is using Zoom.
No alternative for me to participate... Zoom or nothing.
Thanks for the suggestion.
Peter Ehlert
On June 9, 2020 10:56:10 AM Alberto Sentieri <2...@tripolho.com> wrote:


This is a long thread. I did not read it all. Did anyone suggest
http://meet.google.com?

Re: Zoom- best practice?

[Alberto Sentieri]

This is a long thread. I did not read it all. Did anyone suggest 
http://meet.google.com?

Re: Zoom- best practice?

[rhkramer]

On Tuesday, June 09, 2020 05:45:24 AM Nicolas George wrote:
> to...@tuxteam.de (12020-06-09):
> > Can we stop that already? Nobody proved you can't build Jitsi or
> > BBB from source. Everyone here is just too friggin' lazy to even
> > try.
> > 
> > Can we give 'em the benefit of the doubt until someone really makes
> > his hands ditry on that?
> 
> You can be naïve and give them the benefit of the doubt. But I will not.


> Jitsi is a big project, it claims the reputation benefits of being Libre
> Software: the onus of proof is on it.

+1

If a project is new, I'm willing to give a project the benefit of the doubt on 
the assumption that it is a statement of intent, and, as they recognize 
shortcomings, they will fix them.  


> I will state and repeat: until we see actual reliable proof, claiming
> that Jitsi is Libre Software is wrong.
> 
> > That's how fake news spread, btw.
> > 
> > I think it's somewhat disgusting. Folks, put up... or shut up now.
> 
> Your attempt at irrational shaming is dishonest.
> 
> Regards,

Re: Zoom- best practice?

[tomas]

On Tue, Jun 09, 2020 at 06:41:33AM -0400, The Wanderer wrote:
> (Please stop CCing me on replies [...]

Sorry.

[...]

> FWIW, I have tried, at least in part.

Thanks for taking the time to do, and thanks for reporting back.

[...]

> Even a successful build from a repository like that would not
> demonstrate that you can actually completely rebuild the project from
> scratch [...]

Yes, this is a well-known problem with many facets.

ISTR that there was a Lisp which only could build itself: the
whole buildery (which, this being Lisp included everything,
compiler, assembler and all) was written in Lisp, and took
advantage of newer and newer features. A full bootstrap involved
unearthing "old versions" and following the historical evolution
of that thing.

Some "ecosystems", like Java, tend to build up a huge network
of dependencies on "well-known" components -- something I used
to call it the "Java Disease". Until Javascript came with npm,
or PHP with composer. It can get worse.

Building something significant, like Jitsi, lands you in this
hell, and to survive, you end up ingesting those dependencies
(that's what is called "vendoring" -- imo the Euphemism of the
Decennium).

On the other end there are heroes, like the Guix folks [1],
or the reproducible build folks [2] working relentlessly on
disentangling those things. Debian packaging belongs into that
class of heroism.

So from my POV there is a lot to critizice there, and a lot
to fix -- but "this is not free software just because I'm too
lazy to check thoroughly", as some have basically said here
is simply unfair -- and counterproductive.

Cheers

[1] https://guix.gnu.org/
[2] https://reproducible-builds.org/

-- tomás


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[The Wanderer]

On 2020-06-09 at 06:51, Nicolas George wrote:

> The Wanderer (12020-06-09):
> 
>> (Please stop CCing me on replies - especially to messages which I
>> did not actually send - unless you're specifically trying to draw
>> my attention to a particular message and think I may not notice it
>> without the CC. Not only am I subscribed, I am in fact reading this
>> thread on a multiple-times-a-day basis, as my multiple replies to
>> it to date may have indicated.)
> 
> Instead of writing this periodically, you could include:
> Reply-To: debian-user@lists.debian.org
> in your headers just like I did.

Having to add that by hand to every single reply I make would be much
more of a hassle than taking the time to request this explicitly on the
relatively few occasions when people send such CCs with enough frequency
for it to be a bother to me.

> Properly configured mailing-list software does it by default for
> subscribed users, but Debian is an exception. It fixes the issue of
> annoying ccs once and for all.

I subscribe to probably dozens of mailing lists, and I don't know of any
way to configure things to add that header with a proper value
automatically on a per-mailing-list basis. Otherwise, I'd probably have
done this years ago, unless other considerations (e.g., UI for when I
want to do this vs. when I really do want to reply to the sender or to
all recipients) took precedence.

For myself, I use the "Reply to List" button in (a now-old version of)
Thunderbird, and avoid the issue of Reply-To settings entirely unless I
actually do want to reply to something other than just the list.

>> FWIW, I have tried, at least in part.
>> 
>> For the individual broken-out projects (which may or may not be
>> rolled up into the larger "master" project, I can't easily tell), I
>> succeeded with one, and failed with another, but suspect that I
>> could succeed with the latter with more effort.
>> 
>> For the apparent "master" project, I admit that I didn't bother to
>> try, because of the exact "too many prebuilt apparent-dependency
>> objects with no apparent way provided to rebuild them" issue;
>> unless we can rebuild those objects, not only can we not be sure we
>> have the source for them, we can't be sure that building with a
>> different version of that object will even work.
>> 
>> Even a successful build from a repository like that would not 
>> demonstrate that you can actually completely rebuild the project
>> from scratch; you'd have to actually track down the source for all
>> of those individual prebuilt objects, rebuild each one, and pull
>> the result in to the build in a way which will get picked up, and
>> that's more effort than I'm willing to put in for the sake of a
>> mailing-list discussion like this one.
> 
> Thank you for these clarifications.
> 
>> I don't fault the developers too much for providing a version of
>> the project tree with prebuilt dependencies like that; it's a
>> useful convenience for those who just want to get it to work and
>> for whom farting around with trying to find the right dependencies
>> and get them into place would be too much of a hassle. But for (as
>> far as I can tell) providing the tree in *only* that form, and not
>> providing (as far as I've found) *any* documentation on what these
>> prebuilt objects are and why they're needed and how to get them
>> separately and build them and so forth, there I do fault them, and
>> consider that a ding against proper Free status.
> 
> I state it that way: the knowledge of how to obtain and build these 
> objects is part of the source code of the project, just as much as a 
> makefile or configure script. Unfortunately, that bit of source code 
> only resides in the head of the developers, it is not distributed.
> 
> Consider a minified javascript program with a GPL license header
> slapped on top of it: should we consider it Libre Software? Of course
> not. The same happens here: out of negligence probably, the authors
> keep part of the source code for themselves. It is not Libre
> Software.

While I wouldn't necessarily take the argument as far as you appear to,
I am inclined to agree in principle.

That said, while this is an important aspect of the situation, it's
technically a tangent from the question of whether people other than the
developers can build the program and have the result be usable. If we
assume that the developers don't routinely update or replace these
prebuilt objects, and don't hack these objects themselves as part of
working on the project, then the tree we have is the tree the developers
build from - and if we can build a working program from it, then that
narrower question is answered "yes".

I just don't care to bother with doing that myself at present. Which, to
an extent, turns things back to Tomas' point.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the 

Re: Zoom- best practice?

[Nicolas George]

The Wanderer (12020-06-09):
> (Please stop CCing me on replies - especially to messages which I did
> not actually send - unless you're specifically trying to draw my
> attention to a particular message and think I may not notice it without
> the CC. Not only am I subscribed, I am in fact reading this thread on a
> multiple-times-a-day basis, as my multiple replies to it to date may
> have indicated.)

Instead of writing this periodically, you could include:
Reply-To: debian-user@lists.debian.org
in your headers just like I did. Properly configured mailing-list
software does it by default for subscribed users, but Debian is an
exception. It fixes the issue of annoying ccs once and for all.

> FWIW, I have tried, at least in part.
> 
> For the individual broken-out projects (which may or may not be rolled
> up into the larger "master" project, I can't easily tell), I succeeded
> with one, and failed with another, but suspect that I could succeed with
> the latter with more effort.
> 
> For the apparent "master" project, I admit that I didn't bother to try,
> because of the exact "too many prebuilt apparent-dependency objects with
> no apparent way provided to rebuild them" issue; unless we can rebuild
> those objects, not only can we not be sure we have the source for them,
> we can't be sure that building with a different version of that object
> will even work.
> 
> Even a successful build from a repository like that would not
> demonstrate that you can actually completely rebuild the project from
> scratch; you'd have to actually track down the source for all of those
> individual prebuilt objects, rebuild each one, and pull the result in to
> the build in a way which will get picked up, and that's more effort than
> I'm willing to put in for the sake of a mailing-list discussion like
> this one.

Thank you for these clarifications.

> I don't fault the developers too much for providing a version of the
> project tree with prebuilt dependencies like that; it's a useful
> convenience for those who just want to get it to work and for whom
> farting around with trying to find the right dependencies and get them
> into place would be too much of a hassle. But for (as far as I can tell)
> providing the tree in *only* that form, and not providing (as far as
> I've found) *any* documentation on what these prebuilt objects are and
> why they're needed and how to get them separately and build them and so
> forth, there I do fault them, and consider that a ding against proper
> Free status.

I state it that way: the knowledge of how to obtain and build these
objects is part of the source code of the project, just as much as a
makefile or configure script. Unfortunately, that bit of source code
only resides in the head of the developers, it is not distributed.

Consider a minified javascript program with a GPL license header slapped
on top of it: should we consider it Libre Software? Of course not. The
same happens here: out of negligence probably, the authors keep part of
the source code for themselves. It is not Libre Software.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[The Wanderer]

(Please stop CCing me on replies - especially to messages which I did
not actually send - unless you're specifically trying to draw my
attention to a particular message and think I may not notice it without
the CC. Not only am I subscribed, I am in fact reading this thread on a
multiple-times-a-day basis, as my multiple replies to it to date may
have indicated.)

On 2020-06-09 at 04:42, to...@tuxteam.de wrote:

> On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote:

>> If you cannot build an executable from source, you do not know
>> whether the binary you downloaded represents the source
>> faithfully.
> 
> Can we stop that already? Nobody proved you can't build Jitsi or BBB
> from source. Everyone here is just too friggin' lazy to even try.
> 
> Can we give 'em the benefit of the doubt until someone really makes 
> his hands ditry on that?

FWIW, I have tried, at least in part.

For the individual broken-out projects (which may or may not be rolled
up into the larger "master" project, I can't easily tell), I succeeded
with one, and failed with another, but suspect that I could succeed with
the latter with more effort.

For the apparent "master" project, I admit that I didn't bother to try,
because of the exact "too many prebuilt apparent-dependency objects with
no apparent way provided to rebuild them" issue; unless we can rebuild
those objects, not only can we not be sure we have the source for them,
we can't be sure that building with a different version of that object
will even work.

Even a successful build from a repository like that would not
demonstrate that you can actually completely rebuild the project from
scratch; you'd have to actually track down the source for all of those
individual prebuilt objects, rebuild each one, and pull the result in to
the build in a way which will get picked up, and that's more effort than
I'm willing to put in for the sake of a mailing-list discussion like
this one.

I don't fault the developers too much for providing a version of the
project tree with prebuilt dependencies like that; it's a useful
convenience for those who just want to get it to work and for whom
farting around with trying to find the right dependencies and get them
into place would be too much of a hassle. But for (as far as I can tell)
providing the tree in *only* that form, and not providing (as far as
I've found) *any* documentation on what these prebuilt objects are and
why they're needed and how to get them separately and build them and so
forth, there I do fault them, and consider that a ding against proper
Free status.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Nicolas George]

to...@tuxteam.de (12020-06-09):
> Can we stop that already? Nobody proved you can't build Jitsi or
> BBB from source. Everyone here is just too friggin' lazy to even
> try.
> 
> Can we give 'em the benefit of the doubt until someone really makes
> his hands ditry on that?

You can be naïve and give them the benefit of the doubt. But I will not.
Jitsi is a big project, it claims the reputation benefits of being Libre
Software: the onus of proof is on it.

I will state and repeat: until we see actual reliable proof, claiming
that Jitsi is Libre Software is wrong.

> That's how fake news spread, btw.
> 
> I think it's somewhat disgusting. Folks, put up... or shut up now.

Your attempt at irrational shaming is dishonest.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[tomas]

On Mon, Jun 08, 2020 at 02:59:13PM -0600, Tom Dial wrote:
> 
> 
> On 6/7/20 14:14, Russell L. Harris wrote:
> > On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
> >> Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
> >> as shipped in those packages.
> >>
> >> Presumably, as those packages are for download from the authors'
> >> Website, the authors are the ones who built them. Thus, this doesn't
> >> demonstrate that anyone other than the authors have been able to build
> >> Jitsi.
> > 
> > So? It is an open-source alternative to Zoom, and it works.  Of
> > course, if you are worried that the builders put in something
> > malicious or dangerous which is not in the open source repository,
> > then you can turn to Zoom, or build your own, or do without...
> > 
> > Though objectivity is prudent, we ought be promoting alternatives to
> > Zoom, rather than torpedoing them.
> 
> If you cannot build an executable from source, you do not know whether
> the binary you downloaded represents the source faithfully.

Can we stop that already? Nobody proved you can't build Jitsi or
BBB from source. Everyone here is just too friggin' lazy to even
try.

Can we give 'em the benefit of the doubt until someone really makes
his hands ditry on that?

That's how fake news spread, btw.

I think it's somewhat disgusting. Folks, put up... or shut up now.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Tom Dial]

On 6/7/20 14:14, Russell L. Harris wrote:
> On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
>> Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
>> as shipped in those packages.
>>
>> Presumably, as those packages are for download from the authors'
>> Website, the authors are the ones who built them. Thus, this doesn't
>> demonstrate that anyone other than the authors have been able to build
>> Jitsi.
> 
> So? It is an open-source alternative to Zoom, and it works.  Of
> course, if you are worried that the builders put in something
> malicious or dangerous which is not in the open source repository,
> then you can turn to Zoom, or build your own, or do without...
> 
> Though objectivity is prudent, we ought be promoting alternatives to
> Zoom, rather than torpedoing them.

If you cannot build an executable from source, you do not know whether
the binary you downloaded represents the source faithfully. Even if you
have the source, it would take great effort and use of some fairly
esoteric tools to verify that the product is what it says it is, and
does what it says it does (and no more).

As I understand, that is a primary goal of Debian's fairly extensive
effort to ensure that builds for its packages are reproducible.


Building from source is not the only requisite for such assurance,
however. Ken Thompson's ACM Turing Award lecture, "Reflections on
Trusting Trust" [1] is an interesting take on this aspect of security.


Free (or even open source) is a good software characteristic, but it is
not the only one that counts, or even the most important one. Sometimes,
as it may be with Zoom, a closed source commercial product is better
than free alternatives. Even where that is not so such a product may, as
Zoom is, be so much more widely used that it is much more useful as a
general matter.

Regards
Tom Dial

[1] https://dl.acm.org/doi/10.1145/358198.358210

> 
> RLH

Re: Zoom- best practice?

[Anastasios Lisgaras]

On 6/8/20 12:06 AM, Nicolas George wrote:

Open Source is not enough.

I did not think it would be necessary to explain why Libre Software is
important here. It is not just a matter of possible malicious in the
code, it is a matter of being able to change it to suit our needs, to
fix it if there are bugs, to include parts into other projects. If all
of this is not possible, it is a dead-end project, a waste of energy,
only marginally better than closed-source surveillanceware.

Regards,


An interesting point of view that I agree with.
It is a very delicate and important piece, which some consider a detail 
or do not pay attention to. But personally I agree with you, it matters.


But, do you mention this because of the jitsi license that is *Apache 
License 2.0 ?

https://github.com/jitsi/jitsi-videobridge

--
Kind regards,
Anastasios Lisgaras

Re: Zoom- best practice?

[Dan Ritter]

David Wright wrote: 
> On Sun 07 Jun 2020 at 19:30:19 (+), Russell L. Harris wrote:
> > On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote:
> > > to...@tuxteam.de (12020-06-07):
> > > > Yes, the server is free software. As is Jitsi's. So you can get the
> > > > source, build yourself or download pre-built thingies.
> > > 
> > > Do you have evidence of somebody other than the authors themselves
> > > having managed to build it?
> > 
> > A few months ago, I installed a Jitsi server from Debian packages
> > downloaded from the Jitsi web site.
> 
> What do you mean by Jitsi server from Debian packages? I get:
> 
>"You have searched for packages that names contain jitsi in all
>suites, all sections, and all architectures.
> 
>"Sorry, your search gave no results"

The Jitsi team is currently making a .deb repo available, and
updating every 2-3 days. I presume that when it's stable,
they'll offer it to Debian proper -- it's all under Apache
License 2.0, no problems including it in main.

deb https://download.jitsi.org stable/

-dsr-

Re: Zoom- best practice?

[David Wright]

On Sun 07 Jun 2020 at 19:30:19 (+), Russell L. Harris wrote:
> On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote:
> > to...@tuxteam.de (12020-06-07):
> > > Yes, the server is free software. As is Jitsi's. So you can get the
> > > source, build yourself or download pre-built thingies.
> > 
> > Do you have evidence of somebody other than the authors themselves
> > having managed to build it?
> 
> A few months ago, I installed a Jitsi server from Debian packages
> downloaded from the Jitsi web site.

What do you mean by Jitsi server from Debian packages? I get:

   "You have searched for packages that names contain jitsi in all
   suites, all sections, and all architectures.

   "Sorry, your search gave no results"

Cheers,
David.

Re: Zoom- best practice?

[tomas]

On Sun, Jun 07, 2020 at 11:17:39PM +0100, Brian wrote:
> On Sun 07 Jun 2020 at 22:24:56 +0200, to...@tuxteam.de wrote:
> 
> > On Sun, Jun 07, 2020 at 09:07:59PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > Nicolas George states the obvious. All modern VoIP involves immense
> > > resources to deliver to users.
> > 
> > A bit handwawy at that point: do you mean it's a complex programming
> > task or it needs network resources (bandwidth, low latency)?
> 
> Both, but mainly the latter. And lots of organisation and money.

As for the latter: these folks [1] (sorry, in German), Freifunk München
tinker around with mesh networking to offer free WiFi in the city of
Munich (there are similar groups in other cities) and are experimenting
with a distributed Jitsi videobridge which reportedly has supported
up to 200 sessions. You can view current stats here [2].

Defetism is unsexy ;-)

Cheers

[1] https://ffmuc.net/
[2] https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1=1m

-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Brian]

On Sun 07 Jun 2020 at 22:24:56 +0200, to...@tuxteam.de wrote:

> On Sun, Jun 07, 2020 at 09:07:59PM +0100, Brian wrote:
> 
> [...]
> 
> > Nicolas George states the obvious. All modern VoIP involves immense
> > resources to deliver to users.
> 
> A bit handwawy at that point: do you mean it's a complex programming
> task or it needs network resources (bandwidth, low latency)?

Both, but mainly the latter. And lots of organisation and money.

> > Resources cost money. Linux Central is out of funds.
> 
> Who is Linux Central?

The entity that funds VoIP facilities like Zoom and WhatsApp. It doesn't
exist and never will. Therefore, there will never be any Libre Software
competitors to the commercial videoconferencing offerings.

-- 
Brian.

Re: Zoom- best practice?

[The Wanderer]

On 2020-06-07 at 16:14, Russell L. Harris wrote:

> On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:
> 
>> Yeah, but that's not building Jitsi; that's installing a prebuilt
>> Jitsi, as shipped in those packages.
>> 
>> Presumably, as those packages are for download from the authors'
>> Website, the authors are the ones who built them. Thus, this
>> doesn't demonstrate that anyone other than the authors have been
>> able to build Jitsi.
> 
> So? It is an open-source alternative to Zoom, and it works.

The post to which you were responding had just asked the question

>>> Do you have evidence of somebody other than the authors
>>> themselves having managed to build it?

and, because your post started immediately after that, I inferred that
it was intended to be a response to that question.

As far as I can see, your post does not seem to provide any such
evidence. I was pointing that out.

If I parse you correctly, you now seem to be asserting that this is not
an appropriate / relevant question. However, your previous post did not
seem to make clear that you were doing so.

> Of course, if you are worried that the builders put in something
> malicious or dangerous which is not in the open source repository,
> then you can turn to Zoom, or build your own, or do without...
> 
> Though objectivity is prudent, we ought be promoting alternatives to
> Zoom, rather than torpedoing them.

While this is true, and would be on-topic for the thread if the OP
hadn't already said that anything but Zoom is a nonstarter because Zoom
is what the people he needs to speak with are already using and they
aren't going to change, it's not relevant to the question to which your
comments were posted as a reply.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Nicolas George]

Russell L. Harris (12020-06-07):
> So? It is an open-source alternative to Zoom, and it works.  Of
> course, if you are worried that the builders put in something
> malicious or dangerous which is not in the open source repository,
> then you can turn to Zoom, or build your own, or do without...
> 
> Though objectivity is prudent, we ought be promoting alternatives to
> Zoom, rather than torpedoing them.

Open Source is not enough.

I did not think it would be necessary to explain why Libre Software is
important here. It is not just a matter of possible malicious in the
code, it is a matter of being able to change it to suit our needs, to
fix it if there are bugs, to include parts into other projects. If all
of this is not possible, it is a dead-end project, a waste of energy,
only marginally better than closed-source surveillanceware.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[Russell L. Harris]

On Sun, Jun 07, 2020 at 03:56:17PM -0400, The Wanderer wrote:

Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
as shipped in those packages.

Presumably, as those packages are for download from the authors'
Website, the authors are the ones who built them. Thus, this doesn't
demonstrate that anyone other than the authors have been able to build
Jitsi.


So? It is an open-source alternative to Zoom, and it works.  Of
course, if you are worried that the builders put in something
malicious or dangerous which is not in the open source repository,
then you can turn to Zoom, or build your own, or do without...

Though objectivity is prudent, we ought be promoting alternatives to
Zoom, rather than torpedoing them.

RLH

Re: Zoom- best practice?

[tomas]

On Sun, Jun 07, 2020 at 09:07:59PM +0100, Brian wrote:

[...]

> Nicolas George states the obvious. All modern VoIP involves immense
> resources to deliver to users.

A bit handwawy at that point: do you mean it's a complex programming
task or it needs network resources (bandwidth, low latency)?

> Resources cost money. Linux Central is out of funds.

Who is Linux Central?

> Videoconferencing on a mass scale is beyond the capabilities of what
> is available in Debian.

Debian is a distribution. Very little (relative to the whole packaged
content) is written explicitly for Debian/by Debian developers.

You don't really make sense, sorry.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Brian]

On Sun 07 Jun 2020 at 21:19:08 +0200, to...@tuxteam.de wrote:

> On Sun, Jun 07, 2020 at 08:57:54PM +0200, Nicolas George wrote:
> > to...@tuxteam.de (12020-06-07):
> > > No. But I haven't tried, so...
> > 
> > Well, me neither. But if I have not tried personally, I know people who
> > have tried and failed.
> > 
> > If only the authors can build a software, it cannot be considered Libre
> > Software, since part of the source code is missing. Open Source at best.
> > 
> > We have to acknowledge: there are no Libre Software solutions for
> > videoconferencing.
> 
> You may acknowledge what you want. I don't. As long as I don't try
> to make my fingers dirty, I'll refrain from issuing any judgement.
> 
> You keep your belief. I stay agnostic, at this stage.

Nicolas George states the obvious. All modern VoIP involves immense
resources to deliver to users. Resources cost money. Linux Central
is out of funds.

Videoconferencing on a mass scale is beyond the capabilities of what
is available in Debian.

-- 
Brian

Re: Zoom- best practice?

[The Wanderer]

On 2020-06-07 at 15:30, Russell L. Harris wrote:

> On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote:
> 
>> to...@tuxteam.de (12020-06-07):
>> 
>>> Yes, the server is free software. As is Jitsi's. So you can get
>>> the source, build yourself or download pre-built thingies.
>> 
>> Do you have evidence of somebody other than the authors themselves 
>> having managed to build it?
> 
> A few months ago, I installed a Jitsi server from Debian packages 
> downloaded from the Jitsi web site.  The installation was on an old 
> machine (Intel or AMD64) running Debian (9 or 10).  I followed the 
> instructions in an installation video produced by Jitsi; the 
> installation was without difficulty.  I and a friend then 
> video-conferenced over the system; everything worked "as
> advertised".

Yeah, but that's not building Jitsi; that's installing a prebuilt Jitsi,
as shipped in those packages.

Presumably, as those packages are for download from the authors'
Website, the authors are the ones who built them. Thus, this doesn't
demonstrate that anyone other than the authors have been able to build
Jitsi.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Russell L. Harris]

On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote:

to...@tuxteam.de (12020-06-07):

Yes, the server is free software. As is Jitsi's. So you can get the
source, build yourself or download pre-built thingies.


Do you have evidence of somebody other than the authors themselves
having managed to build it?


A few months ago, I installed a Jitsi server from Debian packages
downloaded from the Jitsi web site.  The installation was on an old
machine (Intel or AMD64) running Debian (9 or 10).  I followed the
instructions in an installation video produced by Jitsi; the
installation was without difficulty.  I and a friend then
video-conferenced over the system; everything worked "as advertised".
I am out in central Texas, with a low-bandwidth Internet connection
provided by a microwave link.

Re: Zoom- best practice?

[The Wanderer]

On 2020-06-07 at 15:34, Nicolas George wrote:

> Darac Marjal (12020-06-07):
> 
>> That's a rather ironic thing to say on a Debian mailing list :)
> 
> To the best of my knowledge, Debian is not the author of most
> packages, and yet build them from source themselves: that proves the
> packages are actually Libre Software. Again to the best of my
> knowledge, for most packages, any user can rebuild them from source
> and it works, Debian makes a lot of effort for that.
> 
> Can you say the same for these repositories?

FWIW, in response to this thread I just went on an attempt to build
Jitsi myself. As far as I can tell at a skim of their Website and GitHub
pages, this seems to consist of two components, which are kept in
separate repositories and built / packaged separately: jitsi-meet /
jitsi-meet-web, the Web-interface UI for accessing the system, and
jitsi-videobridge, the actual videoconferencing backend (or something
like that).

I was able to successfully build a jitsi-videobridge Debian package from
current GitHub master, via dpkg-buildpackage, with only a little
difficulty and a few false starts.

I failed utterly in building a jitsi-meet(-web) Debian package from
current GitHub master by the same method; at least one file it relies
upon early in the build (css/all.css) is not included in the repository,
the tools it appears to expect to use to build that file do not appear
to be included or declared as build dependencies, and I don't see any
build documentation at all aside from debian/rules and the (generated?)
Makefile.

I could probably bang my head against this wall for a while longer and
get it working, but I don't care to install more things onto my machine
in stabs in the dark for something I don't actually currently plan to use.

So your point about this at least not being straightforward to build
seems proven, at least to a first-effort approximation.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Nicolas George]

Darac Marjal (12020-06-07):
> That's a rather ironic thing to say on a Debian mailing list :)

To the best of my knowledge, Debian is not the author of most packages,
and yet build them from source themselves: that proves the packages are
actually Libre Software. Again to the best of my knowledge, for most
packages, any user can rebuild them from source and it works, Debian
makes a lot of effort for that.

Can you say the same for these repositories?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[Darac Marjal]

On 07/06/2020 20:21, Nicolas George wrote:
> Seeds Notoneofmy (12020-06-07):
>> Having said all that, the instructions to get BBB going seems solid.
>> Perhaps someone here with a bit of knowhow will do this and then put a
>> guide here? That would be very, very nice:
>>
>> Here's my contribution:
>>
>> https://docs.bigbluebutton.org/2.2/install.html
> Installing from a binary repository: yes, that works. But that's not
> Libre Software.

That's a rather ironic thing to say on a Debian mailing list :)





signature.asc
Description: OpenPGP digital signature

Re: Zoom- best practice?

[Nicolas George]

Seeds Notoneofmy (12020-06-07):
> Having said all that, the instructions to get BBB going seems solid.
> Perhaps someone here with a bit of knowhow will do this and then put a
> guide here? That would be very, very nice:
> 
> Here's my contribution:
> 
> https://docs.bigbluebutton.org/2.2/install.html

Installing from a binary repository: yes, that works. But that's not
Libre Software.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[tomas]

On Sun, Jun 07, 2020 at 08:57:54PM +0200, Nicolas George wrote:
> to...@tuxteam.de (12020-06-07):
> > No. But I haven't tried, so...
> 
> Well, me neither. But if I have not tried personally, I know people who
> have tried and failed.
> 
> If only the authors can build a software, it cannot be considered Libre
> Software, since part of the source code is missing. Open Source at best.
> 
> We have to acknowledge: there are no Libre Software solutions for
> videoconferencing.

You may acknowledge what you want. I don't. As long as I don't try
to make my fingers dirty, I'll refrain from issuing any judgement.

You keep your belief. I stay agnostic, at this stage.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Peter Ehlert]

On 6/7/20 11:53 AM, Brian wrote:

On Sun 07 Jun 2020 at 20:37:55 +0200, Nicolas George wrote:


to...@tuxteam.de (12020-06-07):

Yes, the server is free software. As is Jitsi's. So you can get the
source, build yourself or download pre-built thingies.

Do you have evidence of somebody other than the authors themselves
having managed to build it?

The OP says:

   > Family is using Zoom, International.
   > They will use Zoom, and I need to participate.

If he wishes to participate he uses Zoom.


Correct.

The family has meetings with Zoom, I wish to attend... so I will use Zoom.

That is the bottom line.
sorry I was not super clear about that point at the onset.

I really do appreciate the suggestions for alternate solutions... I may 
use that info for

different groups.



There isn't any interworking
between it and other similar programs. Discussion about Zoom can go on
endlessly. It doesn't alter the technical fact.

Re: Zoom- best practice?

[Seeds Notoneofmy]

On 6/7/20 8:57 PM, Nicolas George wrote:

We have to acknowledge: there are no Libre Software solutions for
videoconferencing.


Having said all that, the instructions to get BBB going seems solid.
Perhaps someone here with a bit of knowhow will do this and then put a
guide here? That would be very, very nice:

Here's my contribution:

https://docs.bigbluebutton.org/2.2/install.html

Re: Zoom- best practice?

[Seeds Notoneofmy]

On 6/7/20 8:57 PM, Nicolas George wrote:

We have to acknowledge: there are no Libre Software solutions for
videoconferencing.


Well, that's about wrap this thread up. Thanks. And I'm glad I did not
proceed with the BBB promise. They've been around since 2007, but we
cannot say of them, an alternative to Zoom, skype, etc. So, what is it;
putting out stuff that only they could really use. Now! that's what I
call a project.

If I were a developer, here's my system for putting stuff online

develop my code

put it on github asking for contributors, not advertising it as a
solution for any problem(s), or for anyone to use

introduce it in forums like these, asking for testers

and when all that is done, build a website and then promise that this
will solve XYZ computing problem/need(s)

to dream up an idea, throw code together and advertise the claim to have
solved a problem when only you and your cat can use it is, well, 'false
advertising.' :)

Re: Zoom- best practice?

[Seeds Notoneofmy]

On 6/7/20 8:37 PM, Nicolas George wrote:


Do you have evidence of somebody other than the authors themselves
having managed to build it?


This made me laugh, as I know where it's coming from; over promise,
under deliver. Of course, it works; in theory. But in practice, well,
that could take /you /the user, a lifetime.

Re: Zoom- best practice?

[Nicolas George]

to...@tuxteam.de (12020-06-07):
> No. But I haven't tried, so...

Well, me neither. But if I have not tried personally, I know people who
have tried and failed.

If only the authors can build a software, it cannot be considered Libre
Software, since part of the source code is missing. Open Source at best.

We have to acknowledge: there are no Libre Software solutions for
videoconferencing.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[tomas]

On Sun, Jun 07, 2020 at 08:37:55PM +0200, Nicolas George wrote:
> to...@tuxteam.de (12020-06-07):
> > Yes, the server is free software. As is Jitsi's. So you can get the
> > source, build yourself or download pre-built thingies.
> 
> Do you have evidence of somebody other than the authors themselves
> having managed to build it?

No. But I haven't tried, so...

Cheers
-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Brian]

On Sun 07 Jun 2020 at 20:37:55 +0200, Nicolas George wrote:

> to...@tuxteam.de (12020-06-07):
> > Yes, the server is free software. As is Jitsi's. So you can get the
> > source, build yourself or download pre-built thingies.
>
> Do you have evidence of somebody other than the authors themselves
> having managed to build it?

The OP says:

  > Family is using Zoom, International.
  > They will use Zoom, and I need to participate.

If he wishes to participate he uses Zoom. There isn't any interworking
between it and other similar programs. Discussion about Zoom can go on
endlessly. It doesn't alter the technical fact.

-- 
Brian.

Re: Zoom- best practice?

[rhkramer]

On Sunday, June 07, 2020 02:23:04 PM Seeds Notoneofmy wrote:
> I just looked into this, having had an issue with Zoom recently. And it
> seems it allows for installing the server locally? Am I understanding
> this right, that one can have their own BBB server and provide access to
> others to connect to and share/chat?
> 
> If that's the case, why would anyone need skype, zoom, etc? Only would
> need to secure one's own BBB server properly. Can someone confirm, please?

Without knowing for sure, I believe I've read that a jitsi server can be 
local, and it wouldn't surprise me that a BBB server can be local.

My guess is, though, that the server needs more bandwidth than any of the 
participants including the moderator / host (on a system like zoom).





 
> https://github.com/bigbluebutton/bbb-install

Re: Zoom- best practice?

[Nicolas George]

to...@tuxteam.de (12020-06-07):
> Yes, the server is free software. As is Jitsi's. So you can get the
> source, build yourself or download pre-built thingies.

Do you have evidence of somebody other than the authors themselves
having managed to build it?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Zoom- best practice?

[tomas]

On Sun, Jun 07, 2020 at 08:23:04PM +0200, Seeds Notoneofmy wrote:
> On 6/5/20 8:57 PM, Peter Ehlert wrote:
> 
> >>Look into Big Blue Button and see if you can get your family to try
> >>that instead.
> >
> >bigbluebutton is interesting. Thanks for the thought.
> >
> >Many family members use Zoom, and like me, are past seven decades.
> >Several of the younger set use Zoom also.
> >I think I will not suggest change, I am the lone wolf.
> >
> I just looked into this, having had an issue with Zoom recently. And it
> seems it allows for installing the server locally? Am I understanding
> this right, that one can have their own BBB server and provide access to
> others to connect to and share/chat?
> 
> If that's the case, why would anyone need skype, zoom, etc? Only would
> need to secure one's own BBB server properly. Can someone confirm, please?

Yes, the server is free software. As is Jitsi's. So you can get the
source, build yourself or download pre-built thingies.

There are fairly recent articles on both of them over at lwn:

Jitsi: https://lwn.net/Articles/815751/
BigBlueButton: https://lwn.net/Articles/817146/

Cheers
-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Jude DaShiell]

There's also barnard for the linux command line users sometimes needs
compiling using go.

On Sun, 7 Jun 2020, Admin4 wrote:

> Date: Sun, 7 Jun 2020 14:00:19
> From: Admin4 
> To: debian-user@lists.debian.org
> Subject: Re: Zoom- best practice?
> Resent-Date: Sun,  7 Jun 2020 18:00:35 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> btw. if audio + chat WOULD be sufficient (it can handle a lot of
> participants)
>
> try mumble! :)
>
> https://sourceforge.net/projects/mumble/
>
> the Android App is called "plumble"
>
> https://f-droid.org/en/packages/com.morlunk.mumbleclient/
>
>   * Client + Server is 100% Open Source
>   * mumble server is easy to setup
>   * mumble client is also pretty easy to setup
>   o headphones / headset recommended
>   * encrypted communication (128 bit OCB-AES128)
>
> apt update
>
> # server
>
> apt install murmur;
>
> # client
>
> apt install mumble;
>
> give it a call:
>
> https://audio-konferenz-server.de/
>
> (sever is running CentOS X-D but Client is Debian 10 :) )
>
> just 4 info
>
> On 6/7/20 3:42 PM, Peter Ehlert wrote:
> >
> > On 6/6/20 10:00 PM, Keith bainbridge wrote:
> >> On 6/6/20 3:32 am, john doe wrote:
> >>> On 6/5/2020 6:28 PM, Peter Ehlert wrote:
> >>>> Family is using Zoom, International.
> >>>> They will use Zoom, and I need to participate.
> >>>>
> >>>> I use Debian Mate Stable, and Firefox ESR
> >>>>
> >>>> I am concerned about security, duh!
> >>>> Looking for ideas.
> >>>>
> >>>> my current thoughts, in order of preference:
> >>>>
> >>>> 1. Use a separate Debian alongside my daily driver, and use Only
> >>>> for the
> >>>> Zoom meetings
> >>>>
> >>>
> >>> I would install a Debian VM for Zoom and alike software.
> >>>
> >>> --?
> >>> John Doe
> >>>
> >>
> >>
> >> I did too - until somebody suggested firejail.
> >
> > I am not a Chromium user... and I don't like to fight the VMs
> >
> > Firefox does have a number of addon privacy tools...
> > this one looks interesting: https://add0n.com/privacy-settings.html
> >>
> >> I always got prompts to install add-ons in chromium.
> >>
> >
>

-- 

Re: Zoom- best practice?

[Seeds Notoneofmy]

On 6/5/20 8:57 PM, Peter Ehlert wrote:


Look into Big Blue Button and see if you can get your family to try
that instead.


bigbluebutton is interesting. Thanks for the thought.

Many family members use Zoom, and like me, are past seven decades.
Several of the younger set use Zoom also.
I think I will not suggest change, I am the lone wolf.


I just looked into this, having had an issue with Zoom recently. And it
seems it allows for installing the server locally? Am I understanding
this right, that one can have their own BBB server and provide access to
others to connect to and share/chat?

If that's the case, why would anyone need skype, zoom, etc? Only would
need to secure one's own BBB server properly. Can someone confirm, please?

https://github.com/bigbluebutton/bbb-install

Re: Zoom- best practice?

[Seeds Notoneofmy]

On 6/5/20 7:09 PM, Greg Wooledge wrote:


  I did not test with Chromium or Firefox or anything else.

Just tried it two days ago on Firefox. It was a disaster. No sound. And
screensharing did not work, at all.

Re: Zoom- best practice?

[Admin4]

btw. if audio + chat WOULD be sufficient (it can handle a lot of
participants)

try mumble! :)

https://sourceforge.net/projects/mumble/

the Android App is called "plumble"

https://f-droid.org/en/packages/com.morlunk.mumbleclient/

  * Client + Server is 100% Open Source
  * mumble server is easy to setup
  * mumble client is also pretty easy to setup
  o headphones / headset recommended
  * encrypted communication (128 bit OCB-AES128)

apt update

# server

apt install murmur;

# client

apt install mumble;

give it a call:

https://audio-konferenz-server.de/

(sever is running CentOS X-D but Client is Debian 10 :) )

just 4 info

On 6/7/20 3:42 PM, Peter Ehlert wrote:
>
> On 6/6/20 10:00 PM, Keith bainbridge wrote:
>> On 6/6/20 3:32 am, john doe wrote:
>>> On 6/5/2020 6:28 PM, Peter Ehlert wrote:
 Family is using Zoom, International.
 They will use Zoom, and I need to participate.

 I use Debian Mate Stable, and Firefox ESR

 I am concerned about security, duh!
 Looking for ideas.

 my current thoughts, in order of preference:

 1. Use a separate Debian alongside my daily driver, and use Only
 for the
 Zoom meetings

>>>
>>> I would install a Debian VM for Zoom and alike software.
>>>
>>> -- 
>>> John Doe
>>>
>>
>>
>> I did too - until somebody suggested firejail.
>
> I am not a Chromium user... and I don't like to fight the VMs
>
> Firefox does have a number of addon privacy tools...
> this one looks interesting: https://add0n.com/privacy-settings.html
>>
>> I always got prompts to install add-ons in chromium.
>>
>

Re: Zoom- best practice?

[Peter Ehlert]

On 6/6/20 10:00 PM, Keith bainbridge wrote:

On 6/6/20 3:32 am, john doe wrote:

On 6/5/2020 6:28 PM, Peter Ehlert wrote:

Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for 
the

Zoom meetings



I would install a Debian VM for Zoom and alike software.

--
John Doe




I did too - until somebody suggested firejail.


I am not a Chromium user... and I don't like to fight the VMs

Firefox does have a number of addon privacy tools...
this one looks interesting: https://add0n.com/privacy-settings.html


I always got prompts to install add-ons in chromium.

Re: Zoom- best practice?

[Keith bainbridge]

On 6/6/20 3:32 am, john doe wrote:

On 6/5/2020 6:28 PM, Peter Ehlert wrote:

Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for the
Zoom meetings



I would install a Debian VM for Zoom and alike software.

--
John Doe




I did too - until somebody suggested firejail.

I always got prompts to install add-ons in chromium.

--

Keith Bainbridge

keithr...@gmail.com

0447 667468

Re: Zoom- best practice?

[Paul Johnson]

On Sat, Jun 6, 2020 at 10:49 AM  wrote:

> On Sat, Jun 06, 2020 at 01:06:02PM +0200, Alex Mestiashvili wrote:
>
> > [...] Btw BBB is also far away from a secure platform imho.
>
> Quite possible. Still, you can choose a server run by people you
> trust. And the developers seem to be quite responsive.
>

This would be why OpenStreetMap recently switched to BBB.

Re: Zoom- best practice?

[tomas]

On Sat, Jun 06, 2020 at 01:06:02PM +0200, Alex Mestiashvili wrote:

> [...] Btw BBB is also far away from a secure platform imho.

Quite possible. Still, you can choose a server run by people you
trust. And the developers seem to be quite responsive.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Alex Mestiashvili]

On 6/6/20 12:13 AM, Linux-Fan wrote:
> Peter Ehlert writes:
> 
>> Family is using Zoom, International.
>> They will use Zoom, and I need to participate.
>>
>> I use Debian Mate Stable, and Firefox ESR
>>
>> I am concerned about security, duh!
>> Looking for ideas.
>>
>> my current thoughts, in order of preference:
>>
>> 1. Use a separate Debian alongside my daily driver, and use Only for the Zoom
>> meetings
>>
>> 2. Sandbox? (but how can I do that?)
>>
>> 3. Use a different browser
> 
> [...]
> 
> Hello,
> 
> best practice is certainly using different software (Big Blue Button has been
> mentioned, Jitsi works OK for small groups, say ~10 persons, too), but there 
> are
> cases where I am not asked to decide the software. At least, Zoom works on 
> Linux
> whereas e.g. Skype for Business doesn't despite claiming to have a „Web App“?
> 
> I am also using Zoom (not by preference, see above) and thought about ways to
> isolate it for which I basically came up with a similar list to yours. Here is
> what I did so far:
> 
> * Zoom inside a VM works well here. I use Virt-Manager + KVM and
>   audio works flawlessly without the need for much additional configuration.
>   I only added this line to .config/pulse/daemon.conf:
> 
> flat-volumes = no
> 
>   This makes sure that opening the VM does not reset volume back to 100%
>   which is dangerously loud on my sound card, see
>    :)
> 
> * As a fallback solution, I setup a sandbox for chromium using firejail
>   (package firejail) with a custom profile (attached for those interested).
> 
>   If you do not like the VM approach, you might consider a sandbox around
>   the zoom client. Of course, it is possible to use the sandbox inside the
>   VM, too. I doubt the added security of combining VM+sandbox is worth the
>   added complexity, though.
> 
> Using an entirely different system is certainly an option security-wise (if
> network isolation is considered properly), but might have some additional
> practical limitations.
> 
> HTH
> Linux-Fan


Thanks for sharing firejail profile, however doesn't it work in the browser?
It is really hidden though, but if you decline 2 times software installation in
the Chrome you get a link to join zoom via browser. That's what I had to use a
couple of times.

The best practice is to avoid installing zoom debian package at all. Btw BBB is
also far away from a secure platform imho.

Re: Zoom- best practice?

[tomas]

On Sat, Jun 06, 2020 at 12:13:28AM +0200, Linux-Fan wrote:

[...]

> Hello,
> 
> best practice is certainly using different software

+100

[...]

>(Big Blue Button
> has been mentioned, Jitsi works OK for small groups, say ~10
> persons, too) [...]

FWIW, it seems to be an infrastructure question. The Munich Freifunk
folks [1] (sorry, in German) are experimenting with cascaded Jitsi
video bridges and report conferences of up to ~200. Here [2] (sorry,
javascript infested, but colorful stats) is their current stats
page.

So it seems worth investing into that. Again a reason more to foster
strong tech groups (local Linux users, hackerspaces, what not) around
you.

Cheers

[1] https://ffmuc.net/
[2] https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1=1m

-- t


signature.asc
Description: Digital signature

Re: Zoom- best practice?

[Tom Dial]

On 6/5/20 13:48, Brian wrote:
> On Fri 05 Jun 2020 at 09:28:21 -0700, Peter Ehlert wrote:
> 
>> Family is using Zoom, International.
>> They will use Zoom, and I need to participate.
> 
> Seems straightforward. Just get on with it.
>  
>> I use Debian Mate Stable, and Firefox ESR
>>
>> I am concerned about security, duh!
> 
> Really? Just get on with communicating with your family. That's a bit
> more important than worrying about possible non-existent issues and 
> basing your actions on them.
> 

I'll second this and offer a couple of additional comments.

On Debian Buster with Gnome, pretty vanilla except for google-chrome and
some R packages from r-cran, I downloaded the Zoom .deb package and
installed it [1], as root, in /opt, with no dependency issues that
another responder noted might interfere. The only issue of any
consequence was that on a 15 inch 3840 x 2160 screen, the boxes were
quite small and the print in the window titles and popups was too small
to read w/o a strong magnifier. It took a while, but of searching in
Zoom's FAQs provided a solution [2].


Security issues whooped up in the media seem to fall mostly into one or
more of three boxes:

Affect (or are known to affect) only Macs;

Have been corrected, some quite a while ago;

User error (e. g., setting up for zoom-bombing by failing to use a
password, using an obvious password, or letting the password leak.

Some appear unworthy of much concern, like early use of 128 bit AES for
session encryption. Clearly of interest if a meeting concerns national
security or other public policy matters, or important organization or
personal privacy matters. Most personal/family communications probably
do not involve such things.

Running it in a VM might improve security, although one responder
mentioned sound pass-through as an issue, and setup, at best, would be
more work. Dedicated hardware, if you have it probably would be a better
choice for isolation.

An alternative would be to install Debian and Zoom on a USB key or
drive. I would expect USB2 to be adequate, although maybe a bit sluggish
at times.

You also could put the machine on a guest WiFi to isolate it from other
machines.

As with all software, keep it up to date. With Zoom's present rate of
update, that could be as often as before every use. All the other users
also should keep theirs up to date.

Zoom users, of course, should be aware (a) that free subscriptions are
not encrypted end-to-end and (b) Zoom cooperates with law enforcement
agencies, probably meaning that they will allow interception if
presented with an appropriate warrant (in the US; other nations' laws
are different).

Cloud session storage might also be an issue, although the Debian client
session recording appears to be local when activated.

Regards,
Tom Dial

[1] Using apt install, and the absolute path, instead of dpkg, may have
helped resolve dependencies; I have seen reports to that effect.

[2] scaleFactor=2 in .config/zoomus.conf instead of default scaleFactor=1.

Re: Zoom- best practice?

[Dominik George]

>> Family is using Zoom, International.
>> They will use Zoom, and I need to participate.
>
>Seems straightforward. Just get on with it.

Don't. Zoom is not necessary to stay in touch with family. If you cannot get 
another video conferencing provider, use a phone. But do not prove to providers 
such as Zoom that you need them for your most intimate needs — it fuels their 
wrong-doing.

Also, I had the impression that this were a technical support mailing list, not 
a family therapist forum.

-nik

Re: Zoom- best practice?

[Linux-Fan]

Peter Ehlert writes:


Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for the  
Zoom meetings


2. Sandbox? (but how can I do that?)

3. Use a different browser


[...]

Hello,

best practice is certainly using different software (Big Blue Button has  
been mentioned, Jitsi works OK for small groups, say ~10 persons, too), but  
there are cases where I am not asked to decide the software. At least, Zoom  
works on Linux whereas e.g. Skype for Business doesn't despite claiming to  
have a „Web App“?


I am also using Zoom (not by preference, see above) and thought about ways  
to isolate it for which I basically came up with a similar list to yours.  
Here is what I did so far:


* Zoom inside a VM works well here. I use Virt-Manager + KVM and
  audio works flawlessly without the need for much additional configuration.
  I only added this line to .config/pulse/daemon.conf:

flat-volumes = no

  This makes sure that opening the VM does not reset volume back to 100%
  which is dangerously loud on my sound card, see
   :)

* As a fallback solution, I setup a sandbox for chromium using firejail
  (package firejail) with a custom profile (attached for those interested).

  If you do not like the VM approach, you might consider a sandbox around
  the zoom client. Of course, it is possible to use the sandbox inside the
  VM, too. I doubt the added security of combining VM+sandbox is worth the
  added complexity, though.

Using an entirely different system is certainly an option security-wise (if  
network isolation is considered properly), but might have some additional  
practical limitations.


HTH
Linux-Fan
include /etc/firejail/disable-programs.inc
include /etc/firejail/disable-passwdmgr.inc
include /etc/firejail/disable-common.inc
include /etc/firejail/disable-devel.inc
include /etc/firejail/disable-interpreters.inc
include /etc/firejail/whitelist-var-common.inc

blacklist /var/log
blacklist /var/www
blacklist /boot
blacklist /root
blacklist /opt
blacklist /srv
blacklist /media

apparmor
netfilter
disable-mnt
private-dev
# problems with multiple browser sessions
private-tmp

#caps.keep sys_chroot,sys_admin
nodbus
nodvd
nogroups
notv
#nonewprivs
nou2f
noexec /tmp

env NO_CHROME_KDE_FILE_DIALOG=1
shell none

#caps.drop all


pgpH3j5Vj51VD.pgp
Description: PGP signature

Re: Zoom- best practice?

[Brian]

On Fri 05 Jun 2020 at 09:28:21 -0700, Peter Ehlert wrote:

> Family is using Zoom, International.
> They will use Zoom, and I need to participate.

Seems straightforward. Just get on with it.
 
> I use Debian Mate Stable, and Firefox ESR
> 
> I am concerned about security, duh!

Really? Just get on with communicating with your family. That's a bit
more important than worrying about possible non-existent issues and 
basing your actions on them.

-- 
Brian.

Re: Zoom- best practice?

[Peter Ehlert]

On 6/5/20 9:56 AM, der.hans wrote:

Am 05. Jun, 2020 schwätzte Peter Ehlert so:


Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for 
the Zoom meetings


2. Sandbox? (but how can I do that?)

3. Use a different browser


Does zoom work just in the browser without installing software?
For me, with Firefox, I had to install a package. It seemed to work ok, 
two party meeting. That was a month ago.


I have to use it in a couple places for work. In my experience, it 
demands
installing software on both debian and Ubuntu. zoom does provide a 
package

with insufficient depends.

A few days ago was the second time I used it. I could not get sound.  
Meeting with 4 connections.


using the Phone for voice connection failed.

From the Zoom website I grabbed the .deb package and installed it on my 
disposable system. It seemed to work, and I did not have to give an email.

I could not instigate a meeting with that app.
I have not asked another to schedule one for me.



It also demands a package for android.

ciao,

der.hans


4. What Me Worry? ... just update and flow with it

Thanks, Peter

Re: Zoom- best practice?

[Peter Ehlert]

On 6/5/20 9:47 AM, Paul Johnson wrote:



On Fri, Jun 5, 2020 at 11:45 AM Peter Ehlert > wrote:


Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.


Look into Big Blue Button and see if you can get your family to try 
that instead.


bigbluebutton is interesting. Thanks for the thought.

Many family members use Zoom, and like me, are past seven decades.
Several of the younger set use Zoom also.
I think I will not suggest change, I am the lone wolf.

Re: Zoom- best practice?

[Charles Curley]

On Fri, 5 Jun 2020 09:28:21 -0700
Peter Ehlert  wrote:

> Family is using Zoom, International.
> They will use Zoom, and I need to participate.

Zoom also has a native client.

Consider using a virtual machine. You will need to get sound to and from
the VM, which I don't believe works on qemu.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Zoom- best practice?

[john doe]

On 6/5/2020 6:28 PM, Peter Ehlert wrote:

Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for the
Zoom meetings



I would install a Debian VM for Zoom and alike software.

--
John Doe

Re: Zoom- best practice?

[Greg Wooledge]

On Fri, Jun 05, 2020 at 04:56:00PM +, der.hans wrote:
> Does zoom work just in the browser without installing software?
> 
> I have to use it in a couple places for work. In my experience, it demands
> installing software on both debian and Ubuntu. zoom does provide a package
> with insufficient depends.
> 
> It also demands a package for android.

It works in the browser without installing anything, at least in Google
Chrome.  I did not test with Chromium or Firefox or anything else.

However, it does require you to register, and then they spam you with
email several times a week.

Re: Zoom- best practice?

[der.hans]

Am 05. Jun, 2020 schwätzte Peter Ehlert so:


Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for the Zoom 
meetings


2. Sandbox? (but how can I do that?)

3. Use a different browser


Does zoom work just in the browser without installing software?

I have to use it in a couple places for work. In my experience, it demands
installing software on both debian and Ubuntu. zoom does provide a package
with insufficient depends.

It also demands a package for android.

ciao,

der.hans


4. What Me Worry? ... just update and flow with it

Thanks, Peter


--
#  https://www.LuftHans.com   https://www.PhxLinux.org
#  C'est la Net - der.hans

Re: Zoom- best practice?

[Paul Johnson]

On Fri, Jun 5, 2020 at 11:45 AM Peter Ehlert  wrote:

> Family is using Zoom, International.
> They will use Zoom, and I need to participate.
>
> I use Debian Mate Stable, and Firefox ESR
>
> I am concerned about security, duh!
> Looking for ideas.
>

Look into Big Blue Button and see if you can get your family to try that
instead.

Zoom- best practice?

[Peter Ehlert]

Family is using Zoom, International.
They will use Zoom, and I need to participate.

I use Debian Mate Stable, and Firefox ESR

I am concerned about security, duh!
Looking for ideas.

my current thoughts, in order of preference:

1. Use a separate Debian alongside my daily driver, and use Only for the 
Zoom meetings


2. Sandbox? (but how can I do that?)

3. Use a different browser

4. What Me Worry? ... just update and flow with it

Thanks, Peter