3 ms·

I disagree. The issue described is an input sanitisation issue. The same thing would have happen to a SQL query and everyone would have put shame on you. It IS

I disagree. The issue described is an input sanitisation issue. The same thing would have happen to a SQL query and everyone would have put shame on you. It IS a bug that the blog engine developers should have catch, in the same way they should have protect the trackback from XSS injection. Guaranteeing your output will always be valid might not be trivial, but it is way less harder that some people pretend it to be.

haberman 13y ago
Bugs will slip through. They just will, it's a fact of life. The question is, when they do, will you let the browser gracefully recover, or will you demand that the browser show an error page, even though it could do something reasonable? The security analogy would be to let all your code run as root, because the main security mechanisms should prevent users from executing arbitrary code. But this is fragile, because any security bug would compromise the security of the system completely. What we do instead is have defense in depth: even if the first layer of security is compromised, there are other layers of security that can (hopefully) contain the damage. Permissive client rendering likewise limits the damage that one bug can do.
- gizmogwai 13y ago
  Having seen so many failure getting worse because people did not paid attention to it in the first place, I would go for the error page. That said, even if we choose a defense in depth, it still is not a valid reason to throw away XHTML as it was done. The same way you will not remove your firewall because it does not block dormant viruses, but add an antivirus, the browsers could have still continue putting effort in rendering the correct, and powerful, XHTML, while setting down some decent fallbacks to recover. Being we a be red warning to raise awareness that something need to be fixed.

3 ms·

I disagree. The issue described is an input sanitisation issue. The same thing would have happen to a SQL query and everyone would have put shame on you. It IS

by gizmogwai 13y ago

haberman 13y ago
Bugs will slip through. They just will, it's a fact of life. The question is, when they do, will you let the browser gracefully recover, or will you demand that the browser show an error page, even though it could do something reasonable? The security analogy would be to let all your code run as root, because the main security mechanisms should prevent users from executing arbitrary code. But this is fragile, because any security bug would compromise the security of the system completely. What we do instead is have defense in depth: even if the first layer of security is compromised, there are other layers of security that can (hopefully) contain the damage. Permissive client rendering likewise limits the damage that one bug can do.
- gizmogwai 13y ago
  Having seen so many failure getting worse because people did not paid attention to it in the first place, I would go for the error page. That said, even if we choose a defense in depth, it still is not a valid reason to throw away XHTML as it was done. The same way you will not remove your firewall because it does not block dormant viruses, but add an antivirus, the browsers could have still continue putting effort in rendering the correct, and powerful, XHTML, while setting down some decent fallbacks to recover. Being we a be red warning to raise awareness that something need to be fixed.