Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! ΞΞ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

"Privacy seppuku" is the decision by privacy-oriented projects to voluntarily shut down, rather than be coerced into collaboration with the surveillance regime and concomitant betrayal of customer trust. The 'seppuku pledge' is a public pre-commitment to the principles of privacy seppuku, This is a place to review & discuss...

tl;dr version: we're making some major changes to our billing procedures, we're entirely cutting connection with the com/net/org TLDs, and we're adjusting team member disclosures - all designed to harden the company further against emerging threat vectors, and thereby protect customer privacy from all known and foreseeable threats. This isn't Privacy Seppuku, but certain low-probability scenarios might lead to a full wipe of our network & clean restart, if that's what's required to ensure customer protection. Prospective customers: please do not sign up with Cryptocloud until these changes are complete - once they're done, we'll give the green-light (both here and via twitter) that things are tested & ready for production use!

[align=center]~ ~ ~[/align]Providing network security service that can stand up against the kind of heavy surveillance pressure we now all know threatens the global internet is not for the faint of heart. There's certainly easier ways to make money in the technology world (for those so motivated), and the omnipresent threat of extra-legal harassment against those individuals providing & teaching core OpSec fundamentals cannot be ignored. Very few teams have the technical experience, practical competence, personal durability, and stubborn dedication to customer protection that are all required to successfully manage serious privacy services.

Cryptocloud has always been one of those teams, since we came together in 2007. We're taking steps now to ensure that we remain at the forefront of best practices in the future. Some of those steps we are announcing today - mostly procedural and staffing related - and others will be coming out publicly in short order. Some will be easy and smooth to implement; a couple are going to be a bit rough. We'll do our best to mitigate these difficulties, and to ensure the end result is a stronger, tighter, more durable service for all of our customers.

Throughout Cryptocloud's history, we've not hesitated to stand up to arbitrary power, on behalf of our customers and our loyalty to them. Our feeling as a team is that, in recent weeks, we've reached a level of visibility different from previous years. This doesn't come from any specific warnings; we've not received any FISA court demands and we don't have anything we're being gagged from discussing. However, as Silent Circle said in recent moves they've made, we're proactively modelling the evolving threat landscape and taking steps to avoid risks to our customers' security before they manifest realtime. Have there been some rumblings? Yes. We have a sense - call it a gut feeling, if you will - that pressure brought to bear via financial transaction processing infrastructure is going to be a serious issue in the near future, for many network privacy providers. We are acting to ensure our customers are as heavily protected against that as possible, whether they pay with credit cards, PayPal, cash, or cryptocurrency. We prefer not to provide more detail than that, to protect certain non-public sources of advance information.

Cryptocloud is not based in the United States. We do lease servers in the US, but they do not contain our customer data. Of course, we don't keep logs so those records are stored nowhere. However, certain payment gateway technology that forms part of our merchant processing interconnection, currently, has ties to the U.S. - and presents a tempting attack surface for a well-funded, well-resourced, highly motivated opponent (read: NSA). This weak link must be strengthened; see below for our decision on how to do so.

Today, we make three specific announcements:

First, we're cutting all connection with the top-level-domains (TLDs) in the com/net/or registries. This has been hotly debated amoungst our team; words have been said that are hard to take back. This is a big issue for us. Originally, our company was located at cryptocloud.net. Later, it was shifted to cryptocloud.com in order to make Google happy. And, of course, presently cryptocloud.org is the main pointer to our discussion forum.

This is all changing, effective Friday this week (16 August).

Our main home for web visitors will henceforth be cryptocloud.ca. Why Canada? No TLD - and no registry - is perfect. However, we feel that the CIRA is run fairly, transparently, and with a strong commitment to free expression. The .ca TLD has a strong, proven track record when it comes to protection against hijacking and/or seizure by shady entities associated with the U.S. government - not perfect, but there is no perfect TLD currently. CIRA is also stable, well-run, reliable, and supported comprehensively worldwide.

The domain name cryptocloud.ca is already active and currently redirects to cryptocloud.com; on Friday, that will reverse and cryptocloud.ca will be the main TLD with the others redirected onto it. Shortly thereafter, we will redirect cryptocloud.com & cryptocloud.net to pages explaining our decision to discontinue use of these TLDs: U.S. governmental meddling in domains contained within these TLDs has reached a threshold where any content hosted on them cannot be trusted to be authentic. Simply put, it's far too easy for rogue state entities to gain control of these TLDs and point them at replicated sites masquerading as genuine - think of this as the ultimate form of man-in-the-middle attack, or DNS poisoning: visitors think they're getting the "real" Cryptocloud website, but instead it's an imposter. This is the threat vector we seek to protect against

