[i2p] Re: HTTPTunnel vs. {privoxy,muffin} + HTTPClient

[jrandom]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi mihi (et al)

> > browser <-> privoxy <-> httptunnel <-> I2P <-> outproxy <->
> > www.pr0n.com
>
> If you think that is good, we can do this like that.

I don't have a very strong opinion wrt the particulars of using
privoxy, integrating muffin, or even using fred's anonymity filter,
but the idea of reusing an existing filtering engine seems both a
more efficient use of scarce developer time and a more component
oriented (read: maintainable) way to go about it.  (ok, thats not
entirely true - I do have a strong opinion that we shouldn't use
fred's anon filter ;)

I agree with your goals for httptunnel - a proxy that is designed
from the ground up for allowing the user to browse eepsites and
the normal web anonymously over i2p.  You've always caveated the
existing httpclient code by saying it was just a quick add-on to
i2ptunnel, and its served its purpose extrordinarily well - we've
been able to host all sorts of interactive and static web content
on eepsites.  But I agree, its time to review how web content will
be accessed - both eepsites and normal web sites.

Everyone has been bitching about the need to switch proxy settings
when going from normal web browsing non-anonymously, to browsing
eepsites, to browsing normal web sites anonymously, and rightly
so.  What I'd love to see is an httptunnel that allows the user to
have their web browser ALWAYS pointing at httptunnel, and giving
them a series of options:
1) browse the normal web non-anonymously
2) browse the normal web non-anonymously, but if a *.i2p url is
   reached, go to that eepsite
3) browse only *.i2p urls, giving a 403 error on all other URL
   accesses (perhaps on that page it'd have a form you could
   submit to jump to option 1 or 4 and continue on to browse the
   normal web page)
4) browse the normal web anonymously, using a trivial round robin
   among a statically defined set of outproxy destinations
   (outproxies.txt or whatnot), as well as browsing *.i2p URLs by
   going to that eepsite.

The "safe" mode of operation would be options 3 and 4, the "i2p
sucks" mode of operation would be option 1, and the "who cares
about my anonymity, I just want to see an anonymously hosted
eepsite" mode is option 2.

In addition, all four of those options would want to include a
toggle to transparently filter the content and headers, using
muffin, privoxy, a homebrew system, or whatever.

Bundling in an outproxy to encourage people to run one would also be
Good imho, but obviously not necessary.  In addition, bunding a
simple webserver to let Joe Sixpack run his own eepsite right out of
the box would be nice as well (Jetty [1] is fairly good at embedded
serving, offers both JSP and CGI, is very well tested, and is only
300KB).  But, yeah, those things aren't /necessary/.

After looking at your new HTTPTunnel code, I see how you're also
exploring a different aspect of anonymity - the (un)linkability of
requests from each other, the tradeoff between pseudonymity (a group
of actions being tied together under a single nym) and anonymity
(all actions coming from unique unlinkable nyms).  That *is* a
very important distinction, and I'm glad you're building in the
infrastructure for addressing it.  That said, strict anonymity in
that sense - using new destinations for each request, as opposed to
simply using an anonymous pseudonym for web browsing might get
pretty overwhelming for anyone who wants to browse more than a few
pages

Even so, I really like how the current I2PTunnel's httpclient goes
about it - creating a new random destination (pseudonym) each time
its run.  Maybe in the new HTTPTunnel the default technique could be
to recreate a new random destination once an hour, so that at most
one hour of your web browsing can be tied together?

> btw, i wanted to write a "prototype" that can show that I2P works
> when I wrote I2PTunnel(HTTPClient). All of you know, that in real
> business prototypes are often abused as "real products", and I
> just wanted to prevent that for HTTPTunnel. (For I2PTunnel I think
> it's no problem, since it got enough refactoring to be seen as a
> "real product" by me).

I agree wholeheartedly - I2PTunnel has been growing and maturing, and
your latest streaming API provides fertile ground with which normal
streaming apps can build on to anonymize their communication.  As I
mentioned to you in private email the other day, there are ways
I2PTunnel can be tuned further to reduce the overhead of the
connection handshaking, and, as you replied, we can deal with that
sort of tuning once I2P is working well enough that it'd make a
difference ;)

> btw2, do you think I2PTunnel was good or bad for I2P?

Without a moments hesitation I can say I2PTunnel has been an
incredible asset to I2P.  I'll never forget the first time I
listened in on an anonymous OGG stream, the first time I saw
someone's webcam load up, or even that very first time you hopped
on IIP through I2P.  While yes, it has slowed down the adoption of
message based protocols and applications designed to exploit I2P's
architecture, the reality is that we can get much more bang for the
buck by finding ways to reuse existing systems with I2PTunnel.  If
you hadn't taken the initiative and put in the time to design and
implement I2PTunnel, we wouldn't have eepsites, streaming audio,
distributed and anonymous irc, usenet, or outbound HTTP proxies.
We'd still be battling with trivial little custom apps like ATalk.

I do feel that there are still some situations where people will
want to look at using I2CP directly - for example, a scalable DHT
over I2P would very likely want to be stateless and message based,
since it would be interacting with thousands (or more) of peers at
a time.  Also, VoI2P or any other UDP-esque protocols (where lossy
behavior isn't bad) would likely be served well by using I2CP.
But with I2PTunnel, you've given us a way to deal with the vast
majority of streaming TCP/IP apps.

In my experience working in software consulting and product
development for both small firms and multinational corporations,
the managers I've known most definitely prefer hiring developers
who are capable of finding the quick and imperfect technique that
meets the real needs of the userbase instead of those devs who
will spend months designing and implementing an 'ideal' system.
The only real exceptions are r&d groups, academia, and managers
who don't know what the fuck they're doing ;)

Anyway, thats my take on things.

=jr

[1] http://jetty.mortbay.com/jetty/index.html

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQFoM0MIgL3Iaet+UEQI83QCg8eljBc9qhYNZ95ZlVFTL2UQcxOkAoKRU
cR1XoQC3jnL1JO89hnQwAd14
=Oxbk
-----END PGP SIGNATURE-----