What Spectre and Meltdown Mean for WebKit

https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/

by pizlonator • 9 years ago

397 285 9 years ago

I really hate to see this rush to "make sure our code doesn't use branch prediction". It may be the best fix we have available now, but it's going to create a legacy of bizarre inefficient machine code that will last forever.

zerkten• 9 years ago

How will this last forever? Browsers seem like a relatively competitive and performance-oriented space.

pizlonator15• 9 years ago

Our mitigations do not prevent branch prediction.

Game_Ender4• 9 years ago

You are removing branches, and adding slightly less clear code to do it. If this resulted in faster or cleaner code you would already be doing it. So the OP’s point holds: if these security holes are fixed at the CPU level, there will still be a generation of software compiled with these mitigation’s in and no way for a user on a newer CPU to disable them.

EDIT: I just wanted to clarify here that I did not mean “all branches” just some of them, hence the name of the technique which is “branchless security” (which is a really good piece of engineering). The frustration is basically we have to bake in CPU model specific mitigation’s into binaries. You can of course patch it out, but the affected CPUs will in theory be in the wild for a long time to come even once corrected ones are released.

alien_at_work6• 9 years ago

I feel the opposite. I'd like nothing better than this to be the end of branch prediciton. I can think of no other technology that's been so deterimental to high level languages than branch prediction. How many elegant, beutiful algorithms are replaced by bizarre data structures, etc., because avoiding pipeline stalls will trump any other optimization you can make.

For most things the CPU is doing, we can ignore in high level languages because the compiler/optimizer can turn our high level code into the appropriate byte code to take advantage of deep hardwar magic. Not branch prediction, though, no matter how high level my language, I still must consider pipeline size, cache alignment and so on when designing a novel new container or algorithm or risk it being inexplicitly slow.

Branch prediction is, and always was a hack. Let it die.

ambulancechaser• 9 years ago

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

bangonkeyboard• 9 years ago

What is the reasoning behind reusing version numbers?

js22• 9 years ago

Apple does this sometimes for macOS. It's probably because it's an application update, not an OS update (so OS patch version does not change), and doesn't require a reboot.

hamandcheese• 9 years ago

This doesn’t explain why they kept Safari at the same version number.

username2235• 9 years ago

WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors.

There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't type check. It's that the people running it don't consciously install it, the people distributing it don't know or care what it is, and the people writing it are often adversaries far more sophisticated than the people running it.

EgoIncarnate14• 9 years ago

Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something, but that is a long way off.

As for relying on users ability to determine what code is safe to download... It's not like users can be relied on to do the right thing all the time even without javascript. People respond to phishing attacks, download executables sent to their email, reuse passwords... I think a sandbox is a better solution than relying on users to understand what code is trustworthy and what isn't.

username2235• 9 years ago

The web by and large requires javascript, and it's not likely to change.

While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting close to a situation where average people recognize that millisecond auctions to run arbitrary code on their machines are a bad idea, and those people also have the tools to say "no." Hope springs internal...

madez18• 9 years ago

Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change.

This fatalist stance is childish, and dangerous. As long as there are people working to make things better, things do improve.

Sure, if you make sure that one small website works without JavaScript then that doesn't change the world. I hear a similiar argument when I explain why I don't eat meat; I'm told that animals will be killed anyways. But if I don't eat meat, then less will be killed. How many less? I can't specify the number, but I don't power-hungrily demand my own decision can magically change the world completely over night, and give up when I realize it doesn't.

Still, each and everyones has an influence. It's about doing what's right. And even if you are the only one doing the right thing, things will be a bit better for your actions. But in fact the situation isn't that bad, and one isn't alone.

It's not like users can be relied on to do the right thing all the time anyway.

So, if you aren't sure you locked the front door of your house, then it also doesn't matter if you left the door to the garden open? Clearly it does matter!

This fatalism deems us into inaction and into accepting the status quo even if we know it's bad.

pjmlp9• 9 years ago

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.

jpttsn3• 9 years ago

Not sure it’s a genie situation. Look at Java applets, Flash player.

