Alternative to Google being used to get external IP #572
Comments
|
Volker set up a general ticket to discuss security and related issues at #314. I don't know if we should move this there? |
|
I already thought about adding it there; but it's not a security issue. |
|
There was quite an extensive discussion around privacy in that ticket, but I see Volker split that out into #316 I think the tl;dr is that Jamlus does not store or process any personally identifiable information, so privacy isn't an issue. In the case of IP addresses, Jamulus would have to be run by an ISP (which would have the power to associate IPs it allocated to customers to their PII), or the police for this to be a problem. |
|
How severe would you rate this privacy issue? Most apps on the phone connect to multiple servers like Google or Facebook by loading ads or tracking the usage. Even a normal Windows PC transmits lots of network packets to multiple servers in the internet. Of course, if you are running an OS like Tails, this can be an issue. But I do not think anybody wants to run Jamulus on an OS like Tails. |
|
I'd say it could be a legal issue (GDPR) if the user doesn't know about it. Is there an other more privacy oriented aproach (other service/ip,...)? Some people i know don't even use jitsi meet if it connects to a google stun server. See https://www.kuketz-blog.de/jitsi-meet-datenschutzfreundlich-ohne-google-stun-server/ |
|
Do you have a reason for why it might be a legal issue? My understanding is that as Jamulus doesn't collect any personally identifiable information as defined by GDPR, then there's no problem. Or do you mean there's a wider issue (like being able to sniff PII in some way using a public IP)? Edit: here's an explanation re. IP addresses. It's complicated, but they seem to be only PII if you can use them to get PII. So the Jamulus server operator would have to be an ISP or the police to treat the 8.8.8.8 issue as a legal one. At least, ordinary people running Jamulus can't obtain PII from an IP address so they don't have to tell Jamulus users that their IP addresses are known to others, any more than they have to tell people their country or instrument are known. That said...... if we are still worried about IP addresses being a legal issue (that is, being seen by other Jamulus users or 3rd parties) under GDPR or any other law, then we could use the existing "licence option" to allow server operators to put up a consent form if they want (since use of consent is up to the server operator, not the Jamulus project). Note that I have in the past flagged my concern with this licence option as it currently stands because I think it does represent an actual legal danger to the Jamulus project that I believe we should fix. But that's not a privacy issue, it's a copyright one. |
|
I‘d see it differently: currently the user doesn’t know that jamulus connects to google. As I understand this function gets called on every (central) server.
and
|
Do you have a recommendation? Maybe some Debian server? Or Wiki? |
Maybe last comment crossed with yours (if so apologies as you may not have read it) but can you explain why you think that to be case? @corrados How does that change anything about the privacy issue here? Isn't the problem the exposure of IP addresses to 3rd parties? Or do we just hate Google? :-) |
Wikipedia? But I think it’s blocked in China. DNS.Watch could be something we could use. |
|
Look, guys - can we be clear about the issues here? We're talking about:
I don't have any problem with us regarding Google as bad. However, that has nothing to do with any possible legal issues arising out of the first two points. If we want to change something based on our feeling that Google is evil, then let's do as Volker says: change the server in the source code. If we want to change something because we think there's a legal issue, then let's create a separate ticket and discuss that there. Please do not confuse the two. |
|
This "IP address is a legal issue" thing has come up before, and people always seem confused by it. I'll create a ticket outlining the issues and options we have. Yes, I am not a lawyer, but you don't have to be one to take responsibility for at least trying to do the right thing based on an agreed understanding. I know (from experience) that if we asked a lawyer about this, they'd say it depends on a great many things and give us various options including doing nothing, none of which they would recommend over any other. Because that's how lawyers roll :-p |
|
Sorry @gilgongo I must have missed your comments. I'd say basically that these 3 points are the problem. |
|
My view when writing that was that anyone who cared enough about it would read the code and know how to block it. Anyone else wouldn't have a clue and would be using a web browser that exposed far more PII than the ping here does. Given than, as @gilgongo says, a lawyer cannot tell you what the ruling a court will give will be in a specific case and will make that plain - it'd come down to exactly that: being taken to court. I simply don't think any case would stand or even ever get that far. |
|
@ann0see OK, and would you agree that in the interests of clarity, then if you re-named this ticket to something like "Alternative to Google being used to get external IP?" then we can then talk about what @pljones just said on a separate ticket? Basically, the issue of IP address privacy has come up before, has done again now, and will continue to do so unless we get our stance on it clear. We can then point people to that ticket every time (or hey, have a wiki page on it if need be), |
ann0see
changed the title
|
Edited the issue title. |
Whether (and why) we do that can be discussed here #576
As long as that doesn't' get confused with the completely separate issue of GDPR consent, then maybe. |
If this were done, there would need to be a pick list of "known good", highly available end points. It must not introduce further "trial and error" for server operators. It must not introduce firewall issues for cloud-based servers. Any change in current behaviour would need documenting so that server administrators can make an informed choice as to why change is being forced upon them. |
|
Given the relative cost/benefit of the issue, might we have a compromise by having a "privacy policy" page on the wiki as @ann0see has suggested that explains the use of 8.8.8.8 (amongst other things) and then suggests that if server operators have a problem with that they can re-compile with an alternative of their choice? This would at least cover the principle of being able to take action on information. |
|
My big concern is that any change might expose the less "in the know" operator to unscrupulous persons advising them to use IP addresses that could then provide means of access to a server. I wouldn't even go as far as suggesting changing the IP address, as I think this is asking for trouble. As I originally said, those worried can check the code. I've no objection to mentioning that the Google IP, 8.8.8.8, is used, of course. |
|
Ah interesting. So we should simply state the facts, and what people do with those is up to them. That seems like a good course of action. So would that be a resolution to this issue? I can draft a statement on the wiki that people can re-jig into something we agree with. |
|
The bit of code in question is only used in one place: to get an idea of the public address when registering a server. On Linux/FreeBSD, at least, you can get the same effect without sending any network packets at all, e.g. by creating a UDP socket, Alternatively, the central server knows the address the registration message came from - you could make the default address 0, and have the central server replace 0 with the source address of the message. |
|
@ann0see @pljones @corrados @atsampson So in order to resolve this ticket (and possibly all Privacy/GDPR like issues), I think we should just put up a privacy statement as suggested by PL Jones, and leave users to make their own decisions. How about this? (@atsampson's UDP connect suggestion notwithstanding): Use of Profile InformationWhen you connect to a public or private Jamulus server, whatever you put in My Profile (in Settings) will be shown to others on that server while you are connected to it. The server does not otherwise store or record your Profile information and the server operator has no access to it unless they are also connected as a client. When you connect to a public server, your profile is also made available to third parties by the Central Server to which that server is registered. This is for informational purposes about the status of the public Jamulus network (for example, here). Profile information is not otherwise logged or stored by the Jamulus server you are connected to, or by the Jamulus Central Server, but may be stored or processed by third parties. Use of IP AddressesWhen you connect to a public or private server, the server operator can see your IP address while you are connected. If the server operator has enabled logging (which is off by default) your IP address will also be logged and stored in the server's log file. As a server operator, when you register a public server with a Central Server, your IP address is sent to Google (8.8.8.8) in order to identify your public IP address. The IP addresses of all public servers registered with the Central Server can also be seen by third parties for informational purposes about the status of the Jamulus network (for example here). Your public IP address is otherwise not logged or stored by Jamulus, but may be stored or processed by third parties. Audio RecordingsYou will see a notice if you are connected to a Jamulus server while server recording is turned on. Recordings of each player are stored by the server separately as .WAV files and only the server operator has access to them. Text ChatWhen you type a message in the Chat Window, other connected players can see that, but chats are not stored by the server and neither the server operator nor any third parties have access to them. |
|
@gilgongo Sounds like a good compromise.
... and to allow clients to connect to the server probably? |
|
@ann0see Not sure I understand what you mean. By "server" do you mean Central Server or "normal" server? I would hope it's obvious that the user's IP address would be used to send audio to the user between the server though. Trying to explain too much might lead to confusion. The use of the word "process" for example seems to hide something (which is why I only use it for third parties because we don't know what they do). (BTW In my text I attempted to clarify that by referring to "normal" servers as just "server" while using initial capitals for "Central Server" but maybe that's not clear - wish we could call them Directory Servers or something instead). |
I tend to use "Server List server" or similar. |
|
Yes I note that we say "Register my server in the Server List" in the server UI. But the trouble is, "Central Server" is used all over the place in the docs and the code, isn't it (eg |
|
Yeah, that's because I wrote the server UI for the registration... :D Once, there was no server registration... Then there was THE Central Server. Everything known server was known to that server (start up argument). Then dynamic registration with the One True Central Server at the centre. Um and then Covid-19 and total madness with 500 servers exploding and destroying the Central Server overnight. One became Two, which were a bit shaky on how you'd decide which to register with (no one knew there were two, so servers got dynamically bounced). Then the "genre" idea came along, so there's a default server list, an all genres server list and the specific genre lists. Personally, like :) However, that said, things are getting quieter on the user side of things. All the server are still there but far more of them are empty much of the time. See http://jamulus.drealm.info/pj_local/html/ if you've not seen it, for my server's connection history. There's a spike in use before the surge in server numbers spread the load. If you "zoom in" (that is, see http://jamulus.drealm.info/jamulus), the recent history is looking comparatively sparse - still high than before, though. We'll have to see if all those empty servers get shutdown and the server lists become bare. Although it might be best to keep them with the problems some have with fragmentation. |
I see. Meanwhile, we have to have something to refer to when saying what happens to people's IP addresses etc. etc. I'll plonk what I've posted on the wiki anyway :-) |
Does the central server send IPs of the registered servers to all the clients? |
|
It's what registering your server means. How technical should the explanation be? The GUI says "Make My Server Public" -- that's pretty explicit.
|
Oh I see. In so far as people using Jamulus clients can't tell what the IP address of the servers listed are, then no. But we do say: "The IP addresses of all public servers registered with the Central Server can also be seen by third parties for informational or other purposes " I think further explanation would just be too confusing as it would bring us into the realms of trying to describe the operation of the TCP/IP protocol itself. If somebody wants to ask questions about the details, there is a link at the bottom on the wiki page linking to the forums. |
|
Ok. So you don't see a need for that? Me neither if the clients don't get the IP of the server. |
|
The clients have to get the IP of the server, otherwise they can't open the socket connection. See |
|
Yes but from the point of view of privacy, this isn't something that people running servers would need to care about because the people who run clients can't see the IP addresses of the servers. We explain that third parties can though.. That I hope will surely cover it :-) |
|
So give the privacy statement as a result of #576 is this ticket now closable? |
|
I don’t think so. Google is still being used and how to change it can not be found anywhere. What about the suggestion of @atsampson? Or a statement on the privacy page saying that it can be changed in the source code? |
|
Ah yes, the suggestion by @atsampson would be best really (#572 (comment)). Raised as a separate ticket so it doesn't get lost. Meanwhile, I'll add something like "Users concerned by the use of Google's network can re-compile the Jamulus source code to use an alternative". Not sure if I can reliably link to the line in question though? I'm guessing that might change over time? |
|
I‘d not link the line but say that the constants WELL_KNOWN_HOST/ WELL_KNOWN_PORT in global.h can be set to some other service. |
|
@gilgongo I've changed your edit and linked to https://github.com/corrados/jamulus/blob/master/src/global.h since this is the latest version. I think you linked a commit? |
|
Oops thanks for fixing that! |
|
No problem ;-).
New issue? |
|
@atsampson Should open that really. So can we close this one meanwhile? |
|
@atsampson‘s solution is probably best, but for a quick "fix" is the ip of a Central Server. I will close this issue in a few days and open a new one if he doesn’t open it. |
|
Ok, thanks! |
I‘m currently looking through the code and found that jamulus connects to 8.8.8.8 to get the external IP address. I could imagine that a connection to google could be seen as a potential privacy issue (also due to the fact that it’s not mentioned anywhere).
See GetLocalAddress() method.
The text was updated successfully, but these errors were encountered: