About 12 years ago I was fighting a losing campaign against JavaScript’s ubiquity. There was a time when JavaScript was a security nightmare, and I ranted and raved against it. Things have changed enormously since then, all for the better. A few of the slogans that I and my colleagues shouted from the rooftops in the previous millennium seem to have stuck in the public mind, “Using JavaScript is insecure” or “JavaScript can’t be used for encryption”. Those slogans are no longer true. This post talks a little bit about how things have changed.

What has happened over the past dozen years falls into two categories. The first have to do with the way browser developers look at JavaScript. All of the vulnerabilities in handling JavaScript taught browser developers to be much more systematic and careful with how they handled JavaScript itself. The design of JavaScript and browsers have gone through a lot of change during this time.

Playing in the sandbox

The second category of change is more recent, and it really changes the game. The buzzword is “sandbox”, and it needs a lot of clarification because it is used all over the place in different ways. Roughly the idea is that something can do what it wants within a limited area and cannot really interact with anything outside of that sandbox. It is a safe place to play.

Increased browser sandboxing affects 1Password in two very big ways, and these are because of two different kinds of sandboxing relevant to us.

Sandboxing the browser

The first sandbox that matters for us is that browsers are becoming increasingly restrictive in what bits of your system they can interact with. The way that 1Password interacts with Safari 5.0 and earlier is profoundly different than the way that 1Password is allowed to interact with Safari 5.1 and above. Prior to Safari 5.1, there were “hooks” in Safari that allowed external applications to communicate with Safari. But in Chrome, from its inception, and in Safari from version 5.1 that kind of communication isn’t allowed. This is a major security enhancement; it limits the damage that a browser exploit can do. A successful browser exploit now can only interact with data and processes that are within the browsers’ sandboxes.

The upshot of this is that we have had to entirely redesign our Safari extension to fit within the tighter, better security model of Safari. It means that 1Password needs to work within the browser to do its job. That work must be done using only CSS, HTML, and JavaScript. Clearly for 1Password most of that work will be in JavaScript.

Sandboxing the extension

Browser extensions shouldn’t step on each others’ toes. We need to prevent this not only for security reasons, but for stability reasons. Extension X shouldn’t be able to see the database created by extension Y. So each Safari extension is also put in its own sandbox. This not only protects others from a misbehaving extension, but it protects the extension from outside interference from other sources, including JavaScript in the web page a browser is visiting.

JavaScript and encryption

People used to say that you can’t do encryption in JavaScript (because it doesn’t have the right data types, and because as in interpreted language it is far too slow). I suspect that most readers will have noticed that computers have gotten a little bit faster over the past 10 years. So while JavaScript may not be ones first choice of language coding encryption routines, there are now well developed, publicly available implementations of all of the algorithms and protocols that we rely on.

Users of 1PasswordAnywhere over the years have already experienced JavaScript opening of their 1Password data.

Times, and rules of thumb, change

It seems like yesterday (though it was actually years ago) that I was telling people to distribute documents as PDFs instead of word processer documents, because PDFs can’t be exploited in the same way. (As an aside, I would like to mention that there is a new security update for iPhone which fixes an exploit that can live in a malicious PDF file). It’s also true that the password advice I would have given 10 years ago is much different that what I would give now. The tools and the threats have changed so much. So it is with JavaScript.

Share this entry

https://blog.agilebits.com/wp-content/uploads/2014/09/agilebits@2x-2014-logo.png00Jeffrey Goldberghttps://blog.agilebits.com/wp-content/uploads/2014/09/agilebits@2x-2014-logo.pngJeffrey Goldberg2011-07-15 19:37:462011-07-15 19:37:46JavaScript grows up and plays in a sandbox

In Safari 5.0.5, 1Password seems to work fine even when JavaScript is disabled for browsing. Will this continue to be the case in Safari 5.1 with the new extension? I hope so, since even with sandboxing it feels a lot more secure to leave local scripting turned off.

It occurred to me that perhaps 1Password is able to use JavaScript even if JavaScript is turned off for browsing is that the case?

That is a great question. It appears that this will be a problem for people who turn off JavaScript in Safari 5.1 and above. Ideally, it would be nice if the switch to turn on or off JavaScript would distinguish between JavaScript from the website vs JavaScript from an extension, but that doesn’t appear to be the case at the moment.

