> Does anything suggest that it is?
Read the website.
173 karma · joined January 15, 2026
Read the website.
You mean the one guy who prompts Claude?
I don't see anything business related in that statement.
What's this new level of gaslighting? "It was not because of me, but because of the business situation I was in". Wait... wasn't he in that "business situation" because of actions HE took?
You don't need it if you have everything allocated upfront. TigerBeetle does this, everybody else can.
Using something like Rust is already a huge win when compared to shipping a browser or running Node.js.
> Your argument falls flat when a page file can be multi-GB and automatically grow
This doesn't solve the original issue and only masks the underlying problem.
Same happens if the page file is full. In that case, why don't those programs use disk directly instead?
No such problem would've ever occured if programs hadn't allocated more than they actually use.
I run Firefox, VSCodium with LSP, Discord, Signal and there's still space left for a game like CS2. I'm not a heavy user by any means.
> I'm not sure they would do much better than crash
I have yet to see a program that silently handles allocation failures and doesn't crash. These days everything is coded to crash if no memory :(
> About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed
In my case it killed system critical processes with no way to recover. With disabled overcommit, it freezes for a while (usually for a minute or two), I close some random program of my choosing and then see in Resource Monitor what's eating my ram.
Unfortunately, many programs commit 2x memory than they actually use. Often I see ~32GB committed and ~16GB resident.
Most likely they still would've been kicked, but without being detained.
It's always this one exact excuse. They were simply "following orders". The police don't have their own brains capable of thinking.
I never claimed so. Please stop stating I said something when I didn't.
> as a general purpose hash table
That's what I claimed. The question IS about hash tables. If you want a hash table of any content, it's impossible to get faster. Unless you check all possible keys at once - only this will get you faster.
Which ones? Websites that ship no JavaScript? All browsers support this.
> can in some cases completely break sessions
Or you can just remove local storage from window and have it just for yourself, which seems what Discord is doing as well.
Attackers cannot use local storage because there is no local storage on the window object.
> A separate attack vector for the same problem
It's not exactly the same problem. The example you mentioned is a footgun because you don't vendor your dependencies. Deliberately giving someone else access to your website is an issue in itself.
Local storage was released more than 16 years ago, and back then PHP was wayy too popular. XSS is almost impossible to execute these days (unless you do selfxss).
Discord has mitigations for grabbing the token from local storage: https://news.ycombinator.com/item?id=48563286
True. However it's not impossible to mitigate that: https://news.ycombinator.com/item?id=48563286
But arguably it's harder to do so.
> this doesn't protect from supply chain attacks
It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)
> unsafe-eval
Technically speaking, nothing prevents you from shipping a JS-in-JS runtime that proxies objects and bypasses eval, which is just eval without eval.
> when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token
No reason to have a dedicated CSRF token because your local storage token already works as a CSRF token.
> A lot of times local storage is much less secure
Without XSS, local storage is actually more secure. You don't have worry 'did I set up this right' because there is nothing to set up and CSRF is impossible to execute.
If you're still paranoid about XSS, CSP is your friend. Also check isTrusted on events.
First time I'm hearing that frameworks require disabling HttpOnly.
> Disabling iframes doesn't fix CSRF. You can still <form method="..." /> or <img /> tags or whatever.
Obviously. IMG tags don't work because of CORS (unless you explicitly allow this) nor script tags etc. Browsers send Origin and Sec-Fetch- headers which you can use to block POST navigation requests from other origins, like you mentioned.
But when you're using tokens in JavaScript then you don't have to worry because you already have your CSRF token, which is inaccessible to third parties and no form submit will include it. That's why local storage is more secure.
See https://news.ycombinator.com/item?id=48574402
> So are they moved to a simple variable then?
Yup, it has to exist somewhere.
What happens if you lose power? You're logged out because it didn't save the token back. Verified this by pausing JS execution and killing Firefox. (the local storage key is "token")
Is it? If an attacker can't do XSS then it's as strong as cookies.
Supply chain attacks aren't an argument here because they can also happen with cookies. CSRF as well. The same can happen in actual executable binaries.
I don't get the 20 yr age argument:
- HttpOnly fights XSS which is impossible to execute with modern frontend frameworks.
- SameSite fights CSRF but the real solution is to disable loading the website in iframes (remember clickjacking?).
- Secure fights MITM which is already fixed by default when using local storage and HSTS is the real deal.
Having said that, I'd say that local storage is more secure than cookies (no need to remember whether you put Secure on or not). Unless you're still using PHP, which means touch grass.