Too long to tweet.

From real news, published today:

The tire pressure monitors built into modern cars have been shown to be insecure by researchers from Rutgers University and the University of South Carolina. The wireless sensors, compulsory in new automobiles in the US since 2008, can be used to track vehicles or feed bad data to the electronic control units (ECU), causing them to malfunction.

From science fiction, published in 1993:

[Scene: The "Power", an incomprehensibly intelligent AI, has unwittingly been activated by humans who are now attempting to flee before it can infiltrate their systems and kill them...]

The new Power had no weapons on the ground, nothing but a comm laser. That could not even melt steel at the frigate’s range. No matter, the laser was aimed, tuned civilly on the retreating warship’s receiver. No acknowledgment. The humans knew what communication would bring. The laser light flickered here and there across the hull, lighting smoothness and inactive sensors, sliding across the ship’s ultradrive spines. Searching, probing. The Power had never bothered to sabotage the external hull, but that was no problem. Even this crude machine had thousands of robot sensors scattered across its surface, reporting status and danger, driving utility programs. Most were shut down now, the ship fleeing nearly blind. They thought by not looking that they could be safe.

One more second and the frigate would attain interstellar safety.

The laser flickered on a failure sensor, a sensor that reported critical changes in one of the ultradrive spines. Its interrupts could not be ignored if the star jump were to succeed. Interrupt honored. Interrupt handler running, looking out, receiving more light from the laser far below…. a backdoor into the ship’s code

Posted in PlanetMozilla | 1 Comment

A little mouse hack

A major theme of the upcoming Firefox 4 release is improving speed and responsiveness, especially in the user interface. It’s easy to see issues where responsiveness is on the order of seconds (like waiting for an update to apply, or the length of time to respond to a modal dialog), but how do you examine and measure UI changes that happen over a period of just milliseconds?

One could instrument the code and get nanosecond-level precision — but it’s difficult to know where to insert probes, and you still may not be measuring what the user is actually seeing. A more direct “ground truth” would be to use a camera to record what’s displayed on the screen, and then examine the resulting video frame-by-frame to obtain data… I dabbled with this briefly last year when working on a Windows CE bug about slow-opening windows and menus. But more recently, Alex Faaborg has started a investigation of the Firefox UI using a significantly refined technique.

A problem Alex quickly ran into, though, is that it’s hard to look at a video and know exactly when the user clicked a mouse button. If only there was some visual indication of the mouse button state… Hmm! That was enough to start the wheels turning in my head, yadda yadda, and one weekend later I had complete a nice little hack that added some LEDs to a mouse so you could see the button states.

Some pictures… (See Flickr for the whole set.)

First, you’ve got to drill a nice hole (*)… I cringe every time I see someone mention doing some hack with a Dremel, because most of the time the result looks like something a drunk monkey with a chainsaw would produce.

Next, tap into the mouse’s microswitches (which are tied to ground) and the USB’s +5V.

Finally, route things nicely. Behold, the four-as… err, two-wired mouse!

This is the business end of the extra wire now attached to the mouse. 2 LEDs (and a couple of resistors) wrapped up in some heat-shrink tubing. When a mouse button is clicked, one of them lights up — red for right, (ye)llow for left.

This is a pretty simple little hack, but it was especially fun it’s not often us software guys get to do hardware stuff. And, hey, it even worked on the first try!

Sadly, there is one little problem… While the hacked mouse worked flawlessly for me, it immediately failed to work for Alex — the OS didn’t see mouse clicks, even though the LEDs lit up. Oh no! Luckily I had made the LED tail detachable (not shown here), as it turns out that if the mouse is plugged into the computer with the LED tail attached, it doesn’t work. But if it’s plugged in without the LED tail, and then the tail is plugged in afterwards, it works fine. I’m guessing that I just need to add some decoupling capacitor where I tapped into the switches, as the mouse’s IC was ok with the short traces to the switches but not the new 4-foot wires hanging off it. Or maybe a pull-up resistor? Both? Dunno exactly what the problem is yet — this is why I’m a software guy. ;-) What say you?

Posted in Firefox, PlanetFirefox, PlanetMozilla | 7 Comments

Brindisi

Blizzard tweeted this video of an operatic flash mob, which stuck a chord with me:

Why? I think it echos the best emotions around Firefox, the Mozilla Project, and open source… People doing what they love and feel passion for, providing that to people in everyday life, at no cost and for the betterment of the community, leading to sharing the mutual joy and delight of the result.

It can bring out the best of humanity.

Posted in PlanetMozilla | Comments Off

On prompting, part 2

In the previous episode, I talked a bit about why I really, really don’t like the existing prompting code in Mozilla. I’ve been working on improving the situation.

