Bug 25339 - [survey needed] Make hz-gb-2312 a label of the replacement encoding
[survey needed] Make hz-gb-2312 a label of the replacement encoding
Status: RESOLVED FIXED
Product: WHATWG
Classification: Unclassified
Component: Encoding
unspecified
All All
: P2 normal
: Unsorted
Assigned To: Anne
sideshowbarker+encodingspec
http://telemetry.mozilla.org/#release...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-14 10:30 UTC by Henri Sivonen
Modified: 2014-11-04 06:34 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henri Sivonen 2014-04-14 10:30:21 UTC
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.
Comment 1 Jungshik Shin 2014-04-14 10:44:30 UTC
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).
Comment 2 Anne 2014-04-14 10:50:23 UTC
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.
Comment 5 Anne 2014-09-20 08:48:43 UTC
That's great, are we sure that will stick? If so, I can remove it from the Standard.
Comment 6 Anne 2014-10-04 09:57:31 UTC
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.
Comment 7 Anne 2014-11-01 16:59:01 UTC
jsbell, removal of this encoding shipped four days ago in Chrome M38 right? Seems it is time to remove this from the specification.
Comment 8 Joshua Bell 2014-11-03 18:14:16 UTC
(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.
Comment 10 Jungshik Shin 2014-11-04 06:34:57 UTC
(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.