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

261–270 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#261

Post by madez »

zzzcpan wrote: post #259
madez wrote: post #256

Earlier quoted context omitted.

Then let's standardize generic ways that permit things like upvotes without reloading the page and without executing externally supplied code. :-)

You can do this already with iframes, link targets and :visited for css classes. Using javascript is unnecessary. This technique used to be popular before XMLHttpRequest.

Thanks for providing a solution.

If using JavaScript to achieve this is easier/more efficient/better in some other way that is convincing, then we can think about standardizing better ways to do it. And if it's not better using JavaScript, then it's just an issue of raising awareness about not using JavaScript for it.

Re: What Spectre and Meltdown Mean for WebKit

#262

Post by swinglock »

UncleEntity wrote: post #212
bakery2k wrote: post #193

Mitigations for Spectre and Meltdown are also being added to the JavaScript VMs in Chrome [1], Firefox [2] and IE/Edge [3]. Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR? Or are these other VMs not susceptible to this form of attack? [1] https://www.chromium.org/Home/chromium-security/ssca [2] https://b…

> Or are these other VMs not susceptible to this form of attack? I think the main difference is all the other dynamic languages don't let someone do a driveby attack, you have to download the code and run it as opposed to clicking a link and having who knows what appear.

Actually it's not entirely exotic for games to use Lua in a manner that's comparable to JavaScript in browsers.

Connecting to a server could instruct the client to download a custom map that embeds code or download and execute sandboxed code alone by design.

Re: What Spectre and Meltdown Mean for WebKit

#263

Post by SquareWheel »

madez wrote: post #261
zzzcpan wrote: post #259

Earlier quoted context omitted.

You can do this already with iframes, link targets and :visited for css classes. Using javascript is unnecessary. This technique used to be popular before XMLHttpRequest.

Thanks for providing a solution. If using JavaScript to achieve this is easier/more efficient/better in some other way that is convincing, then we can think about standardizing better ways to do it. And if it's not better using JavaScript, then it's just an issue of raising awareness about not using JavaScript for it.

Embedding hundreds of iframes into existing pages isn't a viable solution.

Consider that a single reddit comment requires at least: upvote, downvote, save, report, hide. Not to mention actually commenting, expanding/collapsing threads, or gilding comments.

A thread shows 200 comments by default (500 with Gold). Even 200 comments x 5 features requires a thousand iframes, each of which is embedding a complete document.

If you think web performance is bad now...

Re: What Spectre and Meltdown Mean for WebKit

#264

Post by EgoIncarnate »

pjmlp wrote: post #179
EgoIncarnate wrote: post #156

Earlier quoted context omitted.

I think we are talking about different things. Half your links have nothing to do with Flash or Java Applets (.net, XAML?). You seem to be talking about new platforms that may derive some part from the old. I'm not saying WebAssembly won't be used for new platforms as that's sort of the whole point of it. What I'm saying is that WebAssembly won't bring back people making Flash .swfs or writing classes derived from ja…

TeaVM allows any Java application to be ported into WebAssembly, be it an applet or not. As3-WebAssembly is a compiler for porting Action Script 3, Flash's programming language, into WebAssembly. Already integrated into Flash Develop. Microsoft and Xamarin efforts to port Mono into WebAssembly, will allow making Silverlight apps again. You are free to believe this won't turn out into anything, I rather think we will…

As I said, we are talking about different things. I am talking about running binary executables from old platforms and people making new binaries in the old way again, you seem to be talking about porting old source code to new platforms.

The new platforms may use the old languages, but the runtime libraries are not the same. The new platforms have different APIs and functionalities (no threads in TeaVM for instance).

To simplify my point. ActionScript is just a language. Adobe Flash was much more than that. Maybe companies really will find some compelling reason to start using ActionScript again... but Adobe Flash and it's SWFs will still be dead.

Re: What Spectre and Meltdown Mean for WebKit

#265

Post by EgoIncarnate »

jpttsn wrote: post #202
EgoIncarnate wrote: post #104

Earlier quoted context omitted.

The situation is apples and oranges. Dumping Flash and Java took years, and was driven by rapid adoption of mobile devices that either didn't support them at all (Apple) or very well (everyone else). There was an already deployed alternative (Javascript). Javascript is buried much deeper in modern websites and would be much more difficult to replace than either Flash or Java Applets were for most sites. For most site…

Big changes do happen and look small only in retrospect.

But they don't happen overnight. I didn't say change wouldn't happen, I said it wasn't likely to happen anytime soon.

Re: What Spectre and Meltdown Mean for WebKit

#266

Post by iovrthoughtthis »

madez wrote: post #192
iovrthoughtthis wrote: post #173

Earlier quoted context omitted.

> HTML (or whatever standard we come up with) can be expanded to add the needed features I think it is hubris to think we can ever build a spec with all the needed features. > JavaScript is used to lock us in, exactly what the web shouldn't do. While I agree the web shouldn't lock us in I would like to understand how you think JavaScript does that?

