“(…) There have been recent improvements in the browser. Things like the
canvas tag in the latest generation of browsers”

Martin Kliehm has kindly offered me the opportunity to participate in
a dual presentation at the next SXSW to talk about canvas and
demonstrate some interesting uses.

If you are interested in the canvas element, you can cast your vote for
this presentation (until August 29). And while you’re at it, you might also want to cast your vote
for canvas support in IE8 (although it seems to be useless by now)

In the end it wasn’t the best environment to do the tests since it was impossible
for me to split the actual rendering time of the polygons and the rest
of the processes of the map code. In any case, I leave the experiment
for you to see.

One of the main reasons I started to play with this technology was that while I was trying to port a previous SVG experiment, I noticed it had quite a few cross browser issues. The final result with canvas was quite
satisfactory and it gave me the chance to learn features beyond the
basics such as drag and drop, event handlers and performance
optimization.

Since that experiment in October my interests and prototypes in Canvas
have been more and more challenging: Skewing techniques, VR emulation,
polygon rendering, etc. There’s a bunch of code to release though I am
not allowed to release all of it right now. But I will do my best.

Update: Due to the interest and enhancement requests from friends and colleagues, I have created a project page where you can contribute and add items to the to do list.

Update 2: Check the Flickr and Picasa integration from Michael Johnston and Pamela Fox respectively.

// Snippet 1
x = 4;
function init() {
 alert(x);
 var x = x;
 alert(x);
}
init();
	

// Snippet 2
x = 4;
function init() {
 alert(x);
 // var x = x;
 alert(x);
}
init();
	

See the answer

With that said I will leave the code here for anyone who wants to spend more time playing with it or provide some feedback.

Source code

1 - Goode homolosine

This projection belongs to the equal-area projection category, which means it tries to represent countries in their correct proportional size.
I think the first well known app using it was 43places.com.

For a long time, this map made in flash was the main map of the 43places application so the users were able to select countries and see which ones were visited, ‘want to visit’, etc. From my point of view this map was the best choice. However, they later switched to google maps maybe because of the specificity of the markers. Although you still can access the flash version from its users’ profile.

2 - Robinson

This one belongs (among other categories) to the compromised projection ones. Its goal is to find a balance between different kinds of distortions.

That representation can be seen everywhere in the Wikipedia.

3 - Peters

Probably the most popular of the Cyllindrical Equal-Area. However, similar projections like Behrmann or Hobo-Dyer make the countries look less strange. They all differ in the ratio of the vertical to horizontal axis, especially close to the pole areas

I haven’t found any web app using them though.

4 - Mercator

Also called ‘evil mercator’ since it’s the worst one in terms of distortion of the countries. Greenland is 554% bigger than its real size, Canada 258%, USA 68%, etc.

It’s still commonly used in a lot of places. For instance, google maps uses it. Although my guess is that 95% of the use of google maps is not at the world view zoom level.

I have never been in the acknowledgments of a book before.

Ross Harmes from Yahoo! and Dustin Diaz from Google decided about a year ago to write a book about Javascript Design Patterns. As I have the honor of being on the team of the former, I was pleased to offer my feedback on his excellent lessons. Although one wonders who needs technical feedback when the beast Simon Willison is already doing that.

Javascript, being the first mainstream lambda language, has its very own features. It well deserves a good training not only to write better code but to use all the potential of the language. This book will really help you in both aspects and it will make your path easier to the mastery of the language.

If I feel happy to be mentioned in the book, I can’t imagine how proud Ross and Dustin must feel to be the authors after months of work. In fact, it’s a feeling that is worth a try.

Congratulations guys!

In this article we will try to prove that some practices in current web apps have important privacy and security issues both for the user and for the application. To illustrate these issues better we will first analyze the patterns that the main Web 2.0 companies have used when implementing the ‘user registration process’. Then, we will go over some of the aspects of the process, such as authentication flow, email confirmation, captchas and sharing information with third parties. This will hopefully help you decide which practices you should use when implementing your app.

