one eepSite, one destination. Semi-automatic contextual identity management for casually browsing i2p eepSites.
This is an i2p SAM application which presents an HTTP proxy(on port 4443 by default) that acts as an intermediate between your browser and the i2p network. Then it uses the SAM library to create a unique destination for each i2p site that you visit. This way, your unique destination couldn't be used to track you with a network of colluding sites. I doubt it's a substantial problem right now but it might be someday. Facebook has an onion site, and i2p should have destination isolation before there is a facebook.i2p.
I2P Link - Stream Isolation I2P Link - Shared Tunnels
Development here has ceased. A replacement that will work much better is in development at eyedeekay/eeProxy.
Sorry for forgetting to license this. It's MIT Licensed now.
Moved to misc/docs/INSTALL.md
curl -x 127.0.0.1:4443 http://i2p-projekt.i2p
export http_proxy="http://127.0.0.1:4443" surf http://i2p-projekt.i2p
If you'd like to test it, the easiest way is to use Docker. To generate all the required containers locally and start a pre-configured browser, run:
make docker-setup browse
It's still a little experimental, but currently it is possible to set your web browser's HTTP proxy to localhost:4443 and use it to browse eepSites with the guarantee that you will show a different destination to every eepSite you visit. Combined with a browser designed to minimize your uniqueness to the servers you visit, you should be much more difficult to track across sites and across sessions.
That said there is the obvious thing to consider:
If it wasn't super, super obvious to everyone, it's really, really easy to tell the difference between this proxy and the default i2p/i2pd http proxies and I don't think there's anything I can do about that. Also if you're the only person to visit a particular group of colluding eepSites then it's still possible to link your activities by timing, but I don't think it's possible to "prove" that it the same person exactly(certainly not in a cryptographic sense), just that it's likely to be the same person. I can't do anything about a small anonymity set. That said, the tunnels created by this proxy are inherently short-lived and tear themselves down after an inactivity timeout, requiring an attacker to request resources over and over to keep a tunnel alive long-term to be useful for tracking. By the way, as far as I know, using this will drastically reduce your anonymity set unless it's widely adopted. TESTING ONLY.
I haven't been able to crash it or attack it by adapting known attacks on browsers and HTTP proxies to this environment. It should at least fail early if something bad happens.
Addresshelpers are tentatively working again. I'll need to explain more on how soon.
It mostly looks like Jumphelper is working immediately after it's started, but if you try to visit a base32 address before they sync, then si-i2p-plugin will ask jumphelper for it and fail, interpreting it as a hostname error. It lasts for like, 15 seconds and only affects base32 URLs and is fixable.
I wonder if I could make it talk to TorButton?
Littleboss seems like it could potentially be useful in lots of contexts, like in a portable browser bundle and stuff like that.
I really need to get a Windows machine, but it's just such an awful way to work.
The final version should use the parent pipe and the aggregating pipe to send and recieve requests as an http proxy in the familiar way.
Version Roadmap:
Moved to misc/docs/PIPES.md
XMR:43V6cTZrUfAb9JD6Dmn3vjdT9XxLbiE27D1kaoehb359ACaHs8191mR4RsJH7hGjRTiAoSwFQAVdsCBToXXPAqTMDdP2bZB
BTC:159M8MEUwhTzE9RXmcZxtigKaEjgfwRbHt