Jamulus Privacy - Approach and Disclosures

[Rob-NY]

This discussion is spawned from issue #2495

Jamulus has evolved and been extended over time and the approach to privacy - both in implementation and disclosure - should be revisited.

Foundational to this discussion is whether Jamulus is viewed as a service or as a software application. Today, the privacy statement located here conflate the two to some extent. The goal of this discussion is to determine the best way to disclose and discuss privacy for both Jamulus (the software) and Jamulus (the service/community).

Toward this end, I believe there are five areas that need to be addressed:

1. Introduction
2. The Protocol
3. Client to Client
4. Client to Server
5. Directory Servers

Here are some starting thoughts on each written in a 'for the user' voice for consideration. I also believe that the connection dialog box should have a disclaimer added that links to the Jamulus.io privacy policy (I can open a new issue for this).

Privacy and Data Use

Introduction
Jamulus is a software application that provides both client and server components that, when used together, enable musicians to play together over the internet. The creators and publishers of the Jamulus software (the "Jamulus Team") does not operate any servers or clients. The Jamulus Team does, however, make Directory Servers available to help facilitate connections between clients and servers. The data shared or available to be share for each connection in the Jamulus chain are discussed below. Users should evaluate their individual situations to determine whether the privacy environments are appropriate to their use. Jamulus is open-source software and, as such, the Jamulus Team makes no representations as to user privacy or information exchanged among the various components of the software as it can be modified to suit the needs of different user communities.

Definitions:

Server - a Jamulus server operated by an independent system operator.
Client - Typically a musician, running the Jamulus client software for the purpose of connecting to a Jamulus Server.
Directory Server - a server who's sole purpose is to facilitate the discovery of Servers by Clients.
Third-Party - anyone not in the prior three categories.

The Protocol
Jamulus clients, servers, and directory servers communicate over unencrypted internet connections. Traffic between and among these components could easily be viewed, logged, manipulated, or redirected by others and users should have no expectation of privacy with respect to information transmitted over the Jamulus protocol.

Client to Client
In its unmodified state, the Jamulus client application does not permit direct client-to-client communication. As such, any information made available to connected clients is facilitated through a Jamulus Server only.

Client to Server
Jamulus servers are operated by independent parties with no affiliation or connection to the Jamulus Team. In their unmodified state, Jamulus clients connect to servers and supply the user profile information set by the user. The act of connecting to a server also makes the client's IP address available to the server. All actions taken by the client, from adjusting volume levels for channels, to sending chat messages, pass through the connected server. Server operators have the ability to log all connection information as well as any messages that pass through their servers. Generally this is done to facilitate the user experience, manage server environments, and protect against bad actors or malicious use. However, the Jamulus Team does not make any representation as to how this information may be captured or used and users should contact server operators for their specific privacy policies.

In its unmodified state, Jamulus Server software also allows for third parties to ask it for connection information. In this specific case, the server may supply the third party with connection information including profile name, skill level, instrument, city and country only. No other connection information including, but not limited to, IP address is provided. This third-party population also includes the Directory Servers, discussed below.

Directory Servers
As a convenience, the Jamulus Team makes several Directory Servers available for public use. Servers can optionally register with these Directory Servers as a means to make their identity publicly known so that willing clients can connect to them. The Jamulus Team makes no representation as to the privacy and data use policies of any server listed and it is the users' responsibility to ensure that such policies meet with their expectations and approval prior to connecting.

When clients connect to a Directory Server for the purpose of discovering available servers, users do expose their profile information and IP address to the Directory Servers. For Directory Servers managed by the Jamulus Team, none of this information is logged or retained in any way. For Directory Servers managed by others, the Jamulus Team makes no representation as to the data that is collected or logged and use of these Directory Servers are at the sole risk of the user.

[ghost]

Introduction
Jamulus is a software application that provides both client and server components that, when used together, enable musicians to play together over the internet. The creators and publishers of the Jamulus software (the "Jamulus Team") does not operate any servers or clients.

Note correction:
The creators and publishers of the Jamulus software (the "Jamulus Team") does not may operate any servers or clients.

It would be better to omit the sentence above because the Team cannot be compelled by this unenforceable statement.
I cannot (an do not) agree to not running software that I need to use. Especially as a musician that contributes code to Jamulus.

[hoffie]

IIRC Directories servers can function as ordinary Jamulus servers. I think some or all of the official directories servers do that. See https://explorer.jamulus.io/ for a quick check.

[pljones]

