Firefox Keeps You Safe In Ways Other Browsers Don’t

Standard

You might know about some of the more glamorous Firefox 3 security features, but behind the scenes Firefox is protecting you from malicious extensions and plugins through its blocklisting service.

Depicted below is a diagram of how Firefox talks to its blocklist service. This is how it works:

  1. Every day Firefox downloads an XML document from our blocklist service.
  2. This tells Firefox if there are any malicious plugins or extensions out there.
  3. If Firefox detects any of these items on your system, it disables them so you can surf the web safely.

Flow chart for Firefox's blocklist service

What is remarkable about this is that it covers you from things Mozilla doesn’t even release. One of the things I’ve always been proud of is Mozilla’s dedication to its users, and I think this is a good illustration of how we’re finding ways to make the web better and safer. We don’t just care about Firefox, we care about you — and if you are put in a bad position because of poor security in a third-party plugin, we will be there to cover for you — on our dime.

Extension blocklisting has been available since Firefox 2, and we’ve used it in the past to blocklist extensions that cause major crashes or have security problems. Plugin blocklisting is new in Firefox 3, and this is a pretty big feature given recent security news involving plugins.

All major plugins have had arbitrary code execution issues at some point. Plugins like Quicktime or Flash have had some popular cases where hackers could execute code on your system just by having you load a corrupted Flash object or Quicktime movie. Usually vendors are pretty good about updating once these exploits are disclosed, but with Firefox 3 we’ve added plugin blocklisting so we can protect you if vendors aren’t quick enough to respond or don’t provide an easy way for you to upgrade.

Screenshot of a blocklisted item.

Mozilla doesn’t want to leave you out in the cold, and Firefox’s blocklist service is another tool we can use to look out for you.

It’s important to use this tool responsibly so we have discussed a policy for quite some time. The blocklist policy is in our public wiki, and we welcome any questions about it. Any time we consider blocklisting, we contact the vendor or author of the add-on in question to encourage a quick update and let them know we are considering blocklisting. Decisions to blocklist are made by committee to make sure we are not using this service incorrectly or blocklisting things prematurely without just cause.

To show you what the XML document looks like, here is an example of what we are currently serving:

<?xml version="1.0"?>
<blocklist xmlns="http://www.mozilla.org/2006/addons-blocklist">
  <emitems>
    <emitem id="fdm_ffext@freedownloadmanager.org">
      <versionrange minVersion="1.0" maxVersion="1.3.1">
        <targetapplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
           <versionrange minVersion="3.0a1" maxVersion="*"/>
        </targetapplication>
      </versionrange>
    </emitem>
  </emitems>
  <pluginitems>
    <pluginitem>
      <match name="name" exp="Yahoo Application State Plugin"/>
      <match name="description" exp="Yahoo Application State Plugin"/>
      <match name="filename" exp="npYState.dll"/>
    </pluginitem>
  </pluginitems>
</blocklist>

What this does:

  • Tells firefox to blocklist the Free Download Manager extension, versions 1.0 thru 1.3.1 for Firefox 3.0a1 and higher.
  • Tells firefox to blocklist the Yahoo Application State plugin, for all Firefox versions loading npYState.dll.

Information about the blocklist is always found on mozilla.com’s blocklist info page. To learn more about the service itself, feel free to read more about its specifications.

Overall, the blocklist service is another way Firefox is watching out for you, and even though it doesn’t get much press coverage, it’s a remarkable thing and speaks volumes about how serious we are about keeping Firefox users safe — even from stuff that wasn’t Mozilla’s fault.

Profiling PHP with Xdebug and Webgrind

Standard

Using Webgrind and Xdebug, you to tack on ?XDEBUG_PROFILE=true to any URL and view profiling information for that particular URL instantly.

One of the main criticisms of profiling PHP applications has been how difficult it is to manage different kcachegrind or wincachegrind windows — assuming you’re a pro at pointing them to your Xdebug output directory and all that good stuff. I am excited about how easy webgrind makes things because easier profiling will help prevent a lot of stupid performance mistakes (for those of us not using the Zend IDE and its sexy profiler, which is a lot of people).

Webgrind screenshot.

This is really quite simple to set up, and is best used on a dev box behind a firewall with port 80 closed. People can file surf your web server if you leave webgrind on an open port, don’t do it.

So, you’ve read the last paragraph, right? Ok, good. Let’s go.

Use pecl to install the json and xdebug packages

pecl install json
pecl install xdebug

You’ll run into a possible missing phpize issue, in which case you’d need the php-devel package for building PHP extensions.

Configure Xdebug

A simple configuration to get you what you need is below. Read the Xdebug docs if you want to get crazy.

; Enable xdebug extension module
zend_extension=xdebug.so

; Turns it off by default
xdebug.profiler_enable=0 

; Turns xdebug on when ?XDEBUG_PROFILE=true is in GET or POST
xdebug.profiler_enable_trigger=1

; Your output directory - you'll eventually point webgrind at this
xdebug.profiler_output_dir=/tmp/xdebug

If you’re not on PHP 5.2.x, you’ll also need the json extension.

; Enable json extension module
extension=json.so

Restart Apache.

Download and install webgrind

Webgrind is easy to setup, download it and follow the instructions. The main thing you’ll want to do is make sure your Xdebug directories are the same. In this case, it’s /tmp/xdebug

Load any PHP app with ?XDEBUG_PROFILE=true

Now you’ll want to hit your web server with the appropriate GET argument set up. So, you could hit localhost/helloworld?XDEBUG_PROFILE=true and it’d create a new cachgrind.out for that request.

Open up a tab with webgrind in it and enjoy

Webgrind will do a find on your Xdebug output directory and have a list of all your cachegrind.out files up on the top right. Now all you have to do is choose one. Webgrind’s use of jQuery and AJAX makes the app a great example of what you can do with JavaScript and a little motivation. Check it out.

Update: You should use “zend_extension” in your .ini file, not extension. I had a typo above, but it’s corrected.