Another thing we can hope for, which isn’t in place at the moment, is a Safari analogue to the NoScript extension for Firefox. This gives the user the power to say exactly which sources are trusted for running JavaScript.

As I suggested in my post, I used to do as you do now. That is, I would turn off JavaScript and advice others to as well. But I switched my views and behavior in this respect several years back for the sorts of reasons that I’ve posted. JavaScript isn’t the threat that it once was. With the increased sandboxing, I am even more confident that running with JavaScript enabled adds little significant risk.

Far more important is keeping up with browser updates to the most current stable version of your web browsers and doing systematic software and system updates. I know that there are plenty of people who still “have to” run Internet Explorer in the work environments, but I plead when them to upgrade everywhere they can.

Are you saying that if JavaScript is turned off in Safari then with Safari 5.1 1Password will cease to function? I hope that’s not the case.

Opinions differ about the safety of JavaScript, as I’m sure you know. I don’t think Steve Gibson, for example, would agree with your equanimity about it, even now with it’s improved security. In any event, the speed penalty with JavaScript enabled is very significant, even on my 8-core Mac Pro.

I would be very disappointed to learn that I could no longer use 1Password if I decline to enable JavaScript by default, since that was not the case until now and as far as I know we users never had any warning our investment in 1Password (not just the very reasonable cost, but more importantly the large amount of data that cannot be returned to the Keychain easily) would be squandered at some point if we don’t want to turn on JavaScript.

Apple has (for very respectable security reasons) decided that developers can only interact with Safari, from 5.1 onward, using HTML, CSS and JavaScript. That is a fact which we are all faced with. Nothing you are I say can make that fact go away.

1Password 3.6 continues to support Safari 5.0, but future versions of 1Password need to adapt to the rapidly changing environment in which it lives. There will always be a version of 1Password available which integrates with the Safari 5.0. Just as we’ve continued make a version of 1Password that runs on Leopard and even Tiger. But short of persuading Apple to maintain the old plug-in mechanism (which has it’s own security issues) there really isn’t any choice.

Let me take this opportunity to point out something I omitted in the original article. (I was waiting for someone to ask further details in comments). One of the mechanisms used to sandbox Safari extensions is that they are each given their own secret “workspace” when Safari is run. Without knowing the key for that workspace, nothing from the outside can access methods, procedures, data, etc within that space. While things within that workspace can access other things in there, they can’t even reveal the key to the workspace. So they can’t even be tricked somehow into revealing it to bits of JavaScript outside of it.

I realize that that doesn’t address your concern (about enabling JavaScript in the first place). Bus as nobody asked about it, I thought I would mention it here. However, it is relevant to my broader point about how browsers and JavaScript have changed.

If you don’t want to use a browser that requires everything be done via JavaScript, you can either try to not update to Safari 5.1 (I don’t know how feasible that is, if you move to Lion) or that you use a browser such as Firefox. There is no option but for use to interact with Safari 5.1 in any way other than through JavaScript.

About this, I should point out that Firefox is likely to follow the road pioneered by Google Chrome and which Safari has followed. Chrome’s security model, when introduced, was far tighter than the likes of Safari and Firefox. It is for security reasons that Safari is emulating (and improving upon) Chrome’s security model. I can’t be certain, but I suspect that in a few years, all browsers will be doing this.

I do agree that it would be nice of Safari 5.1 had more fine grained control about allowing JavaScript, so that it could be turned on for extensions, but not for website data. We can hope that some capability of that nature will be introduced soon, but I’m not in any position to predict that.

I’m really sorry that this isn’t what you want to hear, Bill; but I hope that it helps you look to the future.

Thanks for the detailed explanation, Jeff. It does sound like you don’t have any choice. And, for better or worse, I must admit that JavaScript is quickly becoming part of the very fabric of the web. We’re in agreement that the best compromise is to allow users fine-grained control over this powerful technology that allows outside code to run on our computers. I wish we had more. Thanks again.

Sorry for not responding earlier, but I’ve been travelling with my family up to Yellowstone National Park.

You are correct that we are forced into using JavaScript. We have no choice. But this still is a good move with respect to security. The security differences between Safari 5.0 and 5.1 is like the difference between Windows XP and Windows 7. The security improvements in Safari 5.1 are not just the run of the mill fixing of particular bugs, but it is an entire change in the security architecture. Narrowing the ways in which processes can interact with Safari is only a small part of that.

For a somewhat technical summary of the kinds of security changes we see in Lion and Safari 5.1 see