Intent to Implement and Ship: navigator.vendor as the empty string

[Philip Jägenstedt]

Contact emails

phi...@opera.com

Spec

No spec, just this HTML spec bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27786

Summary

Let navigator.vendor always return "".

I understand that this is potentially disruptive to analytics and browser engine detection, but please interpret charitably and consider all options.

Motivation

navigator.vendor is currently "Google Inc." by default, but can be overridden at build time. Some Chromium-based browsers do:

Opera: "Opera Software ASA" (also has OPR/* in UA string)

Yandex: "Yandex" (also has YaBrowser/* in UA string)

Cốc Cốc: "Coc Coc" (also has coc_coc_browser/* in UA string)

But some don't. I've tested some Samsung and HTC Android phones and the desktop browsers Comodo Dragon, Sogou and Baidu, all of which say "Google Inc."

I was asked to look into this as part of an effort to reduce the number of gratuitous differences between Google Chrome and Opera. We could simply revert back to "Google Inc.", but even better would be to align with Firefox and IE, which use the empty string. Left alone, the likely long-term outcome is for navigator.vendor to become petrified as "Apple Computer, Inc." or "Google Inc." just like navigator.product is now the constant "Gecko" and navigator.appName is "Netscape" in all browsers I've tested.

Compatibility Risk

navigator.vendor is used on ~8% of page views:

https://www.chromestatus.com/metrics/feature/timeline/popularity/124

This is a lot, and there's no way to measure how the string is used, but there are two other ways to attack the problem:

Existing content

I've looked at the 20141115 httparchive data and found 32688 resources including the string "navigator.vendor" in 218557 archived pages, in other words ~15% of pages have "navigator.vendor" in some resource. I've tried to categorize them using grep and other command line tools:

12861 are definitely unreachable, mostly on the form "navigator.userAgent || navigator.vendor".

5145 are copies of a script that has since been taken down:

http://web.archive.org/web/20131126221928/http://www.quirksmode.org/js/detect.html

It doesn't check for "Google" so there will be no impact.

2423 are Google analytics which does "isChrome=navigator.vendor=='Google Inc.'" This ought not cause any user-observable breakage, but it will have to be updated to not skew the stats.

1642 are vce_st.js which has a check for Safari that wouldn't be affected.

1354 are JW Player 5.x checking for Apple. (JW Player doesn't do that any longer.)

1234 are KISSmetrics which hashes together various bits, which should merely become less unique, not break anything.

630 are raphael.js working around an old bug that won't be affected:

https://github.com/DmitryBaranovskiy/raphael/blob/5234aa33d04be07b0fea7627504ab4b53d872e19/raphael.js#L3057

411 are webtrekk analytics making some pretty fragile assumptions that look like they won't cause total breakage, but we'd need to notify them if we make the change.

389 are a "css helper" which checks for Apple only.

221 are incapsula analytics which put some bits in a cookie before loading an image, so maybe the server side does something with the information.

201 are "BrowserDetection" code that does this:

e.isChrome = function() {

  return null !== this.isChromeCache ? this.isChromeCache : (this.isChromeCache = void 0 !== window.chrome && "Opera Software ASA" != navigator.vendor, this.isChromeCache)

}

There would be no impact for Google Chrome, but Opera would start getting the same code path as other Chromium-based browser, which is good!

180 are variants of what is now Fine Uploader:

https://github.com/FineUploader/fine-uploader/blob/8b6ca26006bd789400549a4037e3a0a62771f4f4/client/js/util.js#L539

It looks like this only ends up being exposed for users of the library as "folderDrop" and "uploadViaPaste", but I couldn't find a single use of either. I filed an issue anyway:

https://github.com/FineUploader/fine-uploader/issues/1346

168 are SpryMenuBar which checks for Apple and KDE only.

113 are Gomez, which does "navigator.vendor || navigator.appName" but never checks for Google. I think it ends up in a cookie.

111 are userreport.js which checks for Apple only.

The list goes on with categories totaling <100, but with nothing really interesting that I can see.

1455 uncategorized resources remain which say google somewhere. To get an idea, I inspected 10 random cases and found none that would be troublesome.

To summarize, the httparchive data makes it look quite possible that the Web does not yet depend on "Google" in navigator.vendor to a significant degree.

Other browsers

The fact that multiple vendors are successfully shipping Chromium-based browsers without "Google" in navigator.vendor suggests that the user-facing impact is at least tolerable. In our internal bug tracker, I have found one case of breakage, in a library called UDM:

http://www.udm4.com/demos/horizontal-relative-left.php

It's broken in Opera, Yandex and Coc Coc. One affected site is https://www.ippc.no/ippc/, the other has been fixed already. If we make the change, we should try to find more sites using this script and give them a warning. I couldn't find any other users in the httparchive data.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug?

https://crbug.com/276813 is a bug to drop navigator.vendor, which isn't what I propose, but that's where the discussion has been.

Link to entry on the feature dashboard

None.

Requesting approval to ship?

Yes. Some amount of trouble is likely, so I suggest making the change now (right after the branch point) to give it maximum time before reaching stable. If we find some serious breakage where outreach fails before reaching stable, we should delay for a release or two. If there's a *lot* of breakage we should reconsider entirely.

[Philip Rogers]

There's a decent amount of compatibility risk here and I don't see strong reasons for changing it in your proposal. Navigator.vendor is, as you point out, useless, but it's one of the few areas where browser cross-compatibility isn't a strong motivator.

[Dirk Pranke]

It seems like it would be interesting to run an experiment w/ this to see if changing it to the empty string actually broke anything.

-- Dirk

[Philip Jägenstedt]

The temptation to change navigator.vendor seems to be strong when
there's a company name in there, as at least Google, Opera, Yandex and
Coc Coc have done it. If we can align with IE and Firefox with modest
risk and effort, then navigator.vendor will be in a stable state and
(more) interoperable, which seems like a long-term win. The empty
string also clearly communicates that it isn't reliable.

Philip

[Philip Jägenstedt]

Bruno pointed out two additional browsers in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27786#c23:

Maxthon: "Maxthon Asia Ltd." (also has Maxthon/* in UA string)
WhiteHat Aviator: "WhiteHat Security Inc." (also has WhiteHat
Aviator/* in UA string)

Philip

[Daniel Bratell]

On Tue, 13 Jan 2015 22:18:04 +0100, Philip Jägenstedt <phi...@opera.com> wrote:

Compatibility Risk

navigator.vendor is used on ~8% of page views:

https://www.chromestatus.com/metrics/feature/timeline/popularity/124

How are extensions counted here? We had a few hits in Opera extensions (few enough to easily handle manually), but if an extension can make the use count be increased on every site, that could contribute a lot to the 8%.

/Daniel

[Philip Jägenstedt]

AFAICT, use counters will by default apply in all context, at least
flexbox has been explicitly split into three and have sane-looking
data:
https://www.chromestatus.com/metrics/feature/timeline/popularity/61 :(
https://www.chromestatus.com/metrics/feature/timeline/popularity/62
https://www.chromestatus.com/metrics/feature/timeline/popularity/63

Philip

[Philip Rogers]

I manually went through a random sampling of the remaining 1455 cases and I agree that this will likely not affect users. I hope we can focus more on things that benefit our users, but I'm no longer worried about the impact of this.

LGTM

[Philip Jägenstedt]

Did you manage to reproduce the same categorization that I got, or how
did you pick a sample?
https://gist.github.com/foolip/fe103b5b139e08c187c8 is the list of my
1455 uncertain cases (duplicates removed) if anyone wants to take a
peek.

I certainly agree that this will at best go unnoticed by Google Chrome
users, but thought it worth a try to eliminate this source of
incompatibility once and for all. If it is noticed we'll have to
re-evaluate and maybe Opera will simply return "Google Inc." instead.

Philip

[Chris Harrelson]

LGTM, but skeptical like pdr@ of the impact.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Nico Weber]

Since analytics packages use this to detect Chrome, what other technique do you recommend they use instead?

[Константин Никитин]

Hi, Philip!

 

We had recently opened an issue in where.js (https://github.com/AntouanK/where.js/issues/1) because our Vendor was not recognised, and that was the reason of problems with some sites. I think that 8% is too much.

 

But in my opinion in the future all of the browsers will behave absolutely equal and there will be no reason to determine a browser vendor :-)

 

 

14.01.2015, 00:18, "Philip Jägenstedt" <phi...@opera.com>:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

 

-- 
With all the best wishes,
Konstantin Nikitin,
software engineer Yandex LLC.
+7 903 0072726

 

[Chris Harrelson]

On Fri Jan 16 2015 at 10:47:24 AM Константин Никитин <stro...@yandex-team.ru> wrote:

Hi, Philip!

 

We had recently opened an issue in where.js (https://github.com/AntouanK/where.js/issues/1) because our Vendor was not recognised, and that was the reason of problems with some sites. I think that 8% is too much.

 

But in my opinion in the future all of the browsers will behave absolutely equal and there will be no reason to determine a browser vendor :-)

I don't buy that specific argument. Analytics of various kinds segmented by browser make sense. Browsers will inevitably have differences between them that are important to understand.

My assumption in the LGTM above is that navigator.vendor is not necessary for analytics. This is Nico's question however, which it would be good to get a clear answer to.

Chris

[Philip Jägenstedt]

Yes, analytics is important, and navigator.vendor can currently be
used to differentiate Chrome from some Chromium-based browsers.

Fortunately, Opera and the other Chromium-based browsers that tweak
navigator.vendor that I tested also add some token to the UA string.
What Bruno in the spec bug did was to exclude all the tokens that
Chrome is known to include. If there's anything left, it's not Chrome,
you don't need to list all the specific non-Chrome browsers to
determine that. Like anything based on the ever-mutating UA string, it
may change in the future.

If we fail to change navigator.vendor to the empty string for compat
reasons, then I will recommend that Opera revert to "Google Inc." to
fix those very problems, joining Dragon/Sogou/Baidu in making
navigator.vendor an unreliable indicator of the actual vendor. At
least I have no better plan B right now.

If the objective is to tell Google Chrome from a browser that doesn't
tweak navigator.vendor or the UA string, I think at best one could
identify specific differences on a browser-by-browser basis. The
English-language Baidu browser is in that category, but I just tested
the Chinese one and it includes BIDUBrowser/7.0. The English version
just seems very stale, I guess it'll be fixed eventually.

Philip

[Philip Jägenstedt]

On Fri, Jan 16, 2015 at 7:47 PM, Константин Никитин <stro...@yandex-team.ru> wrote:
> Hi, Philip!
>  
> We had recently opened an issue in where.js
> (https://github.com/AntouanK/where.js/issues/1) because our Vendor was not
> recognised, and that was the reason of problems with some sites.

Did the fix actually improve the situation? Per your comment, you are now identified as Yandex, not Chrome. The problematic sites were presumably checking for Chrome? If this intent passes, I'll make sure to raise an issue on where.js and suggest a fix.

Also, can you name the problematic sites, off-list if you like?

> I think that 8% is too much.

Yes, but 8% isn't a good estimate of the actual risk. The *potentially* problematic cases in the httparchive sample (Google analytics, webtrekk, incapsula, Fine Uploader and the 1455 uncategorized) amount to about ~0.02% of pages, although it's not weighted for page popularity. 

> But in my opinion in the future all of the browsers will behave absolutely
> equal and there will be no reason to determine a browser vendor :-)

I think the only way that will happen is if only one browser survives and it then stops being developed :-(

Philip

[Nico Weber]

On Fri, Jan 16, 2015 at 12:08 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Yes, analytics is important, and navigator.vendor can currently be
used to differentiate Chrome from some Chromium-based browsers.

Fortunately, Opera and the other Chromium-based browsers that tweak
navigator.vendor that I tested also add some token to the UA string.

It sounds like you're saying that it's better to have varying UA strings and empty vendor strings instead of all chromium-based browsers having the same UA string and different vendor strings. Did I get that right? Why do you think so?

[hexan...@gmail.com]

On Friday, January 16, 2015 at 10:30:07 AM UTC-8, Nico Weber wrote:

Since analytics packages use this to detect Chrome, what other technique do you recommend they use instead.

I suppose you mean Blink, because detecting *Google's* Chrome is almost impossible to detect. A blink browser called Epic doesn't identify itself in neither UA or vendor so that's a very difficult task, that ever I can barely attempt to do.

This would be a short way of detecting blink at the moment: http://stackoverflow.com/a/20866141/1647538

The long way is the way I do it. But there are no short snippets for that.

I can attest here that there are no standards or recommendations in place from Google. So I think the policy of blink browsers should go like this: Unless you modify or fork the rendering engine in a distinct manner, keep the vendor of the entity making the engine, and/or put a window.chrome object for sites that historically rely on that.  Any other forks of AppleWebkit that I know of, keep 'Apple Inc.' Or if it's fork then put you own entity as vendor in order to make that distinction clear.

I have argued a need for a navigator.engine token on the WHATWG thread. But I think i might a swell scream to a deaf hear.

I see no strong reason why blink engine browsers should have a different vendor than Chrome's. And apparently no one here has thought this through ahead of time (which I initially thought would have been the case). That said, I still oppose the removal of 'Google Inc.' to an empty string because of my extensive time spent in browser detection.

While it is not 100% necessary to detect Blink and I could see myself not relying on it. But I do believe it makes analytics much harder on the long term, and could possibly be even more prone for mistakes for average developers. What was/is slightly broken here is the lack of initial thinking on the blink devs' part. But I take issue rewriting the history of 'Google Inc.'s vendor in the middle of nowhere like that.

[Philip Jägenstedt]

I'm honestly not sure which of those two options would be better in the long term, but the options I've considered are different UA and vendor strings vs. different UA strings but the same vendor string. As for the same UA string but different vendor strings, only the UA string is sent in an HTTP header and it is certainly much more common in analytics, so changing it seems a lot more disruptive. It would eradicate Opera from server request logs, unless a new ever-mutating Vendor header is introduced...

Philip

[Philip Rogers]

I apologize for the delay as I've been out a bit recently.

I hear some of hexanet's concerns. What if we remove the WEBCORE_NAVIGATOR_VENDOR option entirely and default all ports to the existing constant along with a comment explaining why? This will address the initial concerns about compat differences between blink-based browsers, but leave a wart for future engines (like "like Gecko"). I don't like having a specific company name in there but it sounds like this would be the best option for users today.

[Philip Jägenstedt]

Very well, I'm not getting the support I need for an empty vendor
string, so let's go with the second best thing and freeze it forever
as "Google Inc." That solves the concrete problem Opera has and
changes nothing for Chrome. I'll notify the other Chromium-based
browsers of the change, in case they really want to tweak the vendor
string they can still do so of course.

Review at https://codereview.chromium.org/896463002

Thanks all for your feedback!

Philip