Yep, a Jamulus Directory (not "Directory Server") is just a Jamulus Server that also provides a Server List when queried by a Jamulus Client, because it's Registered with itself.

Also, none of the Directories is operated by "The Jamulus Team". They're operated on a best endeavours basis by the Jamulus community.

There are a number of Directories "pre-supplied" with the Client and Server (the "Public Directories") but these are no different to any other Directory and no undertakings about them are made that differ in any sense from any other Jamulus Server operated by any other party.

[Rob-NY]

The challenge on the “none of the directories” comment is that the addresses are hard coded so there is an implied relationship that needs to, at least, be disclosed. However, as you point out, it may just be as simple as the suggestion you made.

Yes, I used “directory server” incorrectly per the recent naming change. But for the purposes here we might want to distinguish between a directory of servers, and the server that provides the directory (ie, the directory server); otherwise we might be talking to ourselves. Also, there’s still a bit of ambiguity in the user manual.

To view servers listed by a custom Directory Server, musicians must enter the address in their client’s “Custom Directory Server” settings field. They will then see a Connection Setup list which is generated by your Directory.

Not a huge deal either way, we’ll just have to be specific and consistent.

[pljones]

“Custom Directory Server” settings field.

There's no such field. It's the "Custom Directory Server Address" (i.e. Server Address of the Custom Directory; or "Custom Directories" in the Client).

[ann0see]

What about saying that by default Jamulus connects to default directories operated by Volker Fischer and Peter L Jones. Add some comments about logging. Also say they're used for update checking purposes.

[hoffie]

I like the idea of reworking that page. I also like the idea of separating Jamulus as the software vs. the infrastructure which is provided by team members (e.g. lives under jamulus.io).
"Privacy Policy" is rather associated with hosted services for me, so maybe we should move away from this term when talking about the software.

• Security model for the Jamulus software (with details about what information is transmitted, the fact that it's unencrypted, etc.). I'm not exactly happy with this term though.
• Privacy policy for the official Directories ("we don't store client IPs" or something)

[gilgongo]

Thanks for this @Rob-NY ! Feel free to submit a PR to re-write this file:

https://github.com/jamulussoftware/jamuluswebsite/blob/next-release/wiki/en/Privacy-Statement.md

(note the branch you need is "next-release")

BTW @hoffie we currently call it a "privacy statement" to avoid the impression we have anything much more than a statement of fact :-)

[ann0see]

@Rob-NY this discussion has been sleeping for quite some time now – similar to JSON-RPC.
I still think it's important to discuss it.

Personally I think Jamulus is not as privacy aware as I would like it to be due to design choices. I think the user deserves to know how the app and the servers which most of the team has no access to work by default and how their data is processed. Nom default behaviour should be mentioned too, but clearly marked as such.

Would you like to open a PR on the website repo to the next-release branch?

[ann0see]

Jamulus is open-source software and, as such, the Jamulus Team makes no representations as to user privacy or information exchanged among the various components of the software as it can be modified to suit the needs of different user communities.

Is in my opinion not clear enough. I'd even consider it wrong in some terms. Directories are hosted by individuals not the team. I don't know any of the configurations of Peter's or Volker's directories. They might or might not log, run modified servers,...

Probably we need to put a statement close to the beginning that servers are run by multiple people all over the world and that they might have different privacy settings they control. It should be clear who gets which data.

[gilgongo]

and that they might have different privacy settings they control. It should be clear who gets which data.

Yes, and while this is also the reason why we should be cautious about what Jamulus puts into server logs (there was a discussion about expanding logging information and a PR since closed), this issue is also relevant to the GPL's "SaaS loophole".

So do we also need to say that if you connect to a Server that runs a modified version of Jamulus that logs more data than the official release, the server owner is under no obligation to make their source available?

(For the record: We discussed switching Jamulus to the AGPL so as to close this "loophole", but found it would be too problematic to do so)

[hoffie]

So do we also need to say that if you connect to a Server that runs a modified version of Jamulus that logs more data than the official release, the server owner is under no obligation to make their source available?

I think all of that could be condensed to "the server operator controls what data is collected and retained". Trying to document all possible aspects is sounds impossible to do (code modifications? sniffing? special logging?).

It's the job of any such SaaS provider to properly document that, not ours.

[Rob-NY]

So do we also need to say that if you connect to a Server that runs a modified version of Jamulus that logs more data than the official release, the server owner is under no obligation to make their source available?

I think all of that could be condensed to "the server operator controls what data is collected and retained". Trying to document all possible aspects is sounds impossible to do (code modifications? sniffing? special logging?).

