Let’s say you have a website at https://buygadgets.example.com. Users shop for shiny gadgets on your website and then enter their credit card numbers to buy them.

Because you value the security and privacy of your users, you use SSL for all traffic. You paid top dollar for an SSL certificate signed by one of the most trusted certificate authorities in the world, so your users can always be certain that they’re communicating with your website and not some other site pretending to be yours.

To build your site, you used an open source JavaScript library called FooLib. FooLib is awesome, and it’s backed by FooCo, one of the world’s largest and most trusted technology companies. This company even provides hosted versions of FooLib on their super fast content delivery network (CDN), so that anyone who wants to can link to http://cdn.foolib.com/foo.js instead of having to host the JavaScript on their own servers.

Because browsers display a warning when you serve a page that has a mix of HTTP and HTTPS content, you want to serve FooLib over SSL. Nobody wants to annoy their users with scary security warnings. Luckily, FooCo’s CDN supports SSL! You can just load https://cdn.foolib.com/foo.js, and now your users don’t see that pesky security warning anymore.

Unfortunately, you’re now deceiving your users, and that fancy SSL certificate you bought from the world’s most trusted CA is worthless.

Why? Because you’re letting FooCo execute any JavaScript it wants on your website. You’re loading that JavaScript securely over SSL, so the browser isn’t displaying any scary warnings, but now your users aren’t just communicating with buygadgets.example.com. Now they’re also communicating with cdn.foolib.com, and since cdn.foolib.com can run JavaScript on your pages, they can also see any information the user reads or enters on those pages.

“But why would FooCo do something like that?” you ask. “After all, their motto is `Don’t be naughty`!”

Of course FooCo would never do that. They’re a solid, upstanding, trustworthy company with nothing to gain from stealing credit card numbers. They’re providing a valuable service to the community, and they genuinely do it out of the goodness of their hearts.

But you’re still deceiving your users.

Your SSL certificate says to the user “Hey, you’re safe. It’s only you and me talking here, and nobody else can decrypt our communications. And you can rest assured that I’m really who you think I am, because this trustworthy CA says so.”.

But when you load FooLib from FooCo’s CDN, you’re silently inviting FooCo into that conversation as well. FooCo has their own SSL certificate, which is also signed by a trustworthy CA, but your user doesn’t want to share their information with FooCo. They want to share their information with you. By inviting FooCo into this confidential conversation without even telling your user that you’ve done it, you’re breaking the contract that was implied by your site’s SSL certificate and by the soothing lock icon in the browser’s location bar.

The user thinks they’re only telling you their secrets, but they’re also telling FooCo their secrets. And that’s not cool.

If user trust is important to you, you shouldn’t load JavaScript from third-party CDNs on secure pages. Not even if those CDNs support SSL, and not even if they’re run by the world’s most trustworthy companies.

Now, let’s be realistic: security is always a tradeoff. You trade some convenience for some security. Some websites are willing to share their users’ private information with FooCo, because it’s more convenient to do that than to host a JavaScript library locally. That’s a decision you have to make for yourself.

But as a user, I can tell you that if I found out that a company I trusted was silently making my private information available to some other company without my knowledge, all while making me think they were keeping this information confidential, I’d be pretty pissed. Even if no harm came from it, and even if it was done with the best intentions, I’d consider it a violation of my trust. And I don’t like companies that violate my trust.

Obligatory disclaimer: I work on the YUI JavaScript library at Yahoo!, but these are my own opinions. Nothing in this post should be construed as representing the views of my employer or anyone else on the YUI team.

Failing at privacy is easy. Anyone can do it. I can tell you how in a single sentence:

To fail at privacy, make it an attainable state rather than the default state.

As luck would have it, the inverse is also true:

To succeed at privacy, make it the default state rather than an attainable state.

Surprisingly, succeeding at privacy is in many cases easier than failing at it, yet so many products still fail at it. Why? Because they choose to. Privacy and marketing are often incompatible.

If a website launches a new feature that’s disabled by default, most users won’t even notice it’s there and will never use it. So when Facebook, Google, Yahoo!, and other websites launch new features, they typically enable them by default and allow users to opt out.

The opt-out model achieves marketing objectives and dramatically increases user uptake of a new feature, but if the new feature involves changes to the handling of information that was previously private, achieving the marketing objectives may come at the cost of violating users’ expectations of privacy and betraying their trust.

With enough time and effort, you can almost always convince a user to try out a new feature. It’s much harder to convince a user to trust you again once they feel their trust has been betrayed.

Unfortunately, in an industry where success is typically measured by how many users have a feature enabled and not by how many users are actually using or deriving value from that feature, conservatism doesn’t pay. If you want the usage numbers, you have to make it hard for users not to use your stuff.

Someone with a more mathematical mind than mine could probably derive an algorithm to describe the typical level of privacy you can expect from any given company or product. A younger, newer company or product will typically err on the side of caution. They haven’t yet proven themselves, so user trust is extremely valuable to them; in addition, they typically have less market pressure to drive massive user uptake of new features, and they tend to communicate more directly with their users, which gives them a better idea of what their users want and need.

Larger, older companies and products have less to lose by betraying a user’s trust and have significantly more to lose by not meeting business objectives, particularly if the company is traded publicly. Products at larger companies sometimes suffer from design-by-committee, and the people at those companies may find it harder to keep in touch with their users’ wants and needs (not surprisingly, the wants and needs of shareholders are often given higher priority).

The value of a user’s trust is something that’s hard to measure, especially in an industry as young as the Internet industry. It’s something that isn’t apparent in the short term, but can slowly become very apparent over the long term. Betraying your users’ trust today might not have any noticeable effect on your company right away or even for a few years, but do it enough and it will eventually catch up with you.

This is a lesson that many Internet companies will soon begin learning the hard way. Some already are. Give yourself an advantage by learning from their mistakes: make privacy the default. Encourage your users to trust you, and reward them when they do by valuing their trust and treating it as your top priority. Think about the future, not the now.

Your users are far more valuable as advocates of your product than as numbers in a usage report.