This feels more like a server-side bug than a client one. Checking the source of the page, I saw this: <input type=hidden name="fnid" value="qQcI2u8r4K"> Is this an field to protect against CSRF? Is the server-side bit of info to check this just dropped over time?
Yes, the fnids are the culprit, and they are user-specific continuation functions. There's a rich history of discussion about them on HN. Aside from engineering our way out of them, we can extend the number that can be cached before being culled, or we can decrease the instances of them. We can do both. They are over utilized on Hubski. In my early days, I would generate them willy-nilly, now it's my goal to wind them down to a minimum. I'll bump up the number, and start picking some low hanging fruit.
Hoping that's not a security hole if I spoof a random fnid that belongs to someone else... Wouldn't it make more sense to couple the storage time of the functions to a specified timeout? Or alternatively, couple one ID to a page, so you don't generate one for each comment for each view? As is, it seems like a 10x increase in traffic would mean a 10x decrease in the time before the fnids expire. It might cause memory issues, but that could be easily fixed by firing up more servers (Not sure what your opinion is on The Cloud)
https://news.ycombinator.com/item?id=639976 Some of the fnids do have timeouts, and that's one of a number of ways to alleviate this. We are currently "in The Cloud", on a Ubuntu server at Digital Ocean. We used to be on Linode, which has great service, but DO has SSD, and that has huge advantages with Hubski's unusual architecture.Hoping that's not a security hole if I spoof a random fnid that belongs to someone else...
Wouldn't it make more sense to couple the storage time of the functions to a specified timeout?
Both awesome and worrisome. No post from pg on there, did they patch HN (Slash how did they) to fix the security hole? Does hubski have the same fix applied? Dunno if increasing the length of the fnid / cookie would help if your PRNG has been compromised...
Yeah, really impressive. Not sure about HN, but we use the Arc3 rand-string. pg did respond. I'm still looking into what else might have been a part of it.