This forum, currently housed at cryptocloud.org, will migrate to a new domain name outside the "poisoned three" of com/net/org. Architecturally, the forum and its underlying infrastructure are all housed in Iceland; it's only the domain name that is at risk of meddling. That would translate simply into a denial of service (DoS) attack, or a redirect of the domain to some other underlying server. Rather than have that open risk hanging out there, we have decided to migrate to a new TLD - and a new domain name - for this forum. That will be announced, here and in our twitter feed, before the end of the day Friday. We hope to have a transitional period, in which cryptocloud.org continues to direct here. That may not be the case, in the event an attack materializes faster than models suggest is likely.

[align=center]~[/align]Second, we're engaging in an immediate and radical overhaul of our payment processing backend. Right now, it relies on WHMCS as an interface between our web presentation and the underlying merchant processing networks. It does the job... but it's far from perfect. It's had security issues in the past - which we cannot control, as we don't have de-obfuscated source code with which to test and improve security. It's also clunky and often frustrates our customers with needless complexity.

There are also some deeper issues here, which we are ethnically obligated to avoid discussing in detail - for now. Certain disclosures by Snowden have brought to the surface the risks that non-open code introduce when state-level attackers are involved. The only genuine protection against this class of risks is a complete removal of closed code from infrastructure environments, period. We offer our thanks to certain well-informed, discrete colleagues out there who were kind enough to give us a hint that did wonders in motivating our prioritization of these concerns; we hope to offer those thanks, publicly, someday in the future.

This process of aggressive migration away from our entire current billing framework is likely to be rocky. We won't sugarcoat that. The benefit - dramatically improved systemic security for all customers - is worth the difficulty and risk. That is the conclusion of the Cryptocloud team. We will do our best to minimize the transition drama. We cannot promise it will be nontrivial, however. In part, that's because we are moving fast and moving immediately - based on what we know, this is the best decision, by far, for our customer security. Perhaps in the future we'll be at liberty to disclose why this was necessary, or perhaps it'll end up being disclosed elsewhere in due course. Irrespective, we must act on what we know and in the interests of our customers... even if it is inconvenient for you, and for us... as well as being substantially less than elegant.

[align=center]~[/align]Third, we are formally adjusting the manner in which we engage in public outreach with the media and other community resources. This, too, has been a subject of intense debate within our team for quite some time. When we are contacted by folks in the media - be they journalists, bloggers, or anything else in the mix - we've not had a standard policy as to who replies. We don't have dedicated "public relations" staff at Cryptocloud, and we never have. Hell, we don't even have dedicated marketing staff here... and we never have! We're a network security company, and that's where we focus our hiring, staffing, investment, attention, and research.

As media inquiries arrive, they more or less get handled by the staffer who seems best qualified - or who isn't elbows-deep in code at the moment. That's fine, but it doesn't scale - as we get more inquiries, things get disorganized on our end. That's not ideal. You've already seen a test-run of our answer to this conundrum, here in the forum: rather than specific staffers posting news or updates, you see them come from "Cryptocloud Team" - just like this post does. That test run has worked well, so far, and we're expanding it.

Additionally, we're acutely aware of the risk of harassment posed by personally identifying specific staffers here at Cryptocloud. We engage with privacy questions at the highest levels, and as such we to find ourselves at odds with some pretty powerful folks (read: NSA, etc.); that's not to say we feel they are our "enemies" - we don't. But, the temptation to lash out at us - bash the middleman, when the end-target isn't publicly visible - is always there. We understand that, and our colleagues at Baneki are somewhat specialists in that subject area. One thing they've learned - and shared with us - is the benefit of "lowering the attack surface" on individuals involved in serious security projects. We've taken those lessons to heart.

What we'll be doing is posting information about current, past, and emeritus team members... in aggregate. Some folks publicly associated with the company in the past may well make comments regarding relevant topics, here or elsewhere, and given their well-earned team status, we stand behind those statements. That said, henceforth we won't be identifying by name current staffers, period. Indeed, we might just push out bits of disinformation to keep recreational d0xers busy with interesting threads for investigation. If asked whether a particular person has, at some point, been part of our team, we'll answer with a clear yes/no... but that's it. If they, personally, decide to disclose more than that it's entirely up to them - we'll neither confirm, nor deny, any such statements they make.

Our internal team structure is quite fluid, non-hierarchical, and more mesh-based than pyramid-based: it's a holarchy, not a hierarchy. So, "titles" end up being rather silly and don't reflect workflow or responsibility clusters very well anyhow. As we staff up to support dramatic increases in customers and network usage, we're loathe to get sucked into conventional, formal, rigid models of "corporate" structure (even though some of our team members are deeply schooled in such models, both academically and via prior professional experience). Instead, we're going to retain our "pack" model of team cohesion: loyalty, integrity, and respect are the core of who we are, and how we operate.

