Indistinguishable from Jesse

Swings on BART (photo by Audrey Penven)

Each of these apps makes transit more efficient or convenient. Together, they can do something almost magical: make transit attractive to urbanites who previously saw owning a car as a necessity.

Planning your trips

These apps try to find the best way to reach your destination by combining timetables from multiple transit agencies:

Google Maps^{[Learn more]} shows your current location along with walking, transit, or driving directions. In the iPhone app, you can double-tap the locator button to align the map with the iPhone's compass.

HopStop^{[iOS | Android]} lets you specify whether you prefer trains or buses, and whether you prefer walking or waiting for a transfer. It shows a zoomed-in map for each transfer.

Reroute.it lets you quickly compare modes of transportation before getting directions.

Catching your ride

Routesy, Nextime, and Nextbus use real-time transit data to help you make quick decisions on familiar routes. For example, you'll know when to walk to your stop, when to run, and when to wait inside.

Not missing your stop

A location-based alarm, such as Get Off Now or GPSAlarms, can allow you to nap, read, or work without worrying about missing your stop.

These apps can run in the background and have surprisingly little effect on battery life. They use power-hungry GPS only when cell/wifi location data indicates that you are somewhat close.

Staying productive and entertained

One of the biggest advantages of public transportation is being able to get things done while in transit. Some people check email, watch TV shows, or even order from Chipotle using their phones.

I often use time on the train to read articles. Whenever I find myself with too many Wikipedia tabs open, I send them to my phone using the Instapaper or Spool bookmarklet. Sometimes I read books on my phone using the Amazon Kindle app.

Getting a car when you need one

The Zipcar app lets you borrow cars from Zipcar locations, while Getaround lets you borrow cars from awesome neighbors.

Or you can pay for a ride using Taxi Magic or Uber.

More reading

Some transit authorities recommend apps for their cities: San Francisco, New York, Chicago, Seattle, and Portland, Oregon.

In my next posts, I'll list my ideas for new transit apps and explain how platforms could better support location-aware apps.

My DOM fuzzer can now find bugs where the layout of a DOM tree depends on its history.

In this example, forcing a re-layout swapped a “1” and ”3” on the screen. My fuzzer didn’t know which rendering was correct, but it could tell that Firefox was being inconsistent.

Gecko developer Simon Montagu quickly determined that 13ت is the correct rendering and attached a patch. Later, when a user reported that the bug affected Persian comments on Facebook, we were able to backport Simon’s fix to Firefox 11.

How it works

The fuzzer starts by making random dynamic changes to a page. Then it compares two snapshots: one taken immediately after the dynamic changes, and another taken after also forcing a relayout.

To force a relayout, it removes the root from the document and then adds it back:

  var r = document.documentElement; 
  document.removeChild(r);
  document.appendChild(r);

Like reftest, it uses drawWindow() to take snapshots and compareCanvases() to compare them.

In theory, I could also look for bugs where dynamic changes do not repaint enough of the window. But I've been told that testing for painting invalidation bugs is tricky, so I'll wait until most of the layout bugs are fixed.

Exceptions

Since the testcases are random, I have to be heavy-handed in ignoring known bugs. If I file a rendering bug where the weirdest part of the testcase is floats, I'll have the fuzzer ignore inconsistent rendering in testcases with floats until the bug is fixed.

The current list of exceptions is fairly large and includes key web technologies:

• CSS border/padding (bug 718452)
• CSS position: relative/absolute (bug 728100)
• CSS float (bug 725928)
• Non-ASCII text (bug 726460)
• Right-to-left text (bug 730562)
• <table> (bug 467723)
• MathML (bug 522393)
• SVG (bug 723376, bug 475216)
• Anything that causes coordinate overflow
• Anything that causes assertion failures (which are tracked separately)

None of the major video rental systems appeal to me:

