A few months ago, I decided I would write a blog post after working at Mozilla for one year. I wasn’t sure what it would be about, but I knew that I wanted to talk about the sort of things I’ve been working on, my team and our projects.
I joined Mozilla in May 2011 to work on client security, mostly focusing on desktop and mobile Firefox. I’ve worked in various security roles throughout my career, but personally feel that an engineering role is where I am the happiest and have the most to offer. Although I’ve been interested in security since I was a teenager exploring the Internet, development is where my professional career began. I worked on Solaris at my first job, and subsequently began a long stint as a Windows programmer at a number of companies. At one of these companies, I even worked on software for Windows CE, helping build one of the first-generation mobile firewalls. I became more and more interested in focusing on security professionally and I found myself oscillating between ‘security consulting’-type work and ‘security engineering’-type work. Both have different challenges and their own set of pros and cons. As brilliantly described by David Mandelin in a blog post about starting employment at Mozilla, the hardest problem I had to face on my arrival was figuring out where to focus my efforts to most improve our users’ security and privacy. Among other things, I worked reviewing Firefox’s silent updates feature, reviewing the Android Sync client side implementation, and tracking and advising on security matters for Firefox on Android. I also participated in many feature security reviews, worked on a few random security bugs (which helped a lot with learning my way around the Mozilla codebase and development environment), and finally began work on a Firefox feature I hope to discuss further in a future blog post once it’s landed !
In February 2012, Mozilla’s security teams reorganized. Previously, the security teams had been organized into separate groups responsible for operational security (securing, hardening, and monitoring servers and devices throughout Mozilla), infrastructure security (web applications and website security) and client security (Firefox for desktop and mobile and other client side applications – including fuzzers looking for security bugs in these products). The reorganization merged all teams responsible for reviewing and maintaining security across the organization into the Security Assurance team and established the Security Engineering team to focus on implementing security and privacy features. Security Engineering works on these features both in conjunction with other browsers and websites to improve the security and privacy of the web as a whole, and to attempt to advance the state of the art by going where other browsers cannot or will not go, in alignment with Mozilla’s manifesto of putting users first. After the reorganization, I am now a member of the Security Engineering team – it’s been a very busy first few months for us! Of course, in classic Mozilla style, teams have pretty fuzzy boundaries, so I still work with the same people every day on our shared goal of improving security.
One thing that is incredibly refreshing about working on security at Mozilla, as many of my colleagues will attest, is being able to talk about our plans and what we are working on – this is very unusual for many security folks! Security engineering follows the same open and public approach to developing features the rest of the Mozilla project takes. This means that we open ourselves up to getting advice and input on our security work from the rest of the community, which is especially valuable early on in a project’s lifecycle. By “community” I mean both the security community (just like in cryptography, the more folks who try to break your system the better!) and the Mozilla community, where we can gain insight into the security issues and challenges our users are facing. We can ship early versions of features disabled by default (like click to play) in Nightly builds, and people can turn the feature on, try it out, and provide feedback, ensuring we’re not planning the feature in a vaccuum.
At the first few meetings of the Security Engineering team, we focused on updating the existing Security Roadmap. The roadmap began as a survey conducted by Lucas Adamski in early 2011. Respondents essentially played a variant of Planning Poker, in which everyone was given a set number of points to allot to various ideas for security features or research that had been generated in a previous brainstorming session. This helped gauge the feelings of people interested in security within the Mozilla project on what was most important to focus on security-wise. Sid Stamm, Mozilla’s Lead Privacy Engineer, established a Privacy Roadmap along similar lines last year, focusing on improving the privacy of our users on the web.
The key to both of the Security and Privacy roadmaps is that they are discussed and refined on a regular basis. This agility allows us to keep the roadmaps responsive to current events on the Internet and also helps make sure we are in line with the overall priorities of the Mozilla project. It lets us set long term goals and make sure we are focusing on the right things. We tend to keep projects that aren’t actively being worked on at a lower priority, ensuring we finish the higher priority projects first or have actively decided to change an project’s priority. It’s no surprise that many of the Security Engineering team’s quarterly goals are pretty much lifted from our roadmap.
Personally, I’m currently working on two P1 items on the Security Roadmap:
- <iframe> sandbox – an attribute that can restrict a piece of content is something I became interested in when I was previously working on Flash Player. My first week at Mozilla <iframe> sandbox was suggested to me by Jonas Sicking as a potential project to pick up I’ve completed writing all the code and tests for this, and it’s going through code and security review now. I hope to land it sometime in the near future.
- My main project at the moment is researching sandboxing the Firefox process on Windows, in a similar fashion to how IE’s and Chrome’s processes are sandboxed to try to thwart successful exploitation. I–and other Mozilla security folks–have frequently heard from people in the security community that this is one of the main things they would like us to do to improve the security of Firefox; however it’s a pretty complicated project. At the moment I’m working on a proof-of-concept that would show that it’s possible to at least sandbox some parts of Firefox, aided by our intern, Marshall Moutenot. I plan to talk more about this project in the near future in a blog post as the work progresses.
Another P1 roadmap item, the Security Engineering team has been spending a fair bit of time discussing and pushing along is “opt in activation of plugins”, often referred to as “click-to-play for plugins”. Our aim for this feature from a security-focused perspective is to help drive users to update their plugins and prevent ‘drive by’ attacks attempting to exploit plugin vulnerabilities.
The Security Engineering team is hard at work on many other interesting projects as well :
- Sid Stamm is researching giving users better control over their cookies, especially third-party cookies
- Tanvi Vyas is working to make it easier for users to see when their passwords are being submitted insecurely and exploring creating a workable user experience around this
- Camilo Viecco dug into some bugs to make it harder for sites to fingerprint and identify users on the web and is now working on implementing CA pinning in Firefox
- Lucas Adamski (our fearless leader) has been knee deep in Open Web Apps and B2G for the past few months, driving development of the security model and shaping our story around permissions for WebAPI’s and Open Web Apps
- David Keeler, after two previous stints as a Mozilla intern, joined Security Engineering full-time recently and is doing an awesome job, diving right into working on click-to-play for plugins
- David Dahl also recently joined the Security Engineering team. David was previously working on the Firefox team and is working on DOMCrypt , both the implementation and efforts to get it spec’d and standardized through the W3C process. He’s also been helping with the ‘Sign Into The Browser’ feature.
All this exciting stuff is in addition to our attempts to keep up on everything going on with security and privacy on the web (and as part of the Mozilla project) and discussing security and privacy with community folks whenever we can!
In closing, if you’re interested in Mozilla’s Security Engineering efforts, our meetings are on Thursdays at 3pm PST. Meeting announcements are posted to mozilla.dev.planning and mozilla.dev.security every week.
We also warmly welcome feedback and discussion on security features or the Security/Privacy roadmaps on the mozilla.dev.security mailing list/group or on #security on irc.mozilla.org
Thanks to Lucas Adamski, Sid Stamm, and Tanvi Vyas for reviewing and providing feedback for this post !