block public servers

[jp8]

I've started to think about the needs of music educators. One requirement that I'm pretty sure of is the need to block all the public servers when a parent installs Jamulus onto a child's computer. The child would only be using Jamulus to communicate with their music teacher.

It's easy enough to comment out the public servers and build Jamulus. But it needs to be something a parent could download and install. A separate build would work, and might be the way forward, considering there could be other features in the future that are only relevant to music education.

But if not a separate build, maybe a question in the installer on Windows, or a third icon to drag into the Applications folder on Mac...

[pljones]

If a separate icon is all that's needed, would adding a command line option to disable the servers list on connect work?

[jp8]

in the Mac installer, you get the choice of 2 icons to drag into applicaitons. One is the Jamulus client, the other is the Jamulus server. I'm assuming that the server icon is just a small wrapper that starts the same executable, so on the Mac, having that option at install would address this issue, and yes it would depend on a command line option to disable the servers.

On the Windows installer, I think it would need to be a question during the installation, and the resulting start menu shortcut would pass the necessary option when running the .exe.

On Linux, just the existence of the command line option would be enough.

[storeilly]

this is a complex issue and easily thwarted, a rogue operator can have any victim enter a non listed server in the connect dialog. Parental monitoring and traffic control is needed, that is outside the remit of Jamulus. It would be a serious undertaking to be responsible for content and usage. Stephen

…

On Sun 28 Jun 2020, 16:13 Peter L Jones, ***@***.***> wrote: If a separate icon is all that's needed, would adding a command line option to disable the servers list on connect work? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIJSQMG2QEKZO3UKSHBDHLRY5MZ3ANCNFSM4OKSANUA> .

[jp8]

Yes - but. That's part of having a computer connected to a network.

What I'm talking about is just not having the public servers listed, so that when a school asks a parent to install the software for a child, and when the parent is monitoring the child's use of the software, a list of strangers is not shown in the UI.

[corrados]

Do you really see a risk if a child sees the public server list?
I think this is a very special usecase. Setting up Jamulus correctly is pretty difficult. It usually takes some sessions before you are happy with the results by tweaking settings, hardware configuration, etc. I do not think it would be possible for a child to do this. I think most probably Jamulus would be setup on the parents PC and the child is using that one.
I just write that because my own child gets piano lessons online and it was difficult to get the video and audio quality right (he is not using Jamulus BTW). Everytime he gets a lession, I setup my own laptop and prepare everything for him.

[pljones]

It's also not a "one size fits all" -- for example, should the "Custom" server list option be available - in case a school offers "Music Room 1", "Music Room 2", "Piano practice", "Choir practice", etc?

[jp8]

Indeed. Custom main server, and private servers.

I don't personally see any risk if a child sees the public server list. However I do see a risk that schools will reject the software because allowing access to chat with strangers would break one of their criteria.

[gilgongo]

I do see a risk that schools will reject the software

This seems to be the main issue. "Does this let kids talk to strangers? If so, we can't use it." At the risk of being a bit cynical: they don't care about the kids in this context, they care about their own liability.

[Brian-McBride]

Do you really see a risk if a child sees the public server list?

I am working with schools and the answer is yes. There are a TON of potential lawsuits happening if the school requires an app that then leads a student into a compromising position. The sad reality is that there are predators out there and though it's not likely, it only takes one.

Security and Privacy are both important to educational institutions.

[ann0see]

Just an other thought on the education topic.

Jamulus wasn‘t and isn’t made for schools but in my opinion it does have the potential to be a great tool for this application, especially with all the new features like multithreading, the ability to run private servers, group function, compact skin, ...

But there are probably still some legal (?) problems.

All the typical conferencing tools provide ways to protect and manage a meeting:
Waiting room/password,.../mute (disturbing/zoom bombing) users,... all that is managed by the meeting host.
This creates a more private and child friendly environment.

By using private servers, setting new client level to 0,... there’s quite a good "protection" since you can be relatively safe that no stranger enters the server/disturbs the session/... Of course somebody who knows the IP can join and listen.

I think we should maybe also think of other features teachers/schools need.

One problem I see at the moment is e.g. that there’s no way to manage connected users. The problem with implementing some kind of "hierarchy" is that on public servers there should be no way to kick/generally mute/... a user but on servers for educators it’s a must have. Especially since there are quite some teachers/parents who haven’t forgotten the problems with zoom (default unprotected links, no waiting room,...) which led to zoom bombing. The same goes with waiting rooms. I think the World Jam event does it with separate servers. But that would be security through obscurity.

I‘ve looked into the code and tried to add a "block chat" function. That’s done by preventing the server to send chat messages to all users. But my code is probably not good since I‘m still looking through the code and examining what the functions do.

[Brian-McBride]

I mentioned this in another ticket.

I believe that Jamulus could benefit hugely from a separation of concerns. The code should be separated into modules, with the core audio portion focused on the "engine". Chat, UX, security, etc... can all be handled by the app that uses the core engine as a dependency.

Then, that engine gets a solid focus on working great on PC, Mac, Android, iOS, Chromebook, etc... The more simple the engine is the less code has to be ported to each platform.

However, in addition, interfaces should be maintained to pull in other developers. For instance, Android is mainly Java/Kotlin, so having an interface class that bridges the Jamulus C code will help mobile developers use Jamulus in their apps.

