Perhaps slightly off-topic: The name, GmailSharedTasks, doesn't look like one that Google's legal department would agree with. Your brand/product name incorporates a Google trademark. It might have been better to call it "SharedTasks for Google Tasks™" or "SharedTasks for Gmail™".
I see some just found the piece of JavaScript that registered the handlers, and others found lists by those people, but...
did anyone else find the codes manually? I did. I quickly realised that it'd break off the code as soon as it couldn't lead to a match, greatly reducing the search space (which was only 256 options to begin with).
As soon as I noticed that, I worked out all the codes by hand in only 15 minutes (including playing with the experiments I found).
I just iterated through the search space (starting at all zeroes, counting up in binary) and eliminated whole sets of numbers as soon as it broke off the input. e.g. starting with all zeroes it breaks off at the third zero, meaning anything under 00100000 was impossible (immediately eliminating 32 of those 256 options in my search).
Did anyone else do that too? Perhaps more interesting: did anyone have a completely different approach?
A slightly more interesting approach: find out all non-overlapping ranges you need to test, and then run the fair-and-square generator, testing each to check in which of the ranges it should be put, finally combining the sub-ranges to make the ranges asked for. My (not particularly optimized) Go solution ran through the C-large-1.in set in 3 odd seconds.
I agree I'm a bit inconsistent, but the library is well written, and exchanging the hashing function is a trivial task. That's not really quite "writing your own". I just mean to discourage people who aren't 100% sure they know what they're doing.
I strongly agree with Armin: HMAC-SHA1 (note, the combo, it's not just the latter) is still good security for most applications you'd consider this library for.
Well then fork it and make it use HMAC with SHA256/512... Additionally, "Do not use this module" is bad advice if it leads to someone making their own MAC implementation, because that's almost always a bad idea. HMAC-SHA1 still is good security for this purpose.
I bet that as soon as standards bodies (like NIST) actively encourage you to use better hash functions (which they will probably do soon) the developer of this module will decide on what is safe enough for this purpose.
See "I'm a developer and used Google's developer products/tools to create a new product. Can I use the Google name?" on http://www.google.com/permissions/faq.html