pizlonator15• 9 years ago

And yet presumably you didn't get pwned in the process of writing that comment. It's true that securing the execution of untrusted code is hard. But it's not impossible.

madez18• 9 years ago

Commenting here works just fine without JavaScript.

moz23• 9 years ago

That comment could've been written without executing any Javascript.

// Edit: heh, someone already said the same.

username2235• 9 years ago

I've whitelisted JS from this site, because I "trust" it enough. If HN sold their comment code through some opaque web of third parties, I would be more cautious.

You're clearly an insider, and I'm clearly an outsider, so you understand the nuances here better than I do. What's your concept of securely executing untrusted code? Should users give up control over what runs on their machines? Should they know whose code may run before and/or after it does? Or what data it can or has already exfiltrated?

pjmlp9• 9 years ago

Online forums were already possible without JavaScript.

I would even rather read HN via NNTP, if given the option.

ikeboy• 9 years ago

I'm starting to think naming multiple similar vulnerabilities by different names was a mistake. Every article I read I have to go back and remind myself while one was which.

brianberns• 9 years ago

Giving them similar names certainly wouldn't make it any easier to remember which one is which.

ENOTTY• 9 years ago

Isn't Intel and AMD shipping new fence instructions that prevent speculative execution from progressing beyond a certain point? Why doesn't Webkit use those?

om210• 9 years ago

The fence instruction that Intel recommends (lfence) is way slower than the techniques described here. We measured a 5x slowdown on Web Assembly trying to use it.

Also we have been working on these mitigations since well before Intel made their suggestion.

br1• 9 years ago

Have you considered arr[max(i, arr.len)] instead of AND?

zzzcpan3• 9 years ago

I suspect fencing instructions are quite a bit slower than this, involve more work and don't even cover every CPU.

Branchless bounds checking and type checking with masking and pointer poisoning is probably what we are going to see in other languages too.

pizlonator15• 9 years ago

These mitigations are way cheaper than fences.

For example, for WebAssembly, we measured that the fence instruction was a 5x regression. That’s nuts. Index masking is a rounding error by comparison.

Game_Ender4• 9 years ago

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.

syncsynchalt2• 9 years ago

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.

om210• 9 years ago

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.

stcredzero• 9 years ago

A lot of game-related media has reported that a lot of games are largely unaffected by Spectre and Meltdown. My impression is that the most common result is "about 3%." (With some notable exceptions, however.)

Does this bode well for Apple code, which seems to tend to pull in innovations from games into the general UI?

alkonaut• 9 years ago

The performance issues come from security mitigations when entering/exiting the kernel during syscalls. So I/O heavy workloads such as databases will suffer, whereas heavy compute-oriented tasks such as games should be mostly OK. This is expected. There is nothing any company can do to "take advantage" of the fact that games are cpu/gpu bound in order to mitigate new performance issues in e.g. databases.

SquareWheel6• 9 years ago

Exactly. Though it may encourage different performance best practices now that syscalls are considered more expensive.

Abishek_Muthian• 9 years ago

Good work WebKit team in putting this together, it's just as good as Raspberry Pi's note on why it isn't affected by Spectre & Meltdown - https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...

Of-course here, the mitigation are being detailed as well.

TheCoreh• 9 years ago

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?

skygazer• 9 years ago

In the same article, they describe their intent to, yes, restore timing resolution, once alternative mitigations mature.

bsimpson• 9 years ago

It's surprising to me that there are such various levels of coarseness each browser vendor chose:

Gecko [0]: accurate to 20us

Edge [1]: accurate to 20us, with an additional 20us of noise

Chrome [2]: accurate to 100us (thanks mkeblx for finding this)

Safari [OP]: accurate to 1000us

[0] https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

[1] https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...

[2] https://chromium-review.googlesource.com/c/chromium/src/+/85...

mkeblx• 9 years ago

Chrome is 100us: https://chromium-review.googlesource.com/c/chromium/src/+/85...

flohofwoe• 9 years ago

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 to break :/

om210• 9 years ago

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