I've also mentioned a NodeJS module that offers a C bridge to the Jamulus engine. This will allow the development of Electron (and similar) apps. If you don't know what Electron is, it is a wrapper that apps like Slack and Visual Studio Code use to wrap up a NodeJS engine with either native UI elements or a DOM/Web interface. Another build it once, deploy anywhere idea that has had some solid success.

The point is, there is a community of developers who have a TON of experience on UI/UX, security/auth, etc... but very few of those developers do that in C. Objective-C or C# is most aligned. If the engine was available to NodeJS in an electron wrapper though - it unlocks a HUGE developer pool that can contribute to the Jamulus ecosystem.

Also, if there was a focus on the engine itself, and it was also ported to WebAssembly and worked though the browser fast enough - then get that working with MS's new Blazor... Could be pretty awesome.

[ann0see]

Coming back to the topic, I have "solved" it with a custom build of Jamulus which doesn't have the official central servers included. Compiling on macOS and Linux was easy, Windows was a pain (since deploy_windows.bat makes dirty hacks for an old version of Visual Studio etc.)

Could we load the central servers from a file somebody can exclude or change on build or during run time? This would allow us to easily add and remove new genre based server lists too.

[gene96817]

I'm catching up with this topic. I see three topics.
1- It would be great for a school system to create a custom central server. Then all the servers in their system can be listed. This is important because this will allow collaboration between schools.
2- The client needs two features. (a) a default that only accesses the school system's custom central server. (b) a method for adults or trusted (older) students to have access to the world.
3- Authentication - do we need to introduce an authentication method for the school system to control access to their servers? Don't go overboard on this. The school systems usually have relatively weak authentication. We just need enough for the school system to add this technology to their suite of tech.

[ann0see]

1: can be done easily (without a lot of coding needed)
2: how do we do that? if (ip user wants to connect to ! inArray(allowedIPs))? I don't see that needed actually, in Zoom etc you can also connect to every other meeting BUT you need to know the meeting id
3: yes. That's needed but corrados doesn't like that. A waiting room feature like in my fork might be a short, user unfriendly and insecure fix. Maybe we can agree on a compromise (since WorldJam would also benefit from that) (proposal: disable this feature unless it's enabled during compilation time or: do not let servers with authentication register on public central servers).

[gene96817]

For #2
2A - make it easy to distribute a custom client that only connects to the custom server.
This would force some users to install two clients. the custom client and the standard (general purpose) client. This feels like a hack but this keeps it simple.
2B- it is tempting to lock the servers to only accept the custom client but that would be a mistake.
Consider a class inviting a non-faculty musician for a master class.
It would be better for the servers to accept authorized users through the authentication function.
3A- I understand the dislike for authentication. I suggest default at the server to be authentication-off.
3B- Many schools manage the control access to the education tools through account ID/pwd. Consider systems using Chromebooks. I suggest we use the concept of PAM (pluggable authentication method). Then it is just a link to an external method (e.g. Google, LDAP, exchange, etc.) Definitely don't build and manage authentication inside Jamulus.
3C- I really dislike a waiting room. That requires someone to manage late arrivals or drop-in visitors. I especially enjoy having drop-in visitors. (I have not attended any Zoom meetings where the waiting room did not delay the start time.) I prefer to start early for warmup and just let the other participants trickle in... just like an in-person session.
3D- Instead of a waiting room, it would be better to manage an RSVP list. The option is then to (a) refuse arrivals not on the list (aka a closed session), (b ) allow arrivals not on the list as observers with the default of mic muted. Then the session members can invite observers to participate if desired. Note the drop-in could be a friend that noticed their friends are having a session. A very good thing.

[gilgongo]

Hi all - so that we can agree on what needs to be done for an actionable backlog ticket, I'm moving this to a discussion if that's OK.

[pljones]

@jp8 are you still interested in picking this up? Now we have improved private directory server support (thank you), would you want to add support for disabling the built in ones? Do you have an implementation proposal (i.e. could we get this back to being an actionable change with a target of 3.9.0)?

[jp8]

Yes.

On Unix this would be done with a Jamulus defaults config file under /etc/jamulus

Whenever a client starts up and finds no Jamulus.ini file, it would create one based on the defaults defined by the sysadmin.

I am not sure how to do a similar thing on Windows and Mac, though.

Perhaps on those platforms the sysadmin could set defaults at install time. Some kind of question in the installer "Include public directories ?" I'm not sure Mac supports this.

[pljones]

Not quite sure on Windows. C:\Users\Default\AppData\Roaming or maybe C:\ProgramData?

However...

I have on my list of "totally rewrite the..." things to do the ini-file handling. So for now, I'd rather stick to a minimal - even if easily foiled - approach, like another command line option with installer option.

(Rewritten approach would be something like:

• set the program defaults
• override those with the system defaults
• override those with the user defaults
• override those with the command line
• allow changes during program execution
• on exit, overwrite the user defaults (because eventually I've decided I agree with Volker)

At the moment, headless server and headless client differ in that the former doesn't write an inifile. Ideally, the user file written should only be what changed after the program and system defaults were configured - either by loading the user defaults, from the command line or at run time.)