Canvas Element Issues

Implementing identicon using canvas uncovered some issues relevant to developers. I'll list them here for discussion:
No Data
Storing data used to render into a canvas directly in canvas is a common use case IMHO. With identicon, I am using the 'title' attribute on canvas element to store the identicon code but it would be nice to have an attribute for this purpose ('data'?).
No Script
Since canvas can't be drawn into unless javascript is enabled, canvas support should be disabled if javascript is disabled. As it is now, fallback doesn't kick in and canvas area appears blank.
Spaced Out
I worked around the No Script issue by wrapping a fallback image inside a 'noscript' element but, since the blank canvas takes up space, both will show next to each other when script is turned off, screwing up layout. While CSS tricks can be used to overlap them, I think unnecessary complications should be avoided if possible.
Active Fallback Unnecessary Get

Firefox fetches resources referenced from canvas fallback content even when canvas is working. My expectation is that it shouldn't do this because, when large number of canvases are used in a page and each had fallback content, page would load very slowly.

Canvas Identicon Deployed

I just deployed the latest version of Daily which uses canvas-based implementation of Identicon. If you use a browser with Canvas element support (Firefox 1.5+, Safari 2.0+, Opera 9.0+), take a look at some of my posts with comments (including the one that started the avalanche if you want to see the rare sight of 400+ canvas elements being rendered on the fly). You'll notice that identicons look much smoother looking now. On IE, it looks the same. I could have used excanvas but I didn't feel it was stable enough.
One thing that puzzles me though is that Firefox 2.0 seems to fetch the URL of image element inside the canvas element when I was expecting that to happen only when canvas support is not available (i.e. no canvas support or when scripting is off). That hurts, particularly for monstrous posts with hundreds of identicons. Currently, I am detecting only problematic canvas support (Safari 2.0) to generate canvas tag without image element within it but it looks like I'll have to do more to emit only the canvas tag if I am going to avoid unnecessary image requests.
Anyway, let me know if you run into any problems seeing identicons. Meanwhile, I am going to spend some quality time with the Identitune idea.
Apparently, identicons are not rendered on javascript-disabled Firefox browsers because canvas support is not disabled when script is disabled. They should spell out expected behavior in the canvas spec. While at it, an attribute for specifying data is needed. For now, I am using title attribute but that feels wrong.
Update 2:
Fixed noscript/canvas issue by adding img version inside noscript tag. Fixed unnecessary img URL fetch in Firefox by skipping fallback img tag inside the canvas tag (this speeds up canvas version load lightening fast, even with 400+ identicons in a page!). I think canvas support in browsers needs to workout these common issues.

Identitune for Visually Impaired?

Just doodling wih ideas like I used to do with rocks and dirt when I was a kid, I am wondering what the aural version of identicon (identitune?) might be like and how it would be generated from random bits? It'll help visually impaired folks to distinguish large numbers but not necessarily text.
Turning a sharp corner, I think identitune could run amok copyrighted melodies. But I like the idea of assigning people, places, and things melodies of their own…

Application Ideas for Identicon

Jason: "I am very tempted to do something similar for mobile phone numbers!" – Great idea. I get cross-eyed when I scroll through my contact lists on my PC as well as my cellphone.
 Dominic Cronin comments: "Perhaps it also makes sense to use this when managing a network with lots of different machines." – Bingo, Dominic! Using identicons instead of using the same PC icons in the list or graph of machines in the network will make it easier to distinguish them.
Using identicons to represent products (i.e. ISBN or SKU) will enhance readability of invoices, shipping list, etc.

I'll update this post as suggestions keep rolling in. 🙂

Some design tips:

Multiple Types of Identicons in a Page

If your use case uses more than one 'class' of identicons within a single page (i.e. wiki page using identicons for names as well as links) then you can help users distinguish different identicon classes by wrapping them with class-specific borders (i.e. circle for people and square for links).

Identicon-based Anti-Phishing Protection

I have come up with a couple of new, simple yet very effective, anti-phishing protection schemes using Identicon. One of them requires client-side support so I am interested in talking to browser vendors to build it into browsers ASAP.
It's main features are:
* dead simple user experience

* no certification infrastructure or black/whitelists used

