Mike West

XSS (No, the _other_ 'S') - CSSConf EU 2013

2013-09-24T00:00:00+02:00

I had the distinct pleasure of talking with folks at this year’s CSSConf EU about the dangers of content-injection attacks. They’re not just for JavaScripters, you see: CSS is dangerous too! They’ve just posted the video, and I think it’s worth a little under a half-hour of your time to skim through. You’ll be shocked to learn that Content Security Policy makes an appearance.

Credit is due to Mario Heiderich, et al. for their excellent paper “Scriptless Attacks - Stealing the Pie Without Touching the Sill”, from which I stole much of the attack-based content. Awesome stuff.

Transcript is coming, but for now, please do enjoy the embedded video and slides below:

Video

The video is 29m long, and up on YouTube for your viewing enjoyment.

Slides

The slides are up on Speaker Deck (which is awesome), and I actually used Speaker Deck to present the slides from someone else’s laptop since my computer decided not to connect to the conference’s projector. I love you, Speaker Deck!

Transcript

Coming soon!

Frontend Security - Frontend Conference, Zürich 2013

2013-09-09T00:00:00+02:00

Last week, I was in Zürich attending Frontend Conference (talks and slides linked up on Lanyrd), and had the opportunity to chat with the folks there about client-side security. Content Security Policy, shockingly, was central to the discussion.

In the interests of making the presentation as accessible (and indexable) as possible, a full transcript of the presentation is below, along with an embed of the video and slides.

Video

The video is 48m long, fully captioned, and up on YouTube for your viewing enjoyment (I swiped the original conference feed from UStream (with permission, thanks!)).

Slides

Transcript

» MIKE WEST: Thank you very much. Before I get started, I’d like to say thanks to Frontend Conf because this is the first conference I’ve ever been at where the – where everything was online less than a day after the speeches. In fact, speeches from this morning are already online. I think it’s absolutely incredible. Can you give the guys up there a round of applause? Because that’s…

[applause]

Blows me away.

So my name is Mike West. I work at Google on Chrome. I do some stuff in Blink. I do some stuff in Chrome. If you have any questions about that, I’m happy to answer them. What I’ve been doing recently has had a lot to do with security.

I’m going to talk about a couple of things today that I find really important. The slides are at this URL, I’m actually using them right now because my computer decided that it didn’t want to hook up to the network. So you can follow along with me on SlideShare. Sorry, on Speaker Deck. I stopped using SlideShare for good reasons, and I will tell you about them later. I’m on Twitter. I’m on Google+. You can find my website that I update maybe once to twice a year. It’s very exciting, very good stuff indeed.

So my brain is absolutely full. I’ve been to a lot of talks over the last two days. This is the last talk on the last day. I think if I tried to stuff anything else in my head, it would explode. I suspect that many of you are feeling the same way. So I want to give you the one thing that I want you to remember right now, up front, before you forget everything that I’m going to say.

This is an article talking about Content Security Policy. What is Content Security Policy? Why should I care? I’ll tell you in a minute. But don’t worry about that right now. Open the article, put it somewhere, find it later. It’s something that I really think you should read. It’s something that’s well worth your time and it’s written by a very handsome man. So I think it’s really something that would be worth your time to play around with. It’s on HTML5Rocks, by the way. Does anyone know HTML5Rocks? Does anyone not know html5rocks.com? Excellent. That’s very good. They’re very smart people on my team that write lots of good articles for the site. I really think that if you don’t know about it and many if you do, it’s well worth your time to take a look at.

So how many of you have seen a page that looks like this, in either Chrome or any other browser? That’s not enough of you. You people are browsing really boring websites. You need to go into a – just completely different corner of the web. You’re not going to see this from cnn.com, right? You’ve got to really look for it. This is a malware alert brought to you by the magic of SafeBrowsing. SafeBrowsing is a service that Google has put together that’s used by Chrome, used by Firefox, and a variety of other services. It gives us the ability to relatively rapidly show users that they could be doing something dangerous, that we compare a list of hashes to the website that they’re about to visit. If there’s a match then we can inform the user that they might not want to visit the site. The site is something that we’ve identified as being persistently malicious. That is every time users go to the site, people try to load malware onto their computers or try to direct into phishing sites, or things along these lines. It’s persistent. Meaning that for every user, they’re seeing this sort of behavior.

And then we’ve gotten really good at detecting these sorts of behaviors. We’ve gotten really good at detecting the websites that are always going to do you harm. What we’re not so good at is detecting the more transient attacks. Detecting attacks like content injection that only affect a single request or a single subset of users, or perhaps only users that are logged in to a particular site, only a particular user. We’re not that great in detecting it because we – when we crawl the web, we don’t see these sites, because this site are usually distributed via e-mail or via Twitter or via a wide variety of other mechanisms by which people try to trick you into clicking on links that will do you harm.

I mentioned – I mentioned content injection. Content injection is a broad term that – of which XSS is a specific variant. XSS means cross-site scripting. And generally speaking, this means that an attacker is able to trick a server into sending code that it didn’t mean to. That is, instead of only delivering the JavaScript that actually makes up your application. Your server is tricked into also delivering some sort of malicious code, code that does harm to a user or exfiltrates their data without them even knowing about it which is actually even worse.

Why is XSS problematic? Generally speaking, XSS is one of the most prevalent problems on the web. Almost every website will have an XSS flaw of one sort or another at one time or another, even Google. Given that, why is it dangerous? What can it actually do? What can a – an attacker do when they can execute code in the context of your website?

To understand why it’s important, you have to understand the concept of an origin. An origin is a pairing of a scheme, a host, and a port. That is http, example.com, 80. or https, google.com, 443. Those are distinct origins. And because they’re distinct origins, they should and must not have accessed to each others data. example.com must never have access to google.com’s data. And the browser can actually do a relatively good job of enforcing this sort of restrictions.

There’s a policy known as the Same-Origin Policy which basically means that everything within the context of your origin has access to all of the data for that origin. It can access cookies, it can access localStorage, sessionStorage, you name it. Anything you are storing locally using any of the wide variety of HTML5 mechanisms that are out there is accessible to any and all code that runs within the context of your origin. In other words, the origin boundary is the only boundary that the browser can very effectively enforce.

It is however the case that we generally includes script from all over the place into our origins. The browser allows this. The browser really likes JavaScript. And basically any JavaScript it sees, it’s going to execute. It just loves JavaScript. So every time it gets a chance to execute anything, it executes, which is problematic, right?

What’s the difference between these two script tags?

Exactly right. There is no difference whatsoever. If both of these script tags are included on a page, the browser is going to go, “Yay, JavaScript.”, grab them both, execute them as fast as it possibly can because Chrome’s all about speed and bad things are going to happen, right? Now, visually we can inspect these two scripts. We can say the first one is awesome, the second one not so much. Perhaps, I want to execute the first one that was actually part of my application. The second one, I have no idea how it got to my page, I didn’t write that.

Well, it might’ve gotten on your page like this, right? If you’re using PHP or any other wide variety of other templating languages and you don’t properly escape output, if you just say “Hello {$name}!”, and then accept whatever name, the user gives you as their name then you’re in trouble, right? Because the – if the user gives you a name of <script>beEvil()</script> and you just blindly write that out, then you’re doing yourself of disservice.

This is how a lot of cross-scripting attacks happen. There are a lot of variants on this, so it’s not always the case that it’s just coming from a GET parameter or a POST parameter. Things can be stored locally, things can be reflected from various pieces of the DOM. So attackers are really, really clever about finding holes in your site and exploiting them. How many people have dedicated members of their team working on security? That’s kind of what I suspected.

I guarantee you that if you had any sort of high value data on your website or even medium value, even low value data on your website, there are people that are much more interested in getting access to that data then you are in protecting it. Because generally speaking, your team’s responsibility is to build amazing new features and to build amazing new experiences for your users. It’s kind of assumed that you’re doing security work. And the security work is not really ever part of your goals for a quarter. Your goal for the quarter is yo build this amazing new page. It’s not to make sure the other pages didn’t break in the meantime. That should probably change, but we’ll talk about how we can mitigate the effects.

Happily, this is a absolutely trivial problem to solve. All you have to do is perfectly escape every piece of output that you put on your site. Every piece. Pieces that come from you and pieces that come from users.

You also have to perfectly escape it for the context in which this output will find itself. Here’s a relatively an exhaustive list of different context in an HTML page, you have a color exported into a style tag, you have a name directly in a paragraph tag, you have a URL that’s put directly into an attribute of an HTML element, you have an ID that’s put directly into script, and you have some debug information that’s put into a comment.

The rules for each of these contexts are different. For example, inside of a comment, two dashes will close the comment and everything else will be rendered. Two dashes of course have no effect whatsoever inside a paragraph tag, but if you open a script tag inside of paragraph tag then you’re in trouble. So you need to understand the rules for each of these contexts and you need to perfectly escape all information that you export into this contexts.

It is, honestly, trivial.

However, we are really bad at trivial things, apparently, if you look at the history of the web.

Has anyone heard of OWASP? O-W-A-S-P? Excellent. OWASP is an interesting organization that does a lot of security research and lots of security trainings. They have – as an example of the kinds of cleverness that people can come up with for exploiting things in websites, this is an XSS filter evasion cheat sheet]owaspxss. It’s a little bit old, it’s not really new, it hasn’t really been updated since like, I don’t know, 2012 or so, 2011. But there’s a lot of really interesting things in here that might make you think again about the mechanisms by which you are filtering data that’s going out to your websites.

Long UTF-8 encode without semicolons. Did you know that you can have UTF-8 entities put in to your site without semicolons? So if you’re checking for ampersand, semicolon then you’re kind of screwed because you don’t need those semicolons. Ha ha, hurray for HTML.

Has anyone heard of JSFuck?

» I have.

» MIKE WEST: JSFuck is amazing. It proves that you can write any line of JavaScript using only six characters. Open brace, close brace, open parenthesis, close parenthesis, plus and bang. Do your filters check for any of these characters? They all seem relatively benign, right? But if you put these into an attribute, you’re kind of screwed.

Does anyone know what this code does by the way? Can you guess? You can all read this. I mean, it’s just JavaScript, right? This is alert(1). Usually you will do – usually you will do alert('XSS') when you’re doing a pentest or something but alert('XSS') is about 6,000 characters long, so I didn’t paste it. JSFuck is quite verbose.

Alex Russell puts this beautifully when he says, “I discount the probability of perfection.” It’s really difficult to be perfect.

I would phrase it slightly differently: “We are all idiots with deadlines.” We do the things that we think are important in the moment and it’s very easy to forget about things, these overarching things that are a critical foundation of the work that we should be doing. And it’s very easy to make small mistakes. And unfortunately, small mistakes are really all that it takes.

So what I want to talk about today is what we can do inside of a browser to mitigate the effects of our idiocy because generally speaking, there are going to be holes in the websites that you create. It’s almost unavoidable. It’s a question of – it’s a question of “when” not “if” there’s going to be a hole in your sites and “when” not “if” that hole is going to be exploited. It will be really nice if there was some sort of – I don’t know a policy of some sort that we could give to the browser that, I don’t know will have an effect on the security of our content. I don’t know. We’ll back come back to that idea.

Does anyone what this painting is? This painting is Odysseus and the Sirens. It’s a really good story. It goes something like this. Odysseus is – Odysseus is an amazing man. And by that, I mean, that he is an egomaniacal maniac and bastard. This story goes something like this: Sirens, they sing beautifully. So, beautifully in fact, that they drive you to the brink of madness, sailors in particular, they really like sailors for some reason, who knows why. Sailors are driven to the point that they – all they want to do is be near this music to hear more of the music, so they end up throwing themselves overboard whenever they, you know, sail around the island where these sirens find themselves. The ship then crashes on the island then these sirens I guess eat people, who knows.

Regardless, Odysseus decides, because he is an amazing man, that he wants to be the only living person to have heard the song of the sirens and survived. So, what does he do? Well, he tells his men to tie him to the mast. So, they bind him quite tightly, his hands behind his back, his legs are tied to the mast. He can’t go anywhere. But he can hear the music. He simply prevented from doing things that would be stupid, you know, acknowledging the fact that the entire endeavor is stupid. He then, instructs his men to put beeswax in their ears and they, you know, wrapped things around their head, you know, primitive sorts of earmuffs so that they can’t hear the music of the sirens. And he gives them explicit instruction. You know, “row next to this island”, “don’t go to the island”, “don’t jump out of the boat”, and “just keep rowing”, right? The sirens come, they sing their beautiful songs. He’s driven to the brink of madness but he’s able to continue on his path because he’s given these instructions and then he’s prevented his men from acting on these distractions.

It’d be really great if we could do something like this with the browser. Where we could tell the browser, “Hey, this piece of code is what you want to be executing.” These distractions, all this other beautiful JavaScript that’s out here that youreally, really want to go execute and look at it, but please do not touch, right? It would be nice if your application could ask the browser to tie its hands behind its back and prevent it from doing things that it knows are going to be bad idea.

Content Security Policy is this thing. It is gorgeous. It will give you errors like this when people try to inject code into your sites. Refused to execute inline script because it violates the Content Security Policy directive: "script-src 'self'". We’ll talk about this in a little bit more detail. But the core idea I hope is clear. Content Security Policy gives you a mechanism by which you can whitelist certain origins of content and allow only those origins to execute within the content – within the context of your origin. That is, if I want to include Google Web Fonts I can only whitelist the origin from which this font should come. I get script from that origin, I get fonts from that origin, but I shouldn’t get them from anywhere else in the web. This is really quite powerful.

The specification is here. Content Security Policy 1.1 is currently in draft. Content Security Policy 1.0 is a candidate recommendation. It’s currently implemented in Chrome. It’s implemented in Firefox 23 which just came out as an unprefix header. We’ll talk about that in a little bit.

I edit the spec along with Adam Barth and Dan Veditz from Mozilla. They are much smarter than I am, so I just kind of sit there and type whatever they say. It’s great.

So, what could a Content Security Policy look like? Content Security Policy is delivered as an HTTP header. This is the – this is the policy that’s being used on an incredibly high value website mikewest.org. Yeah. Content Security Policy is the name of the header, right. So, you send Content-Security-Policy and then the value is a semicolon-delimited list of directives. Each of these directives controls a specific type of content.

Here, I’ve set the default of 'none', in other words, nothing should be allowed on my site. Then, I slowly open that up and start saying, “Okay. Well, okay. Nothing except style from my CDN. Okay. Nothing except style and frames from these two places.” and so on.

And you see here that I’ve whitelisted https://www.speakerdeck.com. I did that because Speaker Deck, being awesome, serves things over HTTPS whereas other services do not and have no intention of doing so. This is problematic especially if you’re on a HTTPS site because Chrome and Firefox has started actually blocking HTTP content within the context of an HTTPS site. So, it’s really good if you run a service of any sort and you expect people to embed things on the web, serve it over SSL. If you don’t serve it over SSL, slowly but surely your options are going to be limited with regards to where that content can be embedded. All right.

