With increased adoption there comes more information for relays to sample. I remember a discussion about this a few months back, but I think it would be nice if we refreshed the topic and discussed the plans, it’s effectiveness and any potential flaws.
I remember being told that communications would be dual channeled. Meaning that a relay can only witness only one direction for any given connection. So quering would go through one relay and results would return through another. The issue of snooping though reduced still remains.
Someone then proposed an onion routing system between the user and the network. I’m unsure if this proposal was accepted or found to be flawed. If implemented, would it be optional or default behavior. This is important IMHO, as most data on the network will likely be public thus subject to snooping and possibly censoring (a distributed blacklist of datamaps).
One option might be to connect to SAFE through friends much in the same way Freenet implements their signature Darknet mode. Just throwing the though out there. @dirvine ?
I understood from that previous discussion that the relation between the client, relay and client manager group is onion-like, though only with one layer. The relay doesn’t understand the payload (presumably encrypted), the client manager group doesn’t know the IP address of the client. The communication from relay to client managers is routed through the DHT, they’re not directly connected. Would love to get some additional clarity though.
Couldn’t public data be decrypted by the relay on the fly? Watching for public subversive data seems like a real possibility given the lack of an extra layer of encryption. Is this correct or am I missing something?
Not sure, I guess chunks should be asymmetrically encrypted using the client’s public key before it arrives at the relay. Though the drawback is that caching encrypted chunks is generally useless. There seems to be an inverse relationship between scalability and anonimity…?
Making it optional and off by default might help balance the equation so to speak. Those who need strong anonymity would activate it at the expense of speed. Might any of the other ideas presented above help? Onion routing between the client and the client managers would provide forward secrecy at little expense.
I think it should be possible for a vault to accurately approximate how many hops a chunk in transit is away from it’s destination (based on it’s destination address and the network’s vault address density). It could be made a rule that it is encrypted by the client’s public key (included in the GET request and reply) if it’s 2-3 hops away from destination. That way caching works for most hops, just not the last few.
I’m not really concerned about client managers, they’re only involved in PUTs. It’s the GETs that get me the most.
How about public to private data conversion. The basic idea is that a user finds interesting material that is both public and subversive. To avoid relay snooping, the user triggers SAFE to encrypt the public the data-map and desired data with his/her public key at a cost equivalent to the storage it will use. The user can then access the data privately. How useful is this? Essentially no data is passed to the relay. The data is re-encrypted and instantly transferred to the user’s SAFE drive. Basically cloning the data and assigning it to the users account. This all happens internally without the relay’s direct participation.
Please keep in mind, that without having control of the NAE Manager, LE (who is in control of the relay) does not have the Client_public_key and cannot “test-encrypt” the public data to see if one or more chunks in that public data matches one or more of the chunks flowing through the relay node.
This exact same rationale was used in my follow-up. With a little critical thinking, those links and this explanation should be more than enough to answer your question.
If not, I’d be more than happy to expand on this answer.
P.S. My posts were in reply to another issue, but I believe that the information laid out there will correct your understanding of the functionality of the Network.
@Seneca, “NAE Managers” (Network Addressable Element) are the GET equivalent to Client Managers.
As mentioned above - you are 100% correct on this point:
because they should…and they are…or rather, will be…once released the Network is…
I have to admit that I have no idea how the whole thing is going to work, but my concern is not only about the privacy of the client, but also the safety of all relaying nodes from law-enforcement. If a specific chunk is publicly known to be part of an illegal file, nobody should be able to determine in which vault this chunk is stored (or even where it is cached). Every time somebody receives a chunk (during relay) in a manner that he can read it in clear text (say it was encrypted but he has the right key), it has to be plausible that the relaying node possibly did not know the chunk in clear text. Otherwise you could prosecute this node (at least in certain jurisdiction)…
Polpolrene is awesome! In that long forgotten post he lays it all out nicely. Unless regularly reinforced, I tend to question my own knowledge or lack thereof. I traded clear memory and critical thinking for loads of vodka (I mean it was only a month ago part of this was discussed, geez). Next up, mescaline. Soon I’ll be questioning more deeply my perceived reality. Wait, did I just interact with the internet or did it enter me!? Stop calling me!!! I told you I sweep ping sworn. Shit, mart looping my forge sip!! I think I just experienced a transient ischemic episode.
Watch the movie “thirteenth floor” under the influence of vodka and you will question your reality
A lot of effort went into making data access secure. The only hole left that David agrees at this time is open is if an investigator requests the public data and grabs the IP address of the relay node that sent it to their computer. Not an easy thing to solve. But is not a problem in all but a couple of places/countries as the relay node knew nothing of the data and the user had no control over it. In this case there is no issue about encryption because it was the investigator who requested the public data.
Ah that’s where the confusion came from. I vaguely remember reading that somewhere but didn’t search hard enough to confirm. This led me to believe that public data access was susceptible to snooping. THANK YOU VERY MUCH FOR CLARIFYING THAT FOR ME!!! Seriously, that filled a hole in my understanding. It was that memory floating around my subconscious that left me slightly uneasy. Now I know why. Just for that, I will now accept you as the ONE.
I will definitely check that movie out as soon as I get an uninterrupted 2 hour period in my schedule. I always enjoy a good mind f^ck!
Not only plausible, but necessary. And indeed, the relay has no way (even in the mathmatically improbable scenario) to decrypt the data that is passed.
