background image

User Tracking, Sessions and Cookies

Section Feature Image
Posted by atrasatti - 17 Jul 2007
Twitter share icon Facebook share icon Google Plus share icon

User tracking is a very important feature for any web site whether it's for desktop computers, mobile devices, set-top boxes or anything else. When a user visits your site you want to know how long his visit lasted, which contents he visited, what navigation path was followed and so on. This is functionality we have become used to having in most, if not all the web sites. Tracking can be used for many different reasons - what we are going to cover here is focused on navigation sessions.

Transactions are not preserved between HTTP requests, but you often want to let your users to register, login, set preferences and create a session that can store all these information, plus avoid to ask for login and pass at every following request. This also has the advantage of letting you, the site owner, know which contents were requested by a specific user. This is very useful for analytical tools and to generate statistics. There are in general two ways to create and maintain a session on the web, you can send a Cookie or you can use what is normally called URL decoration.

Cookies are supported by every modern programming language and it is very common practice to use them on the web. Cookies are very useful because when you set them you can define an expiration date. One nice feature of Cookies is that if you don't define an expiration time they will be deleted when the browser is closed, this is important if you want to have a certain level of security on your site, when the user wants to quit, the session is closed automatically. The same happens for mobile devices. When you create a session you might also want to store some data in the session, such as the last page visited, the visited items if you are an online shop, etc. You can either send this information to the browser or store it locally, in a database or elsewhere. If you decide to send all the session information to the remote browser you will save space locally, but you might have security issues because the contents of the session might be changed. If you decide to send only the session ID and store all the information locally you are safer, but you have to make an extra effort to save the information. My preference is definitely to store locally for a number of reasons that I will now explain (added to security that came first). First of all there is a technical reason and this is specific to the mobile: mobile devices have limited memory, limited CPU and run on slower networks than desktop computers. Storing only a short string such as session ID reduces all these overheads. This is certainly a best practice. As an added benefit, if you define a long expiration time, users coming back to your site will not need to login again. Again, this is good practice for the mobile because the user will not have to authenticate again (if you are not too concerned about security) and also because you will know that the same user has come back, good for your statistics.

You will be wondering how well Cookies are supported on mobile browsers. The answer is that Cookies are fairly well supported. The OMA has required the support for all WAP 2 browsers and a minimum of 512 Byte should be made available (and this goes back to the hint of store little data in Cookies). Also, WAP Gateways, when used, should act as a proxy for Cookies too, storing them locally if the browser is not able to do so. This should not be the case in modern browsers.

The bottom line is that you can use Cookies with due caution: avoid overloading the browser, or sending 3 or 4 different Cookies, use one if you can and store the rest of the information on the server. If you don't trust Cookies you may use URL decoration. By URL decoration I mean adding a session ID to the URL, this can be done as a parameter or in the URL itself, for example:

As long as you can keep the session ID alphanumeric and the URL is below 256 characters you should NEVER have any problems. The advantage of this solution is that you don't rely on the Cookie support of the browser, but only on the very basic GET request. You will have to store all the information on the server side, of course. Another advantage other than reliability of this practice is that you will be able to track user navigations in the logs of your web-server.

The only disadvantage of this solution, as compared with Cookies, is that the session will end when the browser is closed, unless the user has bookmarked the URL including the session ID. Also, when a user sends a URL to a friend he might at the same time pass his own session.

Posted by atrasatti - 17 Jul 2007

atrasatti's picture

Andrea Trasatti is Director of Technology Strategy at dotMobi where among the other things he is leading the design and development of DeviceAtlas.
Prior to this Andrea has been a system administrator and a software developer for more than 10 years and a consultant for more than 5 years.
In Italy Andrea started developing the first WAP sites in late 1999 when the first WAP phone was about to be released. Since then he has been developing some of the most innovative services for mobile devices.
Andrea has also actively participated to W3C work first as an invited expert and later as author of one of the documents that was published by the Device Descriptions Working Group.

Posted by jamihall 8 years ago

You make it sound as if cookie support on mobile is at the same level as the Web. This is very far from the truth, at least in North America. To begin with, a not insignificant proportion of devices/gateways don't support cookies (or have disabled support). Of those that do, many have buggy support (like not honoring expiration dates, etc). Plus, most carriers have more than just 1 gateway, and many do not share cookie info between them, so it can be a crap shoot which cookies get sent as part of a given session.

Posted by atrasatti 8 years ago

It's true that some operators disable or block cookies using the gateway and that is certainly a BAD practice that they should learn to avoid.

It is also true that US operators are rather on the edge of standards in many cases and don't comply with the requirements of OMA and GSM because either they don't care or simply because they are not using a GSM network.

While I can't say that you are wrong, I still think that Cookies are a good solution. I think that in most markets, for devices that support XHTML or WAP 2, Cookies are supposed to work and developers can create simple "honeypots" to check the support and then decide. This is also the reason why I showed the example of URL decoration.
A good honeypot might be to send a Cookie and also create links with URL decoration, in subsequent hits you can match the Cookie with the parameter you passed and decide what to do.

If you don't like what operators do with gateways you might suggest to your users to configure their mobile device to use an "internet APN" instead of the "WAP APN", when possible. This would be a good way to let operators understand that keeping things closed is not what users want.

Posted by nizzy 7 years ago

I think Andrea's point is that you can utilize the URL decoration to create cookie/session in the server side. In Japan, most of the mobile phones don't support cookie either. However we use .haccess to redirect users to mobile pages with URL decoration idea.

for example:
.htaccess -> redirects users to a unique URL ->

* .xyz123 is unique and this is not the same session id as in the server for security reason, but we map this unique id to session id in a lookup table.

.xyz123 = j6oAOxCWZh/CD723LGeXlf <- this is your session in the server (tmp dir or DB)

This works well for us.