So, script – sorry – style, frames, script images, fonts, and so on. This is an exhaustive list of the directives that exist in Content Security Policy 1.0 which is currently available in Chrome. There are couple of additional directives behind a flag in Chrome. So, if you go in to Chrome flags and then enable “Experimental Web Platform features” (<chrome://flags/#enable-experimental-web-platform-features>), then you’ll be able to start playing around with the 1.1 stuff immediately.

And I’ll talk about a little bit about what’s new in 1.1 later because they are like two important things and then a bunch of other stuff that’s gotten through for one reason or another. What’s interesting here is the last item, a report URL or URI. Yeah, URI. What this does is actually gives you insight into whether or not you’re being attacked.

You can run Content Security Policy in such a way that every time there’s a violation, every time a resource is loaded that – I’m sorry – an attempt to load a resource has made that goes – that violates your policy, you’ll get a POST message from the browser. The browser will say, “Hey, I tried to load this thing and I blocked it. It was on this page. It had this URL, maybe you should take a look at that,” which is really quite useful if you’re auditing websites.

What’s nice here is that you can actually run kind of Content Security Policy in a “Report Only” mode. That is it won’t actually block any content on your site. What it will do instead is simply send these POST messages out to your web server so that you can start cleaning up your site before you actually deploy a Content Security Policy. What’s really nice is that you can actually run both a Report Only mode and an Enforce Mode policy at the same time. So, you can have a really loose enforce policy that says https: only. So I should load everything over HTTPS and if I don’t, then start telling me about that, so that I can find these places on my site that need to be cleaned up. Then you can also have a Report Only mode that’s more restrictive where you start saying only this origin, only that origin, no inline script, and so on. This gives you a nice mechanism by which you can start rolling this out. You start getting information about how your site’s actually behaving in the wild and it gives you a good opportunity to start cleaning up these areas that need work.

If any of you have any questions by the way, please ask. Did you have a question? Okay. I’m sorry. Anyway, you see the report information here. There are variety of attributes. They do more or less what they say on the tin. document-uri is the document what was being attacked. referrer is the link from which the user came and so on. The interesting bit might be the source file line number and column number at the end. If the violation came from JavaScript we’ll do our best to give you some context that you can actually find it again later on.

But what do we do about inline script? What origin would you say that this comes from? It’s not being loaded via a script tag, right? It’s just inline in the page.

Ha-ha, we didn’t know either. So, we invented one, we called it 'self' (I should have said 'unsafe-inline' here… Oops!). Basically, inline script is the biggest problem that we saw on the web. And it’s the core reason the Content Security Policy is valuable. We can instruct the browser to not to execute inline script. This means that even if an attacker can inject script into your page they can’t do anything. They’ve just injected text, it’s not executed which means it’s not dangerous. It does mean however that if you have inline script in your page that you’re using now, you’re going to have to do a little bit of rewriting. So, code that looks like this, where it defines a function inline in the page and then has inline onclick handlers or javascript: URLs or something along those lines, we have to be rewritten something like this.

So, you externalize the script. You put it in to an external file, you load it from that file, and then you do some DOM manipulation in order to add event listeners. Quite honestly this is what you should be doing now. I know there are good reasons for inline script. I know there are interesting performance questions around it. Generally speaking our approach with Content Security Policy has been to throw the baby out with the bathwater and then to look in the water and see if we can pick the baby up. So, in 1.1 we’re going to be digging around in the water, and I’ll show you a little bit of that in a moment. For 1.0, to get something out the door that was really valuable, we simply say inline script is banned.

You can however turn it back on by using the 'unsafe-inline' origin. We call it “unsafe inline” because it’s kind of unsafe and we kind of don’t want you to do it. Regardless, here’s that article again. This article gives you really all of the practical detail that you’re going to need in order to do – to start implementing this on your own. I think its well worth your time. I really believe the Content Security Policy is one of the most effective mechanisms to mitigate the risk of cross-site scripting that’s come out in the last several years. It’s not perfect. There are ways to get around it. There’s an excellent paper called “Postcards from the Post-XSS World” where people have already figuring out how they can attack you after you have Content Security Policy that bans inline script. Attackers are really, really clever but we should make it as hard as possible for them and I think Content Security Policy is a great way to do that.

Let’s take a quick look at the 1.1 spec just so I can tell you about it. Now I’m in full screen mode. I’m sorry. So, I had everything open on the other machine and then it decided not to connect. So, we’re going to go and let’s see if I can remember where it is. Yeah, look at that. So, Content Security Policy 1.1. The interesting bits of Content Security Policy 1.1 are the inline stuff. There’s also – there’s some discussion around the JavaScript API that might or might not go anywhere. But let’s look at – oh, that’s right. It used to be a separate directive and now it’s not. So, we have the ability to embed nonces as valid sources of script and… I have no idea where it is.

I just write this stuff. I don’t know where it actually is. Give me a break. How can I be expected to find anything? So, “valid nonces”, that sounds good. And it’s a Swiss keyboard, this is sweet.

All right, you’ve seen something like this. Anyway, the idea – there are two competing ideas that we kind of don’t want to implement both of them but we want to discuss both of them. One of them is a nonce which basically a one-time pad. A server, when it generates a page, should generate a unique idea along with that page and send it in the header. It then would embed that ID as a nonce attribute on each of the scripts that are enabled. This means that if the server does its job and generates a new nonce every time, that an attacker won’t be able to guess it. So, even if they inject script, it won’t have the nonce attribute and then won’t be executed. It has the advantage of being very simple, it has the advantage of being transferable so that if I load a third-party widget, I can give it the nonce as well and it can then inject code into my page if I trust it to do that. And ads do this all the time, so, for ads, it’s kind of an important use-case regardless of whether it’s a good use-case or not. The other option is a hash where we would basically hash the inline script. And take, like, the SHA-1 or SHA-256 hash of the script and then compare that to something that was in the header so that you could only inject code that match this hash. I think both of them have advantages and disadvantages. And they’re being discussed right now on the public-webappsec@ list. I’ll get there right now. So, the Web Application Security Working Group is the group that is doing this work. And from this page, you’d be able to find a link to the discussions that are going on the – on the mailing list. If you have opinions and you can back them with use-cases, I’d really suggest that you get involved. Just join the working group, join the discussion. We’re still kind of in the formative stages of 1.1 so it’s a good time to get involved.

Well. OK, cool.

So, that is Content Security Policy. That is the one thing that I want you to remember from this talk. I think it’s incredibly important, I think it’s well worth your time to play around with. Now, we’re going to talk about other stuff because I have more time.

Some of the things that I think are important. SSL is the first and foremost of these. I think serving your sites over a secure channel is an absolute prerequisite to any conception of security whatsoever. If you’re serving your site over HTTP, you have absolutely no guarantee that the bits that leave your server are the same bits that are getting to the – to the client and you have no guarantee that the bits that came from the client are the bits that actually reached your server.

We conceive of the internet somehow like this, that I have my laptop, I send the request directly out to a server. I get a request or I get a response directly back from the server. But when we think about it, we know that that’s not at all how things work.

Instead, I go to conferences and I join the Wi-Fi network at a conference. And then I send all my requests through this Wi-Fi network. Do you trust the people that run Frontend Conf? I don’t know, they look kinda shady.

Generally speaking, proxies that sit between you and the servers that you want to talk to have complete control over every HTTP connection. There’s simply nothing that you can do to verify anything about the connection whatsoever. It’s unencrypted, sent in the clear, which means that those proxies have a) the ability to modify the request but also the ability to read the request and store them and send them to exciting people like the US government. What I would suggest is that your conception of the world should look something like this where there’s always something in between you and the server and you should never trust it. You should always assume that everything going through external servers is being tainted in some way.

You can fix that to an extent by encrypting the data that’s being sent. This at least guarantees that the information that’s leaving your computer can only – well, mostly only – be read by the server that it’s going to. And mostly only – and you can mostly only read the responses that are coming back. SSL is not perfect. There are a lot of ways in which SSL can leak information and we discover new and exciting ways almost everyday. However, it is the only guarantee that we have, period, that any information you send is going to be the same information that’s going out to the – to the server and vice versa. Given that, I think it’s highly important for any service that is doing anything with any information that has any value whatsoever, any, to use SSL. It’s really quite important. And it’s also really quite easy. For example, StartSSL (which is much bigger than 124 – or 1024 by 768) will give you free SSL certificates. All you need is an IP address. StartSSL is great. I use them for my site. It’ll look something like this when you do. It won’t look like this because I never touch this thing, but you’ll get a nice green thing up here. You’ll get some green stuff there. You’ll get some green things over here which is kind of nice. But basically, all of that is theater. What it means simply is that you have the ability to encrypt the connection between you and the client and that is only a good thing. If you start setting up SSL and you want to make sure that you’ve done it correctly, there’s an excellent website called ssllabs.com which has an SSL test. This will run through a lot of tests that show you in great detail how you have screwed up your SSL connections or how you have screwed up your SSL system in general.

I apparently still have some work to do.

Generally speaking, SSL is really quite valuable, really important, and not that difficult to set up. It’s like three lines in Nginx and it’s probably similar in just about every other system. The only complication is generating a request and then sending the request off and then getting a response back and making sure that you concatenate things in the right order so that Nginx will send it. It’s really quite straightforward and really quite nice. So, I highly recommend that you do that.

Once you do, once you’ve gone ahead and set up SSL, make sure that all your users are using it all the time. That is if someone requests an HTTP page, redirect them to the HTTPS page. There’s a 301 permanent redirect, it’s just the location header, it’s really quite straight forward. The clever amongst you will notice that this leaves a window of opportunity for an attacker to do some interesting things. They could strip this redirect, for instance. They could man-in-the-middle you at that point and say, “Okay, I’m going to keep you on HTTP but I’m going to do the HTTPS connection over here to the server and then I’ll just forward the information to you.” They can keep you on HTTPS – or HTTP by doing so. To get back to the concept of client-side and browser-side, you can actually instruct the browser to only connect to your website over HTTPS regardless of what the user actually types into the address bar. You do that by setting a Strict-Transport-Security header. What this means is that the browser will do a transparent redirect locally before it actually goes out to the network. So, if I type in mikewest.org, or if I type in http://mikewest.org, the browser will actually switch that to HTTPS for me before it goes out to the network. This means that there’s not – there’s only one window of opportunity for an attacker to strip the SSL connection and that’s the very first time you connect to a site. So, connect from home in the dark with a hood over your head or something so that you’re extra secure. And then when you go out in to the wild and dangerous world, you’ll be guaranteed that you go to HTTPS and not http. If you’d like to see the list of websites that is actually already set up within Chrome or within Firefox, then go to <chrome://net-internals> and check.

So, I can look at mikewest.org and you’ll see that it’s in strict mode that include – doesn’t include subdomains and there’s some nother stuff that I’ll talk about in just a minute. So, Strict Transport Security, it’s a good thing, I highly recommend that you set it up. This means you have SSL and all your users use it all the time, or as close to all the time as you could possibly get.

If you want even more security – well, actually this is something that you should do even if you don’t want security. Even if you don’t care at all, you should do this anyway. Set-Cookie, whenever you set cookies, make sure that you set a – the secure flag, which means that they are only sent over SSL and never sent over HTTP and you set the HttpOnly flag which means your cookies are not accessible from JavaScript. This means even if someone can inject JavaScript into your page and, even if it gets past your policy and even if it’s executed, they still won’t be able to steal users authentication tokens because – well, not easily anyway. They won’t be able to do it via JavaScript. They’ll have to find other ways in your site to expose the value of the cookie.

Public-Key-Pins is a mechanism of making your security even more secure. So, the weakest link in SSL right now are the people that issue SSL certificates, the Certificate Authorities. It’s the case that any certificate authority has the authority to issue certificates for any origin on the web. So, I can issue a google.com certificate, you can issue a google.com certificate, it’s just a beautiful world where we all have this ability. Google, however, would prefer that not everyone have this ability. Since we can’t change the CA system as it is, we can instead look to things that ensure that the certificate is only acceptable if it meets whatever requirements we set up. In this case, Public-Key-Pins gives us the ability to send a header that says only accept certificates whose public key matches this hash. This means we only accept certificates that we have signed, not that anyone has signed but that we have signed. This gives you the ability to only accept certain certificates and not all certificates that are valid for a particular origin. It’s really quite valuable especially if your site is a high-value target that’s under attack.

I haven’t set this up on my site because it is incredibly easy to screw up. If I lose my keys, then people would no longer be able to access my website because I would generate a new SSL cert but, for the max age of the pinning, which in this case is – I don’t know, some long amount of time, I think that’s a month – people would go to my website and then they get an SSL error even though I’ve set up everything on my end. So, you need to be really, really sure that you’re doing everything right before you start implementing this.

If you want to go a step further, you can talk to Chrome and you can talk to Firefox about having your website hard-coded into Chrome as being on the HSTS list. What this means is that there’s no window of opportunity for an attacker to strip SSL on your site. So, mail.google.com, paypal.com, a wide variety of sites had chosen to do this. They’re basically hard-coded into Chrome as a list of sites that should always be HSTS, that should always use Strict Transport Security. And if your site is one those sites, just file a bug and we’re happy to add any site and every site but beware of the consequences because if you’ve then screwed up your SSL then no one can get to your site, ever, with Chrome.

That is Transport Level – Transport Layer Security. There’s one more topic that I was going to talk about but I think I’m going to skip it because it’s not particularly important. The slides are online so please feel free to skim through all the <iframe sandbox> stuff. It’s pretty interesting but it’s not critical.

What I think is critical is, again, one more time, just so everyone remembers, Content Security Policy. It’s really important. I think it’s the single biggest step forward that we’ve made in quite some time with regard to mitigating the risk of cross-site scripting attacks. It’s not perfect. Attackers will still attack you after you have a policy but at least you’ve raised the bar to the point where attacking you is hard as opposed to not so hard. Thank you for your time.

Q&A

Do you have any questions? I’d be really happy to answer them. Yeah?

I mean, maybe, depending on the question.

» So, this one’s going to be hopefully challenging. So, we were on quite a big web service and we really rely on advertising on all pages. So, what we get a lot is, from security web people like people in this room, is use f-ing SSL and we cannot do that because of all the advertising. Most advertisers do not use SSL to serve ads. Do you have any suggestions what we could do about it?

» MIKE WEST: I – well, the flip suggestion would be find advertisers that serve over SSL. The less flip suggestion is that we’re moving in that direction. Advertisers in general are starting to understand that they simply – they can’t embed into it – SSL sites. And because of that, they’re going to start losing revenue. It’s not happening as quickly as I’d like, but generally speaking, the trend is for everything on the net to be encrypted. If you look at SPDY, if you look at QUIC, if you look at HTTP2 which is currently in discussion, the general trend in those discussions is starting with SSL, and that there just isn’t a non-encrypted variant. There’s some discussion around that, specifically around caching because encryption makes caching difficult. But generally speaking, the trend is towards encryption and the trend, specifically with new protocols, is to only have encryption and to simply not have a non-encrypted channel.

So, my answer would be that it gets better but they we’re going to have to wait for that betterness.

For now, I would suggest using advertisers that can serve over SSL like Google, for instance. But generally speaking, I honestly believe that this is going to be a feature that website owners are going to start asking for more and more. And it’s up to website owners and publishers to put pressure onto advertisers so that they actually start doing the right thing. Until that pressure, until that market pressure exists, it’s going to be very difficult to move advertisers towards a more secure world.

» Hi. Thank you for this talk. What’s your opinion on this plugins that came last year like HTTPSEverywhere for Firefox as well as Adblock Plus which has been, I believe, two or three months ago. In Germany, there was a big announcement of all these media sites serving, saying to you. You have an Adblocker, please, please disable it because we are relying on advertising, for example.

» MIKE WEST: I think those are – I guess I would say that those are two completely different questions. I think HTTPSEverywhere is wonderful. I highly encourage that you install HTTPSEverywhere. It’s a plugin, an extension or a plugin depending on your browser from the EFF, the Electronic Freedom…

» Foundation.

» MIKE WEST: Yes, I don’t – it’s just EFF and it’s awesome. I give them money, I just don’t know their name.

