Should we encrypt all our traffic?

Posted by Webmaster in Uncategorized

We should be encrypting our form submissions. The fact that we don’t bugs the craftsman in me.

Selective Encryption

At first I was thinking about writing a script that gracefully redirects our forms to use encryption. But how do I get people back on a non-encrypted connection after they are done with the form? I could have the same script gracefully redirect back to plain old HTTP. But some people prefer to surf everywhere using HTTPS. There’s even a browser plug-in to make this simple for non-nerds. Forcing a non-encrypted connection for non-form pages robs our users of that choice. And that bugs the craftsman in me too.

So I could just not worry about it, force encryption for form pages and let it ride. People who choose to surf with an encrypted connection with us can do so. And people who submit a form will surf using encryption for the rest of that session. But that causes some problems too.

Potential Problems

Most browsers warn users when they visit a page that mixes encrypted and unencrypted content. For our purposes there’s no real risk if the form itself is encrypted but the CSS used to style it is not. But it becomes a perception issue. With the recent buzz around FireSheep will only make users more wary of unencrypted connections or cryptic browser warnings.

The only way to avoid this problem when mixing connection types is to use protocol relative URLs everywhere on the site. When we roll out a content management system it would need to automagically take care of such things without burdening the end user to understand geeky stuff like protocol relative links.

Encryption Everywhere

Or we could take the HTTP Everywhere approach and encrypt all our traffic. That makes it easy for the end user. And I don’t have the same qualms over removing the user’s choice to not use encryption. The big trade off there is the performance hit we’d take. I spent a couple weeks this past summer working intently to speed up our page load times. Encryption adds overhead and will eat into those (hard won) gains.

Quantifying the Trade-Off

The biggest hit will be on the first page loaded by brand new visitors. Based on my not-exactly-scientific research (IMing some friends and having them test it for me on which loads faster) the worst case takes about 3 times longer to load. Once a site visitor has a primed browser cache the performance trade off drops. Normal conditions produce 20-30% increased load times. So how often does the worst case happen?

About 1/4 of our traffic is first time visits. That means the other 3/4 are visiting the site with primed browser caches. Also, new visitors have a primed browser cache for the 2nd and subsequent viewed pages (at least for CSS, JS, and image files that are used site wide). The average pages per visit for 1st time visitors is 3.44 pages. Cheating on the math a bit we can calculate that about 7.5% of our traffic falls under the worst case.

So is it worth it? It’s only a small fraction. But it’s also our first impression. Google tells me our pages load in 1.7 seconds on average. That would shoot up to around 6 seconds for the worst case. The rule of thumb 10 years ago was load within 8 seconds or lose business through attrition. And that was back when dial-up was still common. If anything users expect even speedier experiences online now. Will a drastically slower load time tarnish our first impression with potential students to the point that it harms our brand?

I honestly do not have answers at this point. If anyone out there has tips or resources to share by all means leave me a comment. In the mean time I’ll be mulling this over and researching for a solution as my schedule permits.