Disabling high precision timers isn't a long term solution. There's probably only a matter of time until someone finds a new way to make a high enough precision timer, and even if that wasn't the case, features like SharedArrayBuffer are just too useful to completely disable forever - and there's no easy way to make it impossible to create a high precision timer with a SharedArrayBuffer (just have a web worker which just increments a number in a shared buffer in a loop).

Would throttling syscalls really prevent using these syscalls? Surely it would just make the exploits lower to perform? Is there something I've not understood, or is the idea just to throttle syscalls enough to make it infeasably slow? If it's the latter, remember that users might potentially be on a website for half an hour at a time (if they're reading a long article or watching a video), so an attacker (whose code is running on the site, potentially through a compromised ad/tracking platform, or just XSS) would have a lot of time to extract whatever memory they want.

> and even if that wasn't the case, features like SharedArrayBuffer are just too useful to completely disable forever

That's only if you continue to participate in the shared delusion that the WWW can or should be a high-performance applications platform. Those of us who usually browse with JavaScript turned off can get along fine without SharedArrayBuffer or WebGL or WebSockets.

Honestly curious, why is it a delusion to want the WWW to be a more powerful platform that offers more than just being a web of shared documents? Why is it bad for there to be an array of purposes or applications available on the Web? Just because you don't see value in it, doesn't really make it fair to call others who do see value in it delusional.

The WWW started out as a document sharing platform, and that has proven repeatedly to be a horrible base upon which to build an application platform. There's technological ugliness in the form of kludges like WebAssembly and WebSockets and WebGL that are (badly) re-inventing large parts of the operating system. There's the usability nightmares caused by trying to make a web application imitate a native UI (or worse, trying to use web technologies locally as a UI toolkit a la Electron). The addition of application-oriented features has detracted from the original feature set: gratuitous overuse of JS for stuff that can be done in CSS and HTML is rampant, leading to less responsive sites with worse accessibility and worse battery life. And sooner or later, every attempt to shoehorn a real security model onto the Web has fallen. Every month, the idea of a secure sandbox for running untrusted third-party code looks more and more like a pipe dream.

I fully understand how much the world has invested in making the web into an applications platform, and I recognize that many things of value have been built on that platform. But it's been a fundamentally flawed enterprise from the start, and the pitfalls are getting harder to ignore. We need to start taking seriously again the idea that untrusted code cannot be trusted. We need to stop re-inventing the operating system within the browser just because some programmers are too lazy to port their applications to more than one OS even when there are libraries to abstract away all the differences that don't require a UI redesign. We need to stop sacrificing so much efficiency for the sake of portability that doesn't live up to its purpose.

In order for a web browser suitable for document-oriented usage with limited interactivity to be secure and offer reasonable protections for your privacy, it has to take measures that preclude it from being a good applications platform. That conflict seems irreconcilable.

There are myriad reasons beyond programmers being "too lazy" to port applications to more than one OS for the web evolving into an application platform. Your rant is on par with suggesting we go back to horses and buggies because high-speed car accidents can be deadly. It vastly overstates the danger posed by JS specifically, completely discounts its superiority in filling the niche that it does compared to the previous status quo, and advocates a non-sequitur, anachronistic resolution.

> Your rant is on par with suggesting we go back to horses and buggies because high-speed car accidents can be deadly.

Don't be ridiculous. I'm not saying we shouldn't have cross-platform apps at all. I'm just saying we need a clear distinction between the WWW and any applications platform, just like we need a clear distinction between sidewalks and freeways. The web browser cannot do both jobs well.

> I'm just saying we need a clear distinction between the WWW and any applications platform, just like we need a clear distinction between sidewalks and freeways.

One problem is, no one seems to be able to define "web application" in a way that makes the distinction clear. Most sites that use javascript still use it in the context of displaying documents, so if you define any site that uses javascript at all as an "application," then most sites, including Hacker News, count as applications. But that doesn't actually fix any problems.

Fully agree.

Web should stay as interactive documents.

WebGL is such high performance that most examples posted on HN struggle on my phone, where I routinely play OpenGL ES 3.x games without any visible jank.

That ship sailed the moment JavaScript arrived on the scene, and Flash rode in on its coat-tails. The writing was on the wall: people wanted more from the web, envisioned more for it, than simply interactive documents, and they still do.

Granted, not everybody: some are more than happy with interactive documents. Great, that's awesome, and I hope you're happy, but you don't get to dictate the behaviour of the 99%.

And that figure is not an exaggeration: for my own sites about 1% of people have JS disabled. This post from Yell, over a much larger sample of data, suggests that 0.07% of their visitors disable JavaScript: https://blog.yell.com/2016/04/just-many-web-users-disable-co....

Granted, a large portion of that 99% won't know or care what JavaScript is, but they'll care if they lose the additional functionality it brings to the sites they use (though, honestly, I doubt they'd miss the ads, for which it's so often misused).

The problem I have is that 99% of my web use is the web as an interactive document - news and articles in particular - but those web sites still load an absolute ton of code.

Yeah, I'm certainly on board with that: vast amounts of ad-related assets and tracking code need to become a thing of the past. Still, for that I have uBlock, and I'm increasingly avoiding the worst offenders on that front anyway.

Still, sites I use on a regular basis that benefit from JS: GitHub (most evident with real-time updates to projects, issues, PRs); Office365; GMail, Google Drive, Google Analytics, Google Docs, the Adsense and Webmaster portals, and - of course - YouTube; Clubhouse (project management, heavier than Trello, lighter than JIRA); Azure management portal; pipeline apps such as TeamCity and Octopus Deploy.

Yeah, no dispute from me on that count, there are a lot of valid uses.

I am getting sick of what I presume is coin-mining code. I was reading an article about keyboards on some site the other day and after a few seconds my laptop started to sound like an aircraft taking off.

But how will you mine bitcoin or whatever for your favourite website then?

/grumble

Yeah, high precision timers aren't a fix-all. Imagine a loop where you test a single bit of some protected memory. If it takes microseconds to determine the value of that bit that's really bad, but even if it takes milliseconds, seconds, or even hours that's still really bad. This is equivalent to how fast an attacker can download your system's memory during an attack. If that rate is mb/s that's catastrophic, if it's kb/s that's still super bad, if it's bits per day that might be enough to mean that only the highest value systems will be targeted, but that's a far cry from actual security.