Generally speaking, I would highly recommend that you install it because what it does is – has a list of all services or lots of services that serve things over HTTPS but for whatever reason give you HTTP options. It forces you onto HTTPS. So, it’s kind of like a client-side version of the Strict Transport Security that we talked about. And then, I recommend that you install it but understand that not every publisher actually expects you to use HTTPS, so, it breaks sometimes. You have to understand that maybe for this site, you have to turn it off and it’s a little bit more work but you’re certainly more secure because you’re sending the vast majority of your traffic over HTTPS and that’s a very good thing. AdBlock is kind of a completely different question and I’m going to ignore it.

I won’t actually.

AdBlock – I don’t understand Adblock. I understand why people use it because ads are often annoying. But for good or for ill, advertising is absolutely central to financing the web, period, whether you like it or not. Given that, I think it’s problematic if a large portion of the populace is blocking ads. I’m not going to tell you to stop blocking ads because you’re not going to. But generally speaking, I think it’s the wrong thing to do. I think the right thing to do is to vote with your feet and if you don’t like the ads on a particular publisher, don’t visit that publisher. I understand there are reasons that people use it. We’ve talked about it yesterday or the day before. But generally speaking, I see it as really problematic and I find that when people complain about ads in the web, like, I find it unsympathetic, but of course I would because I work for Google so, who knows? Feel free to ignore that.

We’ll talk afterwards, okay? It’s not really this topic so we’ll talk afterwards.

» Yeah, sorry. I quite like the reporting feature which we saw before and – but there was just a question on twitter. Is there some way to prevent misuse? Because like the URL for reporting is then public and basically everyone can submit anything there, so, how to use a tech if it’s really from a browser or…

» MIKE WEST: Yeah. So, we do – we – First, I would suggest that you should already have things in place that do rate-limiting. So, if you’re being DDOS’d then you should have mechanisms in place, and this isn’t gonna make that any worse. Second I would say, that for same-origin reporting mechanisms, so, if example.com reports to example.com, we send cookies. If example.com reports to something else then we don’t send cookies. So, at that point, you can use the cookies as some sort of authentication mechanism and say that, you know, this is coming from this user. What you can also do is have a token, a CSRF token in the reporting URL and say that for this page, you go to this URL, for this page, you go to that URL, just with GET parameters and then verify that those parameters are actually what you expect them to be. So, in the same way that you verify form submissions, you can also verify these sorts of POSTs. And I think that would take care of most of the mechanisms.

You’re making him run, that’s just mean!

» I’ll raise about full HTTPS, what is the impact first about SEO, how Google look about HTTPS for the website, have an impact?

» MIKE WEST: I have no idea but Google serves basically everything itself over SSL, almost everything. And generally speaking, Google as a company wants people to be using SSL. I’d be shocked if SSL had a negative impact but I am not a quote-unquote “SEO expert”, so don’t take my word for anything. Talk to people who know something about SEO.

» Just a last comment, when you have a big website with lots of view, if you use full SSL, of course, we need to have a bigger hosting environment. How many percentage?

» MIKE WEST: Not significantly. So, there is kind of this general common knowledge that SSL is much slower than HTTP. It’s not that slow. I think you’re going to – I’m going to quote it wrong. There’s a – there are some really smart people at Google. One of them is – what’s the guy’s name? Smart guy at Google, help me out. Violet – SSL something – ImperialViolet, there we go. Oh, and look, that’s like – that’s the exact article I wanted to go to. That is sweet. So, there’s a good article on ImperialViolet.org called “Overclocking SSL”, where it talks a little bit about the impact of SSL. I want to say, yeah, one – less than 1% of the CPU load, less than 10K of memory per connection, less than 2% of network overhead. There is overhead, it is minimal. This was 2010. My suspicion is that it’s even lower at this point. So, if you have set things up poorly, then your site’s going to be slow. If, however, you follow the best practices for setting up SSL connections and do the right things with regard to false-start and a variety of other code, weird configuration options, you’re going to have a site that’s exactly as fast – within 1% of – non-SSL sites.

» I have one more question about the SSL thing which is, are there any disadvantages in using a free SSL provider like you were showing in comparison to the quite expensive other ones?

» MIKE WEST: Yeah. I don’t get it. I think Thawte would love for you to believe that their certificates are more valuable. They are not. You get 204 – 2048 bits of encryption with any certificate ever. Certs are certs. They are a text file that’s like that long, there’s no reason to pay thousands and thousands of Euros. It’s kind of a ridiculous racket. They can do that because people trust them. So, if you’re doing – the only reason – sorry, the only reason that I would suggest using any of these services that are, you know, widely known and widely trusted is that some networks, especially inside of enterprises for whatever reason, only trust certificates from certain providers. Generally speaking, StartSSL, which is the one that I recommend and the one that I use, is well-supported across the world but you would have to test in the specific enterprise whether they’ve, for whatever reason, disabled certificates from people other than, like, the two CAs that they trust. So, the only reason that’s valuable is because it’s a racket.

» You just showed us this http header was – the pin where…

» MIKE WEST: Uh-hmm. Yeah.

» Do we need a StartSSL or some provider like that anyway or…

» MIKE WEST: Yeah, yeah. You’d have to have a cert before you can pin a cert, so pinning.

» Maybe somewhat, self-sign it to…

» MIKE WEST: You can self-sign it and you can pin a self-signed certificate but the browser isn’t going to trust that anymore. There’s been some discussion around making self-signed certificates less terrible in terms of their presentation but I don’t think that’s going to roll out to the web.

» I see your point before that EV SSL isn’t worth a lot really. Why in browsers do – do browser producers actually change the icon?

» MIKE WEST: That is an excellent question. You would have to talk with whoever made that decision.

I don’t think there’s any value to EV certificate. Basically, the certification means that you have a lot of money and that you paid someone. And that gives you your name in the URL bar and I guess that has some value, and if you’re a company then you have money to burn anyway so, hey, why not throw money at SSL. But generally speaking, there is no difference, period, between the encryption that you get with a self-signed certificate and a totally expensive EV certificate. The encryption is exactly the same.

Great. Thank you very much.

If you have any questions at all…

» Thank you, Michael. We’ll follow-up with our closing keynote. Just a moment.

Debugging runtime errors with 'window.onerror' in Blink

2013-08-08T00:00:00+02:00

After working with Blink’s implementation of window.onerror a little bit over the last week or so, I’m somewhat amazed that anyone ever used it for anything at all. For those of you to whom the API is news, the current implementation in Chrome’s stable channel (28) looks a little bit like this:

window.onerror = function (message, filename, lineno) {
    // Do some centralized error reporting here, for example, by POSTing
    // the error message, filename, and line number to a collection
    // server for later processing.
  
    return true; // The exception is handled, not reported to the user.
};

...

throw new Error('OMG!');

‘window.onerror’ acts something like a global try/catch block, allowing you to gracefully handle uncaught exceptions you didn’t expect to see. This, in theory, is brilliant.

Two issues have made it less than brilliant in practice:

Unlike a local try/catch block, the window.onerror handler doesn’t have direct access to the exception object, and is executed in the global context rather than locally where the error occurred. That means that developers don’t have access to a call stack, and can’t build a call stack themselves by walking up the chain of a method’s callers.
Browsers go to great lengths to sanitize the data provided to the handler in order to prevent unintentional data leakage from cross-origin scripts. If you host your JavaScript on a CDN (as you ought), you’ll get “Script error.”, “”, and 0 in the above handler. That’s not particularly helpful.

There are a few other concerns, but those are the big two. I’m happy to say that recent patches have addressed many of the concerns in Blink.

Christophe Dumez added the column number to the handler.
After a lot of back-and-forth, Hixie added an ‘error’ parameter to the onerror handler in the WHATWG spec. This, as you might imagine, contains the exception that was thrown, just as you’d get in a catch block. The Blink implementation landed last week, which means that you can now access the stack trace in your handler via something like the following:
```
window.onerror = function (message, filename, lineno, colno, error) {
    console.log("This is a stack trace! Wow! --> %s", error.stack);
};
```
Blink now follows Mozilla’s and WebKit’s practice of enabling full detail in exceptions generated from cross-origin scripts that are served with proper access-control headers and attributes. If you add a crossorigin attribute to a script tag, and serve that script with an Access-Control-Allow-Origin header that allows access to the document loading the script, then you’ll be given unsanitized data in your error handlers. That might look something like this:
```
<script crossorigin="anonymous" src="http://cdn.example.com/script.js"></script>
```
Note that this is a bit tricky: you’ll need to make quite sure that your server is properly configured. If a script has a crossorigin attribute but the server doesn’t send appropriate CORS headers, the script load will fail miserably.
Stringification of custom errors is (slightly) improved for the case where an Error object is directly set as the prototype of your custom error. Handlebars, for instance, created a Handlebars.Exception object with code like this:
```
Handlebars.Exception.prototype = new Error();
```
V8 didn’t support that very well in window.onerror: the stringification looked something like [object Object], which wasn’t particularly useful for anyone. Now you’ll get the expected message, as long as you haven’t overridden the toString method.
I’m still knee-deep in the Worker implementation, which is a bit of mess really. I expect to fix the sanitization shortly, and I think it shouldn’t be too difficult to add the error property to the Worker’s onerror handler.

I think this set of changes will make centralized error reporting a bit more realisticly possible in the near future. I’d love for you folks to start banging on these initial implementations now so that I can fix bugs and clean up edge-cases now, before these start rolling into Stable. When you see a bug please do file it at http://crbug.com/new, and ping me the bug ID (+Mike West, @mikewest, or mkwst@chromium.org).

Enjoy Blink’s newly more-usable error reporting!

Securing the Client Side

2013-02-25T00:00:00+01:00

In November, 2012, I attended Devoxx in Antwerp for the first time to present some recent developments in client-side security. Content Security Policy of course was at the top of my list. I think the presentation does a nice job walking through the rationale behind some practices I’d like to see spread.

In the interests of making the presentation as accessible (and indexable) as possible, a full transcript of the presentation is below, along with an embed of the video and slides.

Video

Slides

Transcript

MIKE WEST » Got a cell phone in there, who knows…

The topic of today is, or, of this talk anyway, is “Securing The Client Side”. It’s kind of, I think, an interesting topic for a Java conference, because most Java programs have very little to do with actually building HTML and pushing it out to clients. It is, however, the case that if you want the largest market possible, the target of your language or whatever your application is, is going to be JavaScript, it’s going to CSS and it’s going to be HTML. That gives you the ability to push your application out to a huge audience that you simply wouldn’t have access to if you tried to deploy something in a more native way. The web is simply the largest platform out there.

And a consequence of this is that we’re slowly seeing more and more of the application logic being moved down to the client side. It’s moving out of these large back-end systems and moving down into JavaScript and executing then on a client’s computer, on an untrusted machine, as opposed to a machine, the server, that you have complete control over. There are a couple of things that you can do on the server side in order to ensure that your application is secure, to ensure that no one can write things into your application that you don’t want, and to ensure that the code that your application delivers is secure when it actually gets to the client.

We’re not going to talk about that today.

Instead, we’re going to focus very specifically on what you can do in the browser, in order to ensure some measure of security for your application. It’s simply the case that the browser is an untrusted environment, so you need to be very careful about what you’re doing. But at the same time, there are some new capabilities coming out in browsers of today, that allow you to ensure that your application is delivered in a way that maintains some degree of security.

The web is simply a scary place. Have any of you seen a screen like this? In Chrome or any other browser? Most browsers today have some sort of Safe Browsing system which tells you when you’re visiting a site that we know could be problematic. So, if we’ve seen a lot of malware on a site, we have mechanisms by which we can inform the browser that a specific website might be problematic.

It’s most often the case however, that the things that we’re really worried about aren’t pervasive and aren’t persistent on a website.

It’s very difficult for someone like Google or Mozilla to detect malware on a site, if the site itself is benign. There are a variety of attacks that can allow someone to inject code or inject content into a website that’s otherwise perfectly benign, nd only affects the person who is actually visiting that page at the moment. It’s called a cross-site scripting attack. And there are a wide variety of mechanisms that allow it to occur.

I’m going to talk about two things that you can do to reduce the capabilities of someone who would be attacking your sites and to mitigate the effects of any attack that did get past your defenses.

But before I start talking about things that you can do to defend, I want to talk about one thing that I see as an absolute prerequisite for anything… for any discussion of security on the web.

You must, must send data and accept data over a secure channel. There’s really no excuse these days for using HTTP as opposed to HTTPS to deliver an application. Applications must be delivered over HTTPS because that’s the only mechanism by which you can ensure that there’s even a modicrum of a chance that the data that you send out and the data that the user receives are identical.

Our view of the web kind of looks like this. We think about it. I have a laptop. I go out directly to a server. I pull some information down. I do something locally and then I send more information up to the server. We think about these direct connections, but of course it’s the case that there is no direct connection between me and a server.

Instead, I’d go to a coffee shop. And in that coffee shop, I hook up to their Wi-Fi network and then, in order to transmit my requests up to the server, it hops and hops and hops through a variety of routers and a variety of different servers until it actually hits the end point that I care about.

That’s a lot of things that I have to trust. It’s a lot of different servers that I need to ensure that I – if I want to ensure that the information gets from A to B intact, I need to trust each of those points in between. If you’re sending information over HTTP, it’s very likely that something like this could happen. It’s called the man-in-the-middle attack. I send information over HTTP, some malicious server in between me and the end point takes that information, modifies it in some way and then sends it on, acting as a proxy between me and the server that I actually care about.

At this point, it’s pretty much game over. If I’m sending information over an unencrypted channel, that man-in-the-middle can take the information, either read it, modify it, do really whatever they want. And there’s no way to detect this sort of thing. Because HTTP has no sort of encryption associated with it and no sort of signature associated with it which means that the information that I receive, I’d simply have to blindly trust that it’s the information the server actually sent down to me. That’s something that I don’t think anyone should be doing when writing an application. When writing an application, you should instead be very certain that you’re sending information over HTTPS.

HTTPS gives you a mechanism by which you can first encrypt the connection between you and the server, it still hops over a wide variety of routers in between you and the server. But none of those routers have the ability to read the information. Because they don’t have the private key that exists on the server.

At that point, you have some measure of security, some measure of privacy that is, in that the information can’t be read. Second, you have a measure of security in that the information can’t be modified as it’s sent back down to you without reencrypting the information using the same key as the server. This is very difficult to do. It’s not impossible. So this isn’t a completely secure solution but it’s miles better than HTTP where you have absolutely no guarantees whatsoever.

Anyone who’s running a server should still listen on HTTP ports because most people will just type in the server name into the browser and the browser will default to HTTP, would go out to the website and then something like this should happen. You should be doing a redirect – that’s kind of cut off on the side which is annoying.

What you see at the top is a curl, a HEAD request to mkw.st. It’s going over HTTP and at the bottom you’ll see a location header, which redirects me to the HTTPS server. This is good, this means that I’ll – most of my connections will be over HTTPS. But it leaves the vulnerability because that first connection is going out over HTTP. It’d be nice if we can somehow inform the browser that it should default to HTTPS as opposed to defaulting to HTTP, as it turns out we can. There’s a new header called Strict-Transport-Security. Strict Transport Security says, I’m sending this information over HTTPS and next time you connect to the server, forget about HTTP. Even if the user types in http://servername, go over HTTPS. Do the redirection client side as opposed to making a request and letting it happen server side.

There’s a max-age associated with this, so you can say for a month, do this sort of thing or for a year or for however long you actually trust that you’ll keep your certificates up-to-date. And there’s a mechanism by which you can also say that all subdomains of this domain, should also be protected by Strict Transport Security. This is really good for you guys to be doing. I would, so I would very much recommend that anyone who’s writing an application that’s delivered over the web, go to startssl.com or any of a number of other certificate delivery websites where you can sign up, get a certificate, associate it with your website and ensure that your application is being delivered in a secure fashion.

