Persisting User Data Across Visits

Almost every non-trivial website out there is facing a classical problem: persisting user data across visits (also knows as sessions). For your MySpace account, it’s a list of your friends, and that clever joke you put into the profile to help replicate the DNA. For CocktailBuilder, it’s a list of your ingredients and your favorite cocktails. You don’t want to type them in every time, do you?

Now comes the big problem. How do you remember these in a seamless, non-intrusive fashion?

The obvious answer is a login system. Heck, go to myspace, the first thing you see is a logon box. You can’t access almost any of the site’s features without being logged in. Why is that? Because much majority of the site’s information is private (others would get pissed if you saw their mailbox without their permission), so it’s an absolute must to know who the user is before showing them their mailbox.

So, the plus of this approach is relative security of user data. Another plus: you can access your account from any computer. What are the minuses? You know already – you have to register for yet another darn site. Uhhhh. Pick a login. What’s your email. Check that email. Click the link. Your account is now active, please log in. Next time, type the password again. Uhhhhhhh.

What’s the alternative?

Modern, and not-so-modern, browsers provide a feature called “cookies”. Essentially, it’s a way for a website to store a piece of information on a user’s computer, and access it later. All of this can be done seamlessly, without any explicit user action. For example, many websites store tracking cookies on your computer so that they can later on identify you and offer you customized services based on your previous actions.

What’s good? Transparency. Plus it’s reeeally easy to get the desired effect of “hey, they remembered!”. Minuses: cookies are not secure. If you’re a bank, don’t do this. If you’re a bank IT guy, you read this, and you were surprised, please realize that the sky is blue. Cookies can be stolen by other sites, if the browser has a security issue (and browsers have security issues in this area very frequently). Another minus: cookies are an ancient technology. It’s not very pleasant to work with them from JavaScript (you have to serialize your data into a string less than 4KB; I’ll talk about this at a different time). Another minus: cookie data is not accessible on other computers, so you wouldn’t be able to share data between your home and work computers.

There are many websites that go with the third approach – combination of a login system with cookies, so that you only need to log in once a day, and throughout that day, your cookie serves as your identity. Think Amazon: when you come in, you see “Welcome, Bob (or whatever)”. How do they know? The obviously don’t store your IP address, that would be silly (IP addresses change for many consumers relatively frequently). They store a cookie.

So far, for CocktailBuilder, I decided to go with a plain cookies approach. There isn’t any secure data in there – just a list of ingredients and favorite cocktails. Simplicity is key here. Yes, the “travel with my data” feature is missing. I’m not sure of the best way to cover for it.

One idea I had was “send my settings to another computer”, which would generate an email with a hyperlink that has all of the cookie data. User would be able to send this to themself (or a friend), and get all of their settings on another computer. I haven’t thought about this much, do tell me what you think.

Another idea – non-mandatory login system. You want to save your settings – register for an account. You want to load your settings from another computer – log in. Otherwise, everything else is done through cookies.

cb

Cocktail Builder: JavaScript Alcoholic