Hello Alexander, and list,
that is an essential idea, which is now discussed, and that start of that development is still missing. So good to hear.
First, I agree (as posted earlier), that we need a tit-for-tat Tor:
Everyone who wants to surf with the IP of another peer, needs to give his IP as well, so that others can surf.
That was the idea of peek-a-booty software, which stalled in development.
We raised the question to have a special browser with this exit-node tor implemented to jap and roger and torpark.
But noone ever came up with any solution.
You now mention the firewall problem...
here i might be allowed to suggest as well this kind of architecture, which helps in three ways:
a) surfing of all friends through my IP: psiphon or retroshare patch
an now the interesting thing c) Breaking through a firewall:
RS has implemented openDHT and other RS nodes work as a STUN server, so the connection can break through every firewall.
The idea is now, to use any retroshare node to make the firewall breakthrough for the TOR-Client-Firefox node.
That design uses not the f2f-connections, but the network only for the firewall breakthrough (initial Stun).
Of course you can install as well any central STUN server.
The problem with this design is, if the (central or public known) stun server is killed (or the forwarding tor server), then many client-exit-nodes (the firefoxusers) are killed.
(and of course the users doing evil things to them with the ip of the client-exit node... so here is the real problem, not showing the IP of the pseudo-exit node not in the tor-server list).
You request a total change to a p2p network, away from the client-server approach. That was peek-a-booty.
so your idea has two main impacts:
- firewall breakthrough
- hidden client-exit-nodes (covered by the IP of the proxy-forwarding (stun)server)
As said: the p2p network needs no serverlist, just any user as an outproxy and every user testing TOR can accuse any IP - the one with which he surfs - to shut down the exit node. Indifferent, if it is a pseudo or normal or client exit node.
I would speak then of a "professional server exit node" and an "at-home-Firefox-private-exit-node", and because of the firewall, the private exit nodes need a stun server or "reflector" (term from cucme) or a proxy or a forwarding server - however you want to call it.
professional exit node = Tor servers (appear in the list)
refelctors = Pseudeo-exit nodes
Private exit nodes = Firefox users, connecting to reflectors, getting the requests forwarded from them.
So the hiding of the IP of the private exit node is not the issue..
(though with your design they do not appear in the list of the (normal tor) client, but every user can surf, see the exit-ip and take it down (= test if there is a log, if not -> accuse )).
That is the same problem with the emule clients.. which show the IP downloading a file.
Using the STUN/proxy servers or reflectors to hide them, helps, but then the target are these STUN pseudo-server. If one is down, many private or client-exit nodes are down.
And how do clients find the list of refelctors? so you have the same problem in the Firefox client, which you have now in the tor client serverlist. ("Note that currently, any relay must be able to connect to any other relay.)
2. Make Tor tit-for tat for that deamon.
3. Stun the deamon with retroshare (as it is a p2p stun network and not a cental stun server) and then users need to install both.
(btw. the Qt gui of RS has as well a browser widget, so you can implement as well a small browser there, or link to localhost for your normal browser.)
What is then the function?:
e.g. all private-exits could even perform a new network, STUN by RS.
or: the professional exit nodes are as well given, but then the client/private exit nodes are listed in each serverlist.
In the end, though roger might not like the idea, I believe, that we need trusted privat friend to friend connetions to such reflector servers.
That means, I surf over RS to another RS user, whom I trust, and here I find a reflector or a direct exit point.
That means, this client is free of any serverlist...
And for the reflector... this means, he is not reporting any client nodes (friends) to any professional servers. As he chooses any friend out of his list (by random) to forward the request from normal tor clients or professional circuit tor servers (or other friends).
So you see.,. in the end, the firewall breakout is trivial and only a technical thing.
The hiding of the leaves.. or client-nodes is not really helping, as you see in emule: downloading shows the IP of the file-hoster/inserter or the client-exit-node and makes only the reflector servers the target.
any test to surf with client-exit nodes showing a german ip rises the question: how is data retention done.. as it is not, the users are still accusable.
You only can get away from that problem, if the connection to an exit node is done by trusted friends in europe, while the exit node/reflector is outside the law.
The solution to the problem is, that private persons allow private persons/friends to surf with his own IP adress, while that IP is NOT listed in the public!!
Or the other way round: the problem are the (public) list of tor-servers.
We need to find tor server to forward the request, to a bunch of other IP-adresses out of a cache, while each client has another list in this cache.
one retroshare node with an tor-reflector node in the USA allows all 10 friends in europe to be exit points, which are not know in the tor world.
The connection then between/amoung reflector nodes itself and their connection to the normal peer-based tor network might reveal then all IP adresses of the reflector nodes.. so they are still able to take down.
For that then you need as well a web of trust (excluding private peers) amoung the reflector nodes.
These nodes are then only accusable, if the evil man sets up as well an relfector, to find out all the other reflectors. (that means a new network, reflectors not conneced to public tor server lists)
as they are a kind of multiplicators or supernodes, it is a big damage, if one of them is gone, but if every reflector is only aware of a small list of others, then the IP of that reflector is not in the public.
anyway... just some thoughts and the resticted list of nodes is still an not solved problem. Hidden services might help?
Ideally you want a new network, in which you get in a DHT a list of all nodes, which are all exit nodes, yourself including,
you just need one Ip to bootstrap and then just choose any peer which is online, to use him as an exit point. (to prevent data retenmtion, one hop mixing) oR: that amoung these participating nodes tor circuits are establisehd (proxy network not only to change IP, but also to hide IP).
For that application you of course need a port forwarding, if not STUNed by another peer (see how RS has solved this, above).
And this network is quite easy to do:
just make every tor user an exit node.. then the list is very long...
and you pic up any ip to surf with only one hop or to build normal longer circuits.
But then the police can ask any listed IP, if the logs are running or not - and they can even ask the ISP for that,