91–100 of 294 posts
Earlier quoted context omitted.
And yet presumably you didn't get pwned in the process of writing that comment. It's true that securing the execution of untrusted code is hard. But it's not impossible.
Online forums were already possible without JavaScript. I would even rather read HN via NNTP, if given the option.
There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of forms, etc), for the mere convenience of developers and for user hostile activities (tracking, messing with default behavior of the mouse, keyboard, clipboard, scrolling, etc).
This might be an opportunity for revisiting html and making it better. An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. Once we have a good enough markup alternative, executing javascript can become an optional feature requiring user authorisation like accessing your camera or location.
[edit] also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.
> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't t…
Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something…
I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…
I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…
With current CPU design there is only so much that can be done, but the architectural fix seems obvious to me, one that doesn't give up the performance benefits of speculative execution and branch prediction. The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.
The problem that JSC is dealing with is that Spectre allows untrusted JS code to read things from the memory of the process that runs it. We don't want to allow that, but I don't think your proposed solution would fix it.
This seems a sensible thing anyway as it would mitigate other attacks as well. Allocating one process for JS-using webpage is expensive though.
A lot of game-related media has reported that a lot of games are largely unaffected by Spectre and Meltdown. My impression is that the most common result is "about 3%." (With some notable exceptions, however.) Does this bode well for Apple code, which seems to tend to pull in innovations from games into the general UI?
I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…
Sure the mom down the street who wants to blog about the her kitchen recipes wont be needing it, but a lot of websites "do"
These mitigations feel like a half measure. To quote the Spectre paper: "Even code that contains no conditional branches can potentially be at risk." "long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform." It seems too early to declare Spectre class attacks mit…
This will not happen. So basically, the interest of the one outweighing the interests of the many, results in the many suffering for what exactly?
I wonder if this shouldn't question whether we should still allow all websites to run javascript by default. There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of…
Not really, not if you think about it. Webmail doesn't need anything more than html(> online trading platforms
Ditto.
> online games
Honestly, I think running webgames in a super-sandboxed flash (or similar) runtime is the best thing to do. Again, no use for js on the web.