Driving Decisions With Data

Rob Helmer: “I’m here to introduce a project we’ve been working on for the past few months: Perf-O-Matic 2.0″

We’ve always been pretty good about collecting data at Mozilla, but things are really ramping up as we grow. In addition to Perfomatic 2.0, we’ve got several other efforts already completed, or underway now:

And of course our JS team is always measuring everything. arewefastyet.com really just scratches the surface. Speaking of which, check out that Type Inference branch Brian Hackett is working on. Amazing stuff.

Anything I should add?

Talking Amongst Ourselves

One unanticipated benefit of our switch to a new release system is the increase in communication that’s been required. I found it to be kind of a pain at first, though as we’ve picked up speed, I’m starting to see the benefits roll in. We have a lot of new ways for project members to follow along, and I’m seeing lots of new people show up.

At a conventional company, I suppose some internal mailing lists would get set up to accommodate new processes. There might also be a boring public forum for use after all decisions are made. At Mozilla, things are done in the open. That can make certain days, um, interesting for our PR and marketing teams. But these teams, like so many other parts of Mozilla, are handling unconventional tasks very well. They’re a pleasure to work with.

So, where are we talking? Here are my favorites:

Mozilla has a bunch of other blogs that are much more widely read, but you probably already know about those if you’re reading this post.

Broken Meetings (and how you’ll fix them)

A post on meetings by Merlin Mann. A few months ago, I started doing a bunch of the things he suggests. They seem to work.

“Broken Meetings (and how you’ll fix them)” from Merlin Mann on Vimeo.

I hate meetings, but they can be tolerable. These tips help (the good stuff happens at around 29:00). I’ve seen other people around Mozilla working on these points too.

ISPs deploying rewriting proxies on web content

I visited Asa Dotzler’s post about trees today, and I noticed some requests headed for a strange server. I was using my laptop tethered to a T-Mobile phone. I looked at the source, and found this image tag:

<img src=”http://64.19.142.12/farm3.static.flickr.com/2802/4376295211_b9d0014b3e_z.jpg” class=”photo”>

That src URL looked fairly suspect. I couldn’t figure out why Flickr would prefix images with an IP address and add a hostname to a path. Then, I found this bit of CSS:

.video {
-moz-border-image: url(http://64.19.142.11/weblogs.mozillazine.org/asa/tv-border.jpg) 27 31 37 31 stretch stretch;
border-width: 26px;
}

At this point, it seemed clear that an intermediary was rewriting the HTML content to point the images at a completely different server. Who would that be?

Hostname: 64.19.142.10
ISP: Monmouth Internet Corp
Organization: Flash Networks
Proxy: None detected
Type: Corporate
Assignment: Static IP

Looks like Flash Networks sells a rewriting product to mobile ISPs. Other T-Mobile users have noticed, as have Verizon users.

In the Verizon thread, you can see that the ISP has actually rewritten URLs to JavaScript files. Yikes! Also, I can’t find an instance of this now, but I am pretty sure this same proxy used to insert JavaScript rollover scripts into pages. These things would offer to display images at standard resolution if you right-clicked, if I recall correctly.

This stuff may be old news to some of you, but I was pretty surprised.

TOFU POP MONK – It’s a good idea

Glyph Lefkowitz on fixing HTTPS: We (those of us in the open source hipster security noosphere) need to popularize this concept, because it’s not that hard to implement, people keep re-inventing it everywhere, it’s mostly just about getting some browser vendor to think it’s a good idea.

Speaking only for myself, I am convinced this is a good enough idea to try.

I’m glad it’s not that hard to implement, because that makes the next action for the open source hipster security noosphere very obvious. Write the patches for NSS. Then, these new HTTPS capabilities will be available for Firefox and other Mozilla products, as well as Google Chrome and ChromeOS. NSS can be hacked on in any of the following locations, but the patches must eventually be upstreamed to cvs.mozilla.org to be a part of the official distribution. Here’s where you can find it:

P.S. – No, I have no idea why the NSS developers are still on CVS. :)