Jamulus
Replies: 7 comments 24 replies
-
|
I strongly support this request ! |
Beta Was this translation helpful? Give feedback.
-
|
I think this has been requested before. At the time, the mood was that Jamulus wants to be as anonymous as possible (as per https://jamulus.io/wiki/Privacy-Statement). But things change, so can you elaborate on why you would want to have names recorded in the logs? It might make the debate a bit easier. |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't asking to have a feature added, or for user management to be implemented, just a modification to a log file that already exists. This has no bearing on client behaviour/use (muting or soloing), but can potentially facillitate third party user management by a server operator. I don't have anything more to add, per your request I have outlined why I would desire the change, thank you for your consideration. :) |
Beta Was this translation helpful? Give feedback.
-
|
For the sake of completeness, if not coherency, let's consider the following ! |
Beta Was this translation helpful? Give feedback.
-
|
To which it's worth adding that in non-headless server mode the nickname is not recorded in a log for later analysis, but when nickname is stored (in recording mode) users are alerted to the fact that recording is on. The current request could therefore be seen as "a breach in anonymity" because we actually make a point of saying "The server does not otherwise store or record your Profile information" in the privacy statement. I shall leave the legal point about IP/name matching capability alone, suffice to say it's a consideration. I don't dispute that adding the nickname to the log might be trivial. My point is that Jamulus is, as @ann0see says, private by design. So if nickname storage were to be introduced, users would need to know before they joined the server. Be that as it may, the ask here it to make it easier to kick out troublesome users. But Jamulus provides a method for ignoring such users anyway so (and by the general design principles) I don't think tampering with privacy for that is warranted. And for the sake of completeness: work is being done on an authentication layer of some kind for Jamulus, so user idenfication in principle isn't completely off the cards in the long term. |
Beta Was this translation helpful? Give feedback.
-
|
US$0.02... Whats not mentioned in the privacy statement is the stored filename contains the username, src port, and first three octets of an IPv4 IP (the last octet easily found in the log file) as well. Being informed that a recording is taking place doesn't inform a user of the privacy implications. A typical user has no idea whats happening on the server during a recording. There's a mention of I accept that the team will not implement my request. You may want to update your privacy statement to better inform users what exactly is being stored on disk during a recording. Thanks again for considering my request :) |
Beta Was this translation helpful? Give feedback.
-
Good point. |
Beta Was this translation helpful? Give feedback.
-
|
I understand all sides on this one. I do tend to lean more toward the server-operator side and the need for the right information in order to quickly and accurately identify clients for whatever purpose (bad actors, etc). There are several references to public servers in the threads above, but there's really no such thing -- only listed and unlisted. And since Jamulus is the underlying system in both cases, any reference to "privacy statements" for the underlying software (as opposed to the implementation of the software) is probably not the best idea anyway. Additionally, the privacy policy as it is written today gives third-parties more information disclosure rights than it gives the server operators. Frankly, the ability to do "connection-less" queries of a server exposes more information to more people than this logging request ever would. I completely support the prior changes (like removing the IP from client responses) to protect anonymity at the client level. However, I do think that fair consideration needs to be given to requests like this that are only relevant to the sysop for management and administrative purposes. Further, plenty of systems allow for configuration options that might require storage disclosure to end users (Apache, etc). I think what this entire thread really exposes is a potential issue in the disclosure at the CENTRAL SERVER or the PROFILE SETUP level -- which is a much bigger topic that this log file question. Perhaps a realistic option is to add a general disclosure on the PROFILE screen to the effect that: "Servers may log [your IP address and] your supplied name for server management and administration purposes.", and to modify the privacy statement for the software to include similar language. The logging of session information is not uncommon or unreasonable. |
Beta Was this translation helpful? Give feedback.
-
|
@Rob-NY Thanks for this perspective. You say, "accurately identify clients for whatever purpose (bad actors, etc)". As I've said, the "bad actors" case is already handled by being able to mute or solo. The Jamulus design principle is, "If a feature or function can be achieved in another way by another system or method, then that is preferable to building that feature into Jamulus." So what other use cases are we suggesting here? |
Beta Was this translation helpful? Give feedback.
-
|
@gilgongo - I appreciate your consideration on this. There are several other use cases. Offensive names and offensive chats are two that are not solved with the mute/solo option. Then, there is the economic issue. I believe Jamulus has evolved and is being used in ways that the original framers did not or could not imagine. And to be clear, I completely support the free environment (free as in freedom, not free as in beer) that the directory infrastructure provides to the community. However, at the end of the day someone is paying for these servers. Bad actors consume a seat, bandwidth, and disk space -- and there is an economic reality to that. A recorded Jamulus session with 10 songs and 10 players could easily be 5 gig. If only one of those channels is a bad-actor, then ~500mb is attributed to them -- whether mute/solo was activated or not. So now the system operators are paying to store and ultimately transmit this data to the ultimate 'consumer' of the recording. At scale, these could turn into pretty big numbers. Again, I want to be clear that your point is completely valid and I (sort of) agree with you with respect to servers that are listed on the directory servers as they exist today. Unfortunately there isn't much choice right now if you want your server 'listed' as part of core. And as I said before, this isn't really about the log file -- it is about operational control of a server that is being used in ways that were not necessarily envisioned in the earlier days of Jamulus. One option might be to extend the directory server structure to include one or more "Managed Server" directory servers that are genre agnostic. This would provide fair warning to users about the intended use of the servers (not necessarily private, but also not the Caligula-like environment that is desired on the public side today). At this point you could then lock down the logging option to be 'prohibited' if registering with a directory server in class "A" (the current list), but permissible if connecting to any other directory server or as an unlisted server. This would provide a reasonable balance between anonymity and management need -- and would greatly improve the ability to have a "privacy statement" that is scope appropriate (ie, Dir Servers that are part of the Jamulus infrastructure) and enforceable (with the code option restrictions). I think this is an important discussion because it touches on several themes that have come up before with respect to the original Jamulus vision and the reality of present day usage. I really appreciate the engagement here. |
Beta Was this translation helpful? Give feedback.
-
|
So by providing the user name in the logs, the admin could look at that log to determine which IP to block (assuming they had external tools to do that on the server) in the event of abuse not limited to just audio. On the wider issue of "operational control" of servers: I've mentioned there are currently efforts to build methods of managing access as long-term projects. Ideas like "class A" (or "moderated"?) directories could be part of that perhaps. Maybe if you started a separate discussion of that idea? I would imagine though that if somebody wants to do a PR for showing the name in the log, then that will happen eventually. It is usually true that control wants more control. |
Beta Was this translation helpful? Give feedback.
-
|
PR #2010 has been created for discussion purposes and to provide context for the asks within this thread. |
Beta Was this translation helpful? Give feedback.
-
|
New Idea:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure I understand what you're saying, exactly. If you're suggesting some type of mechanism where you can manage allowed or disallowed IP addresses, then I think everyone is in agreement. This thread seems to be centered around getting the information that you list in your third bullet. Personally, this is exactly what I've done with my vJammers.com solution. Below are two screen shots - one with the server in 'locked' mode, and the other in 'open' mode. Both let you toggle folks in or out. The 'blocking' portion of this application works at an OS firewall level and does not require any changes to Jamulus, per se, but it does require PR #2006 in order to get the complete connection information. The complete connection information is your third bullet point, and getting this information in the log is the root of this entire thread.
|
Beta Was this translation helpful? Give feedback.
-
|
My points above were made quickly as an idea came to me. The points are intended to adhere to the KISS principle. I also mentioned a whitellist (not a black list because of privacy concerns etc.). The idea is similar to a stealth firewall. Furthermore, people that want 'metrics' and 'digging down to root causes' and 'data mining' and other stupid 'management stuff' should sit in the corner wearing their suit and tie. BTW what you have done looks real good (maybe too deluxe - less is more). |
Beta Was this translation helpful? Give feedback.
-
|
The log exposes sensitive data between Jamulus and vJammers. |
Beta Was this translation helpful? Give feedback.
-
|
You definitely sparked a good laugh... I took off my tie... |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. I'm happy and fair game for a good laugh. |
Beta Was this translation helpful? Give feedback.
-
|
Saw you talking about this in the Jamulus channel. I do think the a server admin ends more tools to track problematic clients. The Public server is a valuable free service. It's not like you can't find this info out based on netstat info and figure out what is who. Obscurity is not good security. |
Beta Was this translation helpful? Give feedback.
-
|
This is about accountability. If Jamulus forces you to find the information yourself, you are accountable. |
Beta Was this translation helpful? Give feedback.
-
|
Whitelist? With Musicians. I don't really like whitelist unless your talking about the admin being able to generate it from connected users, then banning anyone not no the list. You know you don't really need to ban them. Just Mute them, they can listen all they want. I see groups today doing this. They solo everyone in their group so the rest of the room is ignored. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
In Software products you add features to attract new customers and add security options to retain customers. Something to remember. |
Beta Was this translation helpful? Give feedback.
-
Currently the log file format is CSV with fields: timestamp, IP, status
Is it possible to add field with nickname used on join?
Beta Was this translation helpful? Give feedback.
All reactions