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.
> 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.
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.
No. Unless the application downloads and executes new code from third parties neither you nor application author can control every time you launch it, it's absolutely not comparable to most of the websites.
>Random, unexpected, untrusted c/c++ written code doesn't execute on my machine every time I browse a website.
It does every time you run a native application, for the same values of "random, unexpected and untrusted."
>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.
Fine. Turn it off then. That's an option you don't really have in any other runtime, so take advantage of it. But just because you don't want javascript on the web doesn't mean it doesn't belong there when authors choose to include it as part of the content they serve.
Also, how exactly does one run "3rd, 4th or 5th party" javascript?
> Also, how exactly does one run "3rd, 4th or 5th party" javascript?
You load a page that includes 3rd party scripts/iframes that themselves load 4th party scripts that themselves load 5th party scripts, etc. You often notice that when you start blocking an ad in your browser and suddenly 10 others disappear at the same time.
>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.
Same thing could happen to apps. There was a Baidu app in China that secretly downloaded random videos just to eat up the users' data plan, so they will buy more data.
Again: we've always known that desktop apps were risky and could do anything to our computer (and for years, a lot of "free" windows software installed malware and viruses). We were always told that JavaScript is "sandboxed".
>> 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).
>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.
> ...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.
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 code because it is better hidden (comes from the same domain and does nothing obvious bad). Just because you use Adblock, malicious code will still be able to run. You are just less likely to notice it because it does nothing obvious so people don’t notice it as quickly and it will not get blocked. If you don’t want to run malicious code at all unless you trust this website, you should probably consider running NoScript.
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).
Javascript is a safe language, but it's powerful enough to exploit Spectre and Meltdown. Rust would be the same. It's not badly-written programs we need to worry about in this context, it's well-written malicious programs exploiting badly-designed hardware.
We don't need apps written in safe programming languages to fix this problem, we need secure browsers, OSes and hardware. (And yes, those bits should be written in safe languages.)
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.
> 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.
You can certainly standardize a certain set of feature and put them in a non-turing-complete language like HTML, but standardizing all the legitimate use-cases of JavaScript is almost impossible, you talked about «drop-down menus, form validation or adaptive rendering», but what about interactive charting, modal view of full-size pictures, auto-completion of search tags ? These are just features I use on my personal blog ! And what about infinite-scrolling ? What about partial content-update ? There are thousands of legitimate use-case for JavaScript: it's not achievable to standardize every single one of them and put it in the HTML, and even if it were possible, do you imagine the nightmare it would be to learn HTML then ?
> but standardizing all the legitimate use-cases of JavaScript is almost impossible
I see the problem of not always having the newest technologies in browsers, but the pain of that problem vanishes the more we already have. One might say that securing JavaScript sandboxes is almost impossible, but still we are working on it. Let's work in the same spirit on advancing the open web :-)
I would be careful about that: It wouldn't suprise me if HTML with CSS (at least with all the new things like animations) is turing complete (it probably is).
‘You can encode Rule 110 in CSS3, so it's Turing-complete so long as you consider an appropriate accompanying HTML file and user interactions to be part of the “execution” of CSS.’
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.
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 browser. The delay is not a nuisance nor a cost without any benefit. We maintain the open trustable web by doing that.
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.
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?
> 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.
A taxidermist could argue that dead animals are better than living ones : they are indeed more convenient, less dangerous and cheaper to feed. But they aren't animal anymore, are they ?
Absolutely true. However, I'm not also not likely to find my stuffed cat slowed to a crawl and using all my electricity by mining Bitcoin because some 3rd party advertising network got compromised.
> However, I'm not also not likely to find my stuffed cat slowed to a crawl and using all my electricity by mining Bitcoin because some 3rd party advertising network got compromised.
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.
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.
Both good points (although the second one could be handled through a meta refresh I guess). But I'd like to point out we were discussing where javascript is absolutely needed, not where it's convenient.
It's absolutely needed in the sense that «without it the web wouldn't exist», something else would be there, with the same security issues or worse.
Remember when the web allowed no video playback ? Flash was everywhere ! And Flash was non-standard and closed-source, maintained by a single company without competition. The current state of the web is a massive improvement compared to what it was 10 years ago, especially on the security side.
If you want to create a webmail (or any other web platform) that needs no JavaScript, go ahead. I doubt you'll be successful competing against people using JavaScript, but if the demand for a JavaScript-free web experience is big enough, you could live happily in that niche.
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.
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.
> 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.
> The ad-based web economy had produced the current publishing dystopia in the first place and prevents the development of a sane business model.
Ah, the 'better business model' argument! A curious specimen, men often speak its name, but rarely agree how it looks or its habitat. Is it a donation model? Wait, no, that doesn't work. A paywall? Ah, but you want content for free. Philanthropist support? Oh, you don't like the conflict of interest. Micropayments? I suppose you have some cunning way of mitigating the transaction costs, without computationally expensive solutions like bitcoin.
Here's my proposition: post a model that is known to work, known to scale, for general purpose content, and you will have a startup on your hands. Otherwise - I ask you to withdraw your comment.
But then why haven't "Spotify for Journalism" projects ever worked? How does a business go from $2 per paper to 0.2c per article? Why are so many artists so unhappy with their meagre Spotify royalties? I think this falls under my "proven to scale" condition.
[In reply to the below - as we have reached the thread limit: there will _always_ be free competition. The problem is: without advertising, the only players left will be those with deep pockets, and deep interests to protect - the state, churches, oligarchs and political groups]
Regarding royalties: My understanding from school is that radio royalties are paid out by samplings from radio playlists. If you song was in the sample then you got paid, otherwise, nope!
Don't the current streaming tech pay artists per literal play? If so, wouldn't that mean more money to the artists since all plays are counted?
My understanding is a bit outdated now perhaps, but would like to understand better if someone knows better :-)
>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.
>The people were hobbyists and the businesses had other projects.
Yes, but my point is that publishing to the web doesn't require advertising on the web. Nor does advertising on the web require javascript.
>Relying on "interested members of the public" for news is how people like Alex Jones get started.
It's how a lot of people got started. You seem to be implying some relationship between the presence of political extremism and the absence of advertising, but I don't see any evidence the two are correlated.
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.
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.
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.
It doesn't matter. The playing field itself allows for shitty practices, and people/companies engaging in those shitty practices get more profit than those who refrain from it.
As long as shitty practices are supported by the browsers general population uses, nothing will really change.
Money doesn't win every fight. And not every fight is about money. For example, Mozilla is a non-profit organization. It's not about making everybody stop doing the wrong thing, it's about doing the right thing. Having one modern browser ditch JavaScript would already be a huge win, and people who care could use it. If Mozilla pushed the open web, it would already be much better, because all those open projects could use that. Not everybody uses Googles or Facebooks websites.
This fight is about money, because you're going against the entire industry, asking some players in it to self-sacrifice.
> Having one modern browser ditch JavaScript would already be a huge win, and people who care could use it.
For a short while, maybe, but as people making websites don't care about minority browsers, the amount of important websites you wouldn't be able to use through that browser would only grow, until the point that browser becomes useless.
People making money off user-hostile activities won't voluntarily stop making money off user-hostile activities.
It is not about making everybody stop doing user-hostile activites. That is my main point here, it is not about that.
There are people who have a website and don't want to monetize the visitors. I want a standardized web for them. Not everbody has to belong to that group for it to have merit.
I don't expect Microsoft or Google to stop making their online office stuff. Honestly, I couldn't care less what they are doing. I want solutions for those that serve the users, and nobody else.
Not everyone who uses javascript does so to monetize visitors. It's just a scripting language, it can be used for anything - and any user or publisher who doesn't want to use it already has the freedom not to.
I agree, and I think it is a pity that JavaScript is necessary for a lot of useful functionality which could be standardized to be made available without JavaScript, so people who care can browser the web and their sites in a browser that doesn't support JavaScript and still have a rich experience.
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 level of abstraction.
>The code on my machine is reviewed, vetted, accounted, maintained and free. That is the big difference.
Is it? By whom? Not by you personally, not all of it. Blind trust is unavoidable at some point.
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.
If that - just that - is your scope, then count me in.
I'd love to have a "standard web" that's entirely focused on providing visitors information in an efficient manner. And by efficient I mean not fighting attempts at providing better UIs or aggregating information through machine methods.
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).
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"
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.
Yeah and if you visit a site everyday, the JS is cached, too. After the initial download, it shouln't be an issue. This is besides the fact that it should not take MBs of JS to make complex applications.
The issue is what people are choosing to do with the tools, not the tools themselves.
HTML can be cached, too. Even if JavaScript permitted some clever way to safe network traffic like for example delivering the site as a torrent that is then downloaded from other visitors [0], then we can standardize that and implement it as a part of HTML or so.
Except that the current trend in webdev is to deploy small incremental changes multiple times per day and cache-bust the assets that change on each of those deploys. So the user is probably actually downloading the JS asset at least once per day Monday through Thursday (because no deploys on Fridays).
Well right now the problem is that the tool is broken. We have a long term non fixable issue (outside of replacing the hardware) with non trusted code running locally.
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.
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.
Nonsense. Bad tools are bad tools as evidenced by the fact that literally no one can use properly at scale.
Evangelists of bad technologies always like to trott out the nonsense about "a good carpenter never blames their tools"... well of course they don't: they buy the tools and always buy the appropriate ones. Further, if they did complain the customer would wonder why they bought bad tools in the first place.
A carpenter would never try to build a building with a "JavaScript" equivalent in the first place. They recognize the tool as garbage (perhaps after trying, and failing, to use it) and switch to something more appropriate.
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.
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?
And it would still be possible if web standards didn't accrue so many capabilities that allowed people to treat them as a new medium of publishing color magazines (with invasive tracking as a cherry on the cake).
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.
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.
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.
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 speculative execution are themselves inefficiencies (i.e. spending power to do things that will turn out to not be needed fairly often).
>the naive implementation would be the best implementation
Not the naive implementation. A well thought out, developed implementation that is defeated by deep hardware details. The promise of high level languages was always to avoid having to know these sorts of details. In designing an algorithm I should be worried about things like how often I access data (e.g. can I cut down on how many accesses with some clever structure?) and the like. Now that's all trumped by deeply knowing the low level implementation.
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?).
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.
The mitigations are largely in code produced by the JIT. It's not hard to patch the JIT's codgen to back this out (perhaps even based on current CPU) if it becomes unnecessary. It would be nice if CPU architectures never had this fundamental vulnerability, but they do. So this seems like the best response for the reality we actually live in.
Sorry maybe I missed something but you had some really cool techniques to avoid using branches to do things like array length checks and type checks? So you replaced an if branch with a new, potentially slower, and harder to understand concept. I was not trying to imply you removed all branches.
It is a really cool piece of engineering but we can still be sad we have to implement it.
(On the hardware side I was assuming sommeone clever at Intel will come up with some security non Perf killing change to make branches trustable again).
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.
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."
More security experts would be encouraged to have a look at the design and to find flaws early on.
Of course, we all know that this doesn't always happen, see OpenSSL. However, once a major incident (Heartbleed) happened, they did: Many more OpenSSL issues were found and fixed, forks with different trade-offs came into place. For example, LibreSSL traded backwards compatibility with ancient systems for a smaller code base and increased security.
Since CPU designs are not Open Source, and on top of that flooded with patents, nothing like that will happen in this space. Intel and AMD are on their own, rather than having their design checked by a motivated international research community.
But these attacks (Meltdown/Spectre) are on a fundamental design approach, which was conceived and developed and researched in the open. People in colleges all over the world study about them. Do you really think this would have been caught much sooner is Intel had released all schematics and layouts to the public?
I'm just saying that in general, the incentive for a scientist to put work into an open system is orders of magnitude higher than to put work into a closed system.
To provide a similar example:
The crypto experts around Daniel J. Berstein and Tanja Lange stated publicly at 34C3 that they refused to perform crypto analysis on a certain algorithm that was patented. But they (and others) published good crypto analysis results (working attacks!) just a few months after the patent expired.
> I'm just saying that in general, the incentive for a scientist to put work into an open system is orders of magnitude higher than to put work into a closed system.
They already do that, I'm sure you can find a multitude of papers on branch prediction and speculative execution if you simply took the time to look. Probably even some by the very same people who designed the Intel chips causing all the fuss.
Nobody said there is no research, just that openness would lead to more research. Even "a multitude of papers" was obviously not enough to catch this earlier.
On top of that, please refrain from personal attacks.
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?
> 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.
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.
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 :-(.
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.
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.
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 to break :/
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?
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.
> 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.
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.
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 sites Flash was just to play videos or display ads. Many sites only had to replace an object tag with a video tag. Java Applets were fairly niche in the first place, so aren't really comparable.
In addition there isn't currently a viable alternative for Javascript. Maybe WebAssembly someday, but currently it's designed to supplement Javascript not replace it.
Would you consider yourself a typical example of a naive user? The security default needs to work for everyone. I think the sandbox approach is better than expecting everyone to correctly decide when it is or isn't okay to allow a site to run code.
You must run in much better circles than I do. Nevermind a naive user, the average users I know wouldn't know how to disable javascript, or whitelist sites, or that there even were sandbox settings in the OS.
Some of the older people I know can't even correctly choose between between writing a text message, and a facebook post.
If you think you are a typical example of a naive user, I would hate to see what you expect of the average user.
iOS, Android and UWP sandboxes for native apps are always enabled, there isn't any configuration for naive user available.
You just allow or not the access to specific actions and that's it.
On UWP you cannot even access files directly, the user has to select them for your application.
You can only change the way sandboxes behave via developer settings, but that is only in the context of debugging, which naive users will never do anyway.
> 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...
The users didn't make the decision, the platforms did, and the decision was made after an alternative was available in Javascript.
If anyone killed Flash and Java, it was Apple by refusing to support either on the iPhone. All the users did was make popular a platform that didn't support them. If Apple had supported Flash and Java we probably would still have them.
Signed code that users had to install was tried before with ActiveX. It didn't work either because you can't rely on random developers to write secure code either. It's also how IE ended up with Flash. Click here to download Flash (signed by Macromedia).
So basically everything sucks because we're human and make mistakes. Maybe one day we'll have machines that reason more thoroughly than us and they can come up with a secure platform. Until then... Javascript and sandboxes.
> If anyone killed Flash and Java, it was Apple by refusing to support either on the iPhone.
Apple may have put the nail in the coffin, but long before that quite a few developers and users were avoiding Java programs when there were alternatives, and ClickToFlash was a popular browser plug-in. As they often do, Apple saw which way the wind was blowing.
I don't think WebAssembly is going to bring back Flash or Java Applets in any meaningful way. Maybe someone will hack something together and use it for niche old Flash game sites, but it's hard to see a reason for widespread adoption of anything new. People have moved on.
Flash and Java Applets may not be "dead" forever, but they also are not likely to ever be more than undead zombies.
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 java.applet.Applet in any mainstream way. In that sense Flash and Java Applets are dead. Maybe someone will hack something together that allows you to run them, but that won't bring the developers back to the old platforms.
If Oracle or Adobe announce something, maybe the industry will jump on board, but currently I don't see anything in your list that makes me change my mind about Flash and Java Applets being dead and not coming back.
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.
> Not paying attention to the news? Just wait until WebAssembly gets more mature.
Not yet. If "WebAssembly" is anything like actual machine code, then it will be easy to compile a bunch of languages to "WebAssembly," and a huge pain to make them talk to each other. So nothing really changes.
> 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.
>> 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.
How is it any more of a fatalist stance than the idea that javascript or running untrusted code in a sandbox is fundamentally broken?
Personally I think it's easier and more likely that we attempt to fix a few web browsers than expect millions of websites to change. You might call it fatalism, but I think of it as realism.
>> 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 not!
My point was not that security is useless because users are unreliable. My point was that it's better to keep the kids in the sandbox, than to have them play in a busy street. Security should be preserved in spite of users actions, not rely on them.
> Personally I think it's easier and more likely that we attempt to fix a few web browsers than expect a millions of websites to change.
This is the same argument I criticized before. The world doesn't change completely over night because one changes their own actions, and that is fine. These million websites maybe never change, and that's what we'd have to live with.
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.
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.
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.
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).
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.
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).
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.
Let's stick with the reddit example. The up/down vote links could be standard anchors with additional tags <a href="upvote" reload="comment#564534">^</a>. Inline posting could be similar.
It doesn't take much to do 99% of what we want with javascript and server side rendering, we used hacks to do it before javascript so I'm sure we could design something even better. It doesn't sacrifice anything.
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?
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.
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!
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> > 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).
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.
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?
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.
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.
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.
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`.
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.)
Thank you for clarifying, that what I thought. Still I find that the article is not clear enough on this point, I fell that some people will read this as "OMG they can control execution remotely, this the apocalypse". I mean to an extent yes, but the results are dropped like you said and the main execution path shouldn't be affected. It only facilitate information leaks AFAIK.
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.
Oh you're right. Specifically, they kept the CFBundleShortVersionString the same, but updated the CFBundleVersion. My guess is that updating CFBundleShortVersionString is a marketing decision. Maybe Apple is waiting till all the WebKit fixes related to Spectre/Meltdown are available before updating it?
Also various Apple systems define CFBundleShortVersionString to be of the format A.B.C, no fourth element allowed. macOS versioning is still stuck with 10 as the A, B identifies the major release and C is the point release that is effectively also marketing driven. With iOS the first number is used for the major releases so C is available for bug fixes.
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.
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
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.
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.
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?
No, it means attacks are still possible in the memory region just after the buffer, when it's smaller than the next power of two. Not ideal but it's better than nothing.
> 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.
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.
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.
> Rust's `match` statement is a dynamic type check just like C++'s `dynamic_cast`.
I wonder if this is a case of a difference in terminology, because enum variants (the branches in `match` expressions) aren't considered types in Rust, and have no interaction with Rust's typechecker (Rust always has to assume that every instance of an enum can be any variant, even in cases where we as the programmer know that only one variant is possible).
At the same time I'm still unclear on what the OP is trying to imply. To reiterate, AIUI Spectre can only read, not write, privileged memory, so it's impossible for a Spectre attack to trick the engine into believing that (to use Rust terminology) an instance of an enum is a variant that it isn't. Am I incorrect?
1) Write a function that reads the "nth" value out of an array in JS.
2) Call the function a bunch of times with JS arrays.
3) Pass an integer to that function for the "array" value. This would normally end up throwing. But before it does, the CPU might speculate the VM-internal typecheck as "it's going to be an Array, like the previous 1000 times" and end up doing an "nth value" read out of a memory address that you fully control (by changing which integer you pass).
That is, you can use speculative type confusion in the VM to allow precise control over what memory addresses get accessed and how for your timing attacks on the cache.
if is_pointer(pt):
// do pointer-based stuff
else:
raise error
If you train the branch predictor to expect a pointer, it will speculatively treat arbitrary values as pointers until it can determine that they are not. So you can pass in any value and get it treated like a pointer for the duration of the window of speculative execution.
Any conditional branch is potentially vulnerable, an attacker just needs some sort of side effect from speculative execution that persists after rollback.
Thanks for the reply, I think I've got it now: the ultimate attack is still to read arbitrary memory, and the part about defeating typechecking and crafting a pointer is intended to expand the range of memory that can be read.
Serious question, is it even possible to have something like ‘match’ or ‘dynamic_cast’ in a programming language without using branches under the hood?
I’m not talking about research/example microprocessors that don’t have equivalent instructions. I mean isn’t branching a fundamental logical construct and we either do it in hardware with branch assembly operations or emulate functional equivalents of them in the software that runs on the microprocessor some other way? Or is there some clever/old logical/mathematical “alternative” to branches?
struct __internal_variable {
uint64_t type;
void *data;
}
uint64_t __last_type = [number of builtin types];
whenever you create a new type: increment __last_type and associate that type with the number;
uint64_t typeof(__internal_variable var) {
return var.type;
}
function[__last_type] typechecks;
functions[] = void function(uint64_t type) { failure; }
functions[int] = void function(uint64_t type) { success; }
functions[typeof(myvar)]()
If typeof(myvar) is int, then the function that returns success will be called, otherwise failure, no branches involved! Yes, it's a kludge, but it kind of works.
---
Of course, you don't actually need this trick. If you put enough effort into it, you can essentially compile anything to c, after which you can just compile it with the movfuscator[1]
It is even worse then switch/match statements. The jump tables can be used to train CPU to jump to a wide variety of addresses than switch/match statements so mounting a speculative execution attack is simpler.
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.
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?
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?
> Since the 2010 Westmere microarchitecture Intel 64 processors also support 12-bit "process-context identifiers" (PCIDs), which allow retaining TLB entries for multiple linear-address spaces, with only those that match the current PCID being used for address translation.[19][20]
Some of the newer Intel server CPUs allow statically partitioning the shared L3 cache between cores. It might (or not) work as a way to reduce side channel communications between cores.
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.
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.
It was painful - mostly because we don't have good tools for that sort of thing and most of our programming sort of hides the idea of multiple CPUs and pretends it's all working at once (in terms of us writing the code anyhow).
It's all abstracted in a very linear way.
Changing all that will take a lot of time if we do.
Actually multiple CPUs are not normally hidden in mainstream programming languages [1]: i.e. threads are visible. The fiction that it is maintained by the programming languages and hardware is that of a single, coherent address space, which Cell very much did not have.
[1] outside of parallel iteration/folding constructs.
> 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 way to the bank.
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.
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.
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.
Well, Meltdown mitigation involves unmapping as much Kernel as possible when switching modes. It’s so much overhead that I wonder if uK messaging and process context switching is cheaper and faster.
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.
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.
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.
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.
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.
Not quite. Our C++ code often does static_cast<> as a downcast based on testing some condition. That's a run-time type check. This isn't solely about those type checks that were implemented using some built-into-the-language type checking mechanism. Also, C++ does have a dynamic type check primitive (dynamic_cast).
We are mitigating these branch-based type checks with pointer poisoning, and I don't think that those changes are biased in favor of C++ or JS, since both are vulnerable.
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.
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?
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.
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.