The first big chunk of work is up for review in bug 563274. This basically removes all of the existing prompting code from /embedding, and creates a new component in /toolkit to replace it. The code is _much_ cleaner (though I may be biased!), and it’s written in JavaScript instead of C++.

For this first step, I’ve tried to keep things backwards-compatible and avoid breaking existing code. In fact, the UI is the exactly the same and the pile of nsIPrompt* / nsIAuthPrompt* interfaces are unchanged; there’s just a shiny new implementation underneath it all. But if anyone’s likely to find surprises, it’s probably embedders who are providing their own implementation of the existing code (eg, to implement their own non-XUL prompts). In theory those existing implementations should still work, but there might be some subtle bugs, build-goop changes, or patch dependencies on now-deleted code… The typical kinds of things that are expected when overhauling crufty old code, but these shouldn’t be hard to fix.

That said, this is just the first step. Upcoming steps are more likely to require changes that may break existing code. Even previously frozen interfaces like nsIPrompt / nsIPromptService might be thawed and changed (though we won’t take that step lightly). A few of the things I’m mulling over:

  • Make password manager watch prompt notifications, instead of implementing prompt interfaces.
  • Implementing tab-modal prompts.
  • Eliminate the nsIAuthPrompt-in-nsIAuthPrompt2 wrappers
  • Simplify the way chrome XHR handlers can override the default authentication prompting
  • Simplify the existing pile of interfaces (so instead of having 6 ways to do the same thing there are only 2 or 3. :)

More updates as plans solidify.

Posted in PlanetMozilla | 4 Comments

On the insanity of prompts

Some of the worst code I’ve had the misfortune of touching in the Mozilla codebase is code related to the handling of prompts. Specifically, the prompts involved with following interfaces: nsIPromptService, nsIAuthPrompt, nsIPromptFactory, nsIAuthPromptProvider, nsIPromptService2, nsIAuthPromptAdapterFactory.idl, etc. Just the plethora of confusing interfaces (for what is a fairly basic feature) is the first sign that something is amiss, and if you look at the actual methods on these interfaces you’ll quickly become lost in a maze of twisty little passages, all alike.

The implementation is spaghetti, too. As an example, let’s take a look at the sequence of functions called when JavaScript calls a simple little alert("Hello")

0) We begin our adventure in nsGlobalWindow::Alert().
1) Obtain an nsIPrompt via a do_GetInterface call on the docshell.
2) Ah, docshell doesn’t implement any of that, it just delegates to an nsIPrompt that it obtains from nsIWindowWatcher’s GetNewPrompter().
3) But GetNewPrompter() is actually just a one line function that calls NS_NewPrompter().
4) That’s over in nsPrompt.cpp, a short function that creates a new nsPrompt and initializes it.
5) Ok, now that we have an nsIPrompt (back from step 1), we can set up some strings and call its Alert() method.
6) …which doesn’t actually do anything, except to hand-off to nsIPromptService’s Alert().
7) This Alert() does some basic string twiddling, and next we end up in…
8) DoDialog(), which does more more twiddling, and FINALLY calls…
9) nsIWindowWatcher’s OpenWindow(), which opens a XUL window containing commonDialog.xul to do the prompt.

This is a little silly. And for outright insane, try tracing through the sequence of functions performed for showing an HTTP authentication prompt.

The good news is that I’ve been working on a large patch to simplify all this, and pave the way for some other interesting changes. More on this next time. :-)

Posted in PlanetMozilla | 5 Comments

Status update

One of these things I did not actually work on:

  • JavaScript / js-ctypes implementation of WeaveCrypto
  • Migration and replacement of localstore.rdf with a .json backing store
  • Rickrolling Fligtar’s new dashboard
  • Tab-modal dialogs proof-of-concept
  • Fix multiple master-password dialogs with session restore
  • Ported Firefox to ColecoVision.
Posted in Firefox, PlanetFirefox, PlanetMozilla | 2 Comments

Weave, crypto, and JavaScript

tl;dr: fa20ae35b8ac53b28dde4fc333aba21f :-)

Up until now, Mozilla’s Weave add-on has been living with an awkward implementation detail: a binary component. When I wrote Weave’s current cryptographic component back in 2008, in order to use the crypto code that’s already in Mozilla (ie, NSS) there was no choice but to write C++ code. NSS doesn’t export any scriptable interfaces at all, and its partner-in-crime (PSM) exposes only a limited set of high-level functions — none of which was useful for Weave.