iainmerrick6• 9 years ago

What's an example scenario where you need an ultra-high-resolution timer?

For WebGL, don't you just rely on requestAnimationFrame to call you at the right times, and draw your frame as quickly as possible? What's the benefit of being able to measure the frame time to the nearest microsecond, rather than the nearest millisecond?

tasty_freeze2• 9 years ago

With current CPU design there is only so much that can be done, but the architectural fix seems obvious to me, one that doesn't give up the performance benefits of speculative execution and branch prediction.

The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.

pizlonator15• 9 years ago

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.

gpderetta6• 9 years ago

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.

tasty_freeze2• 9 years ago

What JSC is doing is addressing a problem that exists in today's CPUs. I'm saying what future CPUs need to do to avoid certain classes of sidechannel attacks. That list isn't sufficient, but if it isn't done it seems like inviting other future attacks.

ams6110• 9 years ago

All type checks are also vulnerable. For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer.

So, even if WebKit were entirely written in Rust, we'd still be fucked. I'm really starting to think it's about time for me to get out of this business.

pizlonator15• 9 years ago

Right, programming-language-based security mechanisms that rely on emitting runtime checks are broken and you need something like index masking or pointer poisoning to fix them. Rust could use those fixes as well.

iainmerrick6• 9 years ago

Why does Rust need those? Those are things you need when running untrusted code in a sandbox. Is there a scenario where Rust is used that way?

There's WASM, but in that case the extra checks need to be applied at the WASM level, not the Rust level.

josephg• 9 years ago

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?

6nf• 9 years ago

CPUs tend to have multiple cores these days, would it be possible to assign (in software) all kernal space work to one or more dedicated cores to mitigate some of the risks?

frik• 9 years ago

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.wikipedia.org/wiki/Xeon_Phi

Unfortunately they drifted of the target (instead of making it the successor of x86-64).

For Javascript engines, it would help if the offer an optional fallback "Javascript interpreter" instead of JIT. A JIT is basically at the moment insecure, especially when running untrusted code. The same goes for WebAssembly, let the user deactivate execution/support of it. Please allow end user to enable an alternative JS interpreter for high security things like online banking.

abecedarius2• 9 years ago

I always liked the https://en.wikipedia.org/wiki/J%E2%80%93Machine idea: gobs of processors each with a small private memory (nothing shared), in a fast mesh network. It fits with physics: accessing local memory can be fast, while distant memory physically just can't. But even if it's really all that, it's just so different from the architectures we've put so much work into or on top of.

pjmlp9• 9 years ago

What is the Rust for CPU design?

Intel iAPX 432 could have been it, but they did a lousy job implementing it.

https://en.wikipedia.org/wiki/Intel_iAPX_432

lower• 9 years ago

Note that the article talks about type checks for the JavaScript code that is being executed by WebKit, not type checks in the implementation of WebKit itself. So there are two different kinds of type checks involved here.

pizlonator15• 9 years ago

We are using pointer poisoning to protect type checks in WebKit itself as well as type checks in the JavaScript code we execute.

We are using index masking in WTF::Vector and WTF::StringImpl, which are used both for JavaScript execution and for lots of other things in WebKit that want a vector or a string.

rcthompson2• 9 years ago

Doesn't Rust do all its type checking at compile time, not run-time?

