Re: [whatwg/encoding] Big5 encoding mishandles some trailing bytes, with possible XSS (#171)

> Since most implementations are now aligned I wonder to what extent they want to change this again.
> ...
> At the very least we should add a warning somewhere

If there is agreement that this is a possible security problem waiting to happen, then a fix is a lot better than a warning. Plus, it really "feels" incorrect: a valid lead-trailing byte sequence gets only half-converted to `U+FFFD`...

It is not an intrinsic problem with legacy encodings, it is a problem with the algorithm as described in this spec.

Let's say we add a warning.
What is an implementer supposed to do to mitigate the security problem?
They can either implement some fix, making them non-WATWG compliant, or they can ignore it.
None of the options sounds like a good one.

_"you have to be sure that it's identical to those defined"_: there is no way to do that. You get some content from somewhere, you don't even control it, and it is tagged as Big 5. There is no way to tag it as some variant of Big 5, because none of them is IANA registered.
The only thing one can do is detect the error and convert the invalid sequences to `FFFD`, which is what this spec is supposed to detail.

---

Would it help if I get some "chime in" from someone in the Chrome team saying they would implement this if the spec changes?

Thank you very much,
Mihai

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/171#issuecomment-458225991