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™".

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

Thanks Luit for the information, I have fixed it.

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?

And another question: what would this be called as a software algorithm? Is it a binary tree walk?

Yes, I did this as well. Was quite easy on my phone.

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.

One way to get a good strong secret key for this purpose:

$ python

>>> import os

>>> os.urandom(64)

You shouldn't use urandom for crypto purposes. /dev/random is generated (on most platforms) as cryptographic strength numbers (usually from hardware), but can block if it runs out of data. /dev/urandom was created with the guarantee to never block and will use /dev/random's pool of numbers initially but can start outputting lower entropy numbers if /dev/random blocks.

/dev/random is better than urandom for this sort of thing. On linux:

dd if=/dev/random bs=64 count=1 2>/dev/null | hexdump

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.

You advise to "fork it", but immediately after that you add the notorious "do not write your own" meme. Can you see the inconsistency of the messages?

Part of security is being up-to-date in regards to things like hashes. If authors don't update their own libraries and you need to tweak them manually, how is it different from "writing your own"?

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.

I always thought the advice against "writing your own" spoke of the algorithm itself, not a library around the algorithm.

Nope. Google Keyczar: standard algorithms; still screwed up. You should always use the highest level interface available.

It shouldn't be more than changing those two lines:

https://github.com/mitsuhiko/itsdangerous/blob/59f3bf7877e21...

And the tests, of course.

My point exactly! Armin (the maker/maintainer of the module) will probably consider doing this somewhere in the future.

I just pushed out a release that makes it possible to override the digest in a subclass easier.

While overrideability is good, wouldn't it be better to also be 'secure by default'? I'd imagine that SHA-2 would be more sensible default for most users.

IMO there's one missing from the list of alternatives: Markdrop (http://www.markdrop.com/) (http://news.ycombinator.com/item?id=3089355)

I've added it now. Thanks.