The C++ code has been working fine, but has a number of serious drawbacks… A binary component has to be compiled for each supported platform (originally just Windows, Linux, Mac x86 and Mac PowerPC). That results in a bigger download, and makes it a pain to support new platforms (like 64-bit Windows, 64-bit Linux, 64-bit Mac, Maemo, Windows CE/Mobile, Android, etc). It’s also a barrier to new developers — compiling a binary component requires a build environment and XULRunner SDK, whereas hacking on most extensions requires nothing more than a text editor. Luckily the C++ code has been quite stable, so Weave was able to hack around this by including pre-compiled binaries in the Mercurial repository.

But enough is enough.

The next (trunk) version of Firefox includes JS-CTypes, a feature that allows JavaScript to interface with native code. Think of it as dlopen/dlsym for JS. By porting the WeaveCrypto component over to JavaScript + JS-CTypes, Weave is now able to talk with NSS directly, without any C++ code. It basically Just Works — adding support for Mossop’s Palm Pre port of Firefox was literally a 1-line change. Adding support for Android was a 4-line change (only because they’re tricky and put libnss3.so in a sub-directory).

I should also mention that unit tests were a HUGE help in getting the new code completed. I wrote extensive tests for the C++ version of WeaveCrypto, and once the JS-CTypes version was working with those tests I was able to make a full-up Weave sync work with the new code on the first try. Easy-peasy!

If you’re interested in seeing what this new code does, take a look at the bug and the code in the Mercurial repository. Note that the XPCOM interfaces are fairly specific to what Weave wants to do — it’s not a general-purpose JS crypto API. But it’s a huge step towards making it easier to do crypto code in JS extensions — and perhaps in the future we’ll look at making a real general-purpose crypto API for extensions; it’s certainly an interesting problem! If folks are interested in helping out with such a project, let me know.

Posted in Firefox, PlanetFirefox, PlanetMozilla | 4 Comments

Post This Hacker

I couldn’t resist a little wordplay on the Mozilla Drumbeat Hack This Poster

(cut strips at bottom so people can have their own tear-off miniblizz!)

Posted in PlanetFirefox, PlanetMozilla | 3 Comments

Status and stuff

A bit of stuff I’ve been up to lately:

  • CSS Transitions for videocontrols. Finally got around to landing this. There’s really no visible change, but it replaces and simplifies a whole bunch of Javascript-driven animation code. CSS Transitions are really nice to work with.
  • Use Services.jsm in Login Manager. Gavin added Services.jsm to trunk not that long ago, and it’s one of those things that’s so slick to use we should have done it years ago. There’s been a small flurry of patches to convert various code over to using Services.jsm; it’s trivial work but is really good for code hygiene.
  • A 3rd round of crashed-plugin UI tweaks. Hopefully we’ve got it nailed this time! Also fixed the last of the significant crashed-plugin UI bugs, and started a cleanup of the trunk code in preparation for future work.
  • Reviews of 2 Form History patches for “good first bug” bugs — I need to start tagging more of these! With these fixes, we now avoid saving credit card numbers, and there’s a new option (off by default) to suppress saving data on SSL pages. I’ve also been finishing up patches for helping Weave to sync form data.
  • Finished reviews, tests, and landing for automatic proxy authentication. BenB’s patch is now in the tree, though it’s currently preffed off. If you use a proxy with authentication, enable “signon.autologin.proxy” and give it spin.
  • Finished porting of the C++ WeaveCrypto module to JS-CTypes, and was able to successfully sync between profiles using it.
  • Thunzilla!

Coming up soon:

  • Finish up last quarter’s E10S scoping, and get this quarter’s E10S goal underway.
  • Final polish on the JS-CTypes WeaveCrypto, get it out for review.
  • Doing a little 1 or 2 day sprint with zpao to port most of the remaining C++ form history code to Javascript.
  • Death to (almost) all superfluous Master Password prompts.
  • Other random awesomeness.
Posted in Firefox, PlanetFirefox, PlanetMozilla | 1 Comment

Thunzilla!

Last week I noticed something quietly frustrating about reading bugmail in Thunderbird… Someone had generated a bunch of bugspam while shuffling around bugs into new components, and I was cleaning it up. For the most part, sorting the messages by time and deleting a range took care of things. But, I realized, you can’t actually see who generated the bugmail from looking at the folder summary. So if someone else happened to make a change within the spam-timespan, I couldn’t easily tell. Sigh.

All bugmail comes with a From header set to “bugzilla-daemon@mozilla.org” (which is basically useless), but there are also a number of other X-Bugzilla-* headers in each message. X-Bugzilla-Who, specifically, has the data I wanted to see. I just needed to have it exposed in Thunderbird!

I filed bug 557945, and the mail folks pointed out this could easily be done with an extension, and even provided links!

So, yadda yadda, a short time later I had written Thunzilla:

Thunzilla is available on AMO. Enjoy!

Posted in PlanetMozilla | 9 Comments