I started using Irssi almost 10 years ago when I first started trolling wandering around the world of IRC. My main use is to run it in a screen and stay connected all the time. To chat I'll just ssh into the server and reconnect to the screen. Generally I leave my terminal open, stretched across the top of my monitor so it's really wide but only about 8 or 10 lines high. This way I can keep IRC visible all day long and respond quickly to questions.
I've customized irssi with custom highlights and commands and all has been well, save one thing: bug 310 - vertical splits. Irssi can't do vertical window splits and with the trends giving us widescreen monitors, horizontal splits aren't really useful to me. The bug has been open since 2005 and I've all but given up on it.
Then the other day Chris McDonald claimed the unfortunately named WeeChat was superior to Irssi. I was all ready to defend Irssi's honor but I read through the documentation and WeeChat was pretty compelling - most notably its support for vertical splits!
So, long story short, I switched last week and it's awesome. I don't miss Irssi at all and in fact WeeChat offers me things I never even knew I'd want (like per-buffer history when hitting the up-arrow). I've customized it so it essentially looks like Irssi (no nickname list, etc.) and I've added a lot of aliases to make it easier for me to use (mostly vim keys). If you're an Irssi user you owe it to yourself to at least read their docs and see what you think.
A lot of my time is spent trying to arrange projects and schedules so we can get
code shipped in a reasonable time. AMO has the blessing/curse of being broad
enough that there is work to do in nearly every area on the site. Once the
highest priority areas have people working on them there is still plenty of work
to go around that isn’t as time critical.
Discussing the security measures of a public facing and popular website is usually taboo. Often owners are unsure they are following best practices, prefer not to draw attention to their site, or hope that they can maintain security through the obscurity of their code. At Mozilla we are fortunate to offer nearly all of the code in the entire company as open source software. addons.mozilla.org is no exception. This means we need to be extra vigilant with the code we write (and a huge thanks to our developers doing code reviews, the security and QA teams testing code, and the community members reporting bugs they find), but it also means I can write posts like this to explain some of the security measures we have implemented and how you can use them to make visitors to your sites safer too.
SSL Encryption: Let's start off easy. Anytime you go to addons.mozilla.org we redirect you to https://addons.mozilla.org. Assuming you make it through the redirect safely you can be reasonably sure you're talking to us at that point. Any data sent between your browser and us is encrypted with industry standard encryption. This seems like a freebie (I know you're thinking, "really? you're talking about SSL?"), but do a quick search and you'll find plenty of financial institutions that fail to take even this most basic precaution on pages where you submit the username and password to your accounts.
Alright, let's get more interesting. AMO has a lot of user uploaded data on it, from images to files (the add-ons themselves) to the files within add-ons (we allow you to browse uploaded add-ons on the site). If a user uploads some malicious JavaScript they'll be able to run it in the context of the addons.mozilla.org domain which would give them access to manipulate the site and change or steal user data. We protect ourselves by using an alternate domain for user uploads - static.addons.mozilla.net. By using .net instead of .org we've sand-boxed user scripts onto their own domain and protected the content on .org. This is industry standard (notice how your content you upload to Google comes off of www.googleusercontent.com) and gives you a free performance boost as well.
Actually, uploaded images should get special mention. It's a best practice to always clean and verify user data but this is often overlooked for images. Back in the days of IE6 you could actually run arbitrary JavaScript embedded in the comments of an image. This has since been fixed in the browser but poorly configured servers and applications can still pose a threat. Neal Poole demonstrated a proof of concept on a Mozilla site where he embedded PHP in an image, saved it as "image.php" and uploaded to a site. The site saved it under a /media/gallery/ directory (under the webroot with PHP enabled) and he had arbitrary PHP execution on the server. The lesson learned was always re-encode user images when they are submitted. Even if you're re-encoding from PNG to PNG, strip the comments - it's not worth it to find out there was something malicious in them later on.
For many sites session cookies are one of the most valuable assets behind the actual credentials to log in. AMO protects the session cookie (and most of its cookies) with two very underused options: the Secure and HTTPOnly flags. Secure simply means the cookie is only sent over a secure connection - that means that when you go to addons.mozilla.org without typing the https, your cookies (and therefore your session) aren't sent and won't be compromised if someone is eavesdropping. HTTPOnly means that the cookies are sent with browser traffic to AMO but the cookie is inaccessible to client side scripts. If a malicious script is somehow injected into the page this option will prevent it from stealing the session id. Assuming you don't need access to the cookies and are running SSL these are essentially free additional layers of security for your site.
Every request to AMO returns a pile of interesting (and sometimes bleeding edge) HTTP headers. If you hit the front page, you'll see X-Frame-Options: DENY. In a supporting browser, this will prevent someone from putting the AMO site into an <iframe> (which prevents things like clickjacking). The vast majority of sites can add this header for more free security.
In a couple examples above I say that once you get to AMO on SSL you'll be fine but I conveniently skip all the traffic and redirects up until then. An attempt to keep people safe until they reach that point is the Strict-Transport-Security: max-age=2592000 header. This tells the browser that for the next 30 days, if you type in addons.mozilla.org without https it will automatically send it over SSL before the initial request - no unencrypted traffic at all. Support for this header is not widespread yet, but it's in all the recent versions of Firefox and I expect support for it to expand.
I can't mention "bleeding edge" and "headers" without a hat tip to the Content Security Policy (specifications). We've had it in reporting mode for a couple months as we work out what needs to be adjusted before we turn it on, but once we do, this will (again, in a supporting browser) define specific rules for what domains will have valid assets (like images, JavaScript, CSS, etc.) as well as disallow any inline JavaScript from executing. This essentially locks down XSS attacks even if someone does find a way to inject code into the page. It's a really exciting development but not for the faint of heart to implement on a complex site at this point in time. There are still some bugs to iron out and some edge cases to clarify in CSP but it's becoming something to seriously consider. I think Twitter is the most prominent site using it to enforce rules (as opposed to only reporting violations) at this time.
Whew, that is a pile of text and that's just covering the extreme front end. I'm going to cut it off there to keep this from running on for pages but if there is interest I'll write another post about more things AMO does to defend itself and its visitors, and other areas where everyone can consider adding in extra security.
In the mean time, if you want even more best practices the Mozilla Security Team has made a great wiki page for further reading about web security.
I was playing around with gource this weekend while watching the TSL 3 Finals and pointed it at addons.mozilla.org's source repository. I sped it up to display 1 day of commits per second and piped it all to ffmpeg to make a video.
It turned out pretty well so here is addons.mozilla.org development so far for 2011 (in HD!):
(Warning: prefetching is off but if you click play you're in for an 80MB video.)
The gource docs are easy to read if you want to do this for your project, but for the record this is what I ran:
gource --viewport 1280x720 \
--user-image-dir ~/sandbox/zamboni/.git/avatar/ \
--title "addons.mozilla.org" \
--auto-skip-seconds 1 \
--seconds-per-day 1 \
--start-position .715 \
--max-file-lag 0.5 \
--max-files 5000 \
--camera-mode track \
-o -
Piped to:
ffmpeg -y \
-r 60 \
-f image2pipe \
-vcodec ppm \
-i - \
-vcodec libtheora \
-b 10000K \
~/out.ogv
That gave me a 180MB uncompressed ogv. The uncompressed version looks far nicer, but that's a lot of bandwidth for a random video so I cut it down with ffmpeg2thoerea (anyone know the switch to do this directly in the ffmpeg command?):
ffmpeg2theora -v 4
~/out.ogv
--optimize
--noaudio
-o amo-2011-development.ogv
getpersonas.com was started as a labs project in 2008. The plan was to get a website up and running to show off what lightweight themes were and see if they got any traction. If the site became popular, we'd merge it in to AMO in six or ten months and everyone would go back to working on other things. Ha.
As is all too common, way leads on to way, and now here we are three years later. getpersonas.com has become a juggernaut of 3000x200px free expression on the web. There are over 1.25 million registered users on the site, 400,000 personas, and a half million hits a day. The site was built with scaling in mind and, honestly, has needed relatively little attention.
On the other hand, the site lost its owners and maintainers last year. Deb stepped up with some awesome volunteers and contractors to fix minor issues but there are no dedicated developers to keep the site fresh. The web security bounty program late last year wasn't kind to the old code, and any time devoted to the site turned in to trudging through old PHP code to solve overlooked problems from long ago.
We've decided that this is the year to finally replace the precarious cron job synchronizing the getpersonas.com and AMO databases for the past 18 months and finally migrate the site to AMO completely. This is no small undertaking, but we've had a lot of time to think about it. ;)
I wrote a migration plan a few weeks ago as a general guide. The searching and listing pages are already at parity with getpersonas.com. The reviewer and author functionality will be added shortly - and if you read the bugs and look at the mockups you'll see it's greatly improved. This is a mutually beneficial migration; the personas will be able to leverage AMO features like statistics reporting and collections, and AMO will get a fresh look at reviewing user submitted content and an influx of creative designers.
I snuck in to a personas planning meeting last week and I saw a lot of fun stuff in the pipeline for personas. I'm happy to say migrating them onto AMO will give everyone the server and developer resources to get that new stuff out the door. This will get underway in Q3 of this year.