It's still sandboxed and deleted when the user clears private data for the website.
The main advantage it has over things like cookies, local storage, etc. is that it provides a byte-oriented, random access API and as a result, you can use third-party libraries like SQLite that expect a file API. Which is more important now that we have tools like Emscripten and WebAssembly that let you use existing C libraries on the web. At the same time it has security guarantees such that webpages cannot write arbitrary files that will be viewed and executed by the user.
Also, in theory you could use this side-channel attack on localStorage and sessionStorage. Its only requirement is that it needs an API that writes to disk where you can measure the latency of a synchronous call, since the fingerprinting is just measuring the interference pattern between disk accesses the attacking website does vs. disk accesses that other websites do.
You literally can't make a website from the 2000's nowadays, because that means you want a 800px fixed width layout or something of sort.
If you do that, your website will look absolutely gorgeous since the 800px width + precise pointer + hover requirement allows you to get rid of all unnecessary whitespace, explain the UI with tooltips, and guarantees you always have enough width for one sidebar, but it won't be responsive.
The real solution to the modern web is to destroy all mobile devices on the planet.
My short experience with Claude and ChatGPT via web is that:
1. the way GPT writes is simply fundamentally annoying. I pretty much had to create a project with a file that said "do not use headings, lists or emojis" to make it bearable. It feels like, as a product, this sort of thing should be a general preference the user sets before they even start talking to a chatbot.
2. Claude just loves wasting tokens doing things nobody asked for. You ask "how do I calculate the distance between 2 points?" and it's probably going to compile some C code in the background with tests to make sure it works, then generate an interactive diagram on the fly to show how the math works, and then give you a downloadable file with the code. Like, dude, I just want some text. Why are you doing all of this?
Both of these problems come from the obvious lack of any UI controls in the software. there is no way for the user to know what sorts of things the software can do, because it's not exposed via UI as a checkbox like "generate interactive diagram" or "avoid using emojis." Discoverability is burning tokens to figure out what prompts work, or looking at example prompts the developer placed in the welcome screen.
I just feel it's completely ridiculous how LLM's are essentially the culmination of a trajectory of bad UI practices masquerading as "good UX" and now they're being implemented everywhere because people think it's good UX a blank textbox where you don't even know what you're supposed to type to do something.
You can't run Node on embedded systems, because there isn't enough memory.
A compiled zig program can be only several kilobytes with no depedenencies.
Array access programmed in low-level languages can be optimized with SIMD and parallelization, which will be orders of magnitude faster than the same thing on Javascript. Text processing, image manipulation, video processing, hashing, etc.
There is like infinite reasons to not use Javascript.