In sum, you won't see anyone identifying themselves as "President" or "Managing Director" or "Jefe" of Cryptocloud, in the future. Such identifications are neither congruent with our social model internally, nor helpful in protecting against targeted attacks from outside. Instead, we're all "Cryptocloud Team," through and through.

Some parts of these changes aren't going to be easy, and probably won't be smooth either. We're rushing them into production for reasons that, albeit not disclosed publicly in detail here, are supremely relevant. They are the decisions we conclude will best protect our customers, maximize the durability of Cryptocloud as a project and as a particular approach to no-compromise network security, and avoid potential "insider threats" against our team-level dedication to customer loyalty (this last one: read closely, as it matters, alot - far more than it's discussed in the "VPN industry" currently... consider it a #protip).

We're going forward with them, and we're going forward with them now. Indeed, these changes are already in the works. By the end of the day Friday, they'll be far more visible on the public side of things. Our hope is that's a fairly smooth process. If it's not, you have our word we'll get through the rough parts as quick as we can. However, we will cut no corners in ensuring protection, throughout. That's beyond negotiation, for us.

This is not Privacy Seppuku. Not exactly, or not yet... call it Privacy Seppuku lite: the diet Coke of Privacy Seppuku, etc. Let us explain a bit, as best we can.

We aren't wiping our machines - nor our customer database. However, the three steps we outline above are similar in motivation to 'conventional' #privacyseppuku - that being to remove obvious weak links in our organizational model, and thus prevent otherwise-probable attacks from being attempted in the first place.

Further, let us be blunt: if these transforms don't move through implementation smoothly, there is a nonzero chance we will in fact commit formal Privacy Seppuku as an organization. In that case, we'll delete all databases of customer payment, service, and contact information - permanently and fully. We'll re-instantiate the project in a new company, on new hardware, with the most current jurisdictional insulation against all model-congruent possible future political/economic attacks. All folks who were previous customers will be provided ample "trial period" subscriptions in any such new project. You have our word on that.

To some degree, our goal here is to "cycle" the existing Cryptocloud organisation - in the formal sense of the word - and start tabula rasa with something that embodies every gram of current best-practice when it comes to hardening organizational entities against state-level aggressors. This isn't a bug; it's a feature. "Severing the cord" between the past and the future has deep structural benefits, from a security perspective. We leave it to the curious reader to work out those benefits, in detail, based on the game theoretic elements of the current threat landscape. This isn't a surface level transform; in fact, it's exactly the reverse. Deep down, the structure is doing a massive overhaul - and we're doing our best to minimise the surface impact.

To conclude, our colleagues at Baneki Privacy Labs have written recently on the logical underpinnings of the Privacy Seppuku Pledge, and how it relates to organizational existence versus project existence. We quote:

Because, we forget: a company is just people (and not the Soylent Green kind). These teams, they're (mostly) small. Facebook is a behemoth, but let's not kid ourselves: we won't see Facebook on this list. Most of our teams are a handful of folks - people, with names and email address and twitter handles and stuff. When we "shut down" a company, we're still alive! This isn't real seppuku, the kind where you eviscerate yourself (read: slit your stomach with a sharp sword, cut your abdominal muscles, and watch your intestines fall out and splatter across the floor in front of you). These are just damned companies: pieces of paper, words. It's not even the code: the code can go where it wants, particularly if it's opensourced.

This project - this team - is not only surviving, but it's thriving. If you want to trot out a metaphor that stretches things - but not too far - then think of it this way: the old skin (cryptocloud.com/net) is being shed, as it's been outgrown... and the world around us has evolved to require a different kind of camouflage. We're choosing to do that now, and to do it aggressively, so there's no interim period where we're needlessly vulnerable. It might not be pretty, this process, but it's better to dive in and get it done - done right, done now - than to prevaricate, hesitate, procrastinate, or just plain fuck around.

We have taken our seven breaths. Now, we take action - which, in the end, speaks far louder than words ever can.

