3 ms·

You probably won't see this response, but in case you do: I see what you're saying, and I'm not going to criticize decisions people made more than a decade ago

You probably won't see this response, but in case you do: I see what you're saying, and I'm not going to criticize decisions people made more than a decade ago, but we've outgrown the robustness principle. You should not be tolerant of accepting bad input to coddle your users. You should write simpler languages (so the effort they must put in is reasonable) and better development tools (so they understand their mistakes). Even if you decided to let HTML be "robust" since it comes from humans, why would you let an HTTP client or server emit broken headers? The real problem with the robustness principles is that it has short-term benefits and extreme long-term costs. Today it means that you can open up netcat and talk to Apache without using CRLF linebreaks (as per the spec). But next year, and the year after that, and the year after that, you'll have to support increasingly noncompliant legacy implementations. We write specifications to make things concrete. The robustness principle, over time, creates a "shadow standard" one must abide by, putting bad code into your project to support the bad code everyone else has been writing because we _let them do it_. Maybe it makes Firefox better able to process its inputs but it makes the web as a whole fragile. It does not make broken data any less broken, it simply silences errors. In short, it is neither robust nor principled. Security is about tradeoffs, but after so much time building broken systems, it's time to realize that this tradeoff is not reasonable.

jolux 11y ago
HTTP clients and servers should absolutely not emit broken headers, but that's a violation of the robustness principle of itself. The way I think about it is imagining how many websites I use daily just wouldn't work if HTML parsing were completely strict. I regularly open up Dev Tools to see which of the websites I visit work without CSS or HTML parsing errors. My primary concern is that there needs to be a way to implement strict parsing that doesn't greatly raise the barrier to entry or make the product unusable. I do think a lot about this but it's nonetheless confounding from both perspectives and I think the usability of strict parsers needs to be addressed, whether that means better error messages or really good linting or whatever.

jolux 11y ago

HTTP clients and servers should absolutely not emit broken headers, but that's a violation of the robustness principle of itself. The way I think about it is imagining how many websites I use daily just wouldn't work if HTML parsing were completely strict. I regularly open up Dev Tools to see which of the websites I visit work without CSS or HTML parsing errors. My primary concern is that there needs to be a way to implement strict parsing that doesn't greatly raise the barrier to entry or make the product unusable. I do think a lot about this but it's nonetheless confounding from both perspectives and I think the usability of strict parsers needs to be addressed, whether that means better error messages or really good linting or whatever.