[...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@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