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

141–150 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#141

Post by madez »

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.

HTML can be cached, too. Even if JavaScript permitted some clever way to safe network traffic like for example delivering the site as a torrent that is then downloaded from other visitors [0], then we can standardize that and implement it as a part of HTML or so.

[0] For example something like https://github.com/xuset/planktos but without the JavaScript.

Re: What Spectre and Meltdown Mean for WebKit

#142

Post by golergka »

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…

I disable JS by default and only enable it if the website requires it (and it seems good enough). Since I've started doing it, quality of my internet experience have raised significantly. Almost all websites load much faster, are more responsive and less intrusive.

Highly recommend it.

Re: What Spectre and Meltdown Mean for WebKit

#143

Post by pjmlp »

EgoIncarnate wrote: post #111
pjmlp wrote: post #86

Earlier quoted context omitted.

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

Again, not paying attention to the news.

http://teavm.org/

https://forums.adobe.com/thread/2432179

http://www.mono-project.com/news/2017/08/09/hello-webassembl...

https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFut...

https://github.com/Microsoft/xaml-standard/issues/197

Re: What Spectre and Meltdown Mean for WebKit

#144

Post by littlestymaar »

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…

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

You can certainly standardize a certain set of feature and put them in a non-turing-complete language like HTML, but standardizing all the legitimate use-cases of JavaScript is almost impossible, you talked about «drop-down menus, form validation or adaptive rendering», but what about interactive charting, modal view of full-size pictures, auto-completion of search tags ? These are just features I use on my personal blog ! And what about infinite-scrolling ? What about partial content-update ? There are thousands of legitimate use-case for JavaScript: it's not achievable to standardize every single one of them and put it in the HTML, and even if it were possible, do you imagine the nightmare it would be to learn HTML then ?

Re: What Spectre and Meltdown Mean for WebKit

#145

Post by pjmlp »

EgoIncarnate wrote: post #117
pjmlp wrote: post #85

Earlier quoted context omitted.

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.

Yes in the context of iOS, Android and UWP native apps.

Re: What Spectre and Meltdown Mean for WebKit

#146

Post by pjmlp »

y0ghur7_xxx wrote: post #91
pjmlp wrote: post #84

Earlier quoted context omitted.

Online forums were already possible without JavaScript. I would even rather read HN via NNTP, if given the option.

> I would even rather read HN via NNTP, if given the option. https://github.com/gromnitsky/hackernews2nntp

Interesting, thanks for the heads up.

Re: What Spectre and Meltdown Mean for WebKit

#147

Post by [deleted] »

littlestymaar wrote: post #144
cm2187 wrote: post #118

Earlier quoted context omitted.

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…

> 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. You can certainly standardize a certain set of feature and put them in a non-turing-complete language like HTML, but standardizing all the leg…

[deleted]

Re: What Spectre and Meltdown Mean for WebKit

#148

Post by littlestymaar »

cabalamat wrote: post #119
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.

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

A taxidermist could argue that dead animals are better than living ones : they are indeed more convenient, less dangerous and cheaper to feed. But they aren't animal anymore, are they ?

Re: What Spectre and Meltdown Mean for WebKit

#149

Post by om2 »

frik wrote: post #55
josephg wrote: post #42

Earlier quoted context omitted.

Something I keep coming back to in all this is that maybe we should be surprised that it’s even possible to share a CPU between mutually untrusted programs, let alone do it in so many contexts. How do we stop his entire class of bugs? What is the Rust for CPU design?

Yes, we need a many-core CPU. Then every program can run on a core. And we can use MPI, CILK, etc to run parallel programs. Each CPU could run its own small operating system, or using a micro kernel OS. Writing algorithms in parallel manner isn't as complicated as make to believe you, a lot can be rewritten based on cookbooks/patterns. Intel developed a many-core CPU (72 CPU cores) called Xeon Phi: https://en.wikiped…

Interpreters generally do a lot of branches, so they are also vulnerable to Spectre.

Re: What Spectre and Meltdown Mean for WebKit

#150

Post by madez »

littlestymaar wrote: post #144
cm2187 wrote: post #118

Earlier quoted context omitted.

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…

> 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. You can certainly standardize a certain set of feature and put them in a non-turing-complete language like HTML, but standardizing all the leg…

> but standardizing all the legitimate use-cases of JavaScript is almost impossible

I see the problem of not always having the newest technologies in browsers, but the pain of that problem vanishes the more we already have. One might say that securing JavaScript sandboxes is almost impossible, but still we are working on it. Let's work in the same spirit on advancing the open web :-)

Post reply on HN