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

131–140 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#131

Post by cornyNetHandle »

bradgessler wrote: post #36

One of the most brilliant features in the latest versions of Safari are per-website settings for ad blockers, notifications, location, etc. Between those two vulnerabilities and the general obnoxious useage of JS on websites, I’d love to see the addition of a per-website setting for JS. I would personally turn it off by default and only whitelist a handful of websites.

Am trying out the brave browser at the moment, it does that pretty well, though for any site that doesn't just work in brave by turning on scripts for a page, I still tend to use firefox or opera, rather than enabling more things on brave.

Re: What Spectre and Meltdown Mean for WebKit

#132

Post by amiraliakbari »

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…

For me, making a better HTML/CSS and forcing it on everyone contradicts with the openness and accessibility of the web. It's 2018 and still there is no reasonable support of not-so-popular languages and locales in any browser or OS.

Consider a simple blog whose users are used to Jalali calendar. Blocking JS will only make the web more hard to use for them. It took many years for simple date utilities to land in HTML5 standard, and I bet things like decent global localization support will not be part of any standard in the next ten years.

User hostile activities should be prevented, but it should be done by developing more PrivacyBadger like tools, not limiting everyone to a small subset of available technology.

Re: What Spectre and Meltdown Mean for WebKit

#133

Post by om2 »

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.

Built-in JavaScript has a better security track record than Flash and it’s ActionScript engine.

Re: What Spectre and Meltdown Mean for WebKit

#134

Post by madez »

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.

The notion that there are so many users of digital devices and services because we are running untrusted, unaccounted code that is automatically executed is plain wrong.

Hardware advanced in ways we didn't imagine in the past, and interfaces got better. Society learned about computers as they got cheaper and knowledge spread, while better software tools formed, accelerating the growth of the ecosystem. Nothing of that requires running delivered code upon visiting a random website.

HTML (or whatever standard we come up with) can be expanded to add the needed features, and enrich the web that way. JavaScript is used to lock us in, exactly what the web shouldn't do.

Re: What Spectre and Meltdown Mean for WebKit

#135

Post by om2 »

syncsynchalt wrote: post #51
Game_Ender wrote: post #15

This is a great article on the subject and I like the clear explanation, with code examples on their fixes. I don’t think I will ever forget the line “we cannot trust branches”, it’s just amazing that such a fundamental part of the CPU was broken here.

I've been explaining to friends that Spectre is like discovering that ESP exists. Not that Spectre attacks are going to be easy to pull off, but it really makes you reconsider everything that you thought you could take for granted.

The scary thing is that without mitigations, it is shockingly easy to pull off. WebKit engineers made multiple fully working exploits internally and we would be hard pressed to do that for other kinds of vulnerabilities. Building full exploits out of your run of the mill use-after-free bug is much harder and requires specific expertise.

Fortunately these mitigations make it way harder.

Re: What Spectre and Meltdown Mean for WebKit

#136

Post by xtanx »

send_computers wrote: post #130
xtanx wrote: post #127

Earlier quoted context omitted.

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

Well, if google can't do it properly then who can? Also, I was talking about SPAs specifically not JS in general.

Re: What Spectre and Meltdown Mean for WebKit

#137

Post by om2 »

roca wrote: post #77

I see how this addresses some examples of Spectre, and it's clever (hi Filip!) and probably worth doing. However, not all possible Spectre-related vulnerabilities involve type confusion. E.g. imagine if we had JS code that does let x = bigArray[iframeElem.contentWindow.someProperty]; Conceivably that could get compiled to some mix of JIT code and C++ that does if (iframeElemOrigin == selfDocumentOrigin) { index = ...…

We assume no if statements that implement a security check are safe without something. It’s not just bounds checks and type checks.

Origin checks are a special case worth considering. I am not sure what you describe would be exploitable in practice (reasons too long to fit in this margin) but worth looking into.

Re: What Spectre and Meltdown Mean for WebKit

#138

Post by madez »

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 for what?

Sure, Google and other advertising companies will never stop pushing technologies that are favourable for them, but we don't have to use them. We can always build open and free alternatives.

Re: What Spectre and Meltdown Mean for WebKit

#139

Post by om2 »

flohofwoe wrote: post #89
TheCoreh wrote: post #19

Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the resolution again? Can we get a Developer menu or Web Inspector option to temporarily enable the old resolution again?

1ms is absolutely overkill IMHO and will require rewriting a lot of code which measures frametime this way. This is not an issue for the precision reductions in the other browsers (Chrome's 100us is just about what's still tolerable, Firefox's 20us is fine). It's probably better to round the measured frametime to the next 'vsync frametime' like 16.667ms or 33.333ms anyway, but I expect a lot of WebGL demos and games…

We are looking at ways to make it more precise but with random jitter. 1ms is a stopgap.

Re: What Spectre and Meltdown Mean for WebKit

#140

Post by om2 »

gpderetta wrote: post #96
pizlonator wrote: post #25

Earlier quoted context omitted.

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.

If browsers are careful not to put any sensitive information in the same process that is executing JS code, sandboxing could work. This seems a sensible thing anyway as it would mitigate other attacks as well. Allocating one process for JS-using webpage is expensive though.

Chrome is working towards something like this with Site Isolation, and it’s a good idea. Unfortunately it’s not a complete defense.

First, web pages can load cross origin resources, and that may be enough to get data or a cookie into the attacker’s web process. Second, some risks of this attack (e.g. ASLR bypass) don’t require any data from another origin to be in process to be dangerous.

Post reply on HN