• Redbox is for people who visit the grocery store two days in a row. (Why don't they put kiosks at train stations?)
• Netflix DVD-by-mail is for people who watch lots of movies and check snail mail daily.
• Amazon Instant Video is for people who live online, yet are willing to give up control over their computers.

The iTunes Store mostly works for my current set of devices, but all the movies I want to watch are either too new or too obscure for them to have rentals available.

Maybe I should sign up for Netflix but use other means to actually watch movies. At least then Hollywood will have enough money to make good films buy politicians, print and distribute billions of optical discs, prevent paying customers from exercising their fair use rights, and sue my neighbors.

This museum’s rooms are empty, waiting to be filled with answers to visitors’ questions.

In my search for nutrition, have I overlooked some fruit that I might find convenient and delicious? I start by trying to find out what’s popular throughout the world.

What fruits are liked by the most people? Human thoughts are not my forte.

What fruits are eaten the most? I get an answer, but not in the chart form I expected.

A row of fruit appears on the floor. The larger ones are shown both whole and sliced. Does the five-second rule apply to food that suddenly appeared on the floor, or only to food that has been dropped? Am I looking at holograms?

A bigger problem is that the list is dominated by small fruits like berries. I don’t like berries.

What fruits are eaten the most, by weight? Insufficient data.

I probe, using simpler questions, to figure out what it knows. What’s the weight of an apple? 180 grams. What’s the total weight of apples eaten in a year? Insufficient data.

I guess I have to be explicit if I want it to combine its weight and consumption data.

For each fruit for which you have sufficient data, chart the number eaten in a year, the average weight, and the product of the two.

I don’t get an answer right away. Is it just taking a while? Did I mangle the question, causing it to make a chart that is invisible because it has no entries? Did I confuse it with the phrase “the product of the two”?

Two women are debating the merits of bananas. In this place, they aren’t limited to speculation. Can you chart fruit by potassium per Calorie? Vitamin B₆ per dollar? It helpfully highlights the “banana” row in each chart.

They explore the supply side as well. Show me maps of where bananas are grown. Can you add a yearly animation with harvests shown as glowing dots? Draw a chart with axes for temperature and latitude, colored to show how well bananas grow in each condition.

I start thinking of my own questions, but I don’t expect it to be able to answer them. How do most people open bananas? How many bananas are used in recipes rather than eaten directly?

How many bananas are used as sex toys? Oops, did I ask that out loud?

It doesn’t even acknowledge my question, but one of the women retorts with a question of her own.

What percent of the time are men thinking about sex? Human thoughts are not my forte.

When I wake up, it’s still dark outside.

Today, the closest thing to the museum of my dream is a web site called Wolfram Alpha. It can chart many things. But it requires us to phrase questions carefully, and sometimes it simply misinterprets queries.

As for fruit? Wolfram Alpha has consumption data for some fruit. But some fruit is missing, and some fruit confuses it.

I start writing this post while eating the last two apples from my fridge.

I go back to bed, hoping for additional pleasant dreams.

Last week, I asked Luke Wagner to explain some security bugs that he fixed in the past. I hoped to learn from each bug at multiple levels, in ways that could help prevent future security bugs from arising and persisting.

Luke is one of the developers working on Firefox's JavaScript engine, which is currently our largest source of critical security bugs.

Method

I imagined we would recurse in exhaustive breadth and exhausting depth. Instead, we recursed only on the most interesting items, and refined a checklist of starting points:

• What was the bug?
• What went wrong in the developer's thinking that caused the bug to be introduced?
• What made the bug exploitable?
• What caused us to use especially dangerous features of C++?
• Could a new abstraction make it possible to do this both fast and safe?
• What caused the bug to persist? Could we have caught this earlier with improved regression tests, fuzz testing, dynamic analysis, or static analysis?

Luke and I made trees for all ten bugs, at first on paper and later using EtherPad. Then I extracted and categorized what I thought were the most useful lessons and recommendations.

Recommendations for introducing fewer bugs

Casts

• Create centralized, type-restricted cast functions. This protects you when you change the representation of one of the types. It also protects against mistakes that cause the input type to be incorrect.

Sentinel values

• Use tagged unions instead.
• Use a typed wrapper (a struct containing a single value). When assigning from the underlying numeric type, convert using one of two functions: one that checks for special values, and one that explicitly does not.
• Audit existing code paths to ensure they cannot generate the special value.

Clarity of invariants

• Increase use of methods named AssertInvariants
• Create an alias for JS_ASSERTION called JS_INVARIANT.

Interacting with other developers

• If you're about to do something gross because someone else doesn't expose the right API/helper, maybe you should get it exposed.

JS Engine specific

• Any patch that touches rooting should be reviewed by Igor.
• Interpreter could have better abstraction and encapsulation for its stack.

Recommendations for catching bugs earlier

Static analysis

• Find all casts (C-style casts, the reinterpret_cast keyword, and casts through unions) for a given type. Could be used to enforce centralization or to find things that should be centralized.
• Be suspicious of a function with multiple return statements, all of which return the same primitive value.
• Be suspicious of a function returning true/success in an OOM path.

Dynamic analysis

• Ask Valgrind developers what they think of providing (in valgrind.h) a way to tie the addressability of "stacklike memory" to a variable that represents the end of the stack.

Fuzzing

• We should fuzz worker threads somehow.
  • In browser (slow and messy, but it's what users are running).
  • In thread-safe shell (--enable-threadsafe?), which has "toy workers".
• We should fuzz compartments better.
  • I should ask Blake and Andreas for help with testing compartments and wrappers.
  • I should ask Gary to run jsfunfuzz in xpcshell, where I can test both same-origin and different-origin compartments, and thus get more interesting wrappers.
• We should give JS OOM fuzzing another shot.

Next steps

I'm curious if others have additional ideas for what could have prevented the ten bugs we looked at. For example, someone like Jeff Walden, who loves to write exhaustive regression tests, might have ideas that Luke and I did not consider.

I'd also like to do this kind of analysis with a other developers on bugs they have fixed.

Not all of our neighbors followed us. Some asked — demanded? — that we send back supplies.

We acknowledged their request, but our immediate task was to explore this Isle of Rapidity. What surprises would we discover? What surprises would discover us?

To survive in this strange land, we would have to befriend new neighbors. Living for so long atop Mount Annum, we had almost forgotten how to introduce ourselves.

But we had brought much to share. We had barely opened our packs when the wind seemed to whisper:

Here, gifts arrive almost before you send them.

Maybe it wouldn’t be so hard to make friends here.

And there was something inexplicably familiar about this island. Was it the scent of the flowers? The rhythmic waves in the distance? The chattering of wildlife, almost a chorus?

Here, a gift to your neighbor is equally a gift to yourself.

We felt a sudden shift in perception: the Isle of Rapidity was home.

Our friends thought us mad.

We had thrived atop Mount Annum. It was the highest peak as far as the eye could see.

Once, we had sprained an ankle on the Foothills of Many Betas in the west. We remembered miserable visits to the Bog of Eternal Driver Approval in the east. Every time, we had quickly returned home.

But there we were, on the summit of Mount Annum, climbing into a cannon aimed at 4°N, 6°W.

So far away, and yet oddly specific. We lit the fuse and plugged our ears.

We flew over the stifling Bog of Eternal Driver Approval. We flew over the perilous Sea of Recklessness.

We landed, as we hoped, on the uncharted Isle of Rapidity. The landing was unexpectedly soft.

We’ve shaken off the dust and gunpowder. We’ve begun to tend our wounds. We’re excited about the upcoming climb.

In the months before Firefox's first rapid release, one concern echoed throughout engineering: crashes.

We had always relied on long stabilization periods to get crash rates down. Firefox 4 would be our last high-stability release. We hoped improvements on other aspects of quality would outweigh the decreased stability.

But then something surprising happened. We released Firefox 5, and Firefox didn’t get crashier.

KaiRo’s explanation parallels what I’ve seen helping with MemShrink:

• The channel cascade gives each release 12 weeks of pure stabilization.
• The channel audiences help by comparing alphas to alphas.
• The short cycles enable backouts and reduce the desire to land half-baked features.

“Rapid release” doesn't mean building Firefox the way we always have, x times faster. It’s a new process that fits together in beautiful yet fragile ways.