Archived

This topic is now archived and is closed to further replies.

AaronX

pc issue Maxthon delivering different user agents

5 posts in this topic

I've found an oddity in Maxthon whilst working on my own website. I have not customised the user agent, and Maxthon has been doing this for a long time - it's not a new issue at all, but I'm only now looking into it in detail.

When browsing normally, Maxthon delivers the following user agent: 

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 Maxthon/5.2.1.3000

However, when I follow a link from Google search results - either natively on Google or from the Google Customised Search embedded in the site - the following user agent is reported:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Note both a different Chrome version, and lack of the Maxthon version bit.

 

The only clue I have as to how or why this is occurring is that Google search results do of course redirect your click through Google's system for tracking, rather than being a plain, direct HREF going straight to the end page. I wonder if it could be something to do with how Maxthon handles header redirection?

1 person likes this

Share this post


Link to post
Share on other sites

it's a "feature". They use it to get around sites that check the UA for browser/blink version. Most sites will still work without issue on older versions, but you get blocked if they don't detect a particular version.

Google sites do this a lot, so it's not unusual that any link via google would have a different UA.

One thing that i'm now curious about is whether this is done locally, or if the URL is sent to MX servers then checked then the "modified" UA is sent to the client which then uses that to send to the site requested. Something to look into.

Share this post


Link to post
Share on other sites
21 minutes ago, 7twenty said:

it's a "feature". They use it to get around sites that check the UA for browser/blink version. Most sites will still work without issue on older versions, but you get blocked if they don't detect a particular version.

Google sites do this a lot, so it's not unusual that any link via google would have a different UA.

One thing that i'm now curious about is whether this is done locally, or if the URL is sent to MX servers then checked then the "modified" UA is sent to the client which then uses that to send to the site requested. Something to look into.

Thanks for this response, 7twenty. Very interesting, and a good further question indeed. Makes me wonder why they don't simply update Blink or spoof the version number consistently? I shall perhaps experiment later and see if a custom UA string makes any difference, although I suspect not.

1 person likes this

Share this post


Link to post
Share on other sites
1 minute ago, AaronX said:

why they don't simply update Blink

whatever they do takes them some time to get it to work with the way MX works apparently. MX isn't like all the other chrome clones where they can simply update the core and push out a new release. That's why it's always behind.

2 minutes ago, AaronX said:

or spoof the version number consistently

Good question, but i guess then you have the question, if they're spoofing that, then what other dodgy things are they doing?

3 minutes ago, AaronX said:

see if a custom UA string makes any difference

No, the MX defined site specific UA takes precedence over any local version.

1 person likes this

Share this post


Link to post
Share on other sites
10 hours ago, 7twenty said:

whatever they do takes them some time to get it to work with the way MX works apparently. MX isn't like all the other chrome clones where they can simply update the core and push out a new release. That's why it's always behind.

I suspected as much. Maybe they'll work out a quicker update process in future. Pity, but heyho.

Share this post


Link to post
Share on other sites