According to the data in the spec, this is a method that IE and Mozilla implement that always returns false. Probably safe to add.

Checked in as WHATWG revision r8039.
Check-in comment: navigator.taintEnabled()
http://html5.org/tools/web-apps-tracker?from=8038&to=8039

It turns out it's probably not so safe to add, as it is being used for browser sniffing. So Gecko needs to have it, but Blink/WebKit needs to not have it. :-(

https://code.google.com/p/chromium/issues/detail?id=451979

Since the spec allows variation in navigator.userAgent and some other properties on navigator that is necessary due to browser sniffing, it would make sense to me to also allow variation in whether navigator.taintEnabled is present or not.

Can you have a look at httparchive data to get an idea of the percentage of sites that do something with navigator.taintEnabled? If that number is too high to convince Gecko of attempting removal again, an analysis of the consequences if supported by Blink would be nice, although time-consuming to do.

Pages matching \btaintEnabled\b anywhere (page's HTML, iframes, external CSS/JS):

SELECT page, COUNT(*) as num
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE REGEXP_MATCH(body, r"\btaintEnabled\b")
GROUP BY page
ORDER BY num desc;

3693 rows.

Total number of pages:

SELECT page, COUNT(*) as num
FROM [httparchive:runs.2014_08_15_requests_body]
WHERE page = url
GROUP BY page
ORDER BY num desc;

129236

So ~2.86% of the pages.

(In reply to Philip Jägenstedt from comment #4)
> If that number is too
> high to convince Gecko of attempting removal again, an analysis of the
> consequences if supported by Blink would be nice, although time-consuming to
> do.

Do you have any bright ideas on how to do that?

I used https://addons.opera.com/sv/extensions/details/violent-monkey/?display=en to define navigator.taintEnabled = function() { return false; }; and loaded the first 40 URLs of the httparchive matches. They all appeared to load fine, but obviously some functionality might have been broken.

I did some IE testing. IE6 and IE11 have navigator.taintEnabled() returning false, and I presume IE7-10 do as well. However, in IE12 Tech Preview with Experimental Web Platform Features enabled, i.e. Edge mode with the Chrome-like UA string, navigator.taintEnabled is gone.

Assuming this change reaches IE12 stable, I don't think it makes any sense for any non-Gecko engine to attempt adding navigator.taintEnabled(). If Gecko is still unable to remove it, this would be a very sad situation.

(In reply to Simon Pieters from comment #6)
> (In reply to Philip Jägenstedt from comment #4)
> > If that number is too
> > high to convince Gecko of attempting removal again, an analysis of the
> > consequences if supported by Blink would be nice, although time-consuming to
> > do.
> 
> Do you have any bright ideas on how to do that?
> 
> I used
> https://addons.opera.com/sv/extensions/details/violent-monkey/?display=en to
> define navigator.taintEnabled = function() { return false; }; and loaded the
> first 40 URLs of the httparchive matches. They all appeared to load fine,
> but obviously some functionality might have been broken.

I'd categorize the 3693 matches into groups of duplicates and look at the largest groups first. I had a quick peek and it looks like the biggest group is MooTools 1.2.x and that unfortunately it just sets window.webkit so that one would have to look for places where that is used, which is hard using grep...

(In reply to Philip Jägenstedt from comment #7)
> Assuming this change reaches IE12 stable, I don't think it makes any sense
> for any non-Gecko engine to attempt adding navigator.taintEnabled().

Agreed.

So is the request here to drop taintEnabled()?

I'm not sure what the spec needs to say, I commented on the Mozilla bug to get more feedback:
https://bugzilla.mozilla.org/show_bug.cgi?id=679971#c73

I did a bit more categorizing of the 20141115 httparchive data, and it really is dominated by various incarnations of MooTools, mostly these two patterns:

window.xpath = !!(document.evaluate);
if (window.ActiveXObject) window.ie = window[window.XMLHttpRequest ? 'ie7' : 'ie6'] = true;
else if (document.childNodes && !document.all && !navigator.taintEnabled) window.webkit = window[window.xpath ? 'webkit420' : 'webkit419'] = true;
else if (document.getBoxObjectFor != null) window.gecko = true;

and

if (window.opera) Client.engine.name = 'opera';
else if (window.ActiveXObject) Client.engine = {'name': 'ie', 'version': (Client.features.xhr) ? 7 : 6};
else if (!navigator.taintEnabled) Client.engine = {'name': 'webkit', 'version': (Client.features.xpath) ? 420 : 419};
else if (document.getBoxObjectFor != null) Client.engine.name = 'gecko';

This is where it changed:
https://github.com/mootools/mootools-core/commit/c053361b7fec3ec454e622ba389fb2be0475f563

I also found the "document.childNodes && !document.all && !navigator.taintEnabled" pattern in other seemingly non-MooTools code.

Gecko dropped getBoxObjectFor in 2009 <https://bugzilla.mozilla.org/show_bug.cgi?id=340571> so Firefox is actually ending up in the unknown bucket with both scripts. Presumably, then, not being WebKit is the critical part.

Great. The compat constraint is then probably something like:
(navigator.userAgent.indexOf("WebKit")!=-1)==(!navigator.taintEnabled)

Bah.

isn't "!navigator.taintEnabled" true regardless?

"!navigator.taintEnabled" is only true if taintEnabled isn't implemented at all, which it needs to be in order to avoid being identified as WebKit.

This bug really needs input from Mozilla, but nobody reacted when I commented in https://bugzilla.mozilla.org/show_bug.cgi?id=679971

Boris, do you have any good ideas how to resolve this, or could you CC someone at Mozilla who might care about this issue?

So our (Mozilla's) point of view is that we tried removing this once.  We got tons of breakage: see the dependencies of https://bugzilla.mozilla.org/show_bug.cgi?id=679971

Once burned, twice shy; we're a bit leery of removing this again...  The potential win, if any, doesn't seem to be worth the likely compat problems.

But yes, what we ran into is pages detecting "is webkit" using !taintEnabled and then doing webkit-specific hacks and workarounds.  You proposed compat constraint from comment 12 seems spot-on to me, assuming there's a compat constraint at all.

Of course at this point, given Spartan, Gecko is just about the only UA which doesn't have "WebKit" in the UA string....

Thanks, Boris. I agree that it doesn't seem sensible for Gecko to try removing taintEnabled given the way it is used.

Perhaps the best thing would be for the spec to have a note explaining that we're currently locked into a non-interoperable state for taintEnabled() with no credible path forward.

Oh I see, people do "!navigator.taintEnabled", not "!navigator.taintEnabled()".

The way forward here is to make all the other ways in which Gecko and WebKit differ go away, so that you get the same result whichever codepath you go down, I guess...

> The way forward here is to make all the other ways in which Gecko and WebKit
> differ go away

The only way to do that web-compatibly is to also make the UA strings match, unfortunately.  There are sites that depend on UA sniffing plus differences in handling of some invalid-per-spec constructs (e.g. functions in blocks in JS) that break if either browser changes to the other's behavior without changing the UA string to match.

How likely all this is to happen... Yeah.

I think the situation we are in is that there are many incompatibilities required for compat, where changing only one of them breaks things, but changing the whole group (navigator.vendor, navigator.userAgent, navigator.taintEnabled, etc., etc.) would work.

The only hope I can see is to align on those bits that aren't constrained by sniffing, but it's not obvious that we can remove them quicker than they accumulate, as obviously it's not only prefixed things that are being used for sniffing.

Well we should definitely all have the same UA string (or no UA string). UA strings are a terrible idea.

If there's a set of things that we can all change at once, it would make sense to work out what that set is and then change them all at once...

In order to stop UA string proliferation we would need to find an alternative to error reporting and analytics. If some proportion of your users is hitting JavaScript exceptions in your Web app, knowing which browser they're using is a good first step. Also, no browser would be willing to be be the first to merge into another on StatCounter or caniuse.com.

A replacement would have to make it very hard to use the analytics to change any behavior, which means it can't really be exposed while the user is still interacting with the Web app. I haven't come up with anything that would really work though. :/

For what it's worth, I'm making this method [Exposed=Window] only in Gecko, so it's gone in workers.

(In reply to Philip Jägenstedt from comment #12)
> Great. The compat constraint is then probably something like:
> (navigator.userAgent.indexOf("WebKit")!=-1)==(!navigator.taintEnabled)

(In reply to Boris Zbarsky from comment #22)
> For what it's worth, I'm making this method [Exposed=Window] only in Gecko,
> so it's gone in workers.

I've made the relevant test expect the above in web-platform-tests in
https://critic.hoppipolla.co.uk/r/3840

I don't think we should wait until all browsers identify as WebKit (or align in some other way) before fixing this, as that might never happen. It seems more helpful for implementors right now to bake in "do you identify as WebKit?" in the spec, IMO.

In https://github.com/whatwg/html/pull/207 I am introducing the concept of "navigator compatibility mode" to document the dependencies between the different attributes on NavigatorID, things that seems safe to change all at once, but not one by one. As part of that, I've made it such that only UAs that use the "Gecko" mode should have taintEnabled(), as I can't see a way to actually converge further without reducing the number of modes, which would mean saying that Gecko should start masquerading as Chrome, like Edge does.

That fix is now live.