cryptofree: what + why + how :-)
For a couple years, we've been poking at the idea of providing some sort of "cryptostorm lite" version of the service that is no-cost but otherwise identical in security and privacy protection to full-bore cryptostorm service. Until recently, we really didn't see a way to make this happen that both meets our strict security/operations standards, and also provides a viable way to support itself financially (yes, we're 100% member-supported and always have been, and we're insistent on ensuring we can keep the bills paid and lights on via operational revenue... if we can't, the network has failed all of us).
Since the summer, we made progress on both fronts - technical and financial - to where we have now made available to the public a beta version of our "freemium" network privacy service: cryptofree.me.
A few things right off the bat:
- 1. We don't have a standalone website yet for cryptofree - we're working on it... sorta - as it didn't seem the top priority in terms of getting the service into the hands of the member community for testing. We do have a twitter feed already - @cryptofree - but it's not doing big things. Yet.
2. The "brand" of cryptofree.me is really an extension of cryptostorm, and as such we're not going to be pouring marketing a design effort into making it uber-cool or whatever... as if we do for cryptostorm anyway, so there's that.
3. Currently we've got configuration files available for linux & Mac/OSX, for testing. We'll get the Windows version, enabled within our widget, out there as quick as we can, as well.
- 1. The service is implemented via server-side network session bandwidth tuning, with a combination of 'tc' directives, iptables scripts, and tweaks to the way the openvpn server-side executables manage individual network sessions over time. Hopefully, we'll get more on our approach published soon... that's our intent, but we're focussed on rolling out and beta testing things at this point, and full framework publication will inevitably lag a bit in the meantime. It's coming, and we're happy to have folks review our approach publicly.
2. Initial per-session bandwidth caps are 1.5 megabits down and 1 megabit up (approximately). We'll see whether those numbers work out well, during beta testing. They obviously can be adjusted, as needed.
3. All cryptofree "instances" (see our Hostname Assignment Framework whitepaper for definition of terms) run on completely independent physical hardware from full-bore ("unlimited") cryptostorm instances, to ensure there's no struggle for resources between paid/unlimited and cryptofree network sessions.
4. Cryptofree sessions cannot be geo-selected to choose exitnode location; this enables far more effective resource management for us, and thus allows us to pencil out the financial side of things and feel confident it works over the long-term; full cryptostorm memberships, of course, have full geolocation/loadbalancer selection capability, as always.
5. There are no other limits, differences, or variations between cryptofree and "real" cryptostorm network sessions: client-side configuration sessions are essentially identical, server-side management & provisioning & security administration & kernel hardening are the same (in fact, we've compiled in full grsec memory-protection capabilities only in the cryptfree-node kernels thus far, although that'll change as time goes by), port-mapping & SNAT provisioning is the same, application & protocol support is the same. We were going to call cryptofree "cryptostorm light" initially, but that's just not true... it's not light. It's bandwidth-capped, but apart from that identical to full cryptostorm.
That's all we can think of, for now. The idea behind the financial side of things is no secret, and we're happy to share and discuss it: our hope is that folks will try cryptofree, be impressed by the network's performance, reliability, and coverage, and decide to purchase a token and "move up" to full-bore cryptostorm membership. If enough folks using cryptofree do that, then we keep the bills paid and ramen in the cupboard for the development team.
We're not sticking a bunch of bullshit limits, "rules," or handicaps on cryptofree sessions. Certainly, some folks will have them connected for weeks or months, streaming... well, whatever folks stream that's fine with us.
Instances, and hence nodes, will hit hard-capped maximum session limits and folks who try to log once all slots in the cryptofree network are "taken" will simply be unable to connect. At that point, we add more (physical) servers, elastically, to our provisioned pool within the larger cryptostorm network. We won't kick people off cryptofree sessions, nor jam too many sessions on one instance/node and thus make them all horribly slow as a result. That's part of our beta testing, to get a feel for those metrics... we have some guesstimates, but need objective data. In the event, the cap is driven by session availability, not by allowing people to jam onto nodes until things slow to a crawl. Fuck that.
Someone will come along and clean up this language, make it "nicer," and explain things better. That's cool. I'm just one of the tech team grunts, reporting on the discussions we've all been having for months and, in some cases, years, on this particular project. I don't know the black arts of marketing, sorry. For now, this is a data dump for beta testers - hopefully it's useful. If things are missing, let us know please.
- ~ pj