Whoa, whoa. Putting the state from the closure in the url is not the same as putting the closure in the url.

But you are still likely to want to sign the state so you can tell if it has been corrupted (or deliberately doctored) and reject it if so.

Sign or sanity check, whichever you prefer. Personally in a simple interface like this site I'd rather sanity check the few simple parameters.

It's not a druthers kind of thing. If you need to trust that it hasn't been tampered with you must sign it.

And if you don't care you might as well not add authentication because without signing it's just a fancy CRC - ie, totally replicable by an attacker. As cookies and links are sent over TCP there should be vanishingly few errors in transmission - you're far more likely to introduce false positives with buggy code, and ...

You need to sanity check your inputs anyways. Just do it. This is also how you avoid bugs normally.

I'm not sure what your argument is.

Yes if you want to trust it you have to sign it and make sure you implement all the crypto correctly. But I don't see a need for that here.

Also TCP's checksum sucks.

You said "sign or sanity check it", as if you can do whichever you want. But in the area suggested they have vast differences and security implications.

How many corrupted web pages do you see because of CRC failure in TCP?

I wouldn't call it a closure unless it has something like a "next-instruction" field, which is probably enough to get control - and certainly enough to do nasty things (think 'debug-mode, 'restart-server, 'shutdown.)

The PLT-Scheme (aka Racket) folks do this. Its kind of awesome, and I used it for a side project. It works pretty well except some browsers have a max url length, so you can only safely shove so much data to the client side, and then your stuck with old fashion IDs again. Still lots of fun to play with :)

In a scary way