thoughts on proxy services

[Ryan Lackey]

[...suggestions on proxy services by Peter Trei...]

(my thoughts follow; might as well post to the list as well since I'd
love for someone else to provide this service vs. me; I care more
about having it available than the eventual revenues it might bring.
But I suspect I'll do it myself; comments from list people would be
useful though.  I would *love* to be surprised by a new and
interesting security company or project doing worthwhile stuff which I
myself would use, even if it's in competition with me.)

(my goals: 100%+ cost recovery.  simple design, implementation, and
operation.  minimal barriers to entry for anyone.  security against
demonstrated threats, and an explicit statement of what risks remain
and maybe how to deal with them later.)

I'm sure the issue of proxying, general traffic analysis protection,
etc. has been discussed many times by people smarter than me, but this
is my basic understanding: do you agree?  If I can't find something
much better, it would be tempting to write a brief summary paper;
nothing really new, but this is an area where a clearly presented
summary could be useful to designers.  (I just deleted about 5 pages
of an attempt to do this; it was just more confusing than it
answered.)

[...safeweb's failed revenue model, good technical model...]

Yeah, the tricky part is making it pay.  Since bandwidth is rather
cheaper in bulk (especially since you can then peer more of it away),
I figure cost per marginal Mbps is 95% of the previous.  I have a
serious surplus of outgoing traffic right now, as do most non-end-user sites;
something which brought inbound traffic would make peering
arrangements easier.

Any traffic which would go to on-Sealand servers anyway is no marginal
cost to me.  Yet, it provides a substantial benefit to server operators;
sure you're talking to a Sealand-hosted server, but which one?  We
have casinos, payment systems, but also some benign content.  The
benefit there is primarily some traffic analysis protection against
outside parties; but you also gain some protection from HavenCo's
customers learning your identity.  At least with the population of
sites we have now, I'm far more concerned about passive monitoring at
the client's LAN or firewall than anything else.  People will "pay"
with time and money if a product solves an actual demonstrated
problem; getting fired for looking at pr0n at work is one of those problems.

An https:// url with maybe http accelerator cache inside the network
and then displaying content in a frame is a first and very easy
solution.  An entirely server-side url rewriter is also possible;
rewrite the html as sent with keyed hash urls or something, translate
on the servers.  But frame is first since it's simple, 100% server
side, and secure.  This also keeps crap out of IE's url history file, and
I can do nocache-rewritting as well on the pages (will have to
experiment with various browsers to see what that really does).  With
a couple of SSL accelerators, this should be fairly cheap to provide.

I'll use that to determine usage patterns, bandwidth consumed, etc.  I
will add more general-interest servers on Sealand (both customers and
free); and perhaps some kind of USENET service, file archive,
discussion board, etc., which will provide a lot of benign cover
traffic.  One of the better arguments against using HavenCo for
anything very sensitive is that even with crypto to the server, you'd be
giving away your participation in an online casino or porn site or
whatever; this will solve that.

I can subsidize random people text-proxying, but I can't do porn or mp3.
I could charge actual site owners to put their porn on Sealand
(normal commercial hosting arrangement), possibly just as an actual mirror
site, vs. moving their primary, to support HavenCo-proxy customers.
An insignificant part of the overall porn market, but maybe a few of
the ~50-100 *big* porn hosters will put a box there just for the 0.01%
of customers who want to access via HavenCo; they then could get
50-100% of that market.  With http accelerator caching, bandwidth
prices would even be reasonable for them.  I think this was where ZKS
missed out with Freedom; cooperation with service providers to
provide on-network anonymous services, assistance in making their
services privacy-compliant, etc. could have made freedom.net actually
contribute to the meaningful (products sold to businesses, not privacy
hobbyists) bottom line.  Oh well.

We do this already with a "net-10" onsite to allow customer to
customer traffic, infrastructure, etc., but making it transparent to
the server operator and using a proxy in normal address space makes
more sense, I think.  The original motivation for using net-10 was to
make accounting simpler, and to "fail secure" (since net-10 isn't
routed); we have flows-based accounting as a possibility, and if you
want fail-secure, net-10 is still a possibility.  

-- 
Ryan Lackey [RL7618 RL5931-RIPE]	ryan at havenco.com
CTO and Co-founder, HavenCo Ltd.	+44 7970 633 277 
the free world just milliseconds away	http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F