22555 2013-07-03 14:34:30 +0000 navigator.taintEnabled() 2015-09-30 11:49:28 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED P3 normal Unsorted 22406 1 ian ian bzbarsky ian mike philipj zcorpan contributor oldest_to_newest 90226 0 ian 2013-07-03 14:34:30 +0000 Examine whether and how many browsers implement navigator.taintEnabled. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=679971 90232 1 ian 2013-07-03 14:48:05 +0000 According to the data in the spec, this is a method that IE and Mozilla implement that always returns false. Probably safe to add. 90456 2 contributor 2013-07-09 05:17:07 +0000 Checked in as WHATWG revision r8039. Check-in comment: navigator.taintEnabled() http://html5.org/tools/web-apps-tracker?from=8038&to=8039 117509 3 zcorpan 2015-01-27 13:54:20 +0000 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. 117519 4 philipj 2015-01-27 17:20:54 +0000 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. 117531 5 zcorpan 2015-01-28 08:20:26 +0000 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. 117533 6 zcorpan 2015-01-28 09:07:01 +0000 (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. 117535 7 philipj 2015-01-28 10:40:25 +0000 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. 117536 8 philipj 2015-01-28 10:44:09 +0000 (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... 117553 9 zcorpan 2015-01-28 12:54:59 +0000 (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. 117608 10 ian 2015-01-29 23:08:06 +0000 So is the request here to drop taintEnabled()? 117612 11 philipj 2015-01-30 04:31:18 +0000 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 117617 12 philipj 2015-01-30 09:14:52 +0000 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. 118286 13 ian 2015-03-04 19:05:49 +0000 isn't "!navigator.taintEnabled" true regardless? 118338 14 philipj 2015-03-05 05:02:42 +0000 "!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? 118340 15 bzbarsky 2015-03-05 05:16:16 +0000 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.... 118344 16 philipj 2015-03-05 06:50:17 +0000 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. 119084 17 ian 2015-03-30 20:47:31 +0000 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... 119113 18 bzbarsky 2015-03-30 23:44:17 +0000 > 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. 119122 19 philipj 2015-03-31 05:54:25 +0000 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. 119318 20 ian 2015-04-07 22:03:37 +0000 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... 119367 21 philipj 2015-04-08 15:30:22 +0000 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. :/ 119549 22 bzbarsky 2015-04-15 22:15:26 +0000 For what it's worth, I'm making this method [Exposed=Window] only in Gecko, so it's gone in workers. 119620 23 zcorpan 2015-04-17 08:26:08 +0000 (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. 123367 24 philipj 2015-09-30 09:39:45 +0000 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. 123375 25 philipj 2015-09-30 11:49:28 +0000 That fix is now live.