Peter Nixey

Rails/Angular developer, Entrepreneur & YC alum. Previously built and sold Now O(only)TO at and part time partner at Entrepreneur First.

Apple’s fingerprint sensor may be the biggest leap forward in payments since the Amazon Account

During today’s keynote, Tim Cook mentioned, almost in passing, that you could log into the iTunes store using the fingerprint sensor.

This statement may turn out to have way more significance than its low-key delivery would suggest. It took me a moment to realise it but the fingerprint sensor is almost certainly not about securing your device. The fingerprint sensor is about securing your account. The fingerprint sensor is about payments, initially to Apple and then maybe subsequently elsewhere. The fingerprint sensor may be Apple’s mobile answer to Amazon’s web-bound One-Click.

For every app, music and in-app purchase made through an iOS device there is at least one other that wasn’t made because someone couldn’t be bothered to type in their password, got it wrong or just didn’t know it. Amazon once measured a discernible difference in checkout rates from page loading increases of only 1/100th of a second. Apple has to request a password. That password has to secure the phone against chargebacks due to theft, purchases made by small children or just a trouble-making friend pinching your phone and playing with it. The only answer to those chargebacks today is to demand users to continually re-enter their passwords.

Perhaps even more problematic for Apple is the proportion of their customer base who don’t even know their passwords. A significant proportion of iOS users won’t be able to tell you their password and may not even have a credit card associated with it. Apple must have swathes of older, tech-challenged or simply disinterested customers who never buy any video, music or apps. Those customers are lost revenue for the iTunes store in the short term and are far more vulnerable to churning over to Android in the long term.

Because it’s not the just the revenue from apps that passwords cost Apple. Apps are what make the platform useful, apps are what tie you to your OS and many of the best ones need to be purchased. If you don’t buy apps the platform is significantly less useful to you, you’re far less loyal and you’re far more likely to be swayed by Android. Apps are Apple’s platform lock-in.

I’m guessing that this new scanner won’t just be a piece of hardware Apple ships and forgets about. I’m guessing that Apple will integrate their efforts around the fingerprint and will encourage you to setup your fingerprint and enter your credit card in the Apple store when you buy a new device. I would. They will do everything they can to encourage you to associate your fingerprint with your credit card and free you to one-scan purchase. I’m also guessing that despite its more homebound nature we’ll see that fingerprint sensor very quickly on the iPad too. The iPad is a perfect shopping tool and one-scan shopping would make that even more true.

The fingerprint sensor is way too much technology just to make it easier for you to get past your lock screen. As Tim Cook said, many people don’t even setup a PIN. I think the fingerprint sensor promises to be a far more strategic tool than simply a souped-up login. What the fingerprint sensor may actually deliver is the biggest improvement in frictionless payments since the Amazon account.

Apple has to make big bets to move the dial now and payments is one of those that many people have spoken about. Many people were waiting for Apple to announce NFC and jump into the payments space but I think they may be even cleverer than that. Payments would be a huge new revenue stream for them but easy authentication and chargeback avoidance must have been a large barrier to offering that. If the fingerprint recognition works a well as advertised, that barrier may just have fallen away.

Comments on Hacker News >

Things I’ve Learned About How to Build Good Product

These are the slides from the talk Taavet Hinkrikus and I gave yesterday at the O2 for Campus week and Wayra.

The talk is about how to build good quality product quickly in highly uncertain situations. It’s about building product in a pre-product-market-fit startup and I like to think that there’s something for everyone (over the age of 29) in there.

If you, like me, lament the fact that Craig David and XKCD sex scenes have have never before met in a presentation about product then you’re going to LOVE slides #90-99 (also I hope you at least remember Craig David unlike most of the blank-faced audience I was talking to).