It's the job of any such SaaS provider to properly document that, not ours.

I think we're mixing concepts here. In my personal case, I made the source code available for all the modifications I've made to Jamulus as have some of the other 'added-value' providers. This is in accordance with the license, notwithstanding the SaaS Loophole. However, there's nothing that says the code will be incorporated into the core product -- so I'm not sure what that actually buys the casual user. More relevant, I believe, is that the Jamulus team has mixed the core functionality of the software with the implied endorsement of non-core 'products' -- like the running of the directories that are hard-coded into the software.

I'll draft a version 2 for consideration that takes into account the feedback within this thread. However, as outlined in this discussion, it is going to be impossible for Jamulus (the project) to make any representation about data collection or privacy for all the reasons stated. In this regard, I agree with @hoffie. So if there isn't core agreement that the server operator is in control of the data collection/use, we're going to be at a stalemate again.

[gilgongo]

So if there isn't core agreement that the server operator is in control of the data collection/use, we're going to be at a stalemate again.

Not sure I understand. Is there not such an agreement? What's the nature of the stalemate?

[Rob-NY]

My comment goes to @ann0see's comment "Personally I think Jamulus is not as privacy aware as I would like it to be due to design choices.". There have been other threads (like in the PR referenced above) that steadfastly rejected the introduction of logging into the core code. This is all fine, but it implies that there may be a difference of opinion as to the stance taken here with respect to privacy that would be promulgated by the Jamulus team vs. pushing it off to the server operators.

[gilgongo]

Oh I see. Yes, this is a bit out of scope for the discussion if its about "design choices". All we're talking about here is simply about being transparent.

[Rob-NY]

I'd like to resurrect this discussion as there is likely to be more spirited conversation in the coming weeks concerning this topic.

Two macro areas that I believe are sticky are:

Defining the relationship between Jamulus, the software project, and the directories that are hard coded. Resolution could be as simple as incorporating the privacy policy of the system operators of those directories.

The second is to determine the extent that Jamulus, the software project, can or should promulgate a privacy policy. Given that Jamulus (the project) as no control or influence over the environment in which the software will run negates the ability to represent complete privacy concerns during the use of the software. Further, as an open source project that encourages community participation and the spinning up of servers, there is no way that Jamulus (the software project) can make a privacy representation for every instance running.

I am not a lawyer, but I would think that Jamulus (the open source project) would want to distance itself far away from privacy issues and push that onto the operators of the servers themselves.

As folks here comment on these items, please be sure to indicate how you reconcile your position with the facts above (lack of instance control, network control, individual ownership of directories, etc.). While taking a privacy position is clearly important, so it crafting an application that can be expanded beyond the original vision.

Thanks in advance - I know this is a sensitive and polarizing topic.

[ann0see]

The directories + update check servers are run and maintained by Volker and Peter, so one could argue that they are responsible for their privacy policy. I think, as only these two have access to these servers, we can't even say "the team" or "the community" is responsible.

I think, the privacy of the App lies more on the hand of the community.

[hoffie]

I am not a lawyer, but I would think that Jamulus (the open source project) would want to distance itself far away from privacy issues and push that onto the operators of the servers themselves.

This.

[Rob-NY]

I'd like to float an idea that might simplify this issue a bit. Let's assume that the core of Jamulus continues with its approach of not allowing anything to be logged or exposed that might be viewed as a privacy issue. The introduction of meaningful RPC that allows for the extension of features and control could (and likely will) go against this.

What if everything "challenging" in this area had to be implemented through RPC? Further, what if the clients knew that the server they were connecting to had 'extended capabilities' with RPC enabled? As I outlined briefly in #2890, I've put together a sample of how a client might be made aware of whether the server they are connected to has RPC enabled, and thus they may be exposed differently. Here's a sample screen shot of a client connected to an RPC enabled server:

The privacy policy page could then be tweaked a bit to include something like:

Server operators may enable features that extend the capabilities of Jamulus and could be collecting more data about users. The system operators are responsible for these features and data collection.

In lieu of the sample static label at the bottom of the mixer dialog, another option would be to prepend something to the welcome messages for servers with RPC enabled. Either way, it is disclosed to the user that something different exists about this server.

Does this go too far? Am I over thinking this? Again, my motivation is to not hobble the capabilities that could be introduced via RPC due to unresolved privacy policy issues.

[ann0see]

Hmm. You mean we should handle JSON-RPC similar to the recording message.