Once you’ve done that, go ahead and set up Strict-Transport-Security headers in your website, so you’ll ensure that your users are always visiting your site over HTTPS. It’s really almost a no-brainer. StartSSL in particular, is great for people with really small applications. It’s also good for large applications, but for people that don’t need these warranties that are associated with larger certificate manufacturers. StartSSL is absolutely free. They only charge you for the work that they do. So, if you don’t care about authentication – no, not authentication. If you don’t care about verification, then you can get a free certificate for your app that is – that works on all browsers, which is great.

If you do care about verification, or you want wild card certificates for something on those lines. The level two verification is like, 60 bucks, 60 US dollars for two years. You get unlimited certificates associated with that. Given this sort of thing, there’s really no excuse to not have certificates even for the smallest of projects.

With that out of the way, with that as a basis upon which we can build everything else, let’s talk about the sorts of attacks that I would like to help you defend against. The most common is a script injection. So if we go to Google.com, over HTTPS of course, we might see something like this. An alert box popping up that says “XSS”. This is kind of the very typical thing that if you pay a penetration tester to go out to your website and show you the vulnerabilities, this is most likely what you’ll see. You’ll see – I was able to inject script in to your site and that script executed and popped up an alert box.

It isn’t very scary though, right? It’s just an alert box. So, why should we really even care about it? What’s more interesting of course, is to pop up the user’s cookies and show them that by executing script on their site, you have access to all of the information associated with that origin.

The web is generally protected by the same-origin policy. That is, a website consists or the origin of a website consists of a scheme, a host and a port: that is (HTTPS, google.com, 443). It’s simply the case that, that website should never have access to information on separate origin. So, Google should never have access to my bank’s information for instance.

[pause to resolve beard issues.]

This of course, is the downside of beards. Beards are generally excellent. I highly recommend them, but if you have a microphone on your face, it makes it slightly difficult.

Regardless, document.cookie can be read by any JavaScript that’s associated with a particular domain or a particular origin. Generally, things are protected by the same origin policy; that is Google can’t directly access anything from my bank. But if I’m able to inject some malicious JavaScript into the context of google.com or any other website, the browser has no mechanism of distinguishing between a maliciously injected piece of content and a piece of content that was injected intentionally by the browser or by the–by the author of the site.

So, we see two alert boxes here and if we actually saw this when an attack was going on, there will be some measure of protection going on. But usually what we see is absolutely nothing. We visit a site it looks just like any normal site. We interact with it and transparently in the background, the person who’s attacking the site is either exfiltrating sensitive information pushing out my cookies to a third party server in order to steal my session or wide variety of other things.

Generally speaking, if someone is able to execute JavaScript on your site, it’s more or less game over. They have complete control over the site and they have complete control over the information associated with that site which is pretty problematic.

This is a really excellent website to go to. If you’re interested in how a cross-site scripting attack might look. It’s called the XSS cheat sheet and it’s delivered by OWASP which is security – an org – an organization of people who are interested in security and put together a lot of documentation, a lot of trainings along these lines. It’s a really long document because there are an incredible amount of ways of injecting code into a site that doesn’t properly escape its output.

JavaScript is really interesting in that it accepts a wide variety of syntax and it’s very difficult to insure that you escaped everything correctly such that JavaScript doesn’t execute. If you simply echo any information that’s been delivered by a user or any user generated content in general.

There are two things that you need to do in order to protect against cross-site scripting attacks. And if you do these two things perfectly, you are a hundred percent guaranteed you’ll never have a cross-site scripting attack on your site.

First, you need to validate all the information that comes into your website. So, if there’s a form where you accept someone’s phone number, you want to insure that you only accept phone numbers, that you don’t accidentally accept JavaScript. One mechanism might be scripting out everything that isn’t the number, right? Then you’re more or less guaranteed you have something that you can safely put into your database that you can safely deal with on the back end.

The next thing you want to do is ensure that you correctly escape every piece of output that you – that you write to a site. So, if you have any content that comes from a user or any sort of untrusted source, then you want to insure that you escape that output correctly when you write it out to the–to the screen.

I said you need to do it perfectly and unfortunately escaping output is much more complex than it seems. Here we have a little bit of HTML and what you – what you notice here is that there are five different contexts in which information could be output. This is a more or less exhaustive list.

You have style information, you have raw HTML, that’s inside the p tag, you have a URL that’s inside of an attribute, you have information that’s been written out directly into script, never ever do this, right? Never write information with the script, that’s just a bad idea. And then you have information it’s written into a comment on a site. You usually see this as debug information where people just write out information, so that they can figure out what’s going on, on their own site.

Unfortunately, each of these contexts has different escaping rules. And you need to be very sure that you’re escaping content correctly for the context in which you find yourself. Again, if you go to that website, I pointed to earlier, it gives you some information about these contexts and about what the rules might be.

For instance, inside of an attribute, you need to be very sure that you’d correctly escape quotes and it’s also the case that quotes aren’t actually necessary. So, you want to make sure that you escape the contents in a such a way that it’s interpreted as an HTML attribute as opposed to a potentially a script.

Fortunately, this is a completely solved problem. It’s been solved at least since 2009 when Google released an automatic context-aware escaper. There are escaping mechanisms in basically every toolkit that people use nowadays. So, if you use Rails or Django or whatever Java people use. Then there are, I guarantee you, mechanisms by which you can escape the content, which you can guarantee that the content is being escaped correctly when it’s delivered.

As I said however, you have to be absolutely perfect about the way you do this. You have to ensure that you perfectly escape every piece of output that goes to the site.

Unfortunately, it’s the case that attackers will spend much more time trying to find a single tiny hole in your application than you will spend defending your application to maintain the status quo. You’re going to be busy building new features. You’re not going to be very busy looking at every piece of HTML that you ever generate and ensuring that the escaping that you do is correct for the individual context.

Empirically, we see that people make mistakes, it’s simply the case. And it’s not even the case that you have to make a mistake. A browser vendor might make a mistake as well. If you look at old versions of IE, it’s very much the case. That strange things need to be done in order to insure that content isn’t executed as script. They’re simply bugs in the way that browsers parse things.

It’s a losing battle, in other words, to ensure that every piece of content is correctly escaped for every browser that a user might come to your site with, but it’s something that’s very difficult to do.

So, we make mistakes, browser vendors make mistakes. It’d be really nice if we could simply instruct the browser in some way that this piece of code is valid and this piece of code is invalid. I mean for you to execute this piece of code, but this other thing over here, why don’t you leave it alone for a little while.

This boils down, I think to the principle of least privilege. The idea is that every application, or every piece of an application should have the minimum level of privilege necessary in order to do its job correctly. This is really quite common in the UNIX world where you see a process start as root, set things up, and then immediately fork and drop down with setuid in order to have fewer privileges, in order to insure that it doesn’t have access to things that it shouldn’t have access to.

This is why you usually end up with like the MySQL or a PHP user on a variety of systems. Those users have fewer privileges than root and the system make sure that the application runs as that user as opposed to a user with higher privileges.

The good thing here is that if you minimize the privilege that an application has, then when an attacker finds a hole – and it will be a “when” not an “if” – then the attacker has a reduced surface area with which to work. They don’t have the ability to, for instance, write directly to the disc. And in that case, you protected yourself simply by minimizing the value of the – of this application as a target.

Has anyone read “JavaScript: The Good Parts” by Douglas Crockford? Yes, a good number of you. I think this actually fits very well into the concept of least privilege.

“JavaScript: The Good Parts” has basically the single theorem that there is a beautiful language hidden inside of JavaScript. The JavaScript itself is kind of large and has become ugly in a variety of ways. But there’s a beautiful core and if you limit yourself to this core, if you restrict yourself from using some of the more esoteric features, then you have a much easier language to understand but also an easier language to program in and to reason about.

My contention is that you can do the exact same thing for HTML and if you can do the exact same thing for your applications. You can explain to the browser that certain things, even though you would be allowed to do them, shouldn’t be allowed within the context of this individual site.

The way that you do this is via Content Security Policy.

Content Security Policy was originally invented by Mozilla about three, four years ago. It was implemented in Mozilla, I believe, Firefox 4 and has been slowly improved and steadily improved since then. It’s now on the W3C on standards track. I believe, actually today it will moved from working draft to candidate recommendation which is the next step would be proposed recommendation and at that point everyone should implement it.

Content Security Policy gives you exactly this mechanism. It allows you to very – to very clearly explain to the browser which things on the page, which pieces of content are intentional and which pieces of content should never be executed. It allows you then to – well, let’s look at mikewest.org.

So mikewest.org is my website and it has a variety of pieces of content. It has images, it uses some web fonts, it uses some script and some style. And we can very clearly explain to the browser that certain pieces of information or certain sources of information are trusted. And any other source, if someone was able to inject content into my website because it is, of course, incredibly high value then you would be able to very clearly distinguish between the injected information and the intentional information.

The policy is an HTTP header it can also be injected as a meta tag in Chrome. It looks something like this, Content-Security-Policy is the name of the header and then we set – we walk through a variety of directives. And each of these directives allows you to very granularly control the information that is delivered to a website or that the browser should interpret as part of the website.

We start out by making it secure by default. So, we set a default-src of 'none'. This means if we left it at that, then no content would run on the site whatsoever. It would render HTML, so the things that are contained within the – excuse me, within the website itself but no images would load, the script would execute, the style would load, no web fonts, no media, no XHR.

Basically, it turns off anything that could inject the content into the page. Then we slowly loosen this policy by saying for instance that mikewestdotorg.hasacdn.net is a valid source of style. So, I can load a stylesheet from this origin. And if it comes from this origin then the browser will allow it. If a style sheet comes from a different origin and is somehow injected into the page, the browser will simply not execute it, will not render that information.

We can skip down to script-src which does the same thing. It says mikewestdotorg.hasacdn.net and ssl.googleanalytics.com are both valid sources of script. If I load script from these origins they’re trusted. If I load it from any other origin, it’s untrusted, so if someone was able to inject the script tag into my site they would need to ensure that their malicious script existed on one of these two servers which will be a very difficult problem indeed.

This is a more or less complete list of all of the directives that are available in Content Security Policy 1.0. Content Security Policy 1.0 is going to – as I said is going to the next step in the standards track today. It’s implemented in Firefox. It’s implemented in Chrome. It’s implemented in Safari 6 and IE 10 implements a single directive, so they’re working on it. They’re not quite there yet.

Opera is participating very heavily in the standards process, so we expect that Opera will probably be 13 will have something like this but at the moment, it’s across about half the browsers that you’ll see on the web.

So default-src, we talked about script-src, object-src allows to control plug-ins that exist on the sites. You could say, you know, Flash files only from this style, images, media allows you to control HTML5 videos, so if I’m loading video information or subtitles or something on those lines that’s controlled the via media source. frame-src allows me to determine which items I can load into frames in a website. So, I might say that I only want to load YouTube videos, so I would allow https://youtube.com as a valid frame source and no other frame will then render on my page.

This gives you the ability to then very granularly determine which pieces of information should be part of your site and which pieces of content or which sources of content should never be allowed access to your website.

It has a down side however. The main – or not really a down side. I think it’s an up side, but a lot of people see it as a down side so I talk about it that way.

The main vulnerability that we see in cross-site scripting attacks is inline JavaScript. That is I write some – I request a page in such a way that causes it to write out the script tag or to write information into a context that gets executed as script. Content Security Policy takes more or less a “take off and nuke it from orbit” approach to inline script: that is, it bans it completely.

This is actually, I think a good thing. It’s enforces the strict separation of content behavior and rendering that we see in HTML, JavaScript and CSS. We’ve been talking about this for years as best practice, that you should separate your page out into: an HTML page that has clean mark up, a JavaScript file that enhances the behavior of the page in some way, and then a script or a CSS file that enhances the rendering, and makes things look pretty.

What we see here is in inline script tag that defines some functionality. We see an inline event handler that associates that functionality with a click on a button. And then we see a JavaScript URL that’s in a link that associates again this functionality that we define with the click on a link.

All of these can be trivially rewritten by extracting the JavaScript out into a separate JavaScript file, loading that JavaScript file in my HTML and associating the handler – the handlers of the events via JavaScript as opposed to doing it within the content of the mark up.

This I think is a good thing regardless of whether you use Content Security Policy. Again, it gives you this clean separation between your mark up and your behavior and allows you to edit each independently. It gives you a very clear picture of where your behavior is happening and where your mark up is happening. And it gives us the ability to very clearly distinguish between code that’s been maliciously injected into your site and code that exists on a trusted source of information.

That is, if I have an external JavaScript file the browser can be very clearly determine what the origin of that file is if on the other hand I have an inline script. It’s simply impossible for the browser to make a distinction between inline JavaScript that’s been maliciously injected and inline JavaScript that you intended to have on your page.

So again, Content Security Policy allows you to reduce the privilege of your website in a way that protects you from this sort of attack. It allows you to say that I’m not using inline JavaScript on my site and I don’t want inline JavaScript to ever execute. This gives you the ability to instruct the browser to help you out. The browser can then be your friend. It can help you ensure that only the information that you’ve actually delivered is getting execute in the context of the website.

What’s also interesting about Content Security Policy is a reporting function. It’s almost never the case that you can cleanly deploy in your Content Security Policy onto an existing application without breaking something. Content Security Policy gives you a mechanism of doing first a reporting mode where you say okay. I want to try this policy out on my application. And you can deploy it to actual users.

If you use Content Security Policy report only then the policy will be evaluated by the browser and will be interpret – or each load of a resource will be interpreted against the policy or validated against the policy, if it passes, great. If it doesn’t pass the load will go through, but it will send to a POST out to an end point of your specification. So you specify report-uri as example.com/csp-violations and it will send some JSON to you that it’ll help you identify the things that are breaking on your website or the things that would break based upon this policy.

So this gives you a deployment mechanism that’s relatively straightforward. You deploy a policy as report only. You look at the reports that are coming in. You fix bugs on your website that are causing these reports or you tweak the policy because perhaps there’s a section of your website that you didn’t actually look at.

Once you have a policy in place that’s not generating a large number of violation reports, you can deploy that policy as an active policy. What’s nice is that you’ve actually have a active policy and a reporting policy existing at the same time, so you can have a very loose policy like this one which simply says only load resource over HTTPS, that is no mixed content of any sort. I’m serving my site over HTTPS. I don’t want to load any information over HTTP. default-src of https: will allow you to do that, simply says no source that isn’t HTTPS should be allowed to deliver content. This is a relatively loose policy because it says any host that’s on HTTPS, so https://evil.com would also match but at least it’s secure, right? So that’s good.

What’s nice here is that you can deploy this sort of loose policy and the loose policy is more or less guaranteed to work on your site and you can test the policy at the same time by setting a report only flag. So, you can both have headers active at the same time.

The CSP report looks like this. As you see it gives you the URL that cause problems. It tells you what resource it tried to load. It tells you the policy that was active and which directive was violated. So, it gives you some information that allows you to debug the problems that you’ll see when you start to deploying CSP to your website.

You can, of course also use a report in an active policy, so if you deploy a CSP or a Content Security Policy to your site you want to know if people are attacking your website and this allows you to send reports based on violations.

So, once you’re sure that all the code that you deliver matches the policy, you can start getting reports about attacks that are existing against your site. And this will give you information to help figure out where those attacks are coming from which can be quite useful.

There’s a good article – this is just really just scratching the surface of Content Security Policy. If you’re interested and I really hope you are because this is the most important thing that’s happened in web security I think for the last two or three years. Content Security Policy on HTML5Rocks. You should go to HTML5Rocks anyway by the way. It’s a great website, that gives you a lot of information about HTML5 and new features that are coming out.