If you’re wondering what the relevance of the Ariel Atom and a kitted-up Peugeot 206 (#106-110) is it’s this. One looks like a piece of scaffolding that fell on a go-cart but goes like s**t of a shovel while the other looks, well… crap but it’s owner clearly spend a lot of time on “design” while paying no attention to the fact that there’s not a lot of point in it as a car. This is a metaphor.

Enjoy, debate and if you chose to upvote this at Hacker News, well then let me tip my hat to you as you’re a gent sir (or mademoiselle). Gracias.

Comments on Hacker News >

How to build product campus week from Peter Nixey

Using Sidekiq and OpenRedis on Heroku

I recently switched from using DelayedJob to Sidekiq for processing my background tasks. Sidekiq’s super-powerful for jobs that have a lot of latency (like external API calls) since it parallelises them in threads and runs 25 (by default) at a time. This can literally divide the number of boxes you need to run things by ten.

However it took me a little while to debug some stuff in order to get it running well on Heroku. I hadn’t been using Redis before and so I had a few moving parts to sort out. I kept getting the error:

sidekiq Redis::CannotConnectError (Error connecting to Redis on localhost)

The problem was that I hadn’t told Sidekiq how to connect to Redis. In case you’re having the same issue, this is how I fixed things.

1. Setup a Sidekiq initializer file

As per you should add a Sidekiq initializer file which will look something like this:


# /config/initializers/sidekiq.rb

redis_url = Rails.env.development? ? ‘redis://localhost:6379/0’ : ENV[‘REDIS_PROVIDER’]

Sidekiq.configure_server do |config|
config.redis = { :url => redis_url, :namespace => ‘twistilled’ }

Sidekiq.configure_client do |config|
config.redis = { :url => redis_url, :namespace => ‘twistilled’ }

NB I haven’t figured out and can’t bring myself to figure out how to format code correctly in tumblr so if you copy and paste my ocde you’ll need to make sure that single-quotes and double quotes come through with the correct characters on your machine.

2. Add your OpenRedis URL to Heroku as an env variable:

heroku config:set REDIS_PROVIDER=your_redis_url_from_open_redis

3. Check things are working via the Sidekiq console

You can monitor the status of the system by mounting the very pretty Sidekiq console in your routes file (NB you should password protect this):

# routes.rb
require ‘sidekiq/web’
mount Sidekiq::Web, at: ‘/sidekiq’
view this from


This may not all be necessary. See this conversation on Twitter with Mike Perham. Unfortunately (possibly due to something I set incorrectly) I couldn’t get this technique to work but you may do:

Our very real liability as Twitter app developers

Last week Carl Icahn sent out a tweet that raised the market cap of Apple by $17Bn. Carl was under no illusions as to the significance of his disclosure, and filed with the SEC before doing so to state that he may use Twitter to release information he considered to be material.

The ability of high-profile Twitter accounts to move markets is now very real and doing so nefariously is not unprecedented. In April of this year crackers got hold of the Associated Press Twitter account and wiped an estimated $135Bn off the S&P 500 Index by tweeting that explosions at the White House had injured president Obama.

Being implicated in such events this has huge consequences. A friend’s company recently suffered a data leak and afterwards he told me that it was one of the worst weeks of his life with an office full of lawyers and FBI agents. He said “I hope you never have to go through this”. That happened as a result of leaking their own (encrypted) passwords. If you were a developer implicated in the compromise of a high-profile Twitter account which broadcast market-moving material then I can only assume things would be many times worse. Such an eventuality may be closer at hand than you imagine.

If you ask for write-permission for Twitter accounts then you have access to those accounts. And if someone gets access to your server or database then they may do too.

In order to get hold of your users’ accounts a cracker needs four things:
- your users’ oauth tokens and secrets
- your application’s consumer token and secret.

The first two aren’t of any use on their own as any API call still needs your application’s consumer token and secret. If, however, the hacker has access to your users’ tokens and your consumer tokens then they’ve got the keys to the kingdom.

You should be absolutely 100% certain that the four of these things are never available to a cracker. The most significant and protectable of these is your application’s consumer secret, however you should also think carefully about how and where someone might get hold of the other three. Best practices for protecting these will vary depending which platform you’re on.

We’re going to see a rise in Twitter attacks over the coming years. It’s now such an influential news source that getting into users’ accounts is only going to become more attractive. The prospect of honeypot apps or developers paid by financiers to move markets becomes ever more likely. Finance aside, the power of Twitter to incite civil action or even violence is very real and would undoubtedly have huge implications for a developer who inadvertently enabled such activity.

As developers we should think carefully about the liability we take on when we request write-permissions for an account on Twitter.

However I think that Twitter also has a responsibility to educate and protect its users more than it currently does. Users with large followings should be warned about the ways their account can be mis-used by connected apps. They should also be encouraged to switch their account to a “secure” mode where it can only connect to apps which have been whitelisted or even perhaps a super-secure mode which would disallow app-connections altogether. Most people have very little idea of the implications of connecting to a Twitter application. Even if did though and they they knew they could trust it, they can’t possibly anticipate how securely the application’s been coded.

Over time we will undoubtedly see more clarity in the law and in how liability will be allocated across such a chain of events. Unfortunately it’s going to be a precedential case and a scapegoat developer which will forge this. When this does happen we will discover how much responsibility will fall at the app-developer’s doorstep for not properly securing themselves and at Twitter’s for not properly informing their users of the risks.

As more and more influential people join Twitter, such attacks will inevitably become more frequent. In the meantime, as application developers, we should be careful with what liability we chose to take on and how we protect ourselves and our users from it.

Comments on Hacker News

"Instead of cures for cancer we got Angry Birds"

“The Valley’s brightest minds once invented things of immense significance like the first PC. But then came the internet and the pursuit of big ideas was eclipsed by a scramble for quick profits. The money pumped into hard technological problems plunged while interest in iPhone apps soared. The result? Instead of cures for cancer we got Angry Birds”.

So concluded a recent article in the Sunday Times. “Does it really matter”, “you could working things that could save lives, why worry about dry cleaning?”. Casual observers love to glance through the office windows of entrepreneurs and wonder “if there’s so much money to be made in entrepreneurship, why don’t these folks do something that really matters”.

I can perhaps understand where they’re coming from. One of my brightest friends is looking to start a new idea in advertising or property. I know that he’ll do very well in whatever he choses but it makes my heart sink to think of his talents being used to optimise advertising. I don’t expect him to stop the spread of malaria but he’s a source of creative energy in the world and it would be nice to see him use it for something that I might at least use.

Asking him or any other entrepreneur why they solved one problem and not another is like asking a river why it doesn’t splash out and irrigate the fields above it. “Since you’ve got so much water, why not wet my crops rather than just deepening the plunge pool under the waterfall?”. The question is moot. Water flows downhill: down a potential gradient. Like water, entrepreneurship also follows a potential gradient. Water depends on a height gradient, entrepreneurship on a value gradient. The greater the gradient, the faster they move and asking why things might be different is as pointless as arguing with water.

Entrepreneurs follow those gradients for good reasons too. While the Sunday Times may photograph Brian Chesky hanging out in AirBnB-central they don’t photograph the entrepreneur who had to give up his company and leave penniless to look after his dying sister’s family. They don’t photograph the hundreds of young hackers holed up for years in Palo Alto with nothing to show for it. They don’t photograph the founders who watched their company fall apart as they stood locked in a legal Mexican standoff. If they did their question might change from “why do you not cure cancer” to: “why do you do this stuff at all?”. Entrepreneurs follow potential gradients because their business is a risky business.

I think the “does it really matter” philosophy comes from two misapprehensions. The first is the assumption that markets are fungible and the second is a lack of ability to distinguish small probabilities.

When you assume markets are fungible - that one can be tackled as easily as the next - you inevitably ask whether “disrupting the dry-cleaning market” really matters when the alternative is “feeding Africa”. These aren’t adjacent problems though, they’re literally and figuratively continents apart. There are already entrepreneurs tackling both problems but they are entrepreneurs with very different knowledge sets. Getting frustrated with software entrepreneurs failing to feed Africa is like getting cross with Norman Borlaug for not doing a dwarf wheat iPhone app. These are different entrepreneurs with different skills and different available markets.

When you have no way to distinguish small probabilities then all long-shots look the same. Two “seemingly impossible” ideas may still be magnitudes apart in probability. As incredibly small as it is, the chance of successfully building a new car manufacturer is still millions of times higher than that of curing cancer. To the average person both ideas may seem vanishingly small but good entrepreneurs work with a microscope. They can magnify their field up so large that they know every nook of it. What looked like two small specks to the untrained eye looks completely different to the entrepreneur. They see one as a cell with all of its mitochondrial energy-producing goodness while the other, a million times smaller still, remains as mysterious as it was without the microscope.

Finally, it’s worth pointing out that entrepreneurship isn’t a salaried job-rotation or an credit-option on an MBA. You don’t chose the option you fancy most and then roll on to a different one three months later. Being an entrepreneur is a nail-biting, ration-sapping, wind-bitten, many-year, unsupported journey into the unknown. Asking an entrepreneur why they took one route and not another is like tweeting to a climber on K2 to ask them why they didn’t take the harder route. Ask away but if you think it should be climbed then you should buckle up and climb it.

Comments on HN

Five techniques that measurably improved our customer development

When we first started building Copyin we had a problem. We found it incredibly useful but our early users felt differently. We loved that it created a knowledgebase out of our email. The problem was that we couldn’t communicate that benefit to our customers. People were receptive to the problem but (at that stage) not the product.

So we found ourselves in a quandary. We had a product which was valuable to us but not to the people we’d so far shown it to. So did we have a product or a market problem? We didn’t have enough data to know. After all, it wasn’t like we were the only product in our space those people didn’t use - almost none of them used Salesforce or Yammer and they were both successful nonetheless. Was our sample size too small or our product off-mark?

In order to answer this we needed to speak to more people. We knew we could get them from a public launch but we didn’t yet know who we were launching to. We felt it would be a waste to launch while still so far off product-market fit. However we still needed to speak to more people and to different people and we needed to do so quickly.

1. We created an inbound customer development pipeline using our blogs

The first thing we needed was more people. For that we turned to our blogs. Both Rob and I had already had a fair amount of success blogging so we decided to experiment with recruiting people directly from blog posts. We built a small signup form, cached it to withstand traffic and embedded it in the bottom of each post.

This is the form:

(Please do sign up - it won’t take you off the page :)

To our delight, the form worked. About 1% of people who saw it signed up and we immediately increased both the reach and diversity of people we were interviewing. We had enquiries from everyone from CTOs of publicly listed technology companies to administrators of NBA teams and mountain rescue societies. We did all of this without even altering what we blogged about. If we’d written about Copyin or its problem space specifically I’m sure we’d have converted even higher.

2. We immediately followed up on new registrations to arrange interviews

Our goal was to get interviews not signups so once people had signed up we immediately sent them an email thanking them for their registration and inviting them to speak to us.

At first we worded this invitation email in a very softly, softly, manner:

Hi, it’s Peter from Copyin. If you have a moment we’d love to chat to you. We can speak to you when it’s convenient, please do get in touch.

Nobody responded to these though so we changed the text to be much more exclusive with limited availability:

We’re prioritising customers with real pains in this area. If this is you then please get in touch and we’ll book you in as soon as we get an opening. If it’s not then please accept our apologies but we’ll get to you when we can

The latter converted very effectively and about 10% of registrations emailed us back to tell us more about their particular needs. Almost everyone who emailed us was happy to do a phone conversation and we’d spend anywhere from ten minutes to an hour speaking to them about how they were currently solving the problems that Copyin addressed.

3. We stopped pitching and started listening

When we first started customer development we made a massive mistake. Instead of listening to a customer’s problems we would instead pitch them our solution What we should have been doing was asking people what their issues were and listening to how we might solve them. What we actually did was wax lyrical about the product and debate with them on whether it really could solve their problems (at the time it couldn’t).

Customer development is a very different process to sales though. Sales is about helping your customer to understand the product. Customer development is about helping the product to understand your customer. Don’t try and sell during the initial exploration.

4. We made sure that the whole team was a part of it

After each interview we’d sent both the transcript and the summary to the the rest of the team using Copyin. Disseminating the research is tremendously important. The temptation as CEO is to yank the product tiller after each and every interview. This leaves the team feeling bewildered as to why the thing they were working so hard on is now so unimportant. Their natural reaction is to stop caring so much in case what they’re passionately working on suddenly gets binned.

Obsessively sharing customer research has three huge benefits. The first is that when you do need to move the tiller everyone already understands why. The second is that it encourages you to discuss product as a team and gives everyone a vested interest. The last one is that you have a written record of what actually happened.

If you don’t give the team access to customers it’s easy to dismiss their opinions as being uninformed. This can cause decisions to be over-volatile and is bad for morale. If they do have the data then they can not only offer valuable opinion but also become a powerful protection against CEO tiller-yanking and over-correction.

5. We used our embedded signup form to test new hypotheses

As you do your customer development you will start to form new hypotheses about what the customers actually want and what their problems actually are. It’s incredibly useful to test these and to see whether they’re correct or just a result of your last interview.

We were able to do this by incorporating three very simple benefits from Copyin back into the original enquiry form and cycled through various features that tested our hypotheses:

- turbo charged mailing lists to better connect your team
- Search-assist to make sure you never answer the same question twice
- Tag, file and edit the email threads actually worth keeping


- Connect to the expertise in your team
- Capture your team’s knowledge
- Know what’s happening

By seeing which phrases people responded to we began to see which things they cared about (and which ones they were prepared to pay for). These phrases also helped drive what they put in the last (most helpful) box which asked them what they would use Copyin for:

We got a variety of answers to this. Early on they were vague and sent by people who (upon interviewing) often turned out to have no budget. Over time and as we improved our positioning we were able to select better and better for people with real budget and more tangible problems.

What people answered to “What would you use Copyin for?”

We’ve got a vastly growing team, with a huge email load. Streamlining this process would be amazing.

Need to track conversations multiple people are having on multiple topics over multiple channels

Populating Knowledge base with relevant content about processes and services.

More Cow Bell


The data was statistically insignificant but it was nonetheless very helpful in understanding which terms appealed to which people (and to which budgets).


It’s very easy for customer development to fall by the wayside and to think that it will “just happen”. It’s not easy to do though and involves being humbly wrong many times in succession. It requires all the pro-active outreach and rejection of sales without any of the highs from actually selling anything.

Done properly though it is incredibly powerful and painful only because it compresses a year of head-in-the-sand learnings into a few short weeks. That much medicine is never easy to swallow.

We found that with the funnel in place the rest followed very naturally. For us, heavy investment in customer development let us go from a product which nobody really understood to one which people now get in a single sentence (create your company knowledgebase from your everyday email) and really want to use.

Discussion on Hacker News >

Beware your project’s Schwarzschild radius

A good physicist knows that every gravitational mass has an associated escape velocity. The escape velocity is the speed which an object needs to have to get away from the mass’ gravitational field. In layman’s terms this simply means that it takes a bunch of energy to fire a rocket off a planet’s surface and get it out into space and the stronger the gravity, the more energy you need.

The heavier a planet is, the more rocket fuel you need to carry to get up and into space. However, the more rocket fuel you carry, the more you need to carry just to lift the extra fuel you’re carrying. Unfortunately there comes a point when, like an overfed Christmas turkey, your rocket needs so much fuel to get away from the planet that it’s too heavy to lift its own bloated self. BTW if this all makes sense then feel good because it really is rocket science.

The same phenomenon is true for projects. The larger your project is, the harder it is for you to actually release a product from it. The more features in your backlog, the more of a struggle it is to wrestle the final product to freedom. This you already know. What you may not know though is that there’s a point where a product becomes so bloated that it may never escape the project’s gravity.

Every project has “churn”. This is the rate at which the project and the requirements change. No sooner have you written down a list of features than some portion of them will change. Priorities, requirements, previously undiscovered dependencies - all of these cause churn.

Despite its name, churn seldom means change and more often means growth. The rate at which this happens depends on the size of the project. The bigger the project, the more things there are to attract change and growth.

Unfortunately while your project churns faster and faster, the rate at which you can actually get it done is constant. You can only do so much in the day and if you’re not careful your forward progress gets drowned by the rate of change. Like a bird flying into a strong wind you will slow down and may even start to move backwards.

actual progress = velocity - churn

Teams assume that their velocity is equal to the number of points the engineering team work through each week. Wrong. Engineering velocity is just your airspeed and airspeed is not the same thing as ground speed. What matters is not how fast you’re flying into the wind but how fast you’re actually travelling towards your destination.

A team’s actual velocity is equal to the engineering velocity (jobs done per week) minus the amount of new jobs added (churn). Churn is approximately proportional to the size of the project- the bigger it is, the more that will change.

Project duration = Project size / (velocity - (churn rate x project size))

So for faster projects you can either reduce churn (bad)

The old school way to accelerate your ground speed was by reducing churn and having a feature-freeze. Feature freezes remove churn but at the cost of flexibility and reactiveness. This is not what you want. Building a product tells you what that product actually is. Seeing people use it tells you what needs to be changed. Adaptation is good and you need the flexibility to change so simply locking down features is going to grind you into some rigid hulk that no-one wants.

…or you can reduce project size (good)

Rather than reducing the rate at which you change things, you can instead reduce the overall mass of things available to be changed. The smaller the project, the less scope there is to churn.

“But we need to build lots of things!” you say. Fine but only ever build small, entirely self-contained versions of the big story. Don’t be afraid to change stuff or to make things that you’ll later have to dismantle. Make each sprint, each release, self contained and effectual. Always have a usable product and have each release add a new chunk of self-contained product to it.

Some teams get confused with this and assume that a massive project squeezed out like a sausage and crimped off in two week chunks is the same thing as a series of two-week projects. It’s not. Large projects will beget large amounts of change, they will beget discussions in meetings, changing requirements and constantly updated (and outdated) specs.

Truly small projects are self contained and work as-is without needing anything else that’s still in the pipeline. Small projects don’t even have stuff in the backlog. You write that when the time comes.

Stay away from a project’s Schwartzschild radius

If you keep chucking stuff at a planet it eventually turns into a star. If you keep chucking stuff at a star then it eventually gets so big that it collapses in on its own gravity and forms a black hole. A black hole is so called because nothing can move fast enough to escape its gravity. Not even light. The distance away from the black hole where this phenomenon begins (the edge of the black) is called the Schwartzschild radius.

Some projects have a Schwartzschild radius of their own. They are so big and so doomed that there’s a critical distance within which people and resources will never be seen again. Steer clear of these, they’re bad news and Accenture’s doomed multi-billion pound rewriting of the British, NHS computer system was one of them.

Conclusion: for faster, more pleasurable projects, stay small

Most teams think that they’re throttled by their engineering teams but in truth, engineering is seldom the bottleneck and the degree to which you can control engineering velocity is extremely limited.

Since you can’t do much about engineering and you don’t want to freeze features, the only way to speed up your project is to make it smaller. Not globally smaller but just divided into genuinely self-contained small digestible chunks. Tear up your backlog, keep an entirely separate wishlist and stay speedy.

(Disclaimer: the bit about Accenture may just have been an excuse to use the term Schwartzchild radius in a blog title).

Absolute knowledge

I’m the type of person who needs to understand why I feel what I feel. I want to understand what drives me and what drives the people around me. I’m emotional but I like to be aware of what’s behind those emotions.

That’s why I found myself confused by last week’s NSA revelations. I found them uncomfortable but I could explain why. My gut said that a loss of privacy was bad but my brain couldn’t verbalise the consequences.

I read and re-read Daniel Solove’s essay, Why Privacy Matters Even if You Have Nothing to Hide. I also read a terrifying account of a citizen of one of the Arab Spring countries. However the post-privacy, dystopian future that Daniel painted is already the rather pleasant reality of my today and I’ve already given away almost enough information to be as vulnerable as that Arabic citizen.

Solove references the Orwellian vision of the future where our location, activities thoughts and relationships are tracked constantly. I’ve largely already opted into that world. My relationships, thoughts, activities and location are tracked via Facebook, my blog and Twitter. I’ve already opted in to being surveilled. My Facebook details may be only available to my friends but when there’s 900 of those, the distinction is academic.

I’ve personally written the dossier for a Kafkaesque trial where information about me is used to convict me without me knowing what’s within. I put my CV on LinkedIn, my philosophies on my blog and my affiliations on Facebook.

So I find myself confused. Sharing per-se does not seem to be bad. CIA dossiers of the 1950s were probably slimmer than Google’s dossier on me today and yet having that information in public has been of great personal and professional benefit. So why did the idea of PRISM bother me? Was I simply being a hypocritical reactionist? Why did I feel that Edward Snowden had done something patriotic and admirable and worth the tremendous cost he will have to pay for it?

The more I thought about it, the more I realised that it wasn’t the loss of privacy which was was bothering me, it was the loss of my right to privacy and perhaps even more than that, the loss of privacy of those who represent and protect me.

PRISM is most frightening because it is secretive and forces us to assume that all of our online activities are recorded. If I know how the government is hoovering up data then I can modify my behaviour accordingly. If I don’t know where they’re gathering data then it’s only sensible to assume that everything is available to them. If I tweet it’s public and I expect that my public thoughts may be taken down and used in evidence against me. While there was some talk of Twitter’s noticeable absence from the PRISM slide it’s probably less to do with their moral fibre and more to do with their API. I expect and you should too that our public thoughts will become public record

The idea of losing my privacy online is uncomfortable. However I can always switch off and become private again. But while going offline today is inconvenient, going offline in 20 years may be debilitating. The rate at which our lives are becoming digitally assisted is breathtaking. That means that not only will we be more digitally-dependent but switching off will be more conspicuous.

If your baggage boards a plane but you don’t follow your absence is not only conspicuous it’s consequential. The plane will be delayed and your baggage removed. In years to come our online absence may prove to be just as conspicuous. Simply by falling off the radar, by switching off our location monitoring, step-tracking, heart-monitoring and sleep monitoring we may become just as conspicuous as that empty seat in 22c.

Today PRISM removes privacy in the part of our lives which are online. When online and offline become inseparable and switching off isn’t any more an option that removing the number plates on my car, PRISM will have removed my right to privacy completely.

So losing online privacy may ultimately mean losing the my entire notion of privacy but I still have little more than an ideological cost to show for that. It sounds bad but how does it hurt me? Is it perhaps a price worth paying in the multi-billion dollar fight against the spectre of terrorism?

While troubling, the loss of my personal privacy may not actually be so consequential, I’m not of immediate interest to the government. They’re much more concerned with politicians they’re debating with with, contractors they’re negotiating with, lawyers or judges who might at some day need to impeach them. What happens though when their lives cease to be private? If an impeached president can read a judge’s notes using his NSA search engine can he really ever be tried?

Our information is our achilles heel, it’s leverage. A disease we haven’t revealed to our employer could compromise our jobs. An STD we kept private might publicly shame us. The fact that maybe our true sexuality is not the one we publicly portray, the fact that maybe the people we love are not the ones we live with. The fact that maybe we weren’t sick on that day we called into work and were instead skiing. All of these are things that can be used to manipulate and maneuver us.

Everyone has an Achilles’ heel buried somewhere in their lives and if a government has unfettered access to everyone’s information then they have access to everyone’s Achilles’ heel. The right to access our lives is the right to access the lives of the people who protect us and the right to do that is the right to rule unchallenged. All the good that Obama did with Obamacare will fade to black if he inadvertently negates the safety nets which protect us from bad leadership. Absolute knowledge is absolute power and absolute power corrupts absolutely.

All democratic nations were built on a system of checks and balances. All of them were built to be resilient to the occasional bad or corrupt leader. If you give that leader control over his opposition though, if you give him an arsenal of weaponry that no politician, no lawyer and no judge can oppose then you hand him the keys to do whatever he wants both domestically and internationally.

So when the average man or woman on the street says they don’t mind the NSA having access to their Gmail they’re probably not being naive. Ask them instead though whether the people that protect them should have privacy, whether the judges, the lawyers, the journalists and the opposition leaders should have the freedom from government. Ask them whether the people who protect them should have freedom to do their jobs unencumbered and you may not get the same answer.

When I first thought about it I couldn’t understand what was tangibly bad about giving government unfettered access to its our digital lives. The more I think about it though, the more I fear that with our ever more digitally entwined lives, a government with absolute access to that digital life has absolute power over us and absolute power to neutralise those we elect to protect us.

First world demons


An increasingly fashionable position on Hacker News is to invoke the “First World Problems” objection to a new startup. The First World Problem objection says that the founders of a particular startup are nought but huckster hipsters because they’ve addressed the tertiary problem of photo sharing rather than a core issue like medical-image sharing.

There’s an old saying which says that we make our own demons. It means that the things that haunt us and that we despise in others are in fact the things we fear in ourselves. We deal with our internal demons by externalising them and belittling them in others. A classic example is Chris Cooper’s portrayal of the angry homophobe in American Beauty. Outraged by the prospect of his son’s apparent homosexuality he rages against Spacey until events finally and violently expose his own inner conflicts.

Whenever I hear someone say “I hate this person” or “that group are idiots” my immediate reaction is to ask what it is that bothers that person. This isn’t pretentiously harmonious - it’s more often phrased as “that guy’s an angry idiot” but my assumption is that whatever they hate is simply the same thing they fear in themselves.

The First World Problem objection is a classic of these. Why should it bother anyone that someone should build another photo sharing service? Is it really such an offensive thing to do? Of course not. Unless that is, you’re in a job you don’t enjoy and the reason you’ve coached yourself not to leave it is that you haven’t found anything “worthy enough” to start yourself. When you’re trapped in this world the idea of someone having the courage to jump ship without waiting for something “worthy enough” to land in forces you back hard against your logic. That is painful.

Many, many people dream of something that frees them from their working lives and the presence of entrepreneurs and startups can be inspirational but also jarring and frightening. If you yearn to do something but have trained yourself you can’t, you have to give that commitment teeth. The most common teeth are the assertion that you will fail. For some though that is not enough and they need to believe that not only they will fail but so will everyone else. Those who don’t were either lucky or perhaps “in the club”.

The credit, as we know, belongs to the man in the ring but maybe it’s empathy we should reserve for the First World Objectionist for he is perhaps only sheltering from his own fears. And to those of you solving the First World Problem of photo sharing - forge on, I would love to see a First World Solution.

Comments on Hacker News