6 ms·
Third party CDN's are a security tradeoff. For Userify (an SSH key management company), we're working on eliminating our use of all third-party domains in both
by jamiesonbecker 11y ago
Third party CDN's are a security tradeoff. For Userify (an SSH key management company), we're working on eliminating our use of all third-party domains in both our app and main website.
This is a process and we're giving up a lot of stuff like Google Analytics (however, it's debatable how useful that is with our target audience anyway). As we move forward, we're also combining (compiling) our resources into a single, cacheable SPA.
Any time you incorporate code from another site, you're:
a) leaking information about your visitors
b) increasing the probability of malicious injection
c) for required assets (JS/HTML, usually not CSS), lowering your overall site availability/reliability -- even if that third party site is often more reliable than your site
d) for less frequently used CDN assets or less frequently used sources, possibly also decreasing the speed of site delivery, especially if resources are requested less often than cache expiration (depending on type of edge caching)
e) similarly, possibly slowing down site by increased name resolution requests (this can be mitigated somewhat with pre-fetching)
f) increasing variation in load times (weakest link)
g) trading off latency for bandwidth
The biggest reasons for us, however, are (a) and (b). This is also why TLS should forced enabled with HSTS for many sites. Security trumps efficiency, especially when the differences are measured in milliseconds.
- manigandham 11y agoYour site right now has some JS that's in a continuous loop adding the same assets to the page. http://i.imgur.com/MoRAVAH.png http://i.imgur.com/MoRAVAH.png EDIT: looks like it's live.js used to check for changes while in dev, probably shouldnt have that on the live site.
- jamiesonbecker 11y agoGood catch! Fixed.
- garrettr_ 11y ago> b) increasing the probability of malicious injection Subresource Integrity (SRI) [0] was designed to avoid this potential vulnerability. It's a brand-new browser feature (jus t landed in Chrome stable, is riding the trains to Mozilla stable now) but it's worth taking a look at. Github is already using it [1]. [0]: http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ [1]: http://githubengineering.com/subresource-integrity/ http://githubengineering.com/subresource-integrity/
- jamiesonbecker 11y agoAbsolutely! unfortunately it may take years before the majority of browsers use it. :(