When using the Tor Browser Bundle, basic configuration and control is made available through TorButton, which, among other things, talks to Tor by way of the control port. It does things like request, restart, and close connections, provide coarse controls over active content, and management of contextual identities. Some or all of these functions may be useful to browsers using this proxy. To do this without modifying TorButton, I may need to create a compatibility layer, which translates TorButton's calls to the Control Port to equivalent requests for information and processes from within the proxy and within the i2p router it uses instead. This issue is to track how, or if I should, attempt to create such a thing.

Update: In order fully to achieve what I wish to achieve(An un-linkable browser for safe casual viewing of multiple eepSites), I should make this proxy understand a subset of the Tor Control Protocol information as used by TBB, and translate them into equivalent i2p requests. New, much longer-term question, should I add outproxy support via Tor and pass instructions for clearnet and .onion sites to the regular Tor Control Port?

So I've pretty much successfully broken the cryptographic connection between a visits to separate eepSites. But less reliable forms of linkability are still possible. This issue is to keep track of what those attacks are and whether the proxy will be able to do anything about them. I'll add them as I hear about/understand them:

"Classic" fingerprinting

Fingerprinting techniques using Javascript are pretty well known, I won't waste time here.

1. Is it something that can be fixed? Probably better to think of it like an arms race rather than a problem to be solved for now. Browsers are complicated AF. Pessimism is a perfectly fair position. In terms of the arms-race stance, though, the tool to use is the Tor Browser Bundle, modified to use non-tor proxies.
2. Does it lead to identification? Kinda. It fails to de-obfuscate the location of the user, but it's capable of gathering so much information about a person's computer that it can be pretty unique.

Addressbook Fingerprinting

Currently, it's probably possible to tell whether a readable address is in the local addressbook. If that's true, then it's possible that an addressbook may be unique enough to be personally identifiable. If that's true, then it defeats the purpose of this software. I need to find a way to make this information useless.

Eventually, jumphelper will fix this, but it needs a LOT of work. Jumphelper also needs the interstitial 'add to book' page, and it also needs

Attacks on the control interfaces:

Right now the primary interface for granular control is the pipe system, but since it's path-based, there's the possibility that a malicious URL could be used to inject something into someplace it shouldn't be(i.e. use a malicously crafted URL to retrieve content overtop of a "send" pipe). In order to fix this, pipe interface names should be reserved, and replaced transparently before they can do damage. A resolution I think will work is now in place.

1. I'm pretty sure I fixed it.

2. It should be resolved.

Besides this, I have planned a disk-avoidance mode which will disable the pipe system entirely in favor of the control port emulator.

Request Timing Attacks:

Using a similar network of colluding sites as the one used to correlate i2p destinations, make a request from one site to a resource from another site. Record the time. Requests close in time are likely to have come from the same user, especially on sites with very little traffic.

1. Is it something that can be fixed? Maybe. One partial solution is to tear-down tunnels to a particular eepSite after X minutes without a request. That way, an attacker has to keep a connection open to create reliable longitudinal data. Of course, that's simple enough, just keep requesting resources from that site. Another partial solution would be to intercept requests to off-eepSite resources and inject a random delay before sending the request. That would make it harder to correlate third-party requests to an individual user if a site has sufficient traffic. Unfortunately, there's no way to determine how long to make the delay that I can see because it depends on the traffic to the eepSite. In combination, these are probably worth doing even if they can't fix the issue completely. Besides that, it's an argument for TorButton integration which I'd been considering anyway(Use new circuit for this site or whatever). It would also be possible to use a unique dynamic URL for the same correlation(i.e. send the destination of the requester in the URL of the request). This is definitely damn-near impossible to fix, except maybe if I scrub it out of requests, but then it's still possible to do with any other unpredictable piece of data. I could make this unproductive by making all cross-site requests appear to be from the destination of the page including the resource request, but as far as I can tell, it's a break-even prospect and would involve more work on my part.
2. Does it lead to identification? Not reliably in most circumstances, AFAICT. It leads to suspicion, it can probably be used to profile, but it neither de-obfuscates a user's location nor links them to a very unique piece of data. Moreover, the more people using an eepSite, the less likely such an attack is to indicate anything useful.

Requests for local resources:

These types of attacks have, traditionally, been mitigated in browsers rather than in proxies, and using TBB will fix this. Still though, I would like to explore whether it would be worthwhile to try and "Strip" malicious requests for say, an image in the i2p router's admin panel out of pages before they reach the browser, or offer some kind of warning?

1. Is it something that can be fixed? Yes, use TBB(more accurately, disable un-proxied requests to the localhost in any browser, but TBB does this automatically). This is simply exploratory.
2. Does it lead to identification? Not usually, but I bet it can.

Great work. This is an important security feature. Can you please include this in I2P by default?