Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host jquery, Raphaël and Underscore locally #8

Open
onitake opened this issue Mar 20, 2015 · 1 comment
Open

Host jquery, Raphaël and Underscore locally #8

onitake opened this issue Mar 20, 2015 · 1 comment

Comments

@onitake
Copy link

onitake commented Mar 20, 2015

Move from mirleft/ocaml-tls#263

It's become a widespread (mis)practice to host JavaScript on external content delivery networks, despite the implied security risks.

JavaScript source files normally contribute very little to page loading times, bandwidth and server load, so the usual arguments for hosting them externally are weak. In contrast, the risk of third party information sharing and code injection is very high. This is obviously a matter of trust, but developers should not simply forego user's concerns about the trustworthiness of Google, Cloudflare, et al.

This should be of particular importance to a project that concerns itself with data transmission security.

@onitake
Copy link
Author

onitake commented Mar 20, 2015

While I'm in general in your favour (of not using CDNs, for containment and privacy issues - which
tls-demo-server also did initally), I don't really see the security risk here: if you accept arbitrary
JavaScript from some server on the internet, you're screwed. OTOH, a browser is much more likely
to have cached the file if using an external CDN. And I cannot see any privacy impact of people
browsing https://tls.openmirage.org

Feel free to open an issue at the tls-demo-server repository if you have a more concrete concern.

In this case, you do make a point. Information sharing is of less importance for an informational site, but there is still the risk of tracking, which is not completely concern-free for everyone.

As for the caching argument: This would generally be a good thing™, but in practice, browsers still generate HTTP requests for static resources, leading to no real benefit except for maybe a few saved kilobytes due to a 304 from the server.

My argument was mainly that experienced developers should lead by example, not spread bad practices to people who simply don't care.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant