localStorage is very much fine and arguably superior to cookies for authentication tokens. First of all, once you have achieved JS execution on a target origin, you can send requests, open up malicious "login" prompts and generally control everything the user sees and does. The article mentions this, but plays it down with no good arguments.
Much more importantly however, is that the cookie standards are a mess! The complexity of cookie default behaviour, their flags, scopes, differences in their SOP (cookies ignore ports for example, so https://example.com:443 and https://example.com:8443 share their cookies) are huge. Research papers have been written in this. And don't even get started on differentials between browsing engines.
This huge complexity of cookies opens up a whole class of authentication attacks where bad (or just weirdly) configured cookies can be stolen cross origin.
localStorage on the other hand is practically impossible to get wrong.
You can never guarantee that the codepath of a dependency that is vulnerable can not be reached or used as a gadget in an exploit chain. Patching dependencies, even when no direct vulnerability arises is an essential part of defense in depth and sevurity hygene.
> So what would a secure implementation of this feature look like? The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
First of all, its not CORS that protects. CORS is an anti-security feature. What does protect is the SOP (same origin policy). The SOP (or SOPs rather, it's not really one feature but more of a paradigm in the standards) blocks documents from one origin, from reading data that belongs to another origin. This is the reason why `let w = window.open("https://example.com"); console.dir(w.document.body);` will work when it is ran from example.com, but not wikipedia.org. Only when protocol, host and port match, can documents access each others data (there is an interesting differential with cookies here, their SOP only looks at protocol and host, not port).
Importantly, the SOP only blocks reading data from other origins, not writing! So while example.com won't be able to read the response of a post request it sends to wikipedia.org, the request is sent and processed nontheless!
CORS now is a feature that allows sites to loosen up the SOP. This allows documents to read cross origin data nontheless. Namely, HTTP responses. (Standards for reading other kinds of data cross origin exist, but are not related to CORS).
No, it's exactly the other way around. The SOP protects you from these security issues. CORS is a feature that can be used to loosen up the SOP, to allow more complex inter-application behaviour.
Algorithms are also improving. I believe it's very unlikely for these two improvements together to not result in one to two orders of magnitude cheaper cost per "intelligence". Of course, that might just make use cases that are too expensive today viable and thereby increase usage further.
LLMs don't tend to help much when solving challenges beyond their skill level. Either they one-shot a challenge, or thei are almost useless as a companion for them.
It is a hard requirement. Once you reach higher levels of challenges you spend most of your time reading through RFCs, web sepcs, Github issues, mailing lists, papers, random bugtrackers and library/framework code. There is no way to create a whitelist for that. Besides, a firewall won't stop good hackers.
It is definetly cheaper now. What I want to say with this, is that token costs rising so dramatically that AI usage becomes uneconomical is not a high probability future. Even if AI subscriptions were sold heavily below cost (which is also unlikely, after R&D).
Self hosting at a reasonable scale is much cheaper than people think. I am running clusters of DGX Spark machines with BiFrost load balancers in our company and for client projects. They work flawlessly!
128 GB unified memory, Nvidia chip and ARM CPU for just around 3k€ net. They easily push ~400 input and ~100 output tokens per second per device on say gpt-oss-120b. With two devices in a cluster, thats enough performance for >20 concurrent RAG users or >3 "AI augmented" developers.
The party is called the "Christian Democratic Party" but in practice pushes no christian policies. 47% of germans are legally atheists. Only 5% regularly visit mass.
vLLM isn't suitable for people running LLMs side-by-side with regular applications on their PC. It is very good at hosting LLMs for production on dedicated servers. For the prod usecase ollama/llamacpp are practically useless (but that's ok - it's not the projects goal to be).
Northdata [1] does basically this, but mostly ingests European data currently. Perhaps they will expand to ingest US data as well at some point. Not affiliated with them in any way. I just use them to look into company structures every now and again.