This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HZ is an exceptionally dangerous encoding, because its escape sequence consists of printable ASCII characters. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=20886#c3 . In Firefox 28, I constrained the inheritance of HZ, removed it from the UI so that it can't be chosen manually and added telemetry for counting sessions in which the HZ decoder has been instantiated. Sessions in which the HZ decoder has been instantiated are very rare: such a session occurs less often than once in a million sessions. http://telemetry.mozilla.org/#release/28/DECODER_INSTANTIATED_HZ/saved_session/Firefox This suggests that the utility of HZ is so small that it should be regarded mainly as an XSS attack vector and be mapped the replacement encoding. I'd be interested in hearing the perspective of developers of other browsers, Chrome especially, since Chrome has resisted the addition of useless or merely marginally useful encodings.
I meant to file this bug, but haven't managed to. I fully agree to the proposal to make HZ a replacement encoding. I don't see any reason to keep it as a regular encoding while turning ISO-2022-{KR,CN,CN-Ext} to replacement encodings. Google's statistics is also similar to what's obtained with Mozilla. (I don't remember the number at the moment).
Can you please go ahead and make this change in Gecko and Chromium and report back here whether it's sticky? I will add a note to hz-gb-2312 that it is considered for removal.
https://github.com/whatwg/encoding/commit/f7a855a39aa0ab96ce3b783957d8ff67e5f97851
Blink made hz-gb-2312 as a replacement encoding. Sorry that I hven't reported sooner. See https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/wtf/text/TextCodecReplacement.cpp&q=HZ-GB-2312%20file:%5C.cpp$&sq=package:chromium&l=28 and https://codereview.chromium.org/265973003
That's great, are we sure that will stick? If so, I can remove it from the Standard.
The fix landed in Gecko too. I updated the specification to say this will almost certainly be removed. Waiting for confirmation that this hit stable before completely removing it.
jsbell, removal of this encoding shipped four days ago in Chrome M38 right? Seems it is time to remove this from the specification.
(In reply to Anne from comment #7) > jsbell, removal of this encoding shipped four days ago in Chrome M38 right? > Seems it is time to remove this from the specification. I believe this went out in Chrome M37, actually. (And M38 hit stable a month ago now.) No bug reports due to making hz-gb-2312 a replacement alias have crossed my radar. Unless Jungshik has any additional data, it looks like it has "stuck" and agree we can add it to the spec.
https://github.com/whatwg/encoding/commit/27513dad60cc80270e28d776939746b040b45fd0
(In reply to Joshua Bell from comment #8) > (In reply to Anne from comment #7) > > jsbell, removal of this encoding shipped four days ago in Chrome M38 right? > > Seems it is time to remove this from the specification. > > I believe this went out in Chrome M37, actually. > > (And M38 hit stable a month ago now.) > > No bug reports due to making hz-gb-2312 a replacement alias have crossed my > radar. Unless Jungshik has any additional data, it looks like it has "stuck" > and agree we can add it to the spec. I haven't seen any report of an issue due to the change, either.