Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Spectre and Meltdown Mean for WebKit

webkit.org

Post reply on HN
Print view View original

111–120 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#111

Post by EgoIncarnate »

pjmlp wrote: post #86
username223 wrote: post #28

Earlier quoted context omitted.

> The web by and large requires javascript, and it's not likely to change. While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting c…

> Client side Java and Flash are dead Not paying attention to the news? Just wait until WebAssembly gets more mature.

I don't think WebAssembly is going to bring back Flash or Java Applets in any meaningful way. Maybe someone will hack something together and use it for niche old Flash game sites, but it's hard to see a reason for widespread adoption of anything new. People have moved on.

Flash and Java Applets may not be "dead" forever, but they also are not likely to ever be more than undead zombies.

Re: What Spectre and Meltdown Mean for WebKit

#112

Post by vog »

WillReplyfFood wrote: post #99
80x25 wrote: post #44

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…

Translated this basically means- for real security to exist, the chip has to be open source down to the layout. 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?

> This will not happen

Note that we do have good Open Source CPU designs, though, such as RISC V.

Re: What Spectre and Meltdown Mean for WebKit

#113

Post by endless1234 »

dingo_bat wrote: post #100
cm2187 wrote: post #92

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…

> There are websites that genuinely need to run some code, like webmails, 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.

>Honestly, I think running webgames in a super-sandboxed flash (or similar) runtime is the best thing to do.

Why is one ECMAScript sandbox (flash) so much better than another?

Re: What Spectre and Meltdown Mean for WebKit

#114

Post by vog »

dingo_bat wrote: post #101
WillReplyfFood wrote: post #99

Earlier quoted context omitted.

Translated this basically means- for real security to exist, the chip has to be open source down to the layout. 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?

> open source down to the layout. I don't see what open source has got to do with any of this.

More security experts would be encouraged to have a look at the design and to find flaws early on.

Of course, we all know that this doesn't always happen, see OpenSSL. However, once a major incident (Heartbleed) happened, they did: Many more OpenSSL issues were found and fixed, forks with different trade-offs came into place. For example, LibreSSL traded backwards compatibility with ancient systems for a smaller code base and increased security.

Since CPU designs are not Open Source, and on top of that flooded with patents, nothing like that will happen in this space. Intel and AMD are on their own, rather than having their design checked by a motivated international research community.

Re: What Spectre and Meltdown Mean for WebKit

#115

Post by cm2187 »

stesch wrote: post #107
cm2187 wrote: post #92

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…

It's too late. For many years (decades?) I got downvoted (here and on Reddit) for mentioning that I used NoScript. I even disabled JavaScript completely on Netscape Navigator. It was in the context of sites that were unusable without JavaScript or security problems that only affected JavaScript in browsers.

It’s too late until we are facing an unfixable hardware flaw that we will be stuck with for the next 10 years (until users fully retire the current CPU architecture).

Re: What Spectre and Meltdown Mean for WebKit

#116

Post by aaron-lebo »

cm2187 wrote: post #102
epenance wrote: post #98

Earlier quoted context omitted.

This is false. Many websites are using Javascript to render the websites in full to give the users a better experience, such as rendered a SPA (Single-Page-Application) to prevent unneeded amounts of data loaded on each page request and only load exactly what you need, to give a faster, smoother and higher quality experience for the user. Sure the mom down the street who wants to blog about the her kitchen recipes wo…

Websites are only bloated because of the MB of javascript to make them applications (images do not count as they need to be rendered either way and can be cached). Most of the websites I visit every day don’t display that much content. Once gzipped it's a tiny file.

Yeah and if you visit a site everyday, the JS is cached, too. After the initial download, it shouln't be an issue. This is besides the fact that it should not take MBs of JS to make complex applications.

The issue is what people are choosing to do with the tools, not the tools themselves.

Re: What Spectre and Meltdown Mean for WebKit

#117

Post by EgoIncarnate »

pjmlp wrote: post #85
EgoIncarnate wrote: post #24

Earlier quoted context omitted.

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…

Depends, I white list JavaScript on the web sites I thrust, and use native apps when given the option. On the OSes I use, I make sure all sandbox options are turned on.

Would you consider yourself a typical example of a naive user? The security default needs to work for everyone. I think the sandbox approach is better than expecting everyone to correctly decide when it is or isn't okay to allow a site to run code.

Re: What Spectre and Meltdown Mean for WebKit

#118

Post by cm2187 »

iovrthoughtthis wrote: post #105
cm2187 wrote: post #92

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…

running untrusted code is a fundamental part of our daily experience. If you kill the webs ability to do that, people will build something else. The we have to go through the rigmarole of securing this whole new platform with the same bugs but in different ways. Instead of neutering the web, let's build secure cpus.

No, drop down menus, pre-validation of forms, adaptive rendering are the daily experience. Javascript is just the way we currently achieve that. I argue that a better html would avoid having to do this in javascript, as these are standard features that are needed everywhere.

And even if Intel comes up with a new design available for sale next month, we will still be stuck for many years with this flaw on all the devices out there. We also need to fix CPUs, but that’s a very long term solution.

Re: What Spectre and Meltdown Mean for WebKit

#119

Post by cabalamat »

iovrthoughtthis wrote: post #105
cm2187 wrote: post #92

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…

running untrusted code is a fundamental part of our daily experience. If you kill the webs ability to do that, people will build something else. The we have to go through the rigmarole of securing this whole new platform with the same bugs but in different ways. Instead of neutering the web, let's build secure cpus.

> Instead of neutering the web

If you took JSW off of most websites, it wouldn't be neutering the web it'd be making it better.

Re: What Spectre and Meltdown Mean for WebKit

#120

Post by _0w8t »

gpderetta wrote: post #106
earenndil wrote: post #87

Earlier quoted context omitted.

Consider something like this: struct __internal_variable { uint64_t type; void *data; } uint64_t __last_type = [number of builtin types]; whenever you create a new type: increment __last_type and associate that type with the number; uint64_t typeof(__internal_variable var) { return var.type; } function[__last_type] typechecks; functions[] = void function(uint64_t type) { failure; } functions[int] = void function(uint…

That's basically a jump table. Still vulnerable to spectre (variant 2) without mitigations, btw.

It is even worse then switch/match statements. The jump tables can be used to train CPU to jump to a wide variety of addresses than switch/match statements so mounting a speculative execution attack is simpler.
Post reply on HN