* protection against DNS-based MITM attacks

* protection against keyloggers
Too good to be true? Well, I was surprised too when the idea hit me like a bullet. It's one of those obvious ideas that hides in the logical blindspots we all share. In a roundabout way, it's related to my idea of using DRM to protect one-time passwords but very different once it hatched.
Anyway, if you are a browser vendor, contact me.
Heck, I am just going to share the idea with the world because I want to see it implemented before yesterday.  

    <h4>Gemini </h4>
            The idea, which I am calling Gemini  for reasons explained below, is to: <em>Use the User&apos;s Password to Authenticate the Server.</em>
         A user&apos;s password is a shared secret which only the user and the server knows. So the server can use it to authenticate itself to the user, by sending a derivative of the password to the user. For example, if the server sent something like <strong>SHA1(password + host_ip + time)</strong> to the client where time is truncated to account for clock difference and the client did the same, two values must match if the server is authentic. <em>The crazy idea of sending the password to the user was the logical blindspot I mentioned. I walked into this idea when I started with the idea of broadcasting passwords. Yes, I am indeed crazy. LOL.</em>  
         The idea is called Gemini because, instead of comparing digested values, identicon images created from digested values are compared visually side-by-side by the user. If the identicons, one from the server and another rendered by the client, are placed either inside or near the password input box, users can easily compare the two before typing the password in. If the two identicons don&apos;t match, then either the server is a phishing site or there is a MITM (proxy will have the same effect).<br><br>Gemini identicons won&apos;t match if there is an intermediary, like a MITM or proxy, between the client and the server because host&apos;s IP address is used to build the identicon. DNS-tricks don&apos;t work because the MITM don&apos;t know the password.<br><br>The overriding assumption here is that the client is managing the passwords, each associated with a host name so the correct password can be selected and used to render the client version of the identicode. Since all popular browsers of today have this capability built-in, all they are missing is the Gemini functionality. For protection against keyloggers, I would add one-click keystroke-less password submission as well.<br><br>Gemini does change the user experience because, in order for the server to build its identicon, it needs the user&apos;s name. If Bank of America&apos;s SiteKey deployment is of any indication, this is not a significant issue.<br><br>Another gotcha is that browser&apos;s identicon has to be authenticated to the user. This can be done by rendering a randomly selected desktop-specific frame around the identicons being compared, like some of those exotic chinese seals have unique looking borders. Simple square or a circle drawn with unique line/gap pattern and color will look great I think.
   Although I was part of the team that built the technology behind SiteKey and feel that it is one of the best anti-phishing solutions out there, I frankly think Gemini is the superior solution. But if any of you see any holes or issues with Gemini, I would appreciate hearing about it. After all, I could be a butterfly hallucinating.
 Speaking of hallucinating butterfly, the reverse of Gemini is interesting too although it appears to be only a slight variation of the usual hashed password method. The only difference is that client&apos;s IP is thrown in to stop the MITM. 
If it is the client that sends the user name and <strong>SHA1(password + client_ip + time)</strong> to the server then the server can check (using the same algorithm) to authenticate the user. This reduces the need for login UI to a single OK/Cancel box and both the phisite site and the MITM can&apos;t do much with the hashed password it captures because:
1. reversing hashed password into password is impractical.
2. hashed password can&apos;t be used because client IP address would differ.
3. replay becomes irrelevant. 
One weakness I can see is the client-based malware somehow getting at the passwords stored on the client, but that can be addressed if the OS uses proper access control.
                        Thinking more about this, this scheme can be reduced to using following three factors:
1. Something the user knows or has: password
2. Something the user uses to access: IP
3. Something no one has control over: time
Re phishing, note that there is no need to authenticate the server to the user in this Butterfly scheme. Although a phishing site can theoretically emulate a website&apos;s secured area to capture sensitive information at some later point, displaying information only the true site posseses can be used to implicitly authenticate the server. 

Seeking New Client

Speaking of client-side, I can now take on a new client. If your company* has interesting projects (it really doesn't matter in what area, what matters is creativity and dexterity) and have the budget to hire a heavy hitter, let's talk.
* EMC and divisions of EMC are not welcome without a letter of apology from their CEO.