4 ms·

If you would've told anyone in the year 2000 that it'd become standard practice to blindly execute programs sent to you by anonymous people you don't know you'd

If you would've told anyone in the year 2000 that it'd become standard practice to blindly execute programs sent to you by anonymous people you don't know you'd get a lecture on why that's stupid. But in 2024 it's standard accepted practice. And that standard has made it so browser developers have to literally prevent the user themselves from having control over their browser because it's too dangerous to do otherwise. The problem with the entire commercial web application ethos, despite it being a perfect fit for for-profit situations, is that it forces the rest of the web stack to gimp itself and centralize itself, CA TLS only, etc, just to keep the auto-code executing people secure. The one horribly insecure user behavior (auto executing random code) takes over from all other use cases and pushes them out. So, we end up with very impressive browsers that are basically OSes but no longer functions as browsers. And that's a problem. Design your own sites so that they progressively enhance when JS is available. When work requires you to make bad JS sites, do so, but only in exchange for money.

smaudet 3y ago
Agreed. And treat all JS engine-requiring sites like viruses that need to be executed in protected VMs.
- jerbear4328 3y ago
  Of course! Actually, for any website that runs JS, in my opinion, we should just automatically forward the JS execution into a virtual machine, it is horrible to allow any random website to just run code directly on our machine. What if we built this virtual sandbox directly into the browser, that way no code could run on our machine, but all websites still work fine? That's revolutionary! Hang on...
  - superkuh 3y ago
    Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse though as browsers expose more and more of their host operating system's functionality (and more and more speculation CPU bugs make sandboxing as a concept appear infeasible). The benefits of using a website instead of a native application are quickly disappearing, while the drawbacks have only been somewhat mitigated.
  - smaudet 3y ago
    If you could actually control the virtualization in the browser, that would be good. Unfortunately you are just left trusting that it is even virtualized (properly).

smaudet 3y ago

Agreed. And treat all JS engine-requiring sites like viruses that need to be executed in protected VMs.

jerbear4328 3y ago
Of course! Actually, for any website that runs JS, in my opinion, we should just automatically forward the JS execution into a virtual machine, it is horrible to allow any random website to just run code directly on our machine. What if we built this virtual sandbox directly into the browser, that way no code could run on our machine, but all websites still work fine? That's revolutionary! Hang on...
- superkuh 3y ago
  Websites are at least supposedly sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse though as browsers expose more and more of their host operating system's functionality (and more and more speculation CPU bugs make sandboxing as a concept appear infeasible). The benefits of using a website instead of a native application are quickly disappearing, while the drawbacks have only been somewhat mitigated.
- smaudet 3y ago
  If you could actually control the virtualization in the browser, that would be good. Unfortunately you are just left trusting that it is even virtualized (properly).