My question is of a practical nature. I currently pay you guys by automatic direct debit every year. Should I cancel that so I can pay again when the new system is up and running or? (I'm not due again until May I think next year...)

Sharp-eyed visitors will perhaps notice things are upgrading around here are a rather jaunty clip this weekend. We noted, a few days back, that yesterday would bring some big changes.

The big changes, they are 'a-comin.

Back in the old days - five years ago - there were clouds on the horizon. Online privacy was no longer an assumption, a given... and it was time to bring some real tech to bear on the challenge.

Today, those quaint days of cloudy concerns recede in the rearview mirror of future-shocked, post-Snowden realities: cyberwar is happening, and the targets are us. The most paranoid amoungst us, when researching NSA perfidy, didn't even come close to predicting how bad it really was. The wizard behind the curtain? Holy fuck - he's a monster.

It's not a time for cloudy good-cheer and outdated OpSec. We're living in the perfect storm of threats against privacy. If you want to survive the storm, you'd best be prepared for the storm... not for mere clouds.

The cryptostorm darknet is today's answer to today's privacy threats. Everything else is history.

We'll be publishing additional information today regarding the big transition currently taking place, but in the meantime if you're a cryptocloud.com customer and <insert whatever issue you're currently facing>, here's what we can do to help:

2. fall back on any of the comms channels listed in this old forum thread - they're all still functional, and will get you in touch with an actual, living, breathing, competent network security professional

3. DM us here.

Here's what we suggest you not do, during this migration period:

i. email to support<at>cryptocloud.com - there is nobody responding to that address currently, so don't have high expectations for a response

ii. try to open a ticket in the old cryptocloud "helpdesk" - it's been decommissioned and, if you're somehow able to get it to accept a submission, it'll just use your bits to make pretty patterns in its erasable memory, or whatever...

There's a method to this madness, so hang tight - and let us know what's up, via the options listed above. We'll be publishing more details on the cryptocloud 2.0 / cryptostorm migration shortly.

I managed to get my account paid for and activated before your team posted a forum thread about "not registering before the new changes take effect". I am getting an "Authentication Failed" message when trying to log in. Does that mean my account is busted or the changes are still rolling in?

marzametal wrote:I managed to get my account paid for and activated before your team posted a forum thread about "not registering before the new changes take effect". I am getting an "Authentication Failed" message when trying to log in. Does that mean my account is busted or the changes are still rolling in?

Yah, despite our best efforts, there was just no way to get to everyone during the migration & let them know to hold off on new signups until the new platform was ready. We do apologize for that - we really worked the issue around, as a team, looking for a uniform solution... but nothing was perfect.

In the end, we chose to focus the lion's share of our effort on the migration and trusted that, with that complete, we'd be able to loop back & clean up the snarls created during the process for the interim customers. So, without furher ado...

Yes the account for which you signed up at cryptocloud.com is essentially busted. We've been able to jigger a few folks onto the old network (don't ask) but it's getting harder and it's not good security policy given the whole backstory of the migration to cryptostorm. If you can still use the account - and if you understand the limitations on security implicit in doing so - then we're certainly not insisting people stop using it. However, it seems like most/all new signups simply can't auth anyhow. That's the bad news - and it's not all bad news...

Buuuut... all prior cryptocloud.com customers are having their subscriptions honoured by cryptostorm. Details are at: http://evolve.cryptostorm.org. Further, all former cryptocloud.com customers receive first cut access to invites on the new darknet - nobody else gets onto it until everyone from the old world has the option to take a slot if they so desire it (with their position in the prior network being honoured in the process, of course).

If this seems a bit, well, Rube Goldberg-esque (why not just migrate over the customer database?) and it seems like we're somehow talking around something without directly addressing it... yep. Can we get into more detail than what we've provided in the launch press release and elsewhere here? Nope. Not currently.

We do understand this is not anywhere near as convenient as a simple database migration, for our customers. This is crystal clear to us - it's equally inconvenient for us, as a team, to do things this way. Given that, one might infer that there's a damned good reason for us to do things this way. Indeed there is.

We're already in process of issuing invites for former cryptocloud.com customers - it's going to take some time to work through everyone, but we've put in place a process to make it as smooth as we are able.

Any other assistance we can provide, in the meantime, please don't hesitate to let us know!

When I log in on cryptocloud.com, where can I update my credit card information? My expiry date has run out and I've got a new one.I've sent 3 e-mails to support... but no reply except the confirmation

dave1984 wrote:When I log in on cryptocloud.com, where can I update my credit card information? My expiry date has run out and I've got a new one.I've sent 3 e-mails to support... but no reply except the confirmation

The situation with the former Cryptocloud network is sort of complex, to be honest.

Basically, it's in process of being shut down. Customers are migrating over to the new network here at cryptostorm. There's considerably more details in this forum thread and in the next week or so we'll be posting some additional backstory.

As soon as you can, we recommend you migrate. That's up to you, obviously, but from a security standpoint we no longer stand behind the old system... which is why we've created cryptostorm from the ground-up to protect against the full suite of post-Snowden threats known to exist.