3 ms·
His thought experiment had the opposite of its intended effect on me. He describes a bug in a framework that could very plausibly have been used as a vector fo
by tc 17y ago
His thought experiment had the opposite of its intended effect on me. He describes a bug in a framework that could very plausibly have been used as a vector for a XSS attack. If browsers implemented strict parsing it is far more likely that this bug would have been noticed sooner. The bug might never have made it off the original developer's machine.
- snprbob86 17y agoAgreed. I'm generally a believer in applications being "strict in what they emit, and liberal in what they accept" which seems to be what this guy is advocating. However, after reading it, I immediately equated this with an XSS attack and was re-evaluating the benefits of the strictness-always approach.
- three14 17y agoThe case in favor of strict parsing is always that you'll catch bugs sooner. The point of his argument is that you forgot about pesky humans, and real life software - where strict parsing means a computer that's much less useful. (In his particular example, which is just an example and not the whole point, you could parse trackbacks strictly, and still give people browsers that just work. And strictly parsed but poorly filtered third party HTML will give you XSS attacks, too. And his example happened to be buggy filtering of charsets, and not specifically poor parsing. So I don't really see the objection.)
- radu_floricica 17y agoEven security is a trade off. Try to estimate the costs of the average security breach on a blog and compare it with the added hassle.
- olavk 17y agoGood point. Also, if the browser is able to recover from malformed markup, why can't you have a module on the server to do the same thing, and rewrite the malformed markup to well-formed before serving it?
- d0mine 17y agoWhy does software contains bugs? Why can't some module on a server rewrite it to make it bug free?