I think it might be worth stating that JSON-RPC is enabled, not "capabilities".
Honestly, I think adding a link to the privacy policy of the operator would be better.

[Rob-NY]

I’m not sure what I mean :-). I’m just laying out options.

I really favor punting everything to the server operators as they have the ability to disclose via the welcome message already. The claims in the current privacy policy now are somewhat problematic because no representation can really be made as to what is actually in the compiled versions of clients or servers in the wild.

The directories are low-risk, so not too concerned about them beyond the implied endorsement for those hard-coded; probably worth a mention.

Again, beyond that, it is not really on Jamulus (the project) to be making any privacy or data use statements as there is just no way to know.

[hoffie]

I don't think we should add such disclaimers based on JSON-RPC (or any other feature, FWIW). Privacy/security can be harmed by lots of things. Packet dumps (tcpdump/wireshark) or modified Jamulus servers would just be some other examples. It might not even be the server operators which could be malicious, it could just be some man-in-the-middle.

[Rob-NY]

Here's an updated proposal for consideration:

Privacy Statement

Please note that the English version of this privacy statement is the original and, as such, the binding version. To access the English version, go to the top/top right of this page and click on the "en" link.

Definition of Terms

• "Server" The Jamulus Server software running on a remote computer to which you will connect.
• "Client" The Jamulus software running on your local computer used to connect to a Server
• "Directory" A Jamulus Server configured to supply a list of Servers to Clients

Jamulus.io Web site

The website at jamulus.io is served using GitHub Pages. See Github's privacy policy for information relating to data collection and privacy.

Jamulus Software

Jamulus is open source software and can therefore be modified by others. As such, the Jamulus project makes no representations related to privacy, data collection, or security with respect to your use of the software.

General Information

Under normal use with unmodified software, your user profile information is exchanged with Servers you connect to, peers connected to those same Servers, and to any interested third party (including Directories) making use ofthat uses the Jamulus protocol. This information is limited to your Jamulus name, city, country, instrument, and skill level as you have set them in your profile. defined them when setting up your profile. The Servers you connect to will also have access to your internet address (IP Address) as it is required for the software to work; but this information is not shared with peers on the same Server or normally available to third parties.

All communications between and among Clients, Servers, Directories, and third-party protocol users are sent without encryption.

Jamulus Servers

When you connect to a Server, either directly or through a Directory, the operator of that Server is responsible for its operation policy, privacy policy, and data use policy. While unmodified Servers do not log or store your connection or profile information, some modified Servers may do this; and you should have no expectation of privacy with respect to your profile information or internet address.

Chat Exchanges

Chats are textual messages that can be exchanged between Clients connected to the same Server. Everyone connected to a Server can see all chats and there should be no expectation of privacy with respect to information sent through the chat feature of Jamulus. While unmodified Servers do not log or store chats, some modified Servers may do this.

Audio Recordings

You will see a notice if you are connected to a Server when recording is turned on. Recordings of each player are stored by the Server and are controlled by the Server operator.
Unmodified Servers will display a notice if recording is turned on. Recordings of each player are stored by the Server and are controlled by the Server operator. Active recording by peer Clients or modified Servers may not always be visually indicated.

Directories

Directories are central connection points for locating Servers. The Jamulus Client comes with a pre-defined list of Directories for the convenience of users. These Directories are independently operated but are represented as running unmodified versions of the Jamulus software.

[hoffie]

I like that proposal a lot -- thanks for your work on this so far!

Unmodified Servers will display a notice if recording is turned on. Recordings of each player are stored by the Server and are controlled by the Server operator. Active recording by peer Clients or modified Servers may not always be visually indicated.

Another proposal for that part (probably don't take it as-is though?):
A Jamulus Servers' native recording function will trigger a notice in all connected Clients. Be aware though that there are other commonly used ways to record sessions which are not transparent. Any connected Client could be running their own recording.

[Rob-NY]

Let me think about that one -- it may be "TMI". Perhaps without the very last sentence.

[gilgongo]

Minor point: it's not good practice to refer to the UI in any detail in case the UI changes. So,

To access the English version, go to the top/top right of this page and click on the "en" link.

should probably be something like: "Use the language switcher to change to the English version" instead.

[hoffie]

So, how would we proceed with this one? I guess it would make sense if you (@Rob-NY) could submit your proposal as a PR?

[Rob-NY]

Minor point: it's not good practice to refer to the UI in any detail in case the UI changes. So,

To access the English version, go to the top/top right of this page and click on the "en" link.

should probably be something like: "Use the language switcher to change to the English version" instead.

Agree... what you reference is the current language on the site today, but I think I have some options. I'll post a final draft here before creating a PR.

[mcfnord]

take the dash out of open source.

The Jamulus Software title could be more descriptive. It's really our central message, that there can be no representations.

Rather than making use, I suggest that uses.

as you defined them when setting up your profile : as you have set them in your profile, ongoing rather than one-time setup.

either directly for ... either directly or

Rather than network address, say internet address, like the previous paragraph.

[Rob-NY]

take the dash out of open source.

Done

The Jamulus Software title could be more descriptive. It's really our central message, that there can be no representations.

Suggestions are welcomed.

Rather than making use, I suggest that uses.

Done

as you defined them when setting up your profile : as you have set them in your profile, ongoing rather than one-time setup.

done

either directly for ... either directly or

Typo, oopsie.

Rather than network address, say internet address, like the previous paragraph.

Done

[QJKX]

Client to server

In its unmodified state, Jamulus Server software also allows for third parties to ask it for connection information. In this specific case, the server may supply the third party with connection information including profile name, skill level, instrument, city and country only. No other connection information including, but not limited to, IP address is provided.

This isn't true - old servers send the IP addresses of all clients over the wire.

[Rob-NY]

The best I think we can do is to say then: "In its current and unmodified state, ..." I'm not sure we can have a privacy policy that accurately covers all versions since inception. The prior PP that this is replacing also made no mention of the IP sharing and, in fact, disclaimed any transfer of IP info.

Alternatively, and maybe better, we open this policy with "The following applies to the current version of the Jamulus Software. Earlier versions may have had different capabilities and are not covered by representations made here."

I do NOT think we should start listing versions. This is a guiding document that is really for information purposes only as this project has absolutely zero real control over anything in this document. Less is more.

Drafting the final version for PR consideration now.

[Rob-NY]

FINAL PRE-PR VERSION. I BELIEVE I CAPTURED EVERYONE'S INPUT.

Privacy Statement

The English version of this document represents the official privacy statement. If there are conflicts with other translations the English version governs. This statement applies to the current version of the Jamulus software. Earlier versions may have had different privacy terms which are no longer supported. Users are encouraged to use the most current version of the Jamulus software.

Definition of Terms

• "Server" The Jamulus Server software running on a remote computer to which you will connect.
• "Client" The Jamulus software running on your local computer used to connect to a Server
• "Directory" A Jamulus Server configured to supply a list of Servers to Clients

Jamulus.io Web site

The website at jamulus.io is served using GitHub Pages. See Github's privacy policy for information relating to data collection and privacy.

Jamulus Software

Jamulus is open source software and can therefore be modified by others. As such, the Jamulus project makes no representations related to privacy, data collection, or security with respect to your use of the software.

General Information

Under normal use with unmodified software, your user profile information is exchanged with Servers you connect to, peers connected to those same Servers, and to any interested third party (including Directories) that uses the Jamulus protocol. This information is limited to your Jamulus name, city, country, instrument, and skill level as you have set them in your profile. The Servers you connect to will also have access to your internet address (IP Address) as it is required for the software to work; but this information is not shared with peers on the same Server or normally available to third parties.

All communications between and among Clients, Servers, Directories, and third-party protocol users are sent without encryption.

Jamulus Servers

When you connect to a Server, either directly or through a Directory, the operator of that Server is responsible for its operation policy, privacy policy, and data use policy. While unmodified Servers do not log or store your connection or profile information, some modified Servers may do this; and you should have no expectation of privacy with respect to your profile information or internet address.

Chat Exchanges

Chats are textual messages that can be exchanged between Clients connected to the same Server. Everyone connected to a Server can see all chats and there should be no expectation of privacy with respect to information sent through the chat feature of Jamulus. While unmodified Servers do not log or store chats, some modified Servers may do this.

Audio Recordings

Unmodified Servers will display a notice if recording is turned on. Recordings of each player are stored by the Server and are controlled by the Server operator.

It is possible for connected clients to make recordings of sessions outside of Jamulus itself for which there may be no notice or indication. Jamulus has no way to detect or control these situations and makes no representations as to the collection or use of such recording data.

Directories

Directories are central connection points for locating Servers. The Jamulus Client comes with a pre-defined list of Directories for the convenience of users. These Directories are independently operated but are represented as running unmodified versions of the Jamulus software.

[Rob-NY]

Created documentation PR: jamulussoftware/jamuluswebsite#872