IE8 has been released today and it comes to my attention that IE8 has been detected as IE6.
Hopefully new browser detection scripts will be released soon to fix this issue.

This is IE8 string on Vista

Back to top

Please take a moment to review the user agent string you posted:



Note that it is seriously corrupted by the embedded bsalsa.com string:


the browser detection script is not smart enough to handle corrupted user agent strings, I suggest you file a bug report with bsalsa.com.

My guess is that bsalsa embeds that string into the standard msie string, which I tested, after removing the buggy bsalsa code:



and which then works exactly as expected.

In general I think it's a bad idea to change highly stable and heavily tested code to handle what is a bug in a tiny niche of the market.

I believe what Windows does is have its useragent string in registry, then a thing like bsalsa injects its own user agent string into that, forming an amalgamated string, mutated and essentially broken, and for data collection purposes, largely useless, unless you are looking specifically for bsalsa stuff, whatever that is.

But thanks for the possible bug report, all are taken seriously, even if they are caused by something unrelated to the browser detection script, as is the case here.
Back to top

The problem is that it is official released version of IE downloaded from windows site:
www.microsoft.com/windows/internet-explorer/default.aspx

I understand that it is probably bug but visitors should do not understand and this bug will be displayed to 100% of IE8 users.
It will be better to find some way around this bug because i do not believe that there will be something changed in future to solve this bug from Windows or bsalsa
Back to top

I disagree with your assessment, that user agent string is most certainly, as I said, the result of that bsalsa thing running in your system.

Again, what occurs is that internet explorer has a user agent string listed in windows registry. That bsalsa thing, which is most definitely NOT a part of windows anything, is injecting its useragent string in after the fact, this is unrelated to windows at all, and is just a bug with that thing.

This isn't related to end users at all, unless your end users all use that bsalsa stuff, whatever it is.

However, since it appears you don't believe me, hopefully you will believe blogs.msdn.com MSIE 8 user agent strings.



This issue is in your computer, not in general user's computers, and it's a bug with the user agent string that bsalsa is sending out, that bug needs to be handled by bsalsa, not this script, I've never even see that product in the wild in 10 years, although I'm sure it exists, of course.

The: SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
part of your string is caused by a few other addons, and are standard, and do not cause problems, because they are done correctly.
Back to top

However, if you want this bug fixed, then I suggest you modify the user agent string detection function to search for bsalsa in the string, and if found and present, to use only the first instance of msie detected. This type of super precise customization is outside of the scope of this script, which is designed to work everywhere, dynamically extracting browser data without requiring manual hacks. This works very well, as long as the string is not corrupted as it is in your sample case.

In pseudocode, what you do is this: in the browser version function, you search the full string for bsalsa, if found, you change the value of the loop to 1, ie, and then make it exit then, which should make it grab the first occurance of msie, 8, and exit prior to the second, 6. However, once you look at that function, you'll also note that it handles a special case for msie already, not to exit on the first found, that's to handle various msie cases where it had the old compatible with first, then the true version second, but newer msie's don't do that. You could make it exit there if the string contains bsalsa as well, break, that is, but again, that's just something for you to play around with, just test for stristr bsalsa if there break at first iteration


The only time I'd think about adding in custom handling is if the msie default, correct, uncorrupted string, was actually also containing two instances of the msie version number, which of course it does not.

I won't add this to the primary function because it's not a general issue, and is caused by an external bug in a tiny niche of the userbase.

Cases like this are when you want to take advantage of the GPL's clear suggestion that all GPL code is free software, which you are free to modify to fit your own purposes.
Back to top

You are right. I have found and removed bsalsa from registry.

Thank you for your time
Back to top

I have the following useragent showing up in our logs, and due to the double compatible thing, it has been blocked.

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET
CLR 2.0.50727; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

I posted here because it seems very similar to the above UA, but without the bsalsa. Can someone tell me, is there any legitimate way this UA could ever come into existence?

In addition, the user claims that the browser he is using is IE6. Is this actually IE8 trying to masquerade as IE6 using registry hacks?
Back to top

Impossible to know, as noted with the above, what a user has done to their system without realizing it by installing some odd tool that was written incorrectly and breaks the registry information is pretty far out of any league we can be in.

Also note it's impossible to test for this, since we have no way of knowing which is the real and which is the bad one, it could be the inner one, or the other one, it's totally random, since it's the result of a programming error in the first place.

However you have a good hint there: OfficeLiveConnector.1.3; OfficeLivePatch.0.0

Personally for my own sites, I never use ie detection except for msie 4, I use the msie conditionals, which are I believe always correct in terms of the browser respecting them, as long as it's msie >=5, at least almost always.

As you can see from the corrupted string, either the user is running xp with msie 6, or he is running vista with msie 8. So you can figure out which for sure by just asking them what operating system they use, vista or xp. Most people know that. The extensions there clearly embedded a false set of data.
Back to top