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.