RTF... TOS

by Douglas Spink  (wrinko@hushmail.com)

This is an article I authored whilst a political prisoner of the United Police States of America, from 2010 through 2012; I submitted it to the good folks at 2600 via colleagues in the Free World, and it ran in the Spring 2012 issue.  It's funny... I read it and I can remember back to sitting in the housing unit, trying to put my mind into "tech mode" and think about the real world - which isn't always easy, in prison.  Anyhow, I think it's got some useful things to say so I've gone ahead and cross-posted here... oh, and sorry about the linebreaks, they're an artifact of the funky submission mechanics I had to use from inside prison; I'll go in and edit them out when there's a bit of extra time available.

For those of us involved in the creation of technology-based projects for social transformation, recent years have seen a profound increase in the tools available in constructing novel systems.  Ten years ago, if we wanted to string together a set of tech tools in order to - let's say - create a secure private network, we'd have needed to purchase a non-trivial amount of hardware, code up substantial amounts of new software, and perhaps even invent from scratch new protocols with which to interconnect all these elements.  That's no longer the case.

Now, we've got a cornucopia of tools, software, hardware, and even fully-developed protocols at our fingertips.  Whilst the latest buzzword to describe such things is "the cloud," in reality what we've got is readily-available toolkit of useful pieces and parts.

With this toolkit, creative technology activists have the ability to bring into existence entirely new classes of projects with dramatically lower startup costs.  Instead of buying all that stuff and flying around the world to install it, we can now gain access to whatever we need via net-based interfaces.  Need a bunch of server capacity spread across multiple geographic jurisdictions?  No problem: just spin up some a few Virtual Private Server (VPS) for a few bucks a month, deploy a decent command & control framework, and you've got your network.  The same goes with payment systems, customer service applications (SaaS-based), storage capacity... you name it.

These are powerful capabilities, and they are now far more widely available than ever before.  That's a good thing, right?

Historically, the startup cost of innovative, socially-engaged projects has always held them back - would WikiLeaks have been possible in the 1990s, when hosting and server capacity was so much more expensive, time-consuming, and limited in scope?  Unlikely.

However, despite the positive impact of such availability, it's imperative that we remember the constraints and limits inherent in the way these resource marketplaces have developed in the real world.  In particular, the Achilles' heel of Terms of Service (TOS) provisions is one that has a profound importance to technology activists, one that is often overlooked.

Sadly, this can create gaps in both the operational effectiveness and the reliability of such projects, a well as substantial security risks.  Again, the high profile example of WikiLeaks is illustrative: repeatedly, the project has been hamstrung by infrastructure components that were unilaterally turned off by service vendors who, after citing their respective TOS, simply offlined their services.  MasterCard, PayPal, NSI, Amazon... even DNS service providers have taken such unilateral actions, and thus forced periodic scrambles by WikiLeaks to locate new resources to replace them.

Often, those new resources have failed to last long... and the process has repeated itself.  The common factor?  TOS.

It is for this reason that we must become much more adept at analyzing - and consistent in reviewing - TOS.  How many folks reading this article have actually done a careful review of the TOS of a net-based resource used in their routine online activities?  Whether we're talking about a hosting provider, a domain name registrar, a Virtual Private Network (VPN) security provider, or a payment processing network... pick any one.

Over the years I've asked folks this question, the answer is generally "No, I don't really read that 'legalese' - it's impenetrable, and besides it really doesn't matter."  Impenetrable it may be (more on that later), but unimportant it's most certainly not!

Essentially, TOS lay out the conditions and constraints under which a provider is offering service in exchange for payment (or, in the case of free providers such as webmail, in exchange for the ability to hammer "users" with advertisements).

The TOS say what the service provider agrees to do, what it doesn't agree to do and - most importantly - what conditions allow it to stop providing the service altogether.

Finally, the TOS usually outline when and how the service provider claims the right to hand over sensitive, private information to third-parties (including cops, lawyers, government spooks, etc.).

Obviously these are important issues, and just because they are buried in small-text notifications - or couched in legalese - in the TOS page that nobody really reads does not make them any less important.  If anything, the fact that they're essentially hidden in plain sight is a surefire clue that there's something in there that most service providers really don't want their customers (whom they label as "users" - a telling distinction) to know.

Let's look at some examples.

A common condition in TOSes for hosting companies is that they reserve the right to cancel the account, without notice, if any "unlawful" materials are stored on their servers.  While that seems fairly straightforward, it's not.

Let's say you are running a project that provides free hosting for controversial websites that have been censored elsewhere online (something I've done for more than 15 years, myself).  That project moves a website onto a leased server, pays three months in advance for hosting, and - suddenly - the server goes offline.  When contacted, the hosting company cites their TOS; the TOS, in turn, have that "unlawful" clause in them, and furthermore state that the company can forfeit the entire prepaid hosting fee if they decide that materials are "unlawful."  The money is down the drain, and the website is offline.

But - you might think - if you just don't host anything "unlawful" this can't happen, right?

Here's the clincher: unlawful where, and by whose decree?

Perhaps you are hosting a website that includes announcements of same-sex marriages performed recently in New York City.  Lawful, or unlawful?  Well, it's certainly unlawful... in Bahrain.  Maybe the websites include details on how to encrypt online communications - that's lawful, right?  Not in Iran, or North Korea.  With a global network, just relying on the word "unlawful" means we've got a lowest common denominator issue.

If it's unlawful anywhere in the world, then - technically - that material is "unlawful" according to many hosting companies' TOS.  They can shut it down, take your money, and point at the TOS for justification.  I've seen this happen many, many times over the years - it's not purely hypothetical.

I've also seen many TOS that refer to "immoral" activities, and I'm sure most readers can see just how unacceptable that will be in actual practice.  Immoral to whom?  To the theocrats in Saudi Arabia or Pakistan?  Immoral to anti-evolution bozos in Kansas?  In fact, I have a rule of thumb about these "morality police" TOS clauses: any piece of information will, inevitably, be considered "immoral" to at least one human being, somewhere in the world.

Thus, a hosting company (or VPN service provider, or domain name registrar, or advertising network, etc.) can cite a "morality police" clause in their TOS to censor or shut down any project, any website, any network they so choose - and usually keep all prepaid fees to boot!

Obviously, these kinds of clauses in a TOS should be a big red flag: avoid at all costs.

Earlier, we acknowledged that most TOS are written in cryptic, hard-to-read legalese.  Why is that?  Is it because there's some legal standard that "requires" such documents to be written in this way?

In fact, no - exactly the opposite.

In Western legal systems, there is a basic standard that courts uphold which prefers "plain language" documents to documents that are completely bogged-down in wherefores, heretos, and aforementioned.

In reality, I've come to conclude after years of reading TOS that companies use this impenetrable language in order to hide unpalatable TOS terms in such a way as to make them hard for people to find before signing up for the service.

If the TOS said that they could turn off service whenever they feel like it, how many people would ever sign up?  Not many, I think.  However, put that same condition in boilerplate legalese, hide it on page 13 of the TOS, and, in practice, nobody will read it.  That's why we see so much needless complexity in the language of TOS - it's also a good reason to avoid needlessly-complex TOS, as you seek out service providers for your own projects.

Finally, and perhaps most importantly for those of us who work on security-intensive projects, we must watch out for elements of the TOS that create enormous risk for the privacy of sensitive information.

A common phrase to see is that a service provider will turn over information "at the request of any law enforcement agency" (or similar words).  What this translates to, in practical terms, is an open-ended ability of anyone with a badge (or just someone pretending to have a badge, via spoofing) to go on an unlimited fishing expedition within otherwise-private information.

While some elements of service infrastructure can be protected by encryption (leased servers can run FDE so the co-location facility couldn't leak private information - even if they want to), other elements don't lend themselves to such protections.  Payment processing is a good example of this risk: if your project takes donations from supporters or participants, that identity information for each supporter is vulnerable to being leaked to unfriendly police goons (or government spooks) if the TOS includes privacy-anathema language.

And, just as with "unlawful" language, such language is hideously vague when it comes to what sorts of "law enforcement agencies" are covered.  Does this just relate to specific countries?  How about spy agencies, or political parties?  Tax-enforcement agencies?  In short, having this kind of language in the TOS - what I refer to as "snitchware' language - puts the security of many projects at risk.

These aren't hypothetical concerns, either - I've seen real-world leaks of highly private information that was retroactively justified by snitchware TOS elements.

This is the bad news: TOS language is often designed to be difficult to ready and understand, and buried inside we routinely find elements that are simply unacceptable in terms of project reliability, economic fairness, and security considerations.  There's some good news to balance out the bad news, however.

Some service providers have set themselves apart specifically by writing and implementing TOS that are free of snitchware, clear about what jurisdictions' laws will be applied, and honest about any other limitations the service has (by writing the TOS in easy-to-read language, not legalese).

When you are looking for providers as you provision future projects, you now know enough to read the TOS and watch for gotcha conditions that are best avoided.  It takes a bit more work than just choosing whoever is cheapest (for example), but it pays off in the long run in increased project reliability, security, and lower overall cost.

How can you know if a company with a good-looking TOS really abides by those terms?  That's actually quite simple: research their reputation and see if they've ever been caught breaking their own TOS.  A solid company, with years of reputation to back them up, will stand proudly by their TOS and, often as not, will emphasize them in their marketing materials.  That's a good sign that they're on the up-and-up.

The other good news is this: in many service infrastructure areas, there are big opportunities for project teams with integrity and good reputations to create services that embody high-quality TOS as a key element of the service itself.

If you can't find a provider that has that kind of TOS for an infrastructure element you need for one of your projects, perhaps that's a sign that there's a market need for exactly such a service.  My experience is that most companies with piss-poor TOS do so because they lack the courage, integrity, or real-world experience to do better than that.

They figure that "everyone else" uses sloppy, unreadable, snitchware TOS... so why not just go along with the crowd?  Well, as we all know, it's the people who are brave enough to ask hard questions - and take brave stances - that often set the tone for where the rest of the crowd eventually goes.

While it might seem boring to pore through the TOS of each component that you include in your next project, the long-term benefits more than make up for the eye-glazing reading times involved.

Plus, you'll probably find that some of the TOS you read are actually entertaining in how utterly unreasonable they actually are: can they really turn off your service and keep your money if they just decide they don't "like" your project?

The more you read over TOS, the more you will come to recognize a bad one when you see it - and they more you'll value those TOS you find that are clearly-worded, honest, and direct.

There's no reason to settle for sloppy TOS that strip your project of rights and protections against mercurial service providers.