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

231–240 of 294 posts

Re: What Spectre and Meltdown Mean for WebKit

#231

Post by zzzcpan »

alien_at_work wrote: post #229
ambulancechaser wrote: post #227

Earlier quoted context omitted.

but removing branch prediction would be to restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right? The effect of this seems to be "I wish everything was slower and then the naive implementation would be the best implementation".

>restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right No, a stall is only a thing because branch prediction exists. Get rid of it and I can go back to not caring about the deep underlying architecture of the hardware I may potentially be running on. And not doing branch prediction isn't inefficient... that's a bizare statement. Branch prediction and spe…

Nothing changes for high level languages. If they are high level enough they can still fix Spectre and abstract away deep hardware details.

Re: What Spectre and Meltdown Mean for WebKit

#232

Post by madez »

krapp wrote: post #214
madez wrote: post #204

Earlier quoted context omitted.

The advantage of not supporting programming languages in the browser from content that comes from servers is that one doesn't accidentally fall into that trap. The functionality in my browser is important. The more the browser is scriptable, the better, but not from the website. The code on my machine is reviewed, vetted, accounted, maintained and free. That is the big difference.

So you're advocating site developers add elements to their HTML which browser plugins then execute like a scripting language? I may not entirely understand what you're proposing. If the end result is the same functionality as was being provided by javascript, then if you didn't trust the javascript, you can't trust the (now Turing complete) HTML. The same trust and verification issues exist, just moved to another lev…

No, I'm not advocating for any Plugin, but for extending the standard (or creating a new one) with common acceptable functionality that we now use JavaScript for.

For example, we can do tables in HTML. We need no scripting nor plugin for that. For a contrary example, without JavaScript or plugin we can't serve our website as a torrent that is then loaded by the visitors from other visitors. But we can standardize that functionality and add it to the browser. The code for that functionality would then be developed by the browser developers as a part of the browser, and delivered with the browser. The website would just deliver the torrent file and the necessary meta information for it. That way no code or script from the website would need to be executed to have the desired functionality.

I don't blindly trust developers. I nearly exclusively use packages from my distribution. These programs are maintained and signed by people with recorded track record of their behaviour as a maintainer, and they are vetted for by others. They don't have an interest to track or montized me, and it is a limited set of people I need to trust. Also, I can hold back on updates, and refuse them, if I choose to do so. Programs that come from other sources are carefully looked at by me. there is a big difference to automatically downloaded and executed code from some website.

Re: What Spectre and Meltdown Mean for WebKit

#233

Post by UncleEntity »

Matt3o12_ wrote: post #211
UncleEntity wrote: post #206

Earlier quoted context omitted.

> ...say that code should be a considered a privilege and not a right, or that it doesn't really belong on the web at all, despite javascript being on the web for ~20 years now. Same could be said about advertising and I'm infringing on all these innocent corporations' natural rights by running an adblocker. For random code to run on my machine a few (IMHO reasonable) steps need to happen: 1) somehow entice me to cli…

Be aware that Adblock doesn’t block all JavaScript code. It blocks code after people have identified that code X run on website Y does something bad (tracking, ads, etc) and they decided to block it. This works well for visible ads because people see them. For tracking scripts, it still happens because most of them have obvious giveaways (come from a different domain, etc) but chances are that you still run random co…

> Be aware that Adblock doesn’t block all JavaScript code.

That's fine as long as it keeps the annoying stuff to a minimum and Privacy Badger seems to do a good job on the tracking stuff.

Re: What Spectre and Meltdown Mean for WebKit

#234

Post by Matt3o12_ »

UncleEntity wrote: post #233
Matt3o12_ wrote: post #211

Earlier quoted context omitted.

Be aware that Adblock doesn’t block all JavaScript code. It blocks code after people have identified that code X run on website Y does something bad (tracking, ads, etc) and they decided to block it. This works well for visible ads because people see them. For tracking scripts, it still happens because most of them have obvious giveaways (come from a different domain, etc) but chances are that you still run random co…

> Be aware that Adblock doesn’t block all JavaScript code. That's fine as long as it keeps the annoying stuff to a minimum and Privacy Badger seems to do a good job on the tracking stuff.

I get that (and that’s why I use it too) but you made it sound like Adblock is blocking malicious code and thus you do not need to worry about Spectre and meltdown, which is defentily not true (though it does prevent some malicious code).

Re: What Spectre and Meltdown Mean for WebKit

#235

Post by joosters »

om2 wrote: post #139
flohofwoe wrote: post #89

Earlier quoted context omitted.

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.

Can't the timing (in)accuracies be worked around by javascript? There must be countless numbers of timer-triggered events in JS, not just the high-res timers but simple second-by-second counters, frame sync events, or even external I/O. Every possible time-based event needs to be made imprecise, otherwise programmers can derive a higher precision timer from them.

e.g. if you have a tight loop that just increments a counter, couldn't you just run that for a second (interrupted by a lower frequency timer source), then find out how many counts/second the JIT can perform, presumably millions or billions. To time operation 'X', you then just perform X and run the tight loop again, and compare how many fewer tight loops you completed.

Re: What Spectre and Meltdown Mean for WebKit

#236

Post by optimuspaul »

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…

if you aren't ready to wipe and trash your box at a moments notice and start fresh then why are you even on the internet?

Re: What Spectre and Meltdown Mean for WebKit

#237

Post by optimuspaul »

zingmars wrote: post #160
littlestymaar wrote: post #153

Earlier quoted context omitted.

Your stuffed cat could not, but a living cat could bring you rabies if some third party in your neighborhood got infected, that's my point ;).

So your point is that we _should_ JavaScript?

I think it's obvious that the point was no javascript... but a live cat is way more fun, so I'm not on board with that.

Re: What Spectre and Meltdown Mean for WebKit

#238

Post by alien_at_work »

zzzcpan wrote: post #231
alien_at_work wrote: post #229

Earlier quoted context omitted.

>restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right No, a stall is only a thing because branch prediction exists. Get rid of it and I can go back to not caring about the deep underlying architecture of the hardware I may potentially be running on. And not doing branch prediction isn't inefficient... that's a bizare statement. Branch prediction and spe…

Nothing changes for high level languages. If they are high level enough they can still fix Spectre and abstract away deep hardware details.

That's exactly my point: you cannot abstract away details of pipeline size. You must know this to get the best performance out of your structures and algorithms. There is no way for a compiler/optimizer to look at your container implementation and say "oh, this will potentially overflow the pipeline, let's split the data structure into multiple parts and change the code to handle this new access stategy"... that would be creating entirely new code (what would stepping through a debugger look like on such code?).

Re: What Spectre and Meltdown Mean for WebKit

#239

Post by _0w8t »

From the patches it seems that the write operation to the array is also protected with masking. What is the reason for it? If due to a bug unrelated to Spectre a JS code could trigger a write beyond the allocated memory, restricting writes to the next power of two just slightly complicates the attacks. This is very different from the reading situation.

Re: What Spectre and Meltdown Mean for WebKit

#240

Post by SquareWheel »

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.

>Not really, not if you think about it. Webmail doesn't need anything more than html(Because redownloading the entire page every time you click a button is such a great experience...
Post reply on HN