I am wondering what my client manager “close group” can get to know about me when I am using the SAFE network, in the hypothetical scenario that one of them is purposefully monitoring my data traffic. Obviously they know my IP address. I just wonder if they can also for example monitor what public (unencrypted) datamaps I download?
4 Likes
They can but they also cannot put themselves in that group. So the quandary of surveillance begins, they do not know who they are monitoring and taken on a global network the more popular the network, then the more difficult that task is, so natural we hope. Basically it’s safety in numbers and geographic distribution.
2 Likes
This is possibly a serious flaw and grounds for hesitation in terms of public data consumption. Giving every constituent of a group that power will almost guarantee that malicious users will abuse it. I’m very surprised that this design has been accepted. A person doesn’t need to know the requester or his/her true intentions to “police” the network motivated by their personal beliefs. With this power I could submit to an oppressive country that one it citizens has downloaded a public data-map of anti political propaganda. You can guess the result.
This is very off-putting. I’m glad forums like this exist. Without it, these things would not have been brought to light so early on due to the lack of proper documentation for the average user. This revelation saddens me… 
Not even Tor grants this ability. Exit nodes can snoop un-encrypted data but aren’t directly connected to the client. I don’t know, maybe I’m not seeing this clearly.
EDIT: Thank you for clarifying. I was VERY wrong. 
You connect to different nodes each time with encrypted streams (to known nodes when you can) after you get on the network. So your ip address is scrubbed, you connect via a random port to a random node(s). I don’t see it as a design flaw but as the best that can be done.
Ideally if a group can create their own private key (group key) then we may be able to do more (look at SQRL type key derivation to see how this may do). Then you connect to a relay nodes(s) and encrypt traffic through them to client managers). So it can improve but already seems significantly better that any other system I can find in securely getting on a p2p network.
4 Likes
The stream may be encrypted but if they know what public map you are downloading, it gives them the power to snoop. IP scrubbing does not help if you use the same group to request your download. I could just be confused as to what you meant. If IP scrubbing occurs by the bootstrap close group before transferring you to another group with your new XOR id, then that’s a different and sexy story! I hope this is the case. This would mean that the close group could snoop on public data maps and link it to your XOR id but would fail to know your IP. Simple and effective solution. 
2 Likes
This is the case. Your close groups (clientManagers) are passed a relay address type. At the moment it includes a way to get your public IP but will not at release. So your address can be considered scrubbed at the relay node. It means then nobody but a relay knows your IP but then it does not know what you are doing. So it works out very well.
I should say at the moment (in testing) we use the real local IP as the identifier, but will not in release (you can see in the code if you look at routing/ClientAddress struct but you will see where that will be a hash (irreversible).
I should also say for GET the ClientManager is not involved and requests go directly to the DataManagers of the data, so it’s pretty secure.
13 Likes
When you say at release, do you mean the very first public test-net expected in a few weeks? Or are you referring to the stabilized release of SAFE with real safecoin?
This I didn’t know, I thought client managers had a direct connection. So this relay, is that a group, or just a single node?
1 Like
Single node(s) It’s a security improvement done a few sprints ago.
5 Likes
In between these times 
1 Like
Thanks for your answers David, it’s much appreciated.
So, I assume that the client manager group encrypt the public datamap with your public key before they send it to your relay node(s)?
1 Like
It is more like this
client → relay node(s) → Client Managers (For Put)
client → relay node(s) → NAE Managers (for Post/Get)
So the relay is almost dumb and does not need to be able to understand what is happening, just pass on “stuff” to an address. In terms of what is readable then routing info minus IP and data (which on the network is encrypted) as well as signed requests to alter (Post) or plain Get requests.
4 Likes
This is what I wrote some time ago after studying how this part works. I think it’s still valid:
So, my close nodes have my IP:port:public key etc. So now they’re gonna watch the chunks come in and out and try to understand what I’m doing you think? Maybe they have lists of files and their chunks and try to catch me downloading an blockbuster movie from Hollywood? Well, time to add another layer of encryption. Yes, you are in group of close nodes and some of them will know your IP because they need to get data from and to your computer. So in a group of 32 close nodes (based on XOR) maybe 4 or 5 will know you IP. But now the magic starts, remember; you don’t ask for data on the network, your close nodes will. So while this group of close nodes is randomly chosen, you will connect to another group of nodes which are your (data)managers. The connection to that group will be the third layer of encryption, and maybe already a forth one! Because for something like “browsing” the Safenet you will use an identity to request data. But let’s go back a little. So, your close group connects you to the manager-group who are “somewhere” in XOR-space. This connection will be encrypted so your close nodes cannot understand the data between you and the managers. Your managers on the other hand, will understand your requests but they have no clue about who you are. To them your just another XOR-adddress that’s close to them in XOR-space. This way the close nodes will work like a proxy to protect your identity.
4 Likes
“s/close nodes/random relay nodes” and you are good I think
1 Like
This is indeed new to me as well. So in layman’s terms, before you connect to anyone or any address in XOR, all your data goes through a “proxy”. This happens on ip-level than? Before you connect to your group. So it used to be that out of the 32 nodes, some would’ve known your ip, but even your close group doesn’t know your ip anymore??? Wooow, this is like really secure. And quite logical indeed.
1 Like
That 2008 crisis really got to you, didn’t it? 
6 Likes
I used to say In Enron’s terms, but that one is way to outdated
7 Likes
This is another hop though, how are the calculations now for 1 million users?? The regular calculation +1 I guess??
Depends, do the client managers know the IP of the relay? Or do they address him through the DHT with an XOR address?
1 Like
