Becoming Self-sufficient and IT Resilient in 2017. Part 2: Define required outcomes and Guiding Principles

These posts form part of a series detailing how I intend to try and take back ownership of my digital life in 2017.

Also available in the series:

  1. Preamble and Problem Statement
  2. Define required outcomes and Guiding Principles
  3. Service reliance mapping, risk appetite and "make vs buy" decisions
  4. Architecture
  5. ...

As detailed in Part 1 of the series my primary concerns with continuous encroachment on privacy stems from a fear of over-reliance or eggs in one basket around a single service provider, coupled with a realisation that I don't actually control anymore a huge amount of core infrastructure that supports me online. There is too much in the way of trust required in organisations and entities who may not always share either my moral compass or have my best interests at heart.

As such I dusted off an old, half-finished, manifesto for something I'd pulled together in the past and set about trying to define what I'd be happy with as an outcome - as this expectation will determine where I end up.

Compromises

Before proceeding, some of the key compromises I've determined to make:

  • I will allow data to be stored with a 3rd party in the cloud - I simply don't have the funds or time currently to co-locate my own hardware in a datacentre.
  • I will maintain my current gmail account - probably around 15yrs old now and still useful from time-to-time, including mailing lists. I will, however, ensure that all future important correspondence goes through an alternative provider.

In order to mitigate the risks outlined above I'll ensure that any data being stored on a 3rd party drive is encrypted according to best practice. In addition nothing will be stored on Google Drive such that collusion between competing partied would be required in order to join on that data (even were they to successfully break the encryption).

Guiding Principles

  1. Any changes being made should result in minimal disruption or inefficiency. I'll accept some but, ultimately, I'm not a Supervillain living in a Volcano hideout...
  2. Where it impacts family / friends the WAF must be high. As a relatively standard end user it's a pretty good indication of what's possible with minimal disruption and should form a lowest common denominator.
  3. Assume that all service providers are threats until proven otherwise
  4. Split reliance and key documents across multiple vendors if absolutely needed (e.g. split encrypted files with provider A and B so recombining isn't possible)
  5. Own the hardware and software stack where possible
  6. Have fun learning!

Number 5 is quite important - as Alec points out in his comment response to the reported WhatsApp backdoor in their End-to-End encryption (E2E).

Because there are way better ways to drill holes in E2E than this, when in fact you own the codebase.

Software and vendor selection
  1. Web / mobile-first design: This is the world we live in of Smartphones, iPads and multiple operating systems. Anything designed should work in a browser out-of-the-box, without any external plugin requirements.
  2. OpenSource components: The world and the web run on OpenSource. This does not need to imply free but ensures that code base is easily reviewable, expandable and will integrate with other systems. Licence costs and setup minimal, only pay for work performed or desired support model. Never again will applications go "out of support".
  3. Flexible without pre-supposing design: Too often vendors sell you their version of your business which, amazingly, exactly corresponds to their product… We should be able to adjust and extend a componentised core system to fit our needs, without needing to break underlying application logic. The same principle goes for data storage - schemes should be flexible where we decide they are even necessary (Document storage models).
  4. Don't be afraid of new things: Change is usually good when it comes to technology.
  5. Avoid "Not Invented Here (NIH)" Syndrome: If something is proven to work elsewhere and is tried and tested resist the urge to re-invent the wheel because my needs are special. Chances are they're not and we are just exposing poor processes if they don't fit into standard patterns.
  6. Monolithic applications were never the answer: Trying to do everything within one application rarely works in practice and, instead, you end up with a monolithic system that does lots of things averagely and users resort to external dedicated applications that then don't integrate. In addition, the size and complexity of the application results in development cycles measured in months, huge dependencies in sub-modules that should really be de-coupled and a lack of flexibility - what you set out in the first place to fix. Instead, adopt a UNIX approach of doing single things very well and, via open APIs and an extendable architecture/framework, link best in class applications together to solve capability gaps.

Outcomes

At the end of the process I want to ensure that I both understand the privacy implication of the key services I identify but also then actively choose which ones I self-host and take off-grid.

No one service provider (or government agency) should have a complete picture of my life without resorting to collaboration both between public/private but also across borders. If I'm such a threat, then prove it to other jurisdictions (as I can't trust you to make that decision yourselves).

James Veitch

Read more posts by this author.