There’s specifically an article about Content Security Policy that I happen to think is relatively well written. And it gives you some good information about how you can start using Content Security Policy, what the purpose is, how it works and how you can deploy of any websites.

I think this is really important and I think it’s quite – it’s not easy to deploy this on existing applications, but there’s really no reason at all that you can’t deploy it on new applications that you’re building.

So, anytime you start building an application think about the resources that you’re using and think about the ways in which you can restrict the browser from loading resources that you don’t want the browser to load.

Content Security Policy 1.1 is in editor’s draft right now. I’m working with the standards body on this so if you guys have questions at all afterwards or if you have suggestions about things that you think could be added to a policy like this please do let me know. There’s a – the working group is the Web Applications Security working group if you have any questions at all you can join public-webappsec@w3.org and participate in all the discussion.

So this is a place that still rapidly in development, so if you have suggestions we’d be very interested in hearing about them.

So, that’s Content Security Policy. I think it’s incredibly important; it’s a really good way to reduce the privileges of a website down to the level that you actually need in order to do your job.

Another mechanism that HTML5 is starting to provide that does more or less the same thing or gives you many of the same ideas is called Sandboxing. Sandboxing allows you to include an iframe on your website in such a way that it runs with reduced privileges. Again, if we think about the single origin or the same origin model we have example.com and mybank.com. If example.com frames mybank.com so it loads MyBank in a frame, then it doesn’t actually have any access to that frame. It can’t use JavaScript to reach in to the frame and the bank can’t reach out of the frame into the parent’s in order to do any sort of damage.

This is a good thing and it allows you to include untrusted content on your website in a way that it can’t interfere with your website. So, the iframe in and of itself can act kind of like a sandbox, but if you include same origin content – that is, if example.com includes a page from example.com in a frame for example a comment or something along these lines, then, because they exist in the same origin, the parent can reach down into the child and the child can reach up into the parent.

Both of these might be useful, but generally speaking they’re not. Generally, if you’re including content in an iframe you wanted to be in someway separate from the page that exist within. Sandboxing is an at – or sandbox is an attribute that you can apply to an iframe but does exactly this.

It works very similarly to browsers that you see these days, where you have a brow – well, I’ll talk about this eventually.

The attribute is quite straightforward. If you apply a sandbox attribute to an iframe then a couple of things happen immediately. First no plug-ins can be loaded within this iframe, no script can be loaded, forms cannot be submitted, top level navigation simply won’t work. That is, if I apply target="_blank" or target="_top" to a link within an iframe usually that’ll navigate my entire page, the window as opposed to the frame, sandboxing blocks this. No pops-ups, no window.open, modal dialogs, things along these lines can’t be created from within the context of the sandboxed iframe. No auto-play. So, if I have video within this link auto-play won’t work, no pointer lock and no seamless iframes.

What’s really important and what I failed to write here is that sandboxing actually will push the frame into a completely separate origin, regardless of from where it was loaded. That is if I load the page from example.com in a frame it won’t act as though it’s example.com or won’t act as though that’s its origin. It will instead have what’s called a “unique origin” and a unique origin is one that matches no other origin ever. That is, it has no access to any data from any origin at all.

This can be quite useful because it gives you the ability to load content – load untrusted content in a way that simply can’t do any damage at all to your website. If script can’t execute in the context, it doesn’t matter if someone can maliciously inject script because it’s simply won’t execute, they won’t be able to navigate your page, they won’t be able to create pop-up’s, they won’t be able to move or bust out of the frame and move users through an area that they weren’t trusted to do.

You can of course loosen these restrictions and this would be the minimal sandbox that you can create. There’s still no plug-ins and there’s still no seamless iframes, but everything else can be enabled. What’s nice about this is that you can create a sandbox that gives only the minimum level of privilege necessary to a website, in order for it to do the work that website needs to do.

This concept allows you to separate the concerns within your application, so you can actually break your application into a variety of pieces, and now we’ll come back to the concept of the browser.

If you look at how Chrome works, you have a browser process that has all the privileges in the world, all the privileges of a normal application running on your system. They can go out through the web and get information, they can go to your disk and get information or write information to random files on your disk, it can execute arbitrary code and so on. It’s an application with all the privilege in the world but it’s a very thin application, it doesn’t do much, instead a lot of the work is delegated out to renderer processes. More or less you can think of every tab is a separate renderer process.

The renderer process is ask the browser for information, the browser determines whether or not the renderer should get the information, delivers the information to the renderer, allows it to do its work and awaits a response. The renderer grabs HTML untrusted content from the web, does a lot processing on it in order to build a render tree and then sends that tree back up to the browser once it’s verified that it’s trusted.

What this means is that the renderer doesn’t actually need any of these privileges. It doesn’t need to go out to the web, the browser does that for it. It doesn’t needs to write things to the disk–again, that’s what the browser is there for.

So, you separate the privileges of your web app or you take the application, you break it into pieces and give each piece only those privileges that are actually necessary in order for it to do its job. This allows you to build applications in such a way that each components can live inside of a sandboxed iframe. So, what you would basically end up doing is creating an API for your application based on messaging. So it would be asynchronous API by which you pass messages into a sandbox, allow that sandbox to do some sort of interesting work based upon the message that you passed in. And then ask the sandbox to send information back up to the parent in order to delegate that work to another process or to do some sort of rendering out to the website. This could look something like this, so here’s a toy example of how this might work.

We have a Content Security Policy associated with this page that says script-src of 'self', so only script that’s loaded from my current origin can be executed within the context of this page, of this protected resource. We load a script called main.js and we have an iframe on the page that loads sandbox.html. The sandbox allows scripts, but allows nothing else.

main.js looks something like this and we’ll talk about it in a little bit more detail later on, but the idea is simply that we bind an event handler to the button and when I click on the button, we pass a message into the iframe and we listen for a response, so we listen for messages on the page and we pass messages into the iframe. This is a very, very simple messaging API using window. – I’m sorry, iframe.contentwindow.postmessage. So, we grab the iframe, we grab its content and then we post the message to that.

The iframe looks something like this. The iframe loads in Handlebars which is a templating library. And it’s a templating library that does a couple of things for performance reasons that are a little bit dangerous. Specifically it’s uses eval in order to generate a function and executes this function in order to actually do the work of templating. So, it’s takes untrusted code. It evaluates in some sort of context and creates a function which could be executed. This is a bit dangerous and Content Security Policy of 'self' will actually block you from doing this. It’ll block you from using untrusted content in the context of an eval. It’ll block eval entirely in fact.

This means that Handlebars could not execute inside the context of the page. So, if I look at index.html, Content Security Policy will actually block Handlebars from executing. However inside the context of the sandbox there is no Content Security Policy because I haven’t set one: it’s a completely separate HTML document. It’s also a document that doesn’t have access to any of the information that was in the main page, that was in the index.html, so I can more or less without issue allow JavaScript to execute in this context and allow potentially dangerous JavaScript to execute in this context without worrying about it stealing my information because there’s no information in this context for it to steal.

It listens for events or listens for message events, grabs the context that was passed in and uses that context to populate a template, so Handlebars does its work. It uses eval, it uses dangerous but very performant code in order to do some templating and then I can pass that HTML back up to my parent frame and in the parent frame you’ll see that it will actually using document.body.innerHTML to write this content out to the page.

This is incredibly dangerous, you should really never do this inside the context of an application because innerHTML will execute scripts, so if I have a script tag that’s pushed into a page via innerHTML that will execute.

The reason that I can do it in this context is because the page is protected by Content Security Policy. It says that even if dangerous content has been injected into the page, no script will actually run. The worse that an attacker could do in this case is deface my website by making the sandbox… If they were able to find a vulnerability in the sandbox the worst that they could do is generate bad HTML, they couldn’t generate dangerous HTML that actually execute a script and exfiltrated information.

This gives you the ability to separate your application into pieces that need special privileges and pieces that don’t need those privileges. It allows you to say that the main application is protected by a very strict Content Security Policy, the pieces of the application that wouldn’t fit into that policy or that would have issues. Maybe it’s a legacy application that you have very – that you have a very hard time rewriting for these piece – for this new style of programming. You put that into a sandbox, you allow it execute within the context of that sandbox and you build a very thin messaging API on top of the sandbox and on top of the application itself in order to pass messages back and forth between these two components.

You separate out the concerns and you say that the one piece of the application should be able to execute script, which should be able to execute potentially dangerous scripts and the other piece of the application has no need of those information whatsoever. It should only rely upon this new API that you built.

This gives you a really nice way of extracting pieces of your – pieces of your application but you don’t – that don’t need privileges and to reduce these privileges down to the minimum level that they actually need in order to do their job.

There’s one other thing that a sandbox can potentially be useful for and this will be available in, we’ll say the near future. It’s in Chrome Canary right now but it’s not quite there yet in other browsers. Specifically I’m talking about the seamless attribute and the srcdoc attribute.

These allow me first, to create an iframe that seamlessly blends in with the content of my page. One of the things that you see with a normal iframe is; that it’s a completely separate document. So, it has its own stylesheets, has its own JavaScript and so on. The seamless attribute allows me to create an iframe in my page and allows CSS to flow down into that iframe. So, if I have a paragraph in that iframe, it’s going to use the paragraph style from my documents not from its own – or it can override them of course but the CSS flows down into that document or into the iframe.

The other nice thing is that the seamless iframe shrink wraps itself to the size of the content on the page. So, instead of specifying that I have an iframe that’s, you know, 500 by 500. I can simply say it’s a seamless iframe which means it will only be as big as the content, that’s been pushed into that iframe. This is really quite nice.

It works with the same-origin policy. So, if I load content from my origin then CSS flows down into it. If I load content from my separate origin, CSS won’t flow into it because I can actually use CSS to extract information from that page with some of the new selector attributes that are out.

What you also see here is a srcdoc attribute. This means, instead of making an HTTP request down to a server to get information to populate this page or this iframe. I can populate it simply by adding information to an attribute. This means that all I have to do is correctly escape information for a single context. I can look at the information that the user has given me for example for a comment on a webpage. I can escape that in such a way that it works within the context of an attribute which is easier than trying to escape it for any context whatsoever. And that information is then used as the body of this iframe. So, instead of making an HTTP request, I can specify the content of the iframe directly within the context to the page itself.

For something like comments, this can work quite well because what I can then do is sandbox this iframe. So, that even if I completely screwed up when escaping the information. I can ensure that no plug-ins can run, no script can run and so on. But the content that’s actually being delivered into this iframe can be executed in a very safe way. The sandbox attribute is supported in WebKit quite well. It’s in – it’s been in – it’s been in Chrome for quite some time. It’s in Safari 6 and it will be in new webkit browsers to come out. It’s just been supported inside Firefox. So, I think, Firefox 18 now has support for the sandbox attribute and it’s supported in IE 10.

So, it’s in the new browsers that are coming out, but it has really no downside for old applications. They will be just as insecure as they were before if you’re using this sort of attribute. With that, I think I’ll ask if anyone has any questions.

I’d really before – actually before I would suggest you go out and read the HTML5Rocks article. I think Content Security Policy is the most important thing that’s happened again in web security for quite some time. I think it’s really quite important and I would be thrilled if even one of you started implementing Content Security Policy on your pages. If you have any questions about that at all, please drop me an email. Please contact me on Twitter or in G+ and if you have any questions right now. I’d be really happy to answer them. Do we have like a mic anywhere?

» Yeah. Yeah. Yeah.

» MIKE WEST: Oh, yeah. It’s over there. Great.

» So, with the Content Security Policy, you said that you can’t also have inline JavaScript anymore. What about style, inline styles?

» MIKE WEST: It’s the same story. There is a mechanism by which you can allow inline style if you really need it. So, if you have a legacy application and you simply don’t have the time to rewrite it, you can allow inline style but by default. It’s – if you set a style-src then inline style will also be removed because it’s just as dangerous as inline script.

» I agree. Thanks.

» MIKE WEST: Cool. Great. Thank you very much. Oh, there was – there was another – sorry. There was another question. If you have actually – if you have question just come up and ask.

» [INDISTINCT]

» MIKE WEST: The question is…

» [INDISTINCT]

» MIKE WEST: Yeah. So, the question is: First of all, this looks difficult. So, you’re talking about sandboxing, correct? Yeah. So, building this sort of API is work and you have to look at your application and determine what the APIs actually are; what the components are and then build some sort of messaging framework that pushes messages back and forth between various frames.

You’re entirely correct. It is more difficult than writing an application in the current style, where you just had everything in a big block that all executes in the same context. It is more difficult and it – I do think it’s the case that frameworks will start to pick up that work.

We see sandbox now being deployed in enough browsers that I think it will be interesting for frameworks to start building things out on this way. Until now, it’s only been available in webkit which has made it less attractive for framework developers.

But this is something, if you look at Chrome applications or Chrome extensions. This is something that we’re starting to force developers to do now. We use it all throughout Chrome and this is a mechanism of building applications that we think has such good security characteristics that it’s worth the effort for us to start asking people to develop in this way.

You’re entirely correct, it’s more difficult. My contention is simply that the benefits outweigh the difficulty.

It won’t be the case for every application, but a good example would be the office document reader inside of Chrome OS. So, the office document reader takes untrusted documents in .doc format, parses them with JavaScript and then renders them to the page. And it does it in exactly this style where you have a sandbox renderer that takes information. So, you pass a document into that renderer. It does this work, it uses all this untrusted code or evaluates untrusted code and then pass this information back to it’s parents in a way that it doesn’t create new security vulnerabilities.

So, it is difficult. It’s not the easiest thing in the world and I don’t think I would be ever claim that it is. My claim is simply that the difficulty is worth it because it gives you such good security characteristics.

You know this piece of your application, even if it’s compromised, even if you made huge mistakes, can’t access the information that is secure inside the context of the non-sandbox piece of the application. So, it’s difficult problem, I agree with you but it’s one that I think that’s worth addressing.

All right. Thank you very much for your time.

If you have any questions, I’ll probably be at the Google booth downstairs for a lot of the time. Actually, one more thing, there’s a talk in this room at I think 4:00 – I think 4:40 called something along the lines of Development with Secure HTTP headers. I think it’s going to be worthwhile. So, if you go – if you’re interested at all in the other things that you can do, other things that you can do, other things that you can instruct your browser about in order to make your applications more secure. I’d really suggest that you get to that talk. I think it’s been given by Frank Kim (@thinksec) and it should be really interesting. So, 4:40, this room, I’ll be here and I hope you guys are too.

So, thank you very much!

Content Security Policy: Feature Detection

2012-05-02T00:00:00+02:00

AngularJS’s latest release candidate is the first framework I’ve seen that cleanly supports a content security policy that restricts usage of eval(), new Function(), and the like. I’m thrilled to see this happening, and it’s a testament to the priority that the Angular developers place on security. CSP is quite simply one the best XSS-protection mechanisms available to developers these days in modern browsers. The more frameworks that hop on board, the faster sites can start adopting CSP, and the safer we’ll all be on the net.

All that said, the implementation isn’t as complete as it could be. Angular requires that the developer manually opt into CSP-friendly mode via the ng-csp directive. This is error-prone at best, and introduces complexity that would be better hidden away inside the framework. The Angular developers recognize this shortfall, and are explicitly requesting some sort of feature detection API that would allow frameworks to query the currently active policy to determine its boundaries, and fork their implementation accordingly.

This does seem like a great addition to the spec; I’d suggest the following implementation:

Add document.[prefix]contentSecurityPolicy as an object that exists in browsers that support CSP. This would enable trivial feature detection of CSP as a whole, which would enable frameworks to make intelligent decisions about how to proceed through the following use cases:

Is a policy enabled? If not, perhaps I’d like to set one via meta injection.

