Intent to remove: <isindex>

[Henri Sivonen]

<isindex> is a strange feature from the dawn of HTML. It predates
proper <form> functionality and provides a single search field that
maps to the URL query string in a way that differs from <form> fields.

When Hixie specced the HTML parsing algorithm, he adopted the Trident
approach to <isindex>, which is to treat the tag as a parser macro
that expands to multiple elements, including a <form> and <input>.

Since <isindex> maps to the query string in a different way than
normal <form> fields, the form submission code has a special case that
recognizes the naming of the <input> generated by the parser macro and
handles the <input> in an abnormal way.

In December 2013, Blink decided to remove <isindex> citing it as a
bypass vector for XSS filters and citing usage as minimal. (Such a
filter would have to be a blacklist-based filter, and those are
fundamentally broken anyway: if you want a filter that actually works,
you must have a whitelist-based filter.)

EdgeHTML has since followed Blink. At this point, sites that are still
maintained and that used <isindex> at the time of removal from Blink
have had to adapt. (Existence proof seems to include e.g.
http://cdcvs.fnal.gov/cgi-bin/searchaddproduct.cgi whose admin
complained on blink-dev, but now the page no longer uses <isindex>.)

Therefore, even though removing <isindex> is a violation of the
Support Existing Content design principle, Blink (and EdgeHTML) having
broken <isindex> and kept it broken for a couple years anyway have
made the feature even less valuable than it used to be, because the
still-maintained sites have had to adapt. (The notion of unmaintained
sites that accept user input is pretty scary.)

The general ugliness of the implementation of <isindex> is sunk cost
at this point, but the implementation does impose an ongoing privacy
weirdness: <isindex> is a case where a Web site can make the browser
provide a string supplied by the browser UI localization as part of
the DOM. That is, even if the user tries to conceal their locale by
e.g. making Accept-Language look like vanilla U.S. English, a site
that wants to target users whose browser UI is in a particular
language can still identify these users by making the browser parse
<isindex>.

Thus, removing this feature makes the portability layer of the HTML
parser a bit smaller and makes the HTML parsing algorithm independent
of localization. It is also possible that the removal of the matching
oddity from the form submission algorithm ends up allowing a slight
cleanup of the URL Standard.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266495
Spec bug: https://github.com/whatwg/html/issues/1088
Blink thread: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/14q_I06gwg8/52oBtr2VCAAJ

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Boris Zbarsky]

I think removing this is reasonable at this point....

-Boris

[Tantek Çelik]

Agreed.

Henri, is there a particular release you plan to "unship" this for? -t

On Tue, Apr 26, 2016 at 7:42 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I think removing this is reasonable at this point....
>
> -Boris
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Ehsan Akhgari]

On 2016-04-26 10:42 PM, Boris Zbarsky wrote:
> I think removing this is reasonable at this point....

So... The last time that I personally used the "we're the only engine
shipping this feature, therefore it must be safe to remove" argument for
unshipping something, we ended up breaking a huge number of websites
(see bug 1255139 for details.)

As much as I'd like us to get rid of <isindex> as soon as we can, I
oppose doing so without first measuring its actual usage for Firefox
through telemetry.

This means that we can remove <isindex> a little bit later than what
we'd like, but I think that's justified when evaluating the risk over
potentially breaking websites in ways that cause pain for our users.

Sorry for being the naysayer here. :-)

[Frederik Braun]

Strong agreement for removing <isindex>.

Looking at
<https://www.chromestatus.com/metrics/feature/timeline/popularity/206>,
it seems that Blink was successful in discouraging its use.

[Henri Sivonen]

On Tue, Apr 26, 2016 at 11:57 PM, Tantek Çelik <tan...@cs.stanford.edu> wrote:
> Henri, is there a particular release you plan to "unship" this for? -t

I was thinking of 49, but if we decide we need telemetry, then my
patch will rot and we'll wait for at least until 53.

On Wed, Apr 27, 2016 at 10:18 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> So... The last time that I personally used the "we're the only engine
> shipping this feature, therefore it must be safe to remove" argument for
> unshipping something, we ended up breaking a huge number of websites
> (see bug 1255139 for details.)

IBM enterprise software also generates ISO-2022-KR email...

> As much as I'd like us to get rid of <isindex> as soon as we can, I
> oppose doing so without first measuring its actual usage for Firefox
> through telemetry.

Suppose we measured hitting the isindex special case in form
submission. Would you measure the times we hit it or the session in
which we hit it at least once? What would the baseline be? How would
you decide that whatever the count is is low enough (assuming
non-zero)?

[Johnny Stenback]

Agreed.

- jst

On Tue, Apr 26, 2016 at 7:42 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> I think removing this is reasonable at this point....
>
> -Boris
>

[Ehsan Akhgari]

On Wed, Apr 27, 2016 at 8:54 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> > As much as I'd like us to get rid of <isindex> as soon as we can, I
> > oppose doing so without first measuring its actual usage for Firefox
> > through telemetry.
>
> Suppose we measured hitting the isindex special case in form
> submission. Would you measure the times we hit it or the session in
> which we hit it at least once?

Both are probably worth measuring, so that we can have a good idea whether
a small number of users/pages use this periodically versus a number of
users hitting this frequently.

> What would the baseline be? How would
> you decide that whatever the count is is low enough (assuming
> non-zero)?
>

The point of measuring the usage is mostly to get a sense of whether the
usage of this feature is "infrequent enough". The exact definition of that
depends on our expectation of how infrequently this is used. I understand
that we don't currently have a baseline that we use for removing features,
but that's because we've been very sloppy with regards to unshipping
features. At the very least we need to make sure that a surprisingly large
number of sessions don't run into isindex, right?

--
Ehsan

[Henri Sivonen]

On Thu, May 5, 2016 at 10:55 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> At the very least we need to make sure that a surprisingly large
> number of sessions don't run into isindex, right?

Out of 36.15 million release-channel Firefox 54 sessions examined,
there were 8 (just 8, no multiplier) with at least one isindex form
submission.

The removal corresponding to this intent is in 56.