(Not to say that a correctly-written Rust program wouldn't be vulnerable to Spectre for other reasons, of course.)

FreeFull• 9 years ago

If I'm reading this correctly, the issue isn't with the types of the language you wrote the Javascript engine in, but with Javascript's types. All major Javascript engines are written in C++, which also does all its type checking at compile-time.

pizlonator15• 9 years ago

Rust has algebraic types, so Spectre could be used to train the branch predictor to take one type case of your match statement, and then have that case taken when the enum is actually in a different shape. That's a violation of the type system.

kibwen3• 9 years ago

I'm actually not sure what that passage is trying to imply at all, I've not seen any prior remarks that Spectre has that sort of implication. AIUI, Spectre lets you read arbitrary memory, not write it, so I'm not sure what they mean by "bypass the type check" and "craft arbitrary pointer". Here's another quote later on:

But Spectre could theoretically involve any branch that enforces security properties, like the branches used for type checks in JavaScriptCore.

I get the impression this is all referring to JIT'd JS, not to the C++ (or Rust etc.) code powering the underlying engine (where all typechecking is done at compile-time anyway). Of course having the JS engine written in Rust would still allow the same, but it's been known for a long time that Rust's typesystem can't do squat to verify the correctness of dynamically-generated code; it's part of the reason why Mozilla only bothered to kick off a rewrite of Gecko and not SpiderMonkey.

pizlonator15• 9 years ago

It's common for C++ code to do type checking dynamically. In WebKit we do this by rolling the type checks ourselves. With RTTI, you can do dynamic type checks using the build-in dynamic_cast primitive. Our changes, particularly the ones having to do with pointer poisoning, are meant to protect C++ code that does dynamic type checks in addition to JIT'd JS code that does dynamic type checks.

Rust's `match` statement is a dynamic type check just like C++'s `dynamic_cast`. I bet you it's implemented using branches.

cerved2• 9 years ago

AIUI you create a pointer by issuing an array OoB. The check against this is a brach statement followed by the array OoB. However, the CPU starts executing the array OoB while the check is happening and the memory in the pointer gets loaded into cache.

This is an architecture bug so any security check that relies on simple branching is potentiality vulnerable.

vasili111• 9 years ago

I'm really starting to think it's about time for me to get out of this business.

Maybe it is time to move to IT security business?

roca2• 9 years ago

Interestingly you could apply these mitigations in Rust itself --- array index masking where Rust has array bounds checks, and pointer obfuscation where you check the variant tags of algebraic types. Some extra work would be required for unsafe Rust code. That would automatically protect almost all Rust code, whereas most C and C++ code would have to be handled manually.

bradgessler• 9 years ago

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.

DamonHD• 9 years ago

This is what I already get with FF + NoScript.

And yes, I am bored by sites that I visit for the first time that will not show me any meaningful content until I enable layer upon layer of JS. Just not necessary, nor is it safe.

pmontra• 9 years ago

Sometimes you can open the developer tools and hack the CSS, because some of those sites hide content with a display: none unless some JavaScript removes it. If it's a site you often navigate to, there are addons like Stylus that can make those changes permanent.

duozerk3• 9 years ago

Same here (with noscript as well). Although I'll say it's hard to blame web developers for not considering the case where JS is disabled beyond a simple "you need Javascript to see this page" message (though even that tends to be the exception, not the rule), because noscript/umatrix users are probably in the low, low minority.

dredmorbius• 9 years ago

uMatrix, for everyone else.

It's a bit fiddly, but you can set moderately sane defaults. Well, sort of. If websites themselves were far more sane, this would be far less a problem.

rickycook• 9 years ago

similar to noscript, there’s “JS Blocker” for Safari. it’s truly an excellent extension; significantly more powerful than noscript because it allows hugely customisable rules for loading only some scripts on some pages (eg https and *.cloudfront.com when loading console.aws.amazon.com), rules about canvas usage, XHR requests and a whole lot of other things. it’s the honestly the only reason i haven’t moved back to firefox, because by comparison noscript is just SO awful!

http://jsblocker.toggleable.com/home

osteele• 9 years ago

Don’t you need to audit the extension source, and verify it matches the build (or build it yourself), to make sure it’s not exfiltrating data from visited web sites?

I’ve been reluctant to install extensions, because I’d have to extend my trust set from the OS and Browser makers, to the extension author and the integrity of whatever system they use for their build.

cornyNetHandle• 9 years ago

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.

80x25• 9 years ago

These mitigations feel like a half measure. To quote the Spectre paper:

"Even code that contains no conditional branches can potentially be at risk."

"long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform."

It seems too early to declare Spectre class attacks mitigated by the mechanisms presented in the OP.

pizlonator15• 9 years ago

Maybe more than half. ;-)