document.contentSecurityPolicy.active is a boolean property: true if a policy is set, false otherwise.
Can I execute eval() or use new Function()?

document.contentSecurityPolicy.isWhitelisted('script-src', 'unsafe-eval') returns true if unsafe-eval has been defined for the script-src directive.
Can I embed a data: image or frame?

document.contentSecurityPolicy.isWhitelisted('image-src', 'data:') and document.contentSecurityPolicy.isWhitelisted('frame-src', 'data:')
Can I include Google Analytics?

document.contentSecurityPolicy.isWhitelisted('script-src', 'https://ssl.google-analytics.com') (Note that isWhitelisted should do the hard work of dealing with wildcards. This example should return true if *.google-analytics.com is whitelisted.)
Are reports being sent? If so, where are they going?

The document.contentSecurityPolicy.reportUri property is either undefined if no report-uri directive is set, and a URI if the directive is set.

This seems like a reasonable first pass at a strawman for discussion. Thanks to Paul Irish, Eric Bidelman, and Pete LePage for walking through this with me.

What do you think?

Chrome connects to three random domains at startup.

2012-02-18T00:00:00+01:00

When you start Chrome, it attempts to connect to three random domains like http://aghepodlln/ or http://lkhjasdnpr/. I’ve seen a few theories about why exactly this happens that brush up against the nefarious. The true rationale is incredibly mundane: hopefully this short summary will clear things up.

The goal of the requests is to determine if you’re currently on a network that intercepts and redirects requests for nonexistent hostnames. For example, it’s not at all uncommon for ISP to transparently redirect failed DNS lookups in order to convert requests like http://text/ into requests for http://your.helpful.isp/search?q=text. Leaving aside a discussion of the rightness or wrongness of these “helpful” activities, this behavior causes problems for Chrome. Specifically, it breaks some heuristics the Omnibox uses to determine whether a user means to search for a specific term, or to visit a non-standard domain name.

Google’s internal network is a good example of how this can cause problems. Internally, a short-link service named “go” makes sharing memorable links straightforward. If I type “go” in Chrome’s Omnibox and hit enter, it’s not exactly clear whether I mean to visit http://go/ or to search for “Go” (which is an interesting programming language, by the way). Chrome does its best to do The Right Thing™ in response to this sort of user input by executing a search, and then, in the background, executing a HEAD request for the potential domain. If the server responds, Chrome will display an infobar, asking if you meant to navigate to http://go/, and it will remember your response for future reference.

As you can see, this feature is completely broken if your ISP intercepts all such requests: you’d get infobars on every one-word search. So Chrome checks things out at startup, and whenever your IP address changes. And, Chrome is beautifully open-source, so let’s take a quick look at the very straightforward implementation:

IntranetRedirectDetector is the place to start. When Chrome starts up, it creates an IntranetRedirectorDetector object. This sets up a short delay (currently hard-coded to 7 seconds) in order to ensure that it doesn’t get in the way of time-critical startup activities, and then calls IntranetRedirectDetector::FinishSleep() where the real work begins. This method generates three random domain names, and kicks off asynchronous HEAD requests to each in such a way that they don’t generate cache entries, and don’t save cookies. As each of these requests completes, IntranetRedirectDetector::OnURLFetchComplete() is called to record the result. If any two of the three requests resolve to the same host, that host is stored as the network’s “redirect origin”. Easy.

This information is used in AlternateNavURLFetcher to determine whether or not an infobar should be shown for a specific Omnibox-generated search. If the HEAD request returns the same site as the redirect origin Chrome saw at startup, then it’s ignored. If it’s a different origin, then a helpful infobar might be in order.

So there you have it. Chrome makes three requests to random domains just after startup in order to provide its Omnibox heuristics with enough information to correctly work out a user’s intent. These requests are not sending your valuable data anywhere for nefarious purposes, nor are they useful for tracking purposes. The requests happen in order to fix crbug.com/18942, and for no other reason.

Nerdy New Year

2011-12-31T00:00:00+01:00

New Year’s resolutions come in all shapes and sizes; if you’re a web developer stuck for good ideas of things you could do to improve the world (or at least the tiny chunk of it that’s concerned with web performance and security) I’d like to propose two: secure user’s connections to all your websites, and use a cookieless domain for static assets.

SSL Everywhere.

If you look closely, you’ll notice that mikewest.org is being served via a secure connection: https rather than http. This is a Good Thing™, for reasons which I explored earlier this year. I’d like to suggest that each of you pop open Firefox (yes, Firefox) and head to StartSSL where you can, for free, create an account, verify your ownership of a domain, and generate an SSL certificate.

I’ve moved to StartSSL for every domain I own that hosts a website. It’s trivially easy, very well supported (I’ve never waited more than 18 hours for a response to a support request), and works well in every browser I care about. Moreover, it’s run by real people who you can email. I’ve gotten responses from the founder himself at two in the morning; the service is brilliant.

I’d suggest, actually, going through the extra step of verifying your identity with them so that you can generate wildcard certificates, and certificates with DNS alt names: both will make it easier for you to host SSL websites without the annoyance of setting up separate IP addresses for each host. They charge $59.90 for the verification, at which point you can create as many certificates as you like. It’s a heck of a deal.

And hey, while you’re at it, start serving Strict-Transport-Security headers too!

Cookieless domains for static assets

You’ve probably heard at some point in the past that it’s a good idea to serve static assets from a domain that doesn’t set cookies. Yesterday, I finally got around to doing that here. If you hop into devtools or Firebug, you’ll see that this page’s CSS, JavaScript, and images are all being served not from mikewest.org, but from mikewestdotorg.hasacdn.net. Setting up an alias like this is trivial in any server. Here’s how I made it work in Nginx:

My websites all have specific directories in which static assets live, /home/mkwst/public_html/mikewest.org/public/static for example. I simply set up a server listening for requests to mikewestdotorg.hasacdn.net, and use the static asset directory as the root. With that in place, I ensure that all files are served with far-future expiry headers, and then set up some trivial versioning magic by ignoring the first chunk of the URL: https://mikewestdotorg.hasacdn.net/20111231/style.css serves the same file as https://mikewestdotorg.hasacdn.net/1/style.css, but because the paths are different, the file can be loaded and cached anew when something changes.

That setup looks like this:

server {
  listen 80;
  server_name mikewestdotorg.hasacdn.net;

  # Turn off logging for static assets:
  access_log  off;
  error_log   /dev/null crit;

  # Set the root from which Nginx reads files for this domain:
  root /home/mkwst/public_html/mikewest.org/public/static;

  location / {
    add_header Expires "Thu, 31 Dec 2037 23:55:55 GMT";
    add_header Cache-Control "public, max-age=315360000";
    
    if (-f $request_filename) {
      break;
    }

    rewrite ^/\d+/(.*) /$1 break;
  }
}

Easy! I’ve thrown the whole config file up on GitHub if you’re curious.

So there you have it; enjoy the end of your holidays with these two resolutions that you can bang out over the weekend. You’ll be ahead of the game, and the envy of all your friends and neighbors when you compare notes at the end of 2012.

Making Your Web Apps Accessible Using HTML5 and ChromeVox

2011-12-16T00:00:00+01:00

Back in November, I presented twice at the Google Developer Day in Tel-Aviv. The first of those talks has been uploaded, and I spent most of the afternoon transcribing it to post here. I wanted to give the audience (you!) an introduction to screen readers, and to building accessible websites and applications. I think it was pretty successful, and I hope you enjoy it if you watch at home.

I’d highly recommend that, if you’re at all interested in this stuff (and you should be), you go out and install ChromeVox to start playing around with how your sites sound. It’s trivial to get up and running, and will start to give you a sense of what you’re doing well, and what needs improvement. The team has done a brilliant job putting it together, and it’s very much worth your time to experiment with.

The slides are available at mkw.st/p/gdd11-berlin-a11y if you’d like to follow along at home, and here, without further adou, is the embed, followed by the transcript:

Video

Transcript

MIKE WEST » What I’d like to discuss with you today is a topic that I think is incredibly important. It’s not a topic that I think is very sexy, and it’s something that often gets ignored when building applications. Even Google’s applications. But I think it’s really important to talk about accessibility.

Making applications not only available to a wide variety of people, but usable by those same people.

As a way of getting into this, I want you to think about the Google+ page. All of you have probably seen this. There’s a button up in the top corner that says “Add to Circles” and the interaction model is the following. I take my mouse, I hover it over the “Add to Circles” button, and then something pops up. And at that point, I’m able to select circles into which I can put one of my friends or one of my contacts. This works really, really well if I can use a mouse.

All of you close your eyes. Now grab your mouse and hover… over the… That’s kinda problematic, right? If I can’t see the screen, how do I use my mouse to hover over anything on the screen? This mode of interaction, while very interactive and very rich, excludes a wide variety of people that either can’t or don’t want to use the mouse for some reason. And in fact, when we first launched Plus, this was completely inaccessible. It was impossible to use the circle picker widget with anything other than a mouse. If you didn’t have a mouse, you were simply out of luck.

What I want to talk about today is how we can avoid that. How we can build applications that are accessible and universally usable.

There are a couple of types of accessibility, and the type that I really want to talk about today is users that use an assistive technology of some sort in order to access a website. These users could be blind, they might be completely unable to see the screen, in which case they’re going to use something like a screen reader or braille reader in order to get the information provided to them in a form that they can access. They could be users with low vision, in this case they might use a magnifier or a lens of some sort in order to make objects on the screen bigger so they can actually interact with them well. Or they could be motor impaired in some way. There are people that use foot pedals. There are people who can only use individual fingers, or they might have some some sort of mouth control, be it either with a physical object they control with their tongue, or with speech control such that they can simulate clicks on specific items on the page.

We want to be able to support all of these users, and what I want to talk about today is how we can do that with HTML5 and with screen readers.

One such screen reader is called ChromeVox. ChromeVox is a screen reader built specifically for Chrome by the Chrome Accessibility Team. This uses the text-to-speech API that Chrome provides as an extension API. So anyone can write anything exactly like this, and actually all the code is open source. So you can take a look at it and see exactly how it works. This is completely free, you can download it. It’s built directly into ChromeOS as the accessibility mechanism for ChromeOS, and you can download it for Chrome on any other platform. It’ll work quite well, and in fact I’ll demo it a little bit today.

CHROMEVOX » Enter your name. Choose your favorite. Screen Reader Introduction Heading Three.

MIKE WEST » This is what ChromeVox sounds like. If none of you, if one of you hasn’t used a screen reader before, this is what it sounds like: you get a very mechanical tone.

CHROMEVOX » [Beep] Enter your name. Edit text.

MIKE WEST » That reads off the thing you’re currently focused on on the page, and generally speaking will give you some meta-information about that. So when we go back up to the header, we’ll hear:

CHROMEVOX » Screen reader introduction. Heading three.

MIKE WEST » It tells you that it’s a heading, and it tells you that it’s a level three heading. What this tells you is that the semantics of your page are really critically important. If we jump down into the form:

CHROMEVOX » [Beep] Enter your name. Edit text.

MIKE WEST » Here we read not only that you can type something into this field, but we get a label for it as well. This gives you a really, kind of, a rich visual, er, mental image of what a visual user would see on this page.

CHROMEVOX » [Beep] Choose your favorite color. Red. List box one of ten.

MIKE WEST » It’s a list box. There are ten items. It gives you some semantics along with it.

CHROMEVOX » [Beep] Submit. Button. Having trouble, click here for help. Link.

MIKE WEST » So it tells you that there’s a link on the page. And there are some other functions so you can see where that link goes and a variety of other functionality. But that’s the basics.

What I want to talk about today with that in mind are three things. First, I want to talk about what you do when you’re starting from scratch. When you have complete control over the HTML, what’s the best practice? What should you start out with?

Second, I want to talk about the case that most of us find ourselves in, where we have an application that isn’t exactly semantic. It doesn’t work quite as well as we’d like it to in terms of the markup or in terms of the CSS, but we still want to make sure that it’s accessible. How do we go about doing that?

And finally, I’ll point you to some tools and resources that you can look at later on. There’s a lot of information here. I’m not going to touch even half of what it takes to make a website accessible, but I am going to give you some pointers, and I hope that I give you a good basis.

So let’s start out.

What’s really important to understand about Chrome, er, about screen readers in general is that all they have to work with is the DOM. They have the document object model. This means that the semantics of your page are incredibly important, and the visual aspect of your page is incredibly unimportant. For instance, we can all see that this sentence here is “The rain in Spain stays mainly on the plain.” Let’s see what ChromeVox thinks about it.

CHROMEVOX » Example. Heading. The plain in rain stays mainly in the Spain.

MIKE WEST » That’s a bit odd. I wonder why that happened. If we look at the DOM that was used to create this, we see that what’s happened is that we’ve simply used absolute positioning in order to move things around on the page so that they look like they’re in a certain order. In the sentence it makes very little sense to do that, but in our applications we do this all the time. We take things from disparate parts of the DOM, and we jam them together visually because that makes sense, that’s how they should be. But we didn’t code it that way. In fact, we coded them at separate ends of the spectrum, and in that case, a screen reader user, or anyone who is only able to work with the DOM, is going to have a really hard time understanding your web page, and working with your web page.

So it’s important to understand a couple of things [CROSSTALK] about things when working with DOM, and when creating a website. What’s important, first off, is to have logical sections of your page, and to order those sections in a way that makes sense for someone who’s trying to use this application. In other words, the thing that’s most important about your page should probably come near the top of the DOM. The things that are much less important should probably come near the bottom, even if it’s easier for you in some way to put navigation links all the way at the top of the DOM, those probably aren’t the things people are most interested in, so you want to put them later on the page.

It’s also important to group the things on the page together that have any sort of semantic relationship with each other. You can use any sort of HTML5 tag to do that, for example, the section tag.

Last thing, yeah, it’s important not to use tables. Tables are for layout. Or, not for layout. They are for data. If you’re trying to set up something on your page with tables, then you’re at the wrong conference in general. So, don’t do that.

Interactive controls. What’s interesting about a lot of applications and a lot of modern web applications that we see on the web today is that people are using div and span to mean absolutely everything. This is a really bad practice for a wide variety of reasons. There are are elements that actually have semantics associated with them, and have interaction associated with them. For instance, if I have an onclick event on a div, I have to do a lot of work in order to make that replicate something like a button. If I just used the button element, I get a lot of that for free. I get some keyboard interactions. I’ve ensured that it has the exact same semantics as a native button on a native web application, because the browser is doing the work for me. I don’t have to go through and build all of this out myself, I can leverage the power of the browser, use the correct element, and in that case, get things like keyboard accessibility almost for free. This is just good practice, there’s no reason not do this at all.

The last thing here that’s really important to note is that divs and spans are by default not focusable. If they’re not focusable, they don’t show up for a screen reader. It’s just that simple. You need to make sure that anything that a person is interacting with can obtain focus on the page. I’ll give you a quick example of why that’s important. In a little bit.

So if we turn ChromeVox back on [CROSSTALK].

CHROMEVOX » Custom button. Live coding example. Heading three.

Click on this button.

MIKE WEST » So, there’s probably a button coming up. I’ve just heard some text that said “button”, that’s important. So let’s jump to the next element on the page.

CHROMEVOX » Send.

MIKE WEST » Send. Ok. Let’s hit a button. Well, nothing seems to be happening. I wonder why that is. If I click on “send”, of course, I get an alert. Hrm. Something’s going wrong here, what could it be?

The most important thing is to simply change this to a button.

If we change it to a button, and then refresh.

CHROMEVOX » [Beep] Send. Button.

MIKE WEST » Send, button. ChromeVox now recognizes this as a semantic element. If I hit enter again, I get the alert. In other words

