Side channel stuff. If it takes longer to reject an HMAC depending on the matching prefix, you can use that to figure out the correct HMAC. For instance, if I have an expired token, I can change the duration and createdAt. The HMAC won't check out, but I repeatedly try `000000...`, `010000...`, `020000...`, ..., `ff0000...`. Repeat each of those enough times to get rid of noise, and the one that is rejected slowest is likely the correct first byte. Say it's `42`. Then I repeat with `42000000...`, `42010000...`, ..., `42ff0000...`. That gets the second byte. Repeat until I have the entire HMAC by doing linear work instead of exponential.

Changing the actual contents of the cookie is probably more a nuisance since it's encrypted, but the point of the HMAC was to provide integrity.

I believe this particular XOR thing is the usual constant-time buffer comparison people use, but, again, I don't actually know much about crypto code. Also it's sensitive to how V8 might happen to optimize it, hence the comment about ideally doing it in C.

`buf[i]` and `buf.readUInt8(i)` is probably the same? I actually didn't know `buf[i]` worked. I assume they do the same thing.