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.
Update:
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.
Update:
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.
 
<hr>
<strong>Butterfly</strong>
 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. 
               <hr>
                    

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.

Client-side Canvas-based Identicon Released

Suggestion from Wes Felter and a good cup of coffee prompted me to write an implementation of Identicon using the canvas tag. If you are using a browser with canvas tag support (i.e. Firefox), take a look at the Identicon Canvas Test page. If not, the screenshot below will have to do because the example falls back to server-side identicon. I am going to hold off on deploying on my blog until I figure out how to get around a Safari canvas-related bug.

 <p align="center"><img src="//www.docuverse.com/blog/donpark/files/identicon_canvas_test%5B5%5D.gif" alt="" width="407" height="224"> </p>
 FYI, updated <a href="//www.docuverse.com/blog/donpark/files/identicon_0_3_src.zip">Identicon source package</a> (version 0.3) includes the canvas implementation code. You can take a look at the javascript <a href="//www.docuverse.com/blog/donpark/files/identicon_canvas.js">here</a>. As you can see from the example and javascript file, identicon code is stored in canvas title attribute. Kinda funky but *shrug* it works.

Feel free to use this at your own website. 

Identicon: Third-Party Implementations

Third-party implementations and variations of Identicon are starting to appear. I'll add to this post as they appear.

    If you have an implementation or a variation of identicon, comment to this post to get added to this list.<br><br>
    To encourage others, I&apos;ve just uploaded <a href="//www.docuverse.com/blog/donpark/files/identicon_0_2_java_src.zip">Identicon version 0.2 source code</a> which has following changes:
           1. Cleaned up and refactored to remove unnecessary crap and simplified flow for improved readability. 
           2. Documented. I am still not happy with the level of documentation but at least it&apos;s getting better. 
           3. Description of how identicon is rendered from a previous post is included in doc folder.
           4. Fixed a color-related bug. This means your identicon color will be slightly different.
           5. IdenticonCache interface added to allow caching identicons. IdenticonServlet will check the cache if the full class name is provided using &apos;cacheProvider&apos; init-parameter. 
           6. Runtime jar file (com.docuverse.identicon.jar) is included.
         Enjoy.
         PS: Until I fix the dang CSS bug caused by indented blocks, you&apos;ll see some odd layout problems.
          
          
        

Identicon Explained

To help people undersand why and what of identicon, I hoisted up one of my comment to previous posts.
I originally came up with this idea to be used as an easy means of visually distinguishing multiple units of information, anything that can be reduced to bits. It's not just IPs but also people, places, and things.
IMHO, too much of the web what we read are textual or numeric information which are not easy to distinguish at a glance when they are jumbled up together. So I think adding visual identifiers will make the user experience much more enjoyable.
I think identicons have many use cases. One use is embedding them in wiki pages to identify authors. Another is using them in CRM to identify customers. I can go on and on. It's not just about IP addresses but information that tends to move in 'herds'.