[deleted]
What Spectre and Meltdown Mean for WebKit
271–280 of 294 posts
Re: What Spectre and Meltdown Mean for WebKit
#272Earlier quoted context omitted.
> Embedding hundreds of iframes into existing pages isn't a viable solution. I know I'm repeating myself, but then let's standardize a better way to solve the problem without executing supplied code. JavaScript is not a magic bullet that solves problems that aren't solveable otherwise.
You'll have to come up with proof of a better alternative before you'll get agreement from people like me. Javascript and sandboxed executable code may not be a magic bullet, but it's the bullet we have. "Lets standardize a better way" doesn't give much to talk about if I don't buy into the issues you have with Javascript and executable code. If you could give a compelling example of a better way that gives the same…
Oh, I don't want to give all the freedom that JavaScript in the browser gives, and that's the whole point. If we came up with something that allowed the same things, then that would be a pointless exercise. There will be cuts in aspects, some necessary, some intentional.
I don't advocate for a better way to have apps on the web, but to have a better app-less web.
I'm a bit tired to talk about this topic right now. I'm also repeating myself. I talked a lot about JavaScript on HN recently, so you can read there more, and the surround comments have lots of other perspectives. Not everything has been said. Maybe I'll write up a structured and hopefully complete blog post about it some day soon.
Re: What Spectre and Meltdown Mean for WebKit
#273I don't understand why they say Spectre can control branching in WebKit. Spectre is an information leak attack, it doesn't allow to modify memory. I could allow to find x in `is x == valueToCheck`. But if this is possible, even before Spectre it's a security issue, it's only harder to guess, and Javascript code should not be allowed to control `x`.
Re: What Spectre and Meltdown Mean for WebKit
#274Earlier quoted context omitted.
You'll have to come up with proof of a better alternative before you'll get agreement from people like me. Javascript and sandboxed executable code may not be a magic bullet, but it's the bullet we have. "Lets standardize a better way" doesn't give much to talk about if I don't buy into the issues you have with Javascript and executable code. If you could give a compelling example of a better way that gives the same…
Oh, I don't want to give all the freedom that JavaScript in the browser gives, and that's the whole point. If we came up with something that allowed the same things, then that would be a pointless exercise. There will be cuts in aspects, some necessary, some intentional. I don't advocate for a better way to have apps on the web, but to have a better app-less web. I'm a bit tired to talk about this topic right now. I'…
I will certainly agree that requiring JavaScript unnecessarily should be frowned on and progressive enhancement should be the norm. A least give user the option of taking on additional security risks associated with Javascript (and WebAssembly) or not (edit: where possible).
Re: What Spectre and Meltdown Mean for WebKit
#275Earlier quoted context omitted.
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.
> web pages can load cross origin resources I know nothing about web technologies, but maybe this is something we should stop doing, at least for any executable resource? This would prevent JS ads I guess, so win/win? > 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. yes, ASLR seems to be busted.
> > web pages can load cross origin resources
> I know nothing about web technologies, but maybe this is something we should stop doing, at least for any executable resource? This would prevent JS ads I guess, so win/win?
It's arguably a flaw in the design of the web that loading cross-origin resources is allowed by default. Unfortunately, there isn't a great path to changing this. We may be able to allow websites to opt out of having their resources loaded cross-origin, maybe (similar to X-Frame-Options but for resource types other than frames).
Re: What Spectre and Meltdown Mean for WebKit
#276Earlier quoted context omitted.
Max() is not a CPU instruction. It's an abstraction, a function that could be implemented either using a branch (which defeats the whole purpose) or, on some architectures, with something like cmovXX. Perhaps they wanted a solution that works on Arm, which I think doesn't have cmovXX. Or maybe Intel does speculation with cmovXX used on array index.
Cmov can speculate as well (it makes sense from a performance standpoint but that isn’t the same as secure ;) )
On some CPUs, cmov is known not to speculate, but in those cases it is apparently super slow.
Re: What Spectre and Meltdown Mean for WebKit
#277Earlier quoted context omitted.
Oh, I don't want to give all the freedom that JavaScript in the browser gives, and that's the whole point. If we came up with something that allowed the same things, then that would be a pointless exercise. There will be cuts in aspects, some necessary, some intentional. I don't advocate for a better way to have apps on the web, but to have a better app-less web. I'm a bit tired to talk about this topic right now. I'…
I will certainly agree that requiring JavaScript unnecessarily should be frowned on and progressive enhancement should be the norm. A least give user the option of taking on additional security risks associated with Javascript (and WebAssembly) or not (edit: where possible).
Agreed to a point. For some apps user interaction is required, and progressive enhancement isn't possible.
For non-apps though, it's still very important. Articles should not require a JS bundle to load. When JS is used, it should be optimized.
Re: What Spectre and Meltdown Mean for WebKit
#278Earlier quoted context omitted.
Random, unexpected, untrusted c/c++ written code doesn't execute on my machine every time I browse a website. The only c/c++ code is code I downloaded and installed or that my OS vendor trusted to include in the OS. It's quite different from javascript where the code is literally executing uninvited, often by 3rd or 4th or 5th parties of the website I visit.
The only c/c++ code is code I downloaded and installed or that my OS vendor trusted to include in the OS. You never brew install anything? Or brew cask install, or git clone followed by make, or... Even npm install sometimes compiles C. It's hard to get away from c/c++ code.
Maybe he's running Linux? There, software installed through the package manager from the distro's repos count as code which the OS vendor trusted.
Re: What Spectre and Meltdown Mean for WebKit
#279Earlier quoted context omitted.
I will certainly agree that requiring JavaScript unnecessarily should be frowned on and progressive enhancement should be the norm. A least give user the option of taking on additional security risks associated with Javascript (and WebAssembly) or not (edit: where possible).
Agreed to a point. For some apps user interaction is required, and progressive enhancement isn't possible. For non-apps though, it's still very important. Articles should not require a JS bundle to load. When JS is used, it should be optimized.
Unfortunately the web seems to be moving away from a progressive enhancement world.
Momentum seems to be with whatever is easiest. JavaScript frameworks, analytics companies, and ad companies would probably all have to make progressive enhancement the default way for that to change.
Re: What Spectre and Meltdown Mean for WebKit
#280I don't understand why they say Spectre can control branching in WebKit. Spectre is an information leak attack, it doesn't allow to modify memory. I could allow to find x in `is x == valueToCheck`. But if this is possible, even before Spectre it's a security issue, it's only harder to guess, and Javascript code should not be allowed to control `x`.
I think this part is misleading =>
"Spectre means that an attacker can control branches, so branches alone are no longer adequate for enforcing security properties."
I think they meant "Spectre means an that attacker can ABUSE branches", and in that they are right.