CHROMEVOX » Send. Button.

MIKE WEST » Enter will simulate a click, if the element is a button. The browser will do the work for you. If it wasn’t a button, you would have to do things like onkeydown, and then, have an event handler for onkeydown in order to make sure that you replicated all of the functionality that a browser would.

This is something that you simply don’t want to do on your own. You want to make sure that you use the right elements.

CHROMEVOX » Labeling. Label your.

MIKE WEST » What’s also important, specifically with regard to forms, is to make sure that every element on the page that users are going to interact with in some way has a label. This is incredibly important, and it’s difficult to overemphasize how important this is. If you don’t have labels, then you simply have text boxes on the page. A text box is completely meaningless without context. I know that I’m supposed to enter some information into this text box, but I have no idea what it is, and I have no idea why it might be important for my interaction with this application. If, on the other hand, I have a label, and the label syntax is absolutely trivial: You simply say “label”, and then use an ID in order to say what this thing is labeling. If I do that, then the screen reader will understand that there is a semantic relationship between the text and the element on the page. It will bind those together when it reads them out to me. In other words, I will get good semantic information about what this thing on the page is that I’m meant to interact with.

Again, and this should be really really basic, every image on your page should have an alt tag. There’s no reason at all that an image shouldn’t have an alt tag. There are two types, however, of images on your page. There are images that replicate information that is already available, in other words they are purely decorative. And there are images that are, in and of themselves, informative.

For the former type, you should have a blank alt tag. If you have a blank alt tag, that means “I’ve thought about this. This image exists on the page, it’s visually important, but it has absolutely no semantic meaning.” In that case the screen reader will simply ignore it. A blank alt tag means “ignore this image.”

A missing alt tag is, however, something completely different, and we’ll look at exactly what that does in a moment. For the normal use case, you have an image on the page that’s informative in some way, you should have alt-text associated with that that says “This image has some meaning, here’s what it is.” Otherwise, it’s completely useless for a person who can’t see the page.

So, again, let’s take a quick look at what a form sounds like when you don’t do things correctly.

CHROMEVOX » Edit text.

MIKE WEST » Edit text.

There’s nothing here. I know that there’s a text box. I should probably type something, but I have no idea what it is.

Oops.

CHROMEVOX » Password. Edit text.

MIKE WEST » Password. Edit text. That’s interesting. It doesn’t really help me. I know that it’s a password, and that’s better, but it really doesn’t help very much.

Now let’s look at the image. What’s really interesting about this is that I have no alt text here at all. What this means [CROSSTALK]. This means that the browser is going try to figure out something for me. And usually it does an absolutely miserable job.

CHROMEVOX » Nine zero one d three n nine four t three. Image.

MIKE WEST » So it reads the name of the image. Especially when you have these sorts of big CMS systems that automatically generate images in a variety of sizes and a variety of contexts, the name of the image is never informative. But it’s just common practice that a screen reader will try to give you any information that it has. And in this case, the only information it has is the name of the image. This is really really bad behavior, and it’s something that you should avoid to whatever extent possible when building your own applications.

Let’s look at how we would solve this problem.

The first thing we would need to do is change these spans to labels.

By doing so, we give each of the, each of the elements on the page, or each of the form elements, semantic information. We tell it that the first label is pointing to the first form element.

I can’t talk and type at the same time, as we’re finding out. For user.

I just can’t type at all, I think is the problem.

So.

CHROMEVOX » User name. Edit text.

MIKE WEST » So this time, when I click on it, or if I’d given it focus in some other way it would have behaved the same, when I click on it, it not only reads out that it’s an edit text box, it also tells me the label associated with it so that I know that here I’m supposed to type my user name. That’s excellent behavior.

Now let’s fix the image.

CHROMEVOX » User name. P I N. Password. Edit text. Golden Gate.

MIKE WEST » Excellent. So now I know that there is information associated with this image. In that case, I’m actually able to use it to understand the page. So again, big lesson here: use an alt tag, use labels. Both of them are absolutely critically important, and really very basic. If you’re not doing this already, you’re doing the wrong thing.

What we’ve talked about and what we’ve seen here is that focus is really important. You see a big outline on the page of what the focused element is. The focused element is exactly what the user is currently interacting with. If they have a mouse, they might be hovering over something completely different, or they might be clicking on things that can’t accept focus. That simply isn’t the case when you’re dealing with someone who’s using a screen reader. In this case, you need to make sure that you provide focus hooks within your application.

First of all, so that the important elements the user is supposed to interact with are focusable. And second, that you not only accept, um, you not only accept things like hover and, um, onkeydown and a variety of other things along those lines.

What will become important later, what we’ll see later on is that it’s not only important to ensure that each element can be focused, but also important to manage focus on the page. If, for instance, I have a dialog box that pops up, I want to make sure that the focus stays within that dialog box if it’s modal.

I’ll show a quick example of how that might work.

So here I have “Buy more printer ink”. I get a modal dialog box. I see that it’s modal because the screen has been darkened, so I have some sort of visual feedback that I should click on one of these two buttons before I do anything else. I’ll click on that. Let’s see how it sounds.

CHROMEVOX » Popup dialog. [Beep] Buy more printer ink. Button.

MIKE WEST » So it’s a button. That’s good. I hit a button.

What happened?

According to the screen reader, absolutely nothing, because the focus didn’t move. I hit enter, or I clicked on it, but the focus stayed on the button because nothing told the focus to move. What really needs to happen here, probably the best case scenario, is to move the focus programmatically to the first focusable element within the context of this dialog box.

Let’s see what we can do about that.

Happily, moving focus around is incredibly trivial. You simply have to call .focus() on the correct element. Let’s look at it again.

CHROMEVOX » O K. Button.

MIKE WEST » What we see here is that focus was automatically moved inside the context of this dialog box. That’s great. However, there’s another aspect that we need to think about. What happens when I click on one of these two buttons? What happens in that scenario, if I hit enter, focus is dropped on the floor. In other words, nothing on this page has focus anymore, which means the screen reader is going to start back up at the top of the page. That’s really bad experience.

What we instead want to happen is to bring the user directly back to where they were when they activated this dialog box. We can do that relatively trivially. So here we see that the button is called “confirm”, so I can simply associate focus with confirm.

If I refresh this:

CHROMEVOX » O K. Button.

MIKE WEST » Jumps me in.

CHROMEVOX » Buy more printer ink. Button.

MIKE WEST » Jumps me back out. This is good experience. This means that I move directly from the dialog, directly back onto the page where I was. I know where I am, I understand the context, and I’m able to deal with that.

What we

CHROMEVOX » O K. Button.

MIKE WEST » What is problematic, however, is that if I keep hitting Tab, I can jump outside of this dialog box. Visually, I understand that I’m not supposed to do that, the page is dark. However, that doesn’t really work when dealing with a screen reader. Instead, we need to manage focus for the user in order to show them that they should stay within this context. They need to make a decision, yes or no. That’s the only time you should use a modal dialog.

So how can we go about doing that … [CROSSTALK]

CHROMEVOX » Buy more printer ink. Button. [CROSSTALK]

MIKE WEST » … and type, so I will copy.

I am cheating, and it’s awesome.

There we go.

So now, I’m hitting tab, and trying to get out of the box. Shift-tab would bring me to the previous focus item. I’m not able to. I’ve thrown in some code that makes it possible for me to intercept blur events and focus events, and make sure that I’m only focusing on one of the two items that should be focusable within the context that I currently find myself.

This isn’t that difficult, basically, I’m really just adding event listeners and dealing with it.

Um.

And now Chrome is crashing. Ha ha.

You know what’s awesome? Dev version of Chrome.

I really recommend that you use the dev version of Chrome. I do not recommend that you demo with the dev version of Chrome because it causes small problems like this.

Good times. Let’s see if I can get out of this.

Regardless.

Um.

Doo, doo doo, doo doo. Ha ha. Good times.

Ah, my good friend Force Quit.

My good friend Force Quit. There we go, hey look at that.

Now let’s open this back up.

So what you might not know about Chrome is that we have three different channels. Actually we have four, but three are important.

We have a stable channel, that’s what every user actually gets. And it is, as the name implies, stable.

We have a beta channel, the beta channel is a little bit less stable than stable. Stable gets built about every six weeks, beta gets built probably about every three weeks. Dev, on the other hand, is built on a weekly basis, sometimes more than weekly. More than weekly is actually awesome, because it shows you exactly what’s happening on trunk. But. It’s slightly problematic in that sometimes it’s broken. Like now. Ha ha.

Anyway.

The last thing I’d point out when dealing with applications that you have complete control over are keyboard shortcuts. It’s really quite useful to give users the ability to control the application in a controlled way with a keyboard. For instance, if you go to GMail, you might not know that you’re able to use Vim keybindings, so J and K, in order to jump between messages. You’re able to use keybindings in order to archive, and jump back to the inbox. It actually makes you much more efficient.

For specific types of applications, keyboard shortcuts can be incredibly useful. There are three types that I list up here. I don’t really think it’s incredibly important to talk about them, and I’m running out of time, so I’ll move on.

We’ve talked about the ideal world. When you have complete control, you want to use semantic elements, and you want to make sure that you manage focus correctly, and that you only use those elements that kinda do all the work for you. That you use buttons instead of divs and so on.

What we usually end up with, in the real world, is code that kinda looks like this. It’s just a jumble of random crap thrown onto the page. You need to figure out first what it is, and then you need to change it to do something useful and accessible.

Generally this means that you’re trying to build an interactive control that HTML simply doesn’t provide for you. So if we look back to the circle picker that we looked at before, there’s no native HTML widget that says “When I hover over this thing, pop something up and do some sort of checkboxy goodness.” That simply doesn’t exist as part of HTML; It’s something you need to build on your own.

When we find ourselves in these sorts of situations, we need to figure out how we implement that in a way that is actually accessible. One thing that we can use is something new called ARIA.

ARIA is part of the HTML5 specification, kinda, depending on who you ask, and it gives more semantic information, or it allows you to create semantic relationships first of all between elements on the page, but also to add semantics to an element like a div that, by itself, means absolutely nothing.

If we look at something like this, this is kinda what the widget looks like, you have two pieces. You have a button and a popup, and we need to figure out how to make those accessible. The HTML that we’re stuck with for whatever reason looks like this. We’ve got some divs, we’ve got some spans. There’s really nothing here that a user can actually do anything with, the screen reader.

So what do we do about it?

The first thing we need to do is to make sure that the elements that a user interacts with are focusable. divs, as I said before, by themselves are not focusable. They simply get ignored by the screen reader, and instead it jumps to their content.

What we can do, however, in order to make it focusable, is to add a tabindex. tabindex means, when you are tabbing through the page, when you’re using the tab key to jump between the focusable elements, first of all this element should be in the tab, uh, in the tab order, and second of all, perhaps it has a specific position.

I have never actually used tab order to say that an element has a specific position. Instead, I set a tab order of zero, which means this element is focusable, and this element should appear wherever it appears in the DOM.

A tabindex of -1 is also sometimes useful for specific scenarios. This means that if you’re tabbing through the page, this element doesn’t get focus, but if you’re using a screen reader or if you’re, if you want to programmatically assign focus in some way, you can.

AUDIENCE » [UNINTELLIGIBLE]

Sorry?

AUDIENCE » [UNINTELLIGIBLE]

Sure, we can talk about details and stuff later on.

Um, right.

So, we talked a little bit earlier about the keyboard, and about the fact that the keyboard is an incredibly important mechanism for interacting with a web page. You need to make sure that you support it. This means that your custom controls should respond to the keyboard in the same way that a native control does. This means, if for example, I tab over to a link on the page, and I hit enter, that link is going to be executed. I’m going to jump to that link. If I’m on a button and I hit enter, it’s going to do something.

I need to make sure that my custom elements do the exact same thing, and there’s a lot of work associated with this. I first of all need to figure out what the semantics are, and second I need to replicate those semantics within the context of my JavaScript.

This is why it’s better to simply use the correct to begin with, because then you avoid a lot of work. But if you can’t avoid that work for whatever reason, you need to make sure that you deal with the keydown or the keyup event, or a keypress event, depending on the interaction that you want.

You need to make sure that you deal with things like enter and escape, in interesting, and, you know, normal ways, ways that a user would expect.

The code for that might look something like this: you intercept the keydown or a key event of some sort, you look at the event, and then you look at the keyCode, and you need to figure out what the keyCode actually is. This is space, this is enter.

It’s generally better practice not to use magic numbers in your code, but instead to set up some sort of constants so that you actually read “space” or “enter”, but I didn’t have space, so I did this.

Also important to note is that the W3C has a document that documents a couple of common keyboard patterns. Things like “Escape should cancel a dialog box.” Things like that are documented relatively well, but the W3C, the only problem with that is that it’s relatively Windows-specific. It’s not the case that all keyboard shortcuts are the same on all platforms. So, keep that in mind, and make sure that you are tuning your keyboard shortcuts to the platform that most of your users are actually using.

If we look at the first part of this widget, I said it was in two parts, look at the button first. And this actually acts very much like a button, even though the user has to hover over it. That’s not the usual button behavior, but the conceptual behavior is very similar. I interact in some way with this thing, and then a modal dialog pops up, and I have to interact with that dialog.

So here we’re going to act as though this div is a button. We do that first of all by giving it tabindex such that I can tab to it on the page. This means that enter for instance, I’ll be focused on it, I’ll press enter, that will simulate a click, and I’ll get some sort of interaction with this button.

What we don’t have, however, is the label semantic. What we instead have to do is to put text into the div such that it actually gets read out when the user focuses on this div. Again, there’s no label that can be associated with anything other than an input element or select element or form element of some sort. That behavior simply doesn’t exist. So you have to make sure that there’s textual content in everything that you have on the page. Even if it’s like a gear, because you’re doing some sort of settings menu, you can’t simply have a gear as like a background image. It’s much much better to have a div, actually a button, but if you have to have a div, then make sure that div has textual content so that a screen reader can actually read it.

If we look at the dropdown that pops up when I hover over this thing, it acts much like a modal dialog, so a modal dialog is what we should emulate. We should make sure that when I’m tabbing through, that I can’t tab out of the dialog. I have to make a decision here before I can interact with something else on the page. We should make sure that it’s focusable, and we should make sure that the elements in particular are focusable. If you look, there are checkboxes up there, um, it’s a little bit light… but there are checkboxes up there. Those are implemented as divs, so we need to make sure that those also are focusable, and that when I do something with them, they behave exactly like a checkbox would.

What we can then layer on top of all of this backend work, so I do all of the event handling, I do all of the markup, what I can then do to add more semantics is to layer on ARIA. ARIA is a mechanism by which I can say that this div is not only a div, it actually has a role on the page. In this case it might be a role of button. This means that when I use a screen reader, or anything that would extract semantic information from the page, it can look at this div and understand that this div is actually a button. This means that the screen reader would read “Add to Circle. Button.” and then the user would understand that they could interact in some way with this thing that they’ve been presented with.

What’s important to note is that this isn’t a panacea. This doesn’t do the work for you of dealing with the keyboard or of making elements on the page focusable. It simply adds a semantic layer. You still have to do the work of intercepting keyboard events, and you still have to do the work of making sure that these elements are, um, potentially interactable.

So, these are a couple of examples of ARIA roles that you can have. You can have a button, and this means that it is a button on the page. You can click on it or use the keyboard in order to interact with it. It invites interaction in that case. A menu item is another example, and search are, kinda, is a landmark on the page so a screen reader can give you some information about the semantics of the page itself. Not simply specific elements, but the things that exist on the page. So there is a search widget somewhere, I can jump to that, potentially. There are sections of the page that have, are, that bind content together in an interesting way. I can jump to those.