50 apps

Before you write a single line of code you will have to make some high-level decisions that determine what features you will need in the user registration. If you are planning on building several applications, you’d better review the user registration requirements for each of them, instead of reusing the same code and patterns for all of them.

Most of the apps in the following table have millions of users registered. In order to handle such a large number of users, they had to change some old school strategies and adopt new ones. For instance, in order to avoid the user picking a username that is not available, they suggest that the user use an email address as username (due to its uniqueness). Also, in order to attract as many users as possible, they try to minimize the registration process to a one step registration process (if possible). As we will see, if we apply the two previous concepts the wrong way the result can create some security or privacy flaws.

Authentication flow

Case 1: confirmation: no. login: email.

This pattern includes the apps that send a confirmation email to the user but allow the user to login and use the app anyway, even if they haven’t gone through the confirmation process.

This practice allows any user to use a non-confirmed email as his unique username. That means if I happen to know Bill Gates‘ email, for instance, then I will be able to use his email as my username in all these apps; at the same time, he won’t be able to register with his own email. In some cases the apps might have a system for expiring those non-confirmed accounts but we only found one case where this was explicitly shown to the user (imeem.com):

“You have 10 days left to verify your email.”

One of the solutions used by some apps goes as follows:
The user is able to access the app but only the more basic features. As soon as the user tries to perform any advanced action, or one that implies the use of the email (like recovering your password) then they are asked to confirm the email address. This approach is not enough to solve the initial drawback. The potential real owner of the email is still blocked from registering with his own email.

Fig 1. Used as login.

Case 2: confirmation: no (blocking). login: username.

In this case we seem to be preventing some possible identity theft issues. The problem, though, is that many of these applications save the given email coupled with the profile data, thus not allowing a new user (maybe the real owner) to register with an email that has already been used before:

“Sorry but this email is already in use”.

This shouldn’t happen unless the owner of the email address has performed some sort of confirmation.

Case 3: confirmation: no (no blocking). login: username.

This is the same case as the previous one, with one difference: the registration process allows the new registrant to use an email that has already been used before.
The email shouldn’t be relevant to any part of the application. If it is, the user should be forced to confirm the email address as soon as they use any feature related to it, such as notifications and reminders. Also, the email should not be publicly visible in the user’s profile until it is confirmed.

Case 4: confirmation: yes. login: email/username.

This is the best practice so far. The user is registered in a two-step process. They fill in the form and then confirm the registration by clicking on the provided link in an email. There are two bad things about this pattern. The first one is obvious: the user will have to go through a longer process than the one-step registration. The second issue is explained in the next section.

Fig 2. Email confirmation.

Confirmation process.

As we have seen in the last case, once we fill in the form an email is sent to our inbox with a confirmation link that completes the registration process. In some cases, an auto-generated password or username will be sent in the email instead of a link (i.e. stumbleupon.com). The goal in both cases is to prove that the user owns a given email account.

We can draw a parallel here to the public key cryptography:

Fig 3. Public-key Cryptography [Source: Wikipedia]

“The most important thing to know about public key cryptography is that unlike earlier cryptographic systems, it relies not on a single key (a password or a secret “code”), but on two keys. These keys are numbers that are mathematically related in such a way that if either key is used to encrypt a message, the other key must be used to decrypt it. (…) By making one of the keys available publicly (a public key) and keeping the other key private (a private key), a person can prove that he or she holds the private key simply by encrypting a message. If the message can be decrypted using the public key, the person must have used the private key to encrypt the message.” [Source: The globus alliance]

In our case, the email address is the public key that we share with the app to send us a message with an exclusive link for us in it. We will be the only ones to read it (”decrypting it”), by accessing our email account through the email password (the private key). Clicking on the link will prove us as the owner.