I don't think it is possible to have a spec thats always contains all the latest functionality. But that is also not necessary. The better the spec, the more problems we can solve completely. I don't think we can always support the newest latest advancement to solve the latest obscure problem, but I think it's no problem to wait a period, even if it were months or years, for it to be standardized and supported in bro…

Waiting months and years for features that your site or app depends on is unacceptable.

> We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should.

And once we have captured those concept, what then? Where do we mine the new concepts, designs, behaviours that will need to be introduced to the spec and implemented by each browser vendor individually?

Re: What Spectre and Meltdown Mean for WebKit

#267

Post by madez »

SquareWheel wrote: post #263
madez wrote: post #261

Earlier quoted context omitted.

Thanks for providing a solution. If using JavaScript to achieve this is easier/more efficient/better in some other way that is convincing, then we can think about standardizing better ways to do it. And if it's not better using JavaScript, then it's just an issue of raising awareness about not using JavaScript for it.

Embedding hundreds of iframes into existing pages isn't a viable solution. Consider that a single reddit comment requires at least: upvote, downvote, save, report, hide. Not to mention actually commenting, expanding/collapsing threads, or gilding comments. A thread shows 200 comments by default (500 with Gold). Even 200 comments x 5 features requires a thousand iframes, each of which is embedding a complete document.…

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

Re: What Spectre and Meltdown Mean for WebKit

#268

Post by madez »

iovrthoughtthis wrote: post #266
madez wrote: post #192

Earlier quoted context omitted.

I don't think it is possible to have a spec thats always contains all the latest functionality. But that is also not necessary. The better the spec, the more problems we can solve completely. I don't think we can always support the newest latest advancement to solve the latest obscure problem, but I think it's no problem to wait a period, even if it were months or years, for it to be standardized and supported in bro…

Waiting months and years for features that your site or app depends on is unacceptable. > We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should. And once we have captured those concept, what then? Where do we mine the new conce…

> Waiting months and years for features that your site or app depends on is unacceptable.

If we do a thorough job now on extending the code-less web, I find it hard to think of sites that couldn't be realized then _and_ shouldn't be a native program in the first place.

I simply don't want a web that has place for "apps". For multiple reasons random websites shouldn't have the possibility to make the visitors system execute supplied code. Yes, some people don't agree with that, but they have usually motives for that which I cannot agree with like withholding code or control from users or tracking them. If you have a good reason why there should be apps in the browser, then I'd love to hear it, though.

The _example_ suggestion to look at existing framework is just a shortcut to not redo work, and to use already existing knowledge. If someone has an idea of what functionality should be supported we can discuss and standardize it. We had lots of technology completely independent of JavaScript. There is a lot of movement in the JavaScript ecosystem because a lot of ecosystem needs to be developed and there are big companies pushing for it, because they need it to monetize their users, but thats it. JavaScript isn't that important.

Re: What Spectre and Meltdown Mean for WebKit

#269

Post by krylon »

UncleEntity wrote: post #230
estebank wrote: post #69

Earlier quoted context omitted.

That sounds like a more extreme version of what the Cell[1] was supposed to be. Developers seemed to think that developing for that architecture was really painful, specially compared to other contemporary console platforms. I'd love it if the progress being made in the industry got us to actually being able to exploit the full potential of such architectures. [1]: https://en.wikipedia.org/wiki/Cell_(microprocessor)

> I'd love it if the progress being made in the industry got us to actually being able to exploit the full potential of such architectures. If they had ever released it as a general purpose computer instead of a locked down game console people could've experimented with it enough to unlock its full potential. If they were smart they'd dust off the old chips, throw them on a RasberryPi type system and laugh all the wa…

There were PCI-Express cards with Cells on them, for numbercrunching or something. These even used the "good" Cells with full 64-bit floating point numbers needed for scientific workloads.

I vaguely remember that the price tag I saw was so outrageous I can understand why that didn't go anywhere.

Would have been interesting, though, I agree.

Re: What Spectre and Meltdown Mean for WebKit

#270

Post by EgoIncarnate »

madez wrote: post #267
SquareWheel wrote: post #263

Earlier quoted context omitted.

Embedding hundreds of iframes into existing pages isn't a viable solution. Consider that a single reddit comment requires at least: upvote, downvote, save, report, hide. Not to mention actually commenting, expanding/collapsing threads, or gilding comments. A thread shows 200 comments by default (500 with Gold). Even 200 comments x 5 features requires a thousand iframes, each of which is embedding a complete document.…

> 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 freedom I would love to hear it. The alternatives I know of all sacrifice something (speed, interactivity, flexibility, development cost) in the name of getting rid of something it seems most people don't have a fundamental problem with (namely sandboxed executable code).

Post reply on HN