Screen readers, by and large, at the moment, don’t support ARIA landmarks as well as they could. What they generally support are headings. This means that if you have a good heading structure on your page, a screen reader user can easily jump from one heading to the next, and get a good understanding of what’s on the page. What will be happening in the future is that screen readers will have better support for ARIA landmarks, and then you’ll be able to jump to specific landmarks on the page as well.

This is already the case in some screen readers. But it’s not really across the board quite yet. But it’s something that we should start thinking about now, and experimenting with now in things like ChromeVox, so that we can use them in the future when they become more ubiquitous.

It’s not only the case, however, that ARIA describes roles on the page. So it’s not only the case that I can say “It’s a button.” I can also say that this button, or that this checkbox, for instance, has been checked. This means that the div has a role of checkbox, it acts as through it was a checkbox, but it has properties associated with that. In this case, aria-checked. This allows me to determine programmatically whether or not this item is in a checked state. So if the box should show a check mark or not. It also enables the screen reader then to read that out to me, so that when I hover, when I focus on this element on the page, the screen reader can tell me it is a checkbox, and that the checkbox is checked.

Using this sort of state information in order to give the user more semantic information about how the page is put together, and what state it current finds itself in, is incredibly useful.

The last thing I note here is ARIA live region. A live region of the page. If you’ve ever used Twitter, and probably most of you have, you know that when you’re typing in your status message, there’s a, there’s a number next to it that counts down from 140. As you’re typing, it tells you, you have, you know, 20 characters left. It’s really quite useful to mark this region as updating, as something that screen reader should pay attention to, even if I’m not directly focused on it. This means, if I mark it as a “live” region, I can type a little but, and then, in a lull, the screen reader can tell me that this thing on the page updated itself. So I type a little bit, I wait, the screen reader tells me I have 20 characters left.

aria-live is the attribute that allows the screen reader to understand that this piece of the page is going to update itself, and that it’s important to pay attention to.

So, if we jump back to the add to circles widget, we could implement it something like this, where we have the div for the button, we tell the browser that it’s a button, we tell the browser to make sure it’s focusable by giving it a tabindex of 0, and we have some text inside of it such that, when I focus on it, the screen reader tells me something interesting.

We can set up this thing here as a dialog, and the ARIA, the screen reader will tell me that this is a dialog that I need to interact with before I move further. We can make sure that these checkboxes are interactable by giving them role of checkbox, I didn’t put a tabindex of 0 here. I should have. I need to. And I need to make sure that there’s an aria-checked attribute in order to tell me whether or not this is checked.

So, at this point, I would just say that there are two tools that I think are really quite useful when testing your own applications for accessibility.

The first is ChromeVox. It’s a completely free screen reader that’s relatively easy to use for people who have never used a screen reader before. There’s good documentation, it’s an extension for Chrome, you can go to the Chrome Web Store, download it, install it into Chrome on any platform, and it will read text to you.

This gives you kind of a quick and dirty mechanism for testing the accessibility of your page. It’s not going to be exactly like a blind user using your page, because they use screen readers simply differently than I do, for instance. But it’s a good sanity check. You can look at your page, make sure that things more or less work the way that you would expect them to when you’re tabbing through. That things are in the right order, that things are focusable.

That is really useful information.

ChromeShades is an accessibility tool that basically turns off all CSS on your page, and makes it, makes it very obvious when you have a DOM that makes no sense. So if you look at your page, you read through it, and you have no idea what’s going on, then you know that the styles that you’ve made, that you’ve applied to your page, are more than presentation, they are in fact semantic. And you need to fix that. You need to make sure that the DOM that you present to a user is usable and semantic.

Another screen reader that is quite useful is NVDA. NVDA is, I think it’s Windows only, for Firefox. It’s a really great screen reader. It’s free, so if you just pop open a VM and start using it, it’s really quite good. VoiceOver on Mac is also quite good, but not quite as good, I think, as NVDA.

There are a couple of libraries with accessibility support within their UI components. jQueryUI is doing quite a good job. GWT is getting there, Dojo has done an excellent job.

At this point, I think I’m running out of time, so I would ask if any of you have any questions.

I’ll pop up some final thoughts that you can read while you’re asking.

Yeah?

Q&A

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » The question is whether ARIA is part of HTML5 or is a separate namespace. To be perfectly honest, I don’t know. I know that there was a lot of argument about it. And honestly, I don’t care, because it’s supported in browsers, so whether it’s part of HTML5 or a separate standard is kinda irrelevant. Browsers generally support it, screen readers generally support it, and it is the only mechanism by which you can add this sort of semantic layer to the page. So, I would suggest that you use it, regardless of what a standards body tells you.

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » The role element, whether… I think the role element is in fact part of HTML5, that it validates if you go to validator.nu. Um, whether it’s part of the spec or not, I don’t know.

AUDIENCE » What’s the state of ARIA support?

MIKE WEST » The question was what the state of ARIA support is. Modern browsers generally support ARIA, and generally make the information available to accessibility, uh, tools. So, I know Chrome, excuse me, Chrome is working on it. Chrome has relatively decent accessibility support now. If you look at the dev version of Chrome, it’s relatively good. It exposes the sort of semantic information, like a role of button. That wasn’t the case as of, like, Chrome 12 and 13. We made a lot of effort in 14 and 15, and we’ve made even more effort since then. So Chrome is getting there.

The support in Firefox has been better over time, they’re generally doing quite a good job of leading in terms of accessibility support within the browser, and the combination of Firefox and NVDA is quite excellent.

So, we’re getting there with Chrome. ChromeVox, I think, is a really good step in that direction. As I said, it’s embedded into ChromeOS, so we’re making sure that when we roll out new, new iterations of Chrome, that we add accessibility support.

IE also has generally quite good accessibility support, or at least, it exposes all of the right things to the operating system layer. That said, IE6 and IE7 don’t understand ARIA at all. IE8 has a little bit of understanding, IE9 is really starting to get there.

So, I would say modern browsers have pretty good support for ARIA, and the support will only get better as time goes on.

AUDIENCE » Is there any, um, is there any connection between accessibility [UNINTELLIGIBLE].

MIKE WEST » So the question was, something along the lines of whether things like alt tags not being there can be validated by tools, or whether that could be part of HTML validation. Is that a correct…

AUDIENCE » W3C. You want to have HTML5, HTML4, validate [UNINTELLIGIBLE].

MIKE WEST » The question, ok, the question is whether alt can be associated in some way with valid HTML5 and valid HTML4. If you don’t have an alt tag then it would simply be invalid.

I think that’s unlikely to happen for a variety of reasons. What I would suggest is.

I’ll. You can tell me about it in a moment.

What I would suggest, before we get there, is that there are tools that will help you determine whether your page is accessible. None are really exceptional, it really requires some human interaction. But I wouldn’t necessarily rely on a validation tool to tell me whether my site is accessible. That’s kind of two separate questions entirely.

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » There are, there are, well, accessible pages will validate. I mean, that’s the case. If you use ARIA, and you use the new, validator.nu, it understands all the ARIA syntax, and will validate your page for you. It will also give you warnings for things like alt tags not existing.

What I would suggest is that you look at things like WCAG. There are documents that declare what it means to be accessible. I don’t find them necessarily convincing, but they work really well for people like government who have to have a checklist of things that they go through to say “this page is accessible.”

I really think it requires human interaction and human testing, but there are tools out there that purport to tell you whether your page is accessible.

Real quick, over here.

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » I’m told that images will not validate without alt tags. So, yay world.

AUDIENCE » What about access keys? They seem to be gone?

MIKE WEST » About access keys? I don’t actually know if access keys are supported in any browsers. Generally speaking, the support, as I understand it, wasn’t very good, and everybody implemented it themselves anyway. My understanding is that the best thing for you to do is to build the keyboard support into your application that actually makes sense for your application.

GMail doesn’t use access keys. GMail does everything via JavaScript.

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » Yeah. The comment is that nobody uses access keys anymore. I don’t think anyone ever used access keys, or at least they they were never well supported.

Ok, well. You did. So that’s good.

I would suggest that you use JavaScript in order to script your page.

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » I wouldn’t say that it’s more accessible to have access keys. To be perfectly honest, I don’t know what the support is for access keys, for that attribute.

AUDIENCE » I’m a strong advocate for accessibility, but my product manager not so much. How can I push it to my product manager?

MIKE WEST » So, the questions is how can a strong advocate for accessibility convince business people that accessibility is important.

This is a problem that everyone faces. Google faces it. You see some of the apps that we have aren’t as accessible as they should be. We’re really working to make them more accessible, but it hasn’t always been a priority.

I think the single most important thing you can do is to look at your current user base. Generally speaking, the number of people who can’t access a webpage is relatively low. There aren’t an amazing number of disabled people in the world. It is a large number, not probably not large enough in and of itself to convince a business person that this is a really important group.

What’s more important are the PR benefits, or, not even benefits, but PR harm of people saying that they simply cannot use your website.

It’s good to look at past legal cases. If we were in the USA, I’d say look at the Target case, which was problematic for a variety of reasons. If you’re in Israel, I’m told that there is a law coming up that will enforce accessibility in some way for sites that are used for certain groups of people. I know nothing about it, and I am not a lawyer, so everything I’m saying is probably wrong.

I would suggest that you look at the laws in your country. Laws are usually a good way of convincing people that don’t otherwise want to be convinced.

I think it’s probably the worst argument, but it is an effective argument for that type of person.

AUDIENCE » [UNINTELLIGIBLE]

MIKE WEST » That’s a bad thing.

Anything else?

Great, if there are any other questions, come up. Thanks!

GDD Keynote: The HTML5 Demos

2011-11-21T00:00:00+01:00

I had the opportunity to present a few demos during the Chrome section of Saturday’s Google Developer Day in Berlin (which, incidentally, was a blast). I expect a video to go up at some point in the vaguely near future, but, since I got more than a few questions about it, I’ll throw the links up here with a bit of background and credit for each. Incidentally, thanks to Paul Kinlan for taking some pictures during the demos. I’m glad I have something to show here as a stopgap before the video’s ready! Update: The keynote video is up on YouTube, and embedded below.

The first demo was pulled from a talk Mike Bostock gave just last week, highlighting the power of the impressive D3.js. D3 is a free JavaScript library that makes it easy to bind data to a DOM, and then generate stunning visualizations based on those bindings. His entire presentation is well worth checking out, and really highlight what an often overlooked technology like SVG is capable of.

Next, I pulled out an oldie-but-goodie: Joe Lambert’s Flux Slider. It’s a quick demonstration of the power of CSS-based transitions, and really well suited to venues like GDD, as it makes the capabilities of modern browsers immediately visually apparent. If you haven’t seen it yet, take a look. It’s another open-source library, so fiddle with the code as well.

Obviously, no HTML5 demo is complete without WebGL, and no WebGL demo is complete without Mr.doob and three.js. I introduced the topic by throwing a huge, Kinect-driven Mr.doob onto the wall behind me.

I followed up the introduction with a beautiful terrain rendering from AlteredQualia. What I liked most about that demo is the fact they they’ve pulled pieces from the ro.me project to save time and effort. Open source is brilliant.

Finally, I pulled the HTML5 Wow Visualizer from Eric and Arne’s excellent I/O 2011 presentation. It’s still the best WebAudio API demo out there, clearly demonstrating the power of the analyzer and showing off things that simply aren’t possible with the audio tag.

And that’s it. Fiveish quick demos in about five minutes. I enjoyed it! What did you think?

Secure Chrome extensions: Content Security Policy

2011-10-30T00:00:00+02:00

After reading the Content Security Policy primer that I wrote earlier this month, you should have a good idea of the benefits that CSP can offer a website developer. Whitelisting known-good resource origins, refusing to execute potentially dangerous inline JavaScript, and banning the use of eval are all effective mechanisms for mitigating cross-site scripting attacks. Implementing and enforcing such policies is simply a good idea.

Recognizing these advantages, Chrome’s engineers have extended CSP’s reach beyond websites into other areas of the browser where policies can serve as a defense against attacks. Most notably, policies can be applied to packaged applications and extensions. Both can make use of Chrome’s powerful and modular set of extension APIs, which give developers capabilities above and beyond what it makes sense for the web platform to offer normal websites. To whatever extent possible, therefore, developers need to ensure that those additional capabilities aren’t leaked out to the broader web. Content Security Policies mitigate this risk by helping developers ensure that the only code that runs with elevated privileges is their own.

Defining policies for an extension is quite straightforward, and we’re working to add them to all the sample extensions in the Chromium project. Walking through one of these samples together should give you a good idea of how it all works.

Implementation

The Mappy sample extension injects a content script into every page a user visits, searches the page for addresses, and passes them back to the extension so that a map can be displayed in the extension’s popup. This is exactly the sort of dangerous scenario in which we need to worry about malicious websites exploiting the extension’s permissions, perhaps by cleverly embedding JavaScript into the address which might then be executed if we’re not careful when it’s passed back to the extension’s context. A content security policy is absolutely necessary.

The first step towards securing the extension is to define exactly which resources it needs to load. Mappy’s needs are pretty simple: it loads CSS and JavaScript from the local extension package, connects to https://maps.googleapis.com to geolocate an address, and finally displays a static map image from https://maps.google.com.¹ A sufficiently paranoid policy would use a default-src policy directive to deny access to everything by default, and then specifically whitelist only those resources via style-src, script-src, connect-src, and img-src directives. I’ve annotated Mappy’s definition (which does exactly that) below:

# Block everything, then whitelist from there.
default-src 'none';

# Accept CSS from the extension's package.
style-src 'self';

# Accept JavaScript from the extension's package.
script-src 'self';

# Allow XHR connections over HTTPS to Google Maps APIs.
connect-src https://maps.googleapis.com; 

# Allow images from Google Maps to load over HTTPS.
img-src https://maps.google.com;

For normal websites, content security policies are delivered via an HTTP header. Chrome extensions use the same policy syntax, but define policies in the package’s manifest JSON as a simple key-value pair. Simply take the policy you’ve defined, and add it to manifest.json: you can see how Mappy’s CSP is defined by visiting Chromium’s source repository.

With the manifest changes in place, the next step is to take a close look at the extension’s code to make sure we comply with the new restrictions we’re defining. Generally speaking, this means ensuring that CSS and JavaScript is moved out from the extension’s background page and popup into separate files. Most of the time, this is a straight copy/paste job, simply moving code wholesale from an inline <script> block into a background.js file. For Mappy, the background.html change is captured in this diff, and the popup.html change is visible in this diff.

That’s it! Once you’ve defined a policy, and adjusted your extension’s code to match it, just test the extension locally, bump the version number, and push the update to your users. They’ll be more secure, and the world will be a (slightly) better place.

Next Steps

Your task is clear: update the extensions you own! It’s very straightforward work, and a real win for security. Content Security Policy support was added to Mappy in revision 106043; take a look at the code review to get some implementation ideas for your own extensions.

At the same time you’re working on your extensions, the Chromium team is working to set a better example by updating the 70 or so sample extensions and applications that Chromium makes available to include the new content_security_policy manifest entry. It’s easy work – following the steps listed above takes less than half-hour on average – but 70 is a big number, so we’re a bit behind. You can follow our progress on that effort at crbug.com/92644: star the bug if you’re interested in updates, and pitch in if you’re interested! Patches are welcome: just send any code reviews my way (mkwst@chromium.org).

Whenever possible, load resources over HTTPS rather than unencrypted HTTP. This has a number of benefits for privacy and security, most importantly (for our current context) a guarantee that the code you’re loading hasn’t been modified since it left the server. Active network attackers need to do a lot more work to inject code into a HTTPS stream, wheres it’s a trivial task via HTTP.↩