Imagine you have an online store that offers brand new gadgets, and users provide their credit card numbers to make the purchases. You put their security and privacy on pedestal and apply SSL for all traffic and spend stacks of money have you SSL certificate to be signed by one of the most well-trusted certificate authorities. Users can be sure that they communicate with your website, not some other web-source pretending to be your company.
Since browsers show a warning when you transfer a page with mixed HTTP and HTTPS content, you prefer serving FooLib over SSL. No one wants to put visitors off with annoying and dreadful security warnings. Good news: FooCo’s CDN works with SSL, so your visitors don’t have to look on these nagging security warnings anymore.
It’s not FooCo to blame: all in all, it’s a solid and trustworthy company that would never steal clients’ credit card numbers. They provide excellent services to the community wholeheartedly, without persecuting unfair goals. However, you still deceive your end-users. The presence of SSL certificate means the visitor is safe, and nobody else can decrypt the communications.
But when you load FooLib from FooCo’s CDN network you unintentionally invite the third party, FooCo. It has its own certificate also signed by a reliable certificate authority, but your users don’t want to share their information with anyone else – it’s should be available only for your website. By inviting FooCo to the interaction without warning visitors about it you break the contract that was implied by your site’s SSL certificate. The user is soothed by the lock icon on the URL bar, but it’s a lie.
Now imagine yourself at your user’s place and decide: would you accept the fact that your confidential information is made available to other companies without your consent? Even if it doesn’t cause harm, there’s always a minor risk of accidents.