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

121–130 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#121

Post by twic »

epenance wrote: post #98
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…

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…

I would be absolutely astounded if there was any SPA which moved fewer bytes over the network than its plain HTML equivalent. HTML can be written compactly, and the repeated structures compress well; any increase in the size of the data over JSON will be more than made up for by not needing to load megabytes of javascript.

Re: What Spectre and Meltdown Mean for WebKit

#122

Post by cm2187 »

aaron-lebo wrote: post #116
cm2187 wrote: post #102

Earlier quoted context omitted.

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.

Well right now the problem is that the tool is broken. We have a long term non fixable issue (outside of replacing the hardware) with non trusted code running locally.

Re: What Spectre and Meltdown Mean for WebKit

#123

Post by [deleted] »

cm2187 wrote: post #118
iovrthoughtthis wrote: post #105

Earlier quoted context omitted.

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 devi…

[deleted]

Re: What Spectre and Meltdown Mean for WebKit

#124

Post by gpderetta »

_0w8t wrote: post #120
gpderetta wrote: post #106

Earlier quoted context omitted.

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.

true. Then again switch statements (and I assume match statements in language that have them) are often compiled down to a jump table...

Re: What Spectre and Meltdown Mean for WebKit

#125

Post by [deleted] »

cm2187 wrote: post #122
aaron-lebo wrote: post #116

Earlier quoted context omitted.

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.

Well right now the problem is that the tool is broken. We have a long term non fixable issue (outside of replacing the hardware) with non trusted code running locally.

[deleted]

Re: What Spectre and Meltdown Mean for WebKit

#126

Post by dingo_bat »

vog wrote: post #114
dingo_bat wrote: post #101

Earlier quoted context omitted.

> 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…

But these attacks (Meltdown/Spectre) are on a fundamental design approach, which was conceived and developed and researched in the open. People in colleges all over the world study about them. Do you really think this would have been caught much sooner is Intel had released all schematics and layouts to the public?

Re: What Spectre and Meltdown Mean for WebKit

#127

Post by xtanx »

epenance wrote: post #98
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…

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…

The statement "a better experience" is debatable.

I cannot remember how many times I have visited SPA websites that break the browser url history.

Also, if a SPA fails to load a request for any reason, try reloading it. Ops you start over.

And I am not talking about some people that don't know what they are doing. At times I've had issues with Google's new developer console, gsuite admin, analytics, product hunt and others.

Re: What Spectre and Meltdown Mean for WebKit

#128

Post by [deleted] »

xtanx wrote: post #127
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…

The statement "a better experience" is debatable. I cannot remember how many times I have visited SPA websites that break the browser url history. Also, if a SPA fails to load a request for any reason, try reloading it. Ops you start over. And I am not talking about some people that don't know what they are doing. At times I've had issues with Google's new developer console, gsuite admin, analytics, product hunt and…

[deleted]

Re: What Spectre and Meltdown Mean for WebKit

#129

Post by send_computers »

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.

Yeah lets all just use bash commands to browse the web, way more secure and sure you can get the information you need... oh wait wasn't that 20 years ago?

Re: What Spectre and Meltdown Mean for WebKit

#130

Post by send_computers »

xtanx wrote: post #127
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…

The statement "a better experience" is debatable. I cannot remember how many times I have visited SPA websites that break the browser url history. Also, if a SPA fails to load a request for any reason, try reloading it. Ops you start over. And I am not talking about some people that don't know what they are doing. At times I've had issues with Google's new developer console, gsuite admin, analytics, product hunt and…

These are all examples of bugs or badly designed/coded applications. Don't blame JS for bad coding...
Post reply on HN