The problem is if we misspelled the email in the initial form. This is something that has happened to everyone at least once. In that case the email confirmation will be sent to another (potentially existing) account. If the owner of this other account completes the process, then they will be able to access the application and the data stored in our profile that we have input in the initial form. They will be also able to perform the password recovery. That’s why some apps ask you to type your email twice, as if it were a password.

Fortunately, none of the apps that we analyzed ask you for confidential data, like the street where you live or your phone number. But most of them ask you for your zip code, your date of birth or your full name. These data can also be considered sensitive for the privacy of the user and can be misused by the fake user.

It’s clear that something needs to be changed in the authentication flow to ensure that anyone who wrongly gets the password isn’t able to login into the account so easily.

Accessing a third party’s contact list

There is another practice with quite a few applications: After the registration is done, the app will allow the user to import their contacts from other accounts (gmail, hotmail, etc.). In this situation the interface should be very unobtrusive to the user. It’s very important to make the user confident that all their privacy issues are under control. The truth is that asking for the user data from a third party account is aggressive enough.

There are some apps that need to give a clearer message that none of this information will be stored for any use other than import the contacts in the actual process. More importantly, a ’skip this step’ message, if it exists, should be very noticeable (instead of being the very small letter at the bottom of the page) so that the user can have the freedom to decide whether or not to commit this process.

As an example of a bad practice we have Tagged.com, which uses a very aggressive method: after finishing the registration process, we are redirected to the ‘add contacts from third parties’ process. In this stage we are not provided with any link that allows us to skip the form. There is no link to go back to the home page, and not even the main company logo is linkable.

Captcha

There are still quite a few apps that don’t prevent spambots from automatically registering with their sites. Surprisingly, those that do use captchas sometimes use the same image for every registration page in the same process. That is the case when the user fills any form field incorrectly and the application gives the user another opportunity to do it. This is a really bad practice since, in order to deter spambots, a given captcha image should be shown only once, and it should always be changed to a new image if an incorrect response is given.

Fig 4. Use of captcha.

User privacy

Web application companies will eventually have a huge amount of users registered, if they are popular. The companies store the user data in their databases. PrivacyInternational.org recently released an excellent study about privacy practices of key Internet based companies. They analyze details like data retention, responsiveness, ethical compass and many others.

In our case, we will focus in those elements presented to the user in the initial form of the registration process. In this step of the process the company needs to be as transparent as possible to the user, giving them easy access to the terms of service and privacy policy documents. As the pie chart indicates there is still a 24% of apps that don’t clearly provide the user any link or information to the privacy policy or the terms of service in the sign up form. On top of that, those that do provide this information (76%) don’t necessarily do it in an active way. 31% of them don’t include a check box so the user can select and explicitly accept the company policies or their terms of services in order to complete the sign up process.

Fig 5. Display of TOS/PP.

Alternatives

As we have seen in this article, we as web developers have to foresee every kind of action our users are able to perform with the choices we give them. We have to test and prevent all possible hacks and errors. Check if these actions have poor security or privacy issues for the user and fix them. With all these principles in mind it’s evident that the patterns used for most of the current well-known apps are not completely prepared for that.

Some alternatives like OpenID and OAuth are coming up with their open specification to try to change the current paradigms. Each of them, though, are meant to solve different issues:

“While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts). (…) OAuth talks about getting users to grant access while OpenID talks about making sure the users are really who they say they are.” [Source: OAuth.net - about]

That means that while OpenID is an alternative of the four different authentication flows we analyzed, OAuth would take care about the ‘Accessing the third party’s contact list‘ issue we have seen before.

OAuth released a draft so apps can use a common protocol instead of different proprietary protocols used so far for the same purpose (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API, etc). OpenID has been available longer but, unfortunately, only one out of the fifty analyzed apps (mag.nolia.com) showed very clearly, in its registration process, the ability to use OpenID (with a big OpenID logo). Not even livejournal.com, who is an OpenID provider, had it as visible as it should be.