Samsung Instinct Issue (and possibly other phones?)

May 23, 2009 at 5:24 PM

My team is working on a mobile site for a client using ASP.NET MVC and device detection using the MDBF. In most cases, the data we're getting from the file is working exactly as desired, but there is one case (that might be broader than we personally know) that I wanted to bring up since I believe that the MDBF might need some tweaks to support scenarios like this (again, not knowing how broad they are). It's possible that there's a fix I'm not seeing, so please let me know if that's the case.

The site that we have created targets three classes of device: iPhone/iPodTouch, SmartPhone (Blackberries, Windows Mobile, etc) and Standard Phones (Phones that do not support CSS, etc.). One of the dividing line properties that we are using in the Request.Browser object to distinguish between type 2 and type 3 phones is "SupportsCSS." Our rationale is that if your browser reports no support for CSS, you get the bare-bones text and few images version of the site.

As I said, this works well for the large majority of devices that we have tested on to date. One notable exception has been the Samsung Instinct on Sprint.

One of our clients uses the Instinct to load the test version of this site, and has reported that she is being directed to the Standard phone (bare-bones) site, when, rightly so, she expected to see the SmartPhone site. Upon investigation, we discovered that the Browser file was reporting that her phone did not support CSS, when in fact it does. We had her hit a device capture site that we've created and obtained the following User Agent from her phone:

Mozilla/4.1 (U; BREW 3.1.5; en-US; Teleca/Q05A/INT)

No mention of device or manufacturer at all in this string. I poked around in the browser file and toted that the device entries are looking for keywords like "Samsung," "SPH-," etc. in the RegEx match statements. That's not at all surprising, and what I expected to see. What was surprising was that the Samsung Instinct is sending a User Agent that provides no reliable method of correlating said User Agent to a particular device or class of devices. The use of Teleca/Q05A/INT seems to be unique among known User Agents, but that's a browser entry, not anything that would authoritatively identify the device over time.

I did a bit more poking around and I discovered that the Samsung Instinct uses two different "modes" when browsing the web: "Standard Mode" and "Mobile Mode." Apparently, in order to provide a near-equivalent to the iPhone experience of loaded zoomed-out versions of full web-sites, Samsung introduced "Standard mode" as a way to allow the user of the phone to access web sites as through a desktop browser. As such, the User Agent string above is what is sent by the Instinct in Standard Mode, which also happens to be the default on the phone. Here's what's sent in Mobile Mode:

TELECA-/2.0 (BREW 3.1.5; U; EN-US;SAMSUNG; SPH-M800; Teleca/Q05A/INT) MMP/2.0 Profile/MIDP-2.1 Configuration/CLDC-1.1

There's enough there for the Browser file to properly seed device capabilities. So in mobile mode, the user gets the enhanced site.

I find it interesting that, though the Samsung is trying to use a bare User Agent to trick browsers into thinking it's not a mobile device, Request.Browser.IsMobileDevice is still set as true. Were it false, the user would get the SmartPhone view (which is the desktop default) instead of the standard view. I assume that this is because of the reference to Teleca, or is it because the file obtains no match from this string and is simply seeding Request.Browser with default values?

Here's my bottom line question: Is there a way to modify the MDBF to set IsMobileDevice to false when UA's like this are provided? (I assume that Samsung/Teleca will be doing more of the Standard/Mobile shenanigans in the future, meaning this issue might become larger over time) Or does the Instinct need an enhanced entry to support these scenarios.

Thanks for your help, for the great work on the MDBF and for taking the time to read this lengthy post.

Jun 4, 2009 at 11:30 AM


Brilliant, thank you very much for the detailed description of the issue. We are working to add support for Teleca browser to our .browser files in an upcoming release.

It is great to get such feedback and we really appreciate it. We’ve seen a number of new devices try this trick of switching UA strings to try and force PC style page to be delivered by the web browser. It does raise a number of interesting questions – what if the browser / device simply can not render the PC page (runs out of memory) ?, is it still important to know that this is a mobile device? – e.g. to offer additional mobile services ?, should the content publisher be able to determine the experience the user sees or should the user be able to state that they want the PC site ? – is this better done via a website option or via the mobile device ?

Keep the feedback coming, and indeed let us know if you have any views on the questions above.