4 ms·
Awesome article and thumbs up to github. I'm having great reservations towards CSP however. I think it breaks the web in a way that wouldn't have been necessar
by tannhaeuser 10y ago
Awesome article and thumbs up to github.
I'm having great reservations towards CSP however. I think it breaks the web in a way that wouldn't have been necessary had we been a little bit more careful about HTML syntax rather than dismissing markup validation as an obsolete technique back when the vulgar "HTML 5 rocks" campaigns were in full swing.
CSP spec drafts have been around forever but were never finalized. CSP basically blocks execution of JavaScript in script tags in content (as opposed to script in the header), as well as in content handler attributes (onclick and co.) by disabling those alltogether on a page. This totally breaks page composibility where you assemble content at the markup stream level from multiple sources, like, say on every single news aggregation site. The removal of scoped CSS styles from HTML similarly breaks composition.
From Chrome's Content Security Policy page:
[Blocking inline script] does, however, require you
to write your code with a clean separation between
content and behavior (which you should of course
do anyway, right?)
I think this comment is totally clueless wrt. what the Web is about. "Separation of concerns" is most certainly not a characteristic of the Web, and never has been.
I'm sorry, but rather than using kludges such as CSP to turning the lights off with a broad brush, how about fixing HTML and JavaScript in the first place?
(note my comment isn't addressed at github but at web standard comitees)
[1]: https://developer.chrome.com/extensions/contentSecurityPolicy https://developer.chrome.com/extensions/contentSecurityPolic...
- jerf 10y ago"I'm sorry, but rather than using kludges such as CSP to turning the lights off with a broad brush, how about fixing HTML and JavaScript in the first place?" OK... how? To be clear, I'm asking for an HN-comment level of detail, not a standards-body level of detail. I can't speak for everyone else on HN but I won't go over things with a fine-tooth comb, I'll only look at top-level issues. But I will at least point out that being able to casually float third-party content into any site that has a weakness to XSS or man-in-the-middle or vulnerabilities in any other third-party content in the website is pretty fundamental. The fundamental composition power of the web is too powerful and it is going to have to be cut back. Some of the obvious solutions like "whitelisting hashes of valid content" have their own problems, like how a lot of the scripts being included out there are deliberately not constant and that's their whole point in the first place.
- tannhaeuser 10y ago1. Defining and using safe JavaScript subsets (in the style of Google's Caja [3] and AdSafe [4], though probably that ship has sailed and cramming syntax sugar into JS is the order of the day instead) 2. Defining and using safe CSS subsets (with countermeasures against click-jacking/-phishing, and hiding "nose print" etc.) though granted this is challenging; I had hoped a formal semantics for CSS came along (such as in [2]) but it didn't 3. Using HTML-aware template engines (such as [1] but there are maybe lighter approaches with hard-coded HTML rules as well; disclaimer: my project) [1]: http://sgmljs.net/blog/blog1701.html http://sgmljs.net/blog/blog1701.html [2]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/extended.pdf https://lmeyerov.github.io/projects/pbrowser/pubfiles/extend... [3]: https://developers.google.com/caja/ https://developers.google.com/caja/ [4]: http://www.adsafe.org/ http://www.adsafe.org/