20599 2013-01-08 13:32:04 +0000 Remove ISO-2022-KR encoder (or the entire encoding) from the spec 2013-08-24 20:07:28 +0000 1 1 1 Unclassified WHATWG Encoding unspecified All All RESOLVED FIXED https://bugzilla.mozilla.org/show_bug.cgi?id=827796 P2 normal Unsorted 16687 16691 19942 1 VYV03354 annevk excors jshin mike pub-w3 zackw sideshowbarker+encodingspec oldest_to_newest 81042 0 VYV03354 2013-01-08 13:32:04 +0000 Currently Gecko doesn't support the encoder. I would not like to implement it only to comply with the spec. Is there any reason it is needed in the spec? I'd rather remove the decoder if every encoding requires both encoder and decoder. Removing ISO-2022-KR is also proposed on www-international. http://lists.w3.org/Archives/Public/www-international/2012OctDec/0039.html 81044 1 annevk 2013-01-08 13:44:27 +0000 Is there a bug on removing the decoder? What happens if someone needs the encoder? Does Gecko use utf-8 instead or some such? 81045 2 VYV03354 2013-01-08 13:59:11 +0000 (In reply to comment #1) > Is there a bug on removing the decoder? Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=827796>. > What happens if someone needs the > encoder? Does Gecko use utf-8 instead or some such? Yes, uses UTF-8. 83281 3 VYV03354 2013-02-18 18:13:09 +0000 Removing stateful encodings will affect some types of attack such as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20886#c3 83282 4 zackw 2013-02-18 18:16:30 +0000 It would be unfortunate if we had to continue supporting legacy stateful encodings just to avoid a hypothetical attack based on something *not* getting interpreted in a legacy encoding. 83316 5 annevk 2013-02-19 11:00:52 +0000 http://zaynar.co.uk/docs/charset-encoding-xss.html lists another problem with not supporting ISO-2022-KR but also notes that IE already has this problem. And this problem might already exist for ISO-2022-CN too. 92483 6 jshin 2013-08-22 22:13:04 +0000 I also proposed the same by email. ISO-2022-KR should be removed from the spec entirely. It's not for Web. No sane person would use it on the web. Moreover, it's a potential security risk like any other non-ASCII 7bit encoding. We have to live with ISO-2022-JP, but no other non-ASCII 7bit encoding should be specified for the web. 92497 7 annevk 2013-08-23 10:35:17 +0000 Jungshik, was that quite a while ago? I don't have any recent email from you suggesting that, but I recall you might have said that on a mailing list at some point. In any event, two implementers willing to take the plunge works for me. https://github.com/whatwg/encoding/commit/01f872bf168e138533d5aa67405d358f8c2fdc94 92543 8 pub-w3 2013-08-24 20:07:28 +0000 (In reply to comment #6) > We have to live with ISO-2022-JP, but no other non-ASCII 7bit encoding > should be specified for the web. The encoding standard currently includes the 7-bit Chinese HZ encoding — should that one be removed as well?