A Security Annoucement

A few hours ago we were alerted to a serious security breach in Handset Detection which allowed authenticated users (anyone logged in) to view and potentially edit any site in the system. No user, billing, payment or contact information was accessible. Only site information. The bug was introduced in a rework of our access control system for a few up coming features, released yesterday afternoon.

We’ve combed the logs and identified that 5 sites were ‘admin viewed’ and only one site was ‘admin edited’, by the person reporting the problem (on their own site). This problem could certainly have been much worse, a fact not lost on us, and we’re thankful that Antony reported the issue as soon as he noticed it.

If you have any queries, concerns or require more information feel free to reach me directly.

Thanks,

Richard Uren
richard@handsetdetection.com

PS : We take the trust you place in us seriously and so have made this blog post in the interests of full disclosure. We hold our ourselves, and our product, to a high standard. When we fall short of that standard its important we let you know.

SEO Friendly Mobile Redirection

Heads up, mobile developers! In a recent blog post, Google announced that they were going to start penalizing sites that are misconfigured for smartphone users (in mobile search)

Problems, Problems

Mobile Search Misconfiguration Errors

Is this where you want to send your Smartphone traffic?

Fortunately, they didn’t leave us hanging, and detailed the two most common smartphone configuration errors, the first of which was the always-frustrating faulty redirect.

This happens when someone clicks a link to your site from search but doesn’t end up on the equivalent page on your site.

Ex: They click http://www.handsetdetection.com/blog because they want to check out your awesome new blog post about variable substitution….

But they end up at http://m.handsetdetection.com instead.

You had a faulty redirect. This creates more work for the user, who now has to search around your home page. If they were already dealing with a slow mobile network to begin with, you’ve already frustrated your potential customer. Not to mention Google’s algorithm. Uh oh.

The Solution

Handset Detection has you covered on faulty redirects with our Variable Substitution feature.

When redirecting to your mobile site from search, Handset Detection can be configured to preserve URL query perimeters. So if someone clicks your “About” page on a search listing, you can send them directly to the mobile version of your About page. No more accidentally routing them to your nice mobile homepage.

To make a long story short, while logged into Handset Detection:

1) Create a website profile
2) Add a redirection rule (such as ismobile is true)
3) In the ‘Redirect to this URL’ field place your url with the substitution eg m.domain.com$path$

This will redirect from www.domain.com/about-us to m.domain.com/about-us and
from www.domain.com/a/b/page.html to m.domain.com/a/b/page.html (It takes the path and substitutes that into the redirected url).

Click here for all the vital details on redirection using variable substitution. Google will smile upon you if you do.

PHP API kit bug effecting Ultimate customers

We’ve just verified a bug in the PHP API kit that effects Ultimate customers. The bug is centered around the php_json function consuming vast amounts of ram to decode the JSON handset specs file. Setting memory_limit to 512M in your php.ini file  (or use the ini_set function) is a workaround solution. We’re looking into the options now and hope to have a solution for you shortly.

Database Maintenance, Small tweaks you might like to know about

An experiment in visual kinetics

Shortly we’ll be making a few changes to our device database to improve device classification and make our naming more straight forward.

First and foremost all generic device profiles will now have the vendor set to Generic. This will mainly impact Android devices which were previously referred to as vendor ‘Android’, model ‘Generic’, now they’ll be vendor : ‘Generic’, model ‘Android x.x Mobile’.  Which is a little more specific than before. In cases where we cannot extract the operating system version (I’m looking at you, Firefox), we’ll report ‘Generic Android Mobile’ or ‘Generic Android Tablet’ without version information.  Example user-agents are :

Mozilla/5.0 (Android; Tablet; rv:17.0) Gecko/17.0 Firefox/17.0
Mozilla/5.0 (Android; Tablet; rv:18.0) Gecko/18.0 Firefox/18.0
Mozilla/5.0 (Android; Tablet; rv:19.0) Gecko/19.0 Firefox/19.0
Opera/9.80 (Android 4.0.4; Linux; Opera Tablet/ADR-1301080958) Presto/2.11.355 Version/12.10
Opera/9.80 (Android 4.1.1; Linux; Opera Tablet/ADR-1212030829) Presto/2.11.355 Version/12.10
Opera/9.80 (Android 2.3.6; Linux; Opera Tablet/ADR-1210241511) Presto/2.11.355 Version/12.10

In the examples above all Firefox devices would return Generic Android Tablet, wile the devices running Opera would return Generic Android 4.0 Tablet, Generic Android 4.1 Tablet, and Generic Android 2.3 Tablet.

Handset Detection has specific detections for Operating System and Browser, so consult those fields if you need more information on the browser, browser version, platform (operating system) or platform version (operating system version).

Additionally many Generic browser device profiles will shortly be removed in favor of the convention above.

Happy Detecting :)

Bug Alert : Stats are showing incorrectly in the dashboard.

Just a quick note and a word of thanks to the folks that mailed in overnight on stats not reporting correctly on the dashboard. Its a bug ! Gah !

The stats inside each site profile are correct, only the aggregate totals on the dashboard are effected. We’ll have it fixed tomorrow, sorry for the hassle folks.

UPDATE : The bug with incorrect usage totals on the dashboard is fixed and the figures now correctly reflect actual usage. Yay ! :)

 

API Kit Maintenance Updates

Last week we found a few bugs in the v1.0 Python API kit and the v3.2 ASP.NET (3.5 & 4.0) API kits.

The bug in the v2.0 Python kit will prevent you from being able to authenticate with Handset Detection, so an update to 1.1 is required. Use Pypi or grab it from the Python Device Detection API Kit downloads page.

The bug in the ASP.NET v3.2 API kits effects only customers using local device detection. Under some conditions ‘x-’ http headers with empty values could cause an exception. See the ASP.NET Device Detection API Kits page for the relevant download files.

Happy Detecting.

Richard

Handset Detection Wants YOU to Help Us Chart Our Course!

We’ve grown by leaps and bounds since our humble beginnings in 2008, but our next step is to make sure we’re growing with our customers. As you see more and more mobile handsets detecting your websites and online stores, you most likely see new challenges and have new questions. That’s why we need to hear from YOU! Take our survey to let us know what you’re looking for an for a chance to get a sneak peek at new Handset Detection features before they go live. Thank you!

Upgrades, Updates & Slight Delays on Stats

Just a quick note : We’re rolling out some minor updates to the analytics system today.  Stats will be delayed by up to 12 hours while the upgrade takes place. Once the database upgrade is finished the system will take around 18 to 24 hours to catch back up. Thanks.

Handset Detection, website update & major upgrades.

Hi, Just a quick note : We’re rolling out some large upgrades over the next few hours. Detections will not be impacted. Site login will be unavailable for an hour and stats will be unavailable for 4 hours while we migrate to a new stats database format. Thanks.

Cheers, Richard

 

Stats delayed up to 36 hours for some sites.

Just a quick note to let you know that some sites are experiencing a delay in stats data, of up to 36 hours in some cases. We’re loading the data up now and the issue should be completely resolved in 24 hours. Sorry for the hassle folks.