I think that the branch aspect of Spectre is the thing that WebKit is most affected by.

EgoIncarnate14• 9 years ago

I don't think anyone is claiming this is solved. Mitigations are by definition a half measure. "Mitigate (verb): make less severe, serious, or painful."

WillReplyfFood• 9 years ago

Translated this basically means- for real security to exist, the chip has to be open source down to the layout.

This will not happen. So basically, the interest of the one outweighing the interests of the many, results in the many suffering for what exactly?

dingo_bat5• 9 years ago

open source down to the layout.

I don't see what open source has got to do with any of this.

vog4• 9 years ago

This will not happen

Note that we do have good Open Source CPU designs, though, such as RISC V.

eridius• 9 years ago

I'm really curious how SharedArrayBuffer can be used to create high-precision timers. I'm also wondering what's now broken due to SharedArrayBuffer being removed.

indexerror• 9 years ago

From page 10-11 of [1]:

A shared resource provides a way to build a real counting thread with a negligible overhead compared to a message passing approach. This already raised concerns with respect to the creation of a high-resolution clock [19]. In this method, one worker continuously increments the value of the buffer without checking for any events on the event queue. The main thread simply reads the current value from the shared buffer and uses it as a high-resolution timestamp.

[1] https://gruss.cc/files/fantastictimers.pdf

syncsynchalt2• 9 years ago

By running a worker thread in a counting loop.

Laremere• 9 years ago

My understanding is: Have a web workers continuously increase a number, and save it to the SharedArrayBuffer. As long as the web worker is running, you have a steadily (enough) increasing timer that can be accessed by any other thread. It's not as precise, so relying on it makes things harder, but still usable.

roca2• 9 years ago

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 = ... get someProperty ...
    x = bigArray[index];
  } else {
    ... error ...
  }

and speculative execution could let the property value leak into the cache.

So I'm not optimistic about the prospects for fully automating defenses against Spectre without hardware fixes :-(.

om210• 9 years ago

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.

pizlonator15• 9 years ago

Hi Robert! It’s been a while! :-)

Oooh that’s a good catch. I agree that pointer poisoning and index masking don’t handle this case. Unless the pointer to the data structure being accessed (bigArray or whatever) is poisoned with a function of origin. Maybe that’s the way to do it.

I am still optimistic about this. It’s going to be a lot of work and there will be surprises but then that’s always true when writing software.

cm21877• 9 years ago

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 forms, etc), for the mere convenience of developers and for user hostile activities (tracking, messing with default behavior of the mouse, keyboard, clipboard, scrolling, etc).

This might be an opportunity for revisiting html and making it better. An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. Once we have a good enough markup alternative, executing javascript can become an optional feature requiring user authorisation like accessing your camera or location.

[edit] also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.

duozerk3• 9 years ago

Unless you're considering client-side encryption, I don't think webmails qualify either (squirrelmail, for example, works pretty well without JS).

littlestymaar5• 9 years ago

Indeed because auto-complete of recipient address from my contacts is useless, right ? Same could be said for retrieving new emails without reloading the page I guess …

Had JavaScript not existed, the web would be dead a long time ago already.

Vinnl• 9 years ago

That will only happen if users will stop visiting websites with Javascript enabled. Which will only happen if an actual exploit becomes so widespread that it affects most of them financially.

epenance• 9 years ago

This is false. Many websites are using Javascript to render the websites in full to give the users a better experience, such as rendered a SPA (Single-Page-Application) to prevent unneeded amounts of data loaded on each page request and only load exactly what you need, to give a faster, smoother and higher quality experience for the user.

Sure the mom down the street who wants to blog about the her kitchen recipes wont be needing it, but a lot of websites "do"

cm21877• 9 years ago

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.

JohnStrange• 9 years ago

You mean those eternally scrolling pages whose main purpose is to hide content that belongs to the user in the first place? These sites are a pest.

twic• 9 years ago

I would be absolutely astounded if there was any SPA which moved fewer bytes over the network than its plain HTML equivalent. HTML can be written compactly, and the repeated structures compress well; any increase in the size of the data over JSON will be more than made up for by not needing to load megabytes of javascript.

xtanx3• 9 years ago

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

LaGrange• 9 years ago

If you took away JS from Facebook and Twitter, they'd literally be a better experience. They'd be forced to give up much of what makes them painful to use. At least Twitter had a character counter, that was a useful JS feature, but they broke even that.

And if you need a diagraming tool, maybe a website isn't the best solution.

dingo_bat5• 9 years ago

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(<5)+css.

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.

endless1234• 9 years ago

Honestly, I think running webgames in a super-sandboxed flash (or similar) runtime is the best thing to do.

Why is one ECMAScript sandbox (flash) so much better than another?

send_computers2• 9 years ago

Yeah lets all just use bash commands to browse the web, way more secure and sure you can get the information you need... oh wait wasn't that 20 years ago?

om210• 9 years ago

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

SquareWheel6• 9 years ago

Not really, not if you think about it. Webmail doesn't need anything more than html(<5)+css.

Because redownloading the entire page every time you click a button is such a great experience...

iovrthoughtthis4• 9 years ago

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.

cm21877• 9 years ago

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 devices out there. We also need to fix CPUs, but that’s a very long term solution.

cabalamat• 9 years ago

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.

madez18• 9 years ago

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.

stesch• 9 years ago

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.

cm21877• 9 years ago

It’s too late until we are facing an unfixable hardware flaw that we will be stuck with for the next 10 years (until users fully retire the current CPU architecture).

madez18• 9 years ago

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.

amiraliakbari• 9 years ago

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.

golergka• 9 years ago

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.

krapp7• 9 years ago

I wonder if this shouldn't question whether we should still allow all websites to run javascript by default.

Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, or not allow anyone to program a GUI unless they can justify the use of canvas space. Yet the web, arguably the most successful and free (as in both beer and freedom) and accessible software platform yet devised, is the only one on which people - erstwhile hackers - 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.

What you're describing seems a lot like adding Windows UAC prompts to the web - no one would find that better, particularly given that anyone can simply turn javascript off in their browser already. This isn't even a javascript problem per se - you could erase javascript from the universe and make the web as plain as you like and Spectre and Meltdown would still exist.

also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.

That seems reasonable, and I would be willing to bet, possible to configure with modern tools. But pretending javascript is a second-class citizen on the web isn't the answer.

xtanx3• 9 years ago

no one is saying we should deactivate native apps written in unsafe languages

No we should definitely not, but we should encourage using something like rust or whatever comes after rust.

cm21877• 9 years ago

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.

UncleEntity6• 9 years ago

...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 click on a link 2) get past AdBlock 3) get past Privacy Badger

Seems like a privilege to me --and I'm not someone who cares all that much about the shenaganians the big webcorps get up to since I have no money so spend on their ad campaigns anyway.

alien_at_work6• 9 years ago

Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages,

That's not remotely a valid comparison. If I run a native app, I had to get that app somehow and install it. I know it can modify my computer (and probably have to give it persmission to do so). A web page can automatically load other pages, even in the background and do who knows what. For most of the existance of the web we've all had the mental model of "sandbox". We never had that for native apps.

Nursie2• 9 years ago

> Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages

This is not in any way equivalent to browsing an informational site and having arbitrary code execute.

> Yet the web ... is the only one on which people - erstwhile hackers - say that code should be a considered a privilege and not a right,

Hell no, code execution is a privilege in all situations! I don't just download scores of random executables and run them. Do you?

> But pretending javascript is a second-class citizen on the web isn't the answer.

Making it one might be an improvement though. There's no way in hell I should be (to give a recent example) browsing a keyboard review and notice that my laptop now sounds like an aircraft about to take off because the site is running something unidentified as fast as it can (likely a coin miner).

ancarda• 9 years ago

Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages

Isn't that exactly what a lot of people have been saying ever since Rust started taking off? Every time there's a security vulnerability, someone suggests rewriting the program in Rust, if not some other safe program.

jbreckmckye5• 9 years ago

An ecommerce, a newspaper or a blog should have no reason to execute client side code to render.

The main reason is advertising, which is ultimately how this web content is paid for.

But there could be alternatives. We could create static img elements that could securely and discretely record whether they were viewed by a human (to prevent ad fraud). We could support simple animations and interactivity in a secure, resource-friendly way. And we could allow these to be disabled by user agents (e.g. epileptics).

Could newspapers exist without online advertising? Possibly, but only in specialised niches. Consumers have shown that they will always seek the cheapest, most accessible forms of information - even when provided by highly biased, unreliable sources.

The danger to killing online advertising is that it creates a world where the only people who can afford to publish are those with other interests - plutocrats, politicians, churches - and who will inevitably bankroll news only to further political ends.

UweSchmidt3• 9 years ago

Static img elements with built-in surveillance and tracking, unblockable and intransparent, on a browser level? You have to be kidding.

The ad-based web economy had produced the current publishing dystopia in the first place and prevents the development of a sane business model.

krapp7• 9 years ago

The danger to killing online advertising is that it creates a world where the only people who can afford to publish are those with other interests - plutocrats, politicians, churches - and who will inevitably bankroll news only to further political ends.

You say that as if server space is super expensive, but it isn't, certainly not compared to other forms of media. It's entirely possible to publish to the web without being an elite, people and businesses did it for years before advertising on the web became a thing.

htk• 9 years ago

This whole thread became a big "throw the baby out with the bathwater". Of course there is a long way to a secure web (if that is ever achievable), but disabling javascript is just a lazy alternative, creating a lot more nuisance than whatever damage is being done via javascript lately.

OTOH the "chain of trust" idea looks promising. And increases the responsibility on the visited website, because if it wants third party content to run javascript it'll have to host it itself.

optimuspaul2• 9 years ago

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?

roywiggins• 9 years ago

I can't help thinking that some large percentage of what Javascript is used for could be replaced with a much less powerful language.

_0w8t4• 9 years ago

It is not clear from the article how WebKit avoids changing semantics with array index masking. In JS out-of-bounds access should return undefined, not a random element of the array. To preserve that a branch still has to be made.

bennofs2• 9 years ago

If you combine index masking with a branch that should still be Ok. For example, if you do `if(idx > arrayLength) return undefined else array[idx & mask]` then the CPU can only predict "return undefined" or "array[idx & mask]", none of which can cause any harm.

_0w8t4• 9 years ago

Does that imply that WebKit always allocate by power of two and a script cannot read the memory for unrelated allocation between the array length and the nearest 2n?

bakery2k2• 9 years ago

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://blog.mozilla.org/security/2018/01/03/mitigations-lan...

[3] https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...

UncleEntity6• 9 years ago

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.

swinglock• 9 years ago

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.

pizlonator15• 9 years ago

Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT?

Yes.

What about the JVM and Microsoft's CLR?

Yes.

bakery2k2• 9 years ago

Thanks. I suspected as much for LuaJIT because, like a JavaScript engine, it supports JIT compilation of untrusted code. It's interesting to hear that PUC Lua also needs these mitigations even though it's only an interpreter.

As for implementations of Python and Ruby, they might not worry about these attacks - because AFAIK they do not try to support secure execution of untrusted code.

_0w8t4• 9 years ago

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.

olliej2• 9 years ago

The masking is done in addition to bounds checks, not instead of, so no it isn’t adding a mechanism to write out of bounds - the masking is purely to limit the upper bounds of speculative load distance.

As far as the attack: writing to memory pulls the effected page into the cache just as a read does

0x7f3• 9 years ago

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

0x7f3• 9 years ago

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.

pizlonator15• 9 years ago

This is clarified later: “Spectre means that branches are no longer sufficient for enforcing the security properties of read operations in WebKit.“

It’s totally true that Spectre allows attackers to control reads, but when they do this, they enter a non-destructive execution mode. They can read but anything they write is thrown away. (To our knowledge, lol.)

What Spectre and Meltdown Mean for WebKit

Related Stories