Werd I/O

I enjoyed this episode of This Week in Startups with USV's Fred Wilson. It's a fairly candid conversation from this year's Launch Festival, and Fred comes across as having both integrity and a very practical approach to investing in startups.

The story that jumps out at me is that of Tumblr's acquisition by Yahoo!. There are two important details: the first is that Tumblr's initial investment round was less than a million dollars. The second is Fred's disclosure that the acquisition happened at a time when Tumblr had spent a lot of money on growth, and would have to either raise a huge round to make up the shortfall, significantly diluting the existing shareholders in the process, or raise unrealistic amounts of revenue. So selling to Yahoo! for $1.1 billion made sense for them.

There has been a great deal of backlash against venture capital in data ownership circles over the last year. Certainly, VC money gravitates towards a certain kind of company strategy, where designing for extremely rapid growth is a hallmark, and a profitable exit - either to IPO or acquisition - is desired. Rapid, sustainable growth is very difficult to achieve without a budget. It also overwhelmingly leads to strategies like revenue through advertising, where user growth isn't hampered by having to pay to use a service. Advertising is often criticized for requiring people to give up some personal privacy so that advertisements can be more targeted, and therefore more valuable to the service.

I think it's worth considering that services like Tumblr, Twitter and Facebook have also connected us and become a part of the cultural landscape in ways that wouldn't have been possible if people had needed to pay for them. Assuming that everyone should pay for a service is not realistic if you want to build a global community. Again, a resource-strapped startup is also more likely to see slower growth than one with millions of dollars in the bank: their box of tricks is necessarily more limited.

If you're opposed to this kind of financing, it's worth asking: would you pay for Tumblr, or Twitter, or Facebook? If not, why not? How many services do you actually pay for?

Venture capital isn't the only way. Notably, O'Reilly Alpha Tech Ventures created Indie.vc in order to explore a more revenue-centric funding model (and I hope more will follow). But I do think VC is a legitimate funding tactic for a particular kind of highly-available, free-to-use mass-market tool, and it seems to me that whether it has a detrimental effect on a startup's service has more to do with the individuals at the startup, and the personalities of the VC investors they choose, than the model as a whole.

In today's climate, it's important that we secure communications with our servers. For example, if you're on open wifi (at a coffee shop, for example, or at a conference), it's trivial to steal the unsecured logins of the people around you. Using secured connections also helps protect against people monitoring your communications further up the chain, at an infrastructure level. In the era of the Snowden revelations, protecting your privacy is an obviously good idea - but there is also an immediate practical value in preventing people from stealing your passwords and credit card details, too. Security is so important that Google recently said that they would rank secure sites higher in their index.

But it's so hard to implement that today, most peoples' websites are nowhere near secure - and it's the technology's fault.

First, let's talk about secure websites work.

Here's a summary version.

When you visit a secure website, your browser and the site's web server discuss which secure encryption protocols and algorithms they both support. The server also sends your browser a security certificate, which contains the website address, as well as details about a central certificate signing authority that can verify that the certificate is authentic. The certificate is cryptographically signed by the digital signing authority. Every browser comes with the cryptographic keys of all the major certificate signing authorities, which it uses to verify the certificate's authenticity. Only once the secure protocols have been chosen and the certificate is verified as being both authentic and for this website does the page load.

Even the summary is kind of technical, so if your eyes glazed over, just take away these two things:

1. Secure websites are only accessible if they have been certified by one of a handful of central organizations, and the certificates contain the address of the website they pertain to.
2. There are lots of different algorithms that can be used to secure the traffic between your web browser and the website, and some of them are more secure than others.

So how do I secure my website?

Let's back up a little bit. Here's how a lot of people create their websites:

1. Sign up with WordPress.com or Squarespace (or Known Pro, of course!)
2. Pay for a custom domain name

If they've chosen to self-host, here's how most individuals create their websites:

1. Sign up for a shared host like Dreamhost or Fasthosts
2. Click on their server control panel to install WordPress or Known

I mean, it could be easier, but it's short of being an ordeal, right?

Meanwhile, here's what you have to do if you want to install a secure certificate to make sure your self-hosted website uses encrypted connections:

1. Log into your server using an SSH terminal
2. On the command line, create a certificate signing request by following the command-line instructions for your particular web server
3. Specify a cryptographic key of appropriate length (don't know what that is? too bad)
4. Enter your address details on the command line
5. Open the certificate signing request file
6. Copy and paste the contents
7. Go to a certificate authority website
8. Click to buy a certificate for your domain
9. Paste your certificate signing request
10. Download the certificate and what are called the certificate chain files, which describe to the browser how to validate the certificate
11. Install them on your server, probably using command line tools
12. Make sure your server is set to use strong encryption algorithms in its configuration files
13. Check your website's security score to see how well you did

To be fair, some hosts, like DreamHost, take care of many of these steps for you. But it's still not easy.

And as far as using SSL on custom domains on managed services like WordPress.com and SquareSpace? Here's the truth: you can't.

Why SSL is hard for custom domains on managed services

Remember when I said that the certificates were issued for a domain? Multi-domain certificates can also be bought, but in all cases, the domains have to be specified at the point when you buy the certificate. If you already know you have 50 domains that you want to secure, then that's great - but if you're providing a service where you know you want to secure domains you will host in the future, you're stuck. You would need to request and buy a new certificate for every new domain, or do it in batches.

Because each certificate needs to be separately requested and installed, this is a hard process to automate. To make matters worse, most virtualized server environments - for example, Amazon Elastic Beanstalk - only support one SSL certificate per instance. That means you've literally got to set up a new clone of an application environment every time you want to support a new SSL domain.

That's unsustainable, and because most services like WordPress.com and SquareSpace use these kinds of virtualized environments so they can add and remove servers to cope with changing demand, they have trouble supporting secure websites for their custom domain users.

We need security, so it needs to be easier to deploy

Security is vital. A clue that it isn't easy enough are those website security scores: a letter grade for your website that describes how secure it is. I've seen engineers ooh and aah at sites that managed an A+ grade.

If we want everyone to use this kind of security, it needs to be totally brainless. Trusted encryption needs to be there by default in every web server and adding new domains programmatically needs to be simple.

The certificates are also difficult because they are trusted by central authorities - which themselves need to be trusted. Not only is the secure web cumbersome to maintain, it's actually potentially insecure. We have certificates to prevent against man in the middle attacks, but maybe there's an alternative? Could the blockchain help, for example?

There's no dispute that you should secure your site, and you should strive to use secure sites. But it's difficult. You'll note that at the time of writing, I haven't secured my own site yet (although the Known service does use secure connections). I don't think the existing technology is cutting it, and to protect all of our security, we need to find something new.