Last week I was in California. It was my first time in the Mozilla SF office --- lovely view of the Bay from the roof. I always enjoy the free snacks and I'm always glad we don't have them in Auckland. I spent quality time with some of the people I know and love at Mozilla, and that's always exciting.
On Wednesday and Thursday I was at Half Moon Bay doing LEAD training. It was fun, but thinking about "soft skills" for two days straight is quite draining for me; my social skills are learned, not innate.
This cohort is different from previous cohorts --- most members are relatively new to Mozilla; of our cohort, Vlad and I have been at Mozilla the longest, by far. This gives me the honor and duty of representing the Mozilla old guard. I feel the power of the narrative that has me in the "crusty old engineer, harping about the old days and resisting change" role ... and I do my best to reject it :-).
One of the results of LEAD so far is that I perceive my relationships with other Mozilla staff to be warmer and stronger than they perceive them, on average. I suspect this may be related to the difficulty of maintaining deep relationships with remote employees I see a few times a year at best. I'm still trying to figure that out.
- Gangster Squad: Genre flick. OK.
- Zero Dark Thirty: Pretty good. Not exactly entertaining, but interesting.
- Live And Let Die: Some kind of cross between a Bond movie, a blaxploitation flick, and the Dukes Of Hazzard. Odd.
- The Town: Genre flick. Slightly better than average.
- I, Anna: Sort of noir-ish psychological thriller. OK.
- Les Miserable: The movie of the musical. Pretty good. I need to read the book sometime.
Interestingly, Air New Zealand lets you see what movies they're showing on their routes. This Web interface is a pretty faithful mockup of the actual in-seat interface (which is pretty bad ... it would be great to be able to see more than one movie title at a time).
On Friday I leave for Taiwan for a week at the Mozilla office, a "Web rendering" work week. This should be even more fun than last week.
Over time I've become increasingly impressed with the broad applicability of Matthew 18:15-17: If your brother or sister sins, go and point out their fault, just between the two of you. If they listen to you, you have won them over. But if they will not listen, take one or two others along, so that ‘every matter may be established by the testimony of two or three witnesses.’ If they still refuse to listen, tell it to the church; and if they refuse to listen even to the church, treat them as you would a pagan or a tax collector.
The first step is often difficult but crucial. The path of least resistance can be to go behind your antagonist's back --- to your friends, or their friends, or their manager. I've seen all kinds of negative consequences from following that path --- hurt, distrust, unnecessary escalation, confusion and fear. I feel my integrity depends on people knowing that whatever I say about them to others, they will not be surprised by because they've already heard it from me.
This applies in the other direction too, when people complain about third parties to me. If the third party is unaware of the issue, I don't want to know --- go away and talk to them first.
There are rare exceptions, usually involving time-critical emergencies or complex secrecy requirements.
Our Web Audio implementation is making great progress. This is mainly due to the efforts of Ehsan Akhgari, who is, astoundingly, cranking out one or two features per day. Paul Adenot and I are spending hours every day just reviewing his code. I think this is partly due to Ehsan and I laying down some pretty good infrastructure at the outset.
Our current goal is to have a basically complete implementation for Firefox 24, which branches from trunk in about eight weeks. There are a few things we need to do to get there:
- Complete the feature set. At this point that mainly means adding all the node types that aren't implemented yet: MediaStreamAudioDestinationNode, MediaStreamAudioSourceNode, MediaElementAudioSourceNode, ConvolverNode, OscillatorNode, and WaveShaperNode. The first three are all related and shouldn't be too hard since we designed Web Audio from the start to share infrastructure with MediaStreams (which are already integrated into media elements) --- internally, a Web Audio node is just a special kind of MediaStream. We still need to implement HRTF and soundfield panning modes for PannerNode. We need to implement OfflineAudioContext. For some of the audio algorithms that aren't very well specified, we're borrowing code from Blink. This is suboptimal but there's ongoing discussion about what level of detail we should specify the audio algorithms at.
- Work on latency. Right now audio output has pretty bad latency, especially on Android, FirefoxOS and Windows; the biggest problems are intrinsic issues with the platform APIs we're using. On older versions of Android and Windows XP it may be a lost cause, because good APIs simply aren't available. For Windows Vista and up we're writing a new audio output backend using WASAPI. On FirefoxOS we may rip out the Android code we're using and replace it with PulseAudio. There is additional work to do to better integrate the MediaStreamGraph (that drives MediaStream and AudioNode processing) with our libcubeb audio backends for lower latency and better tracking of the audio clock. This latency work is desperately needed for WebRTC as well as Web Audio.
- Work on throughput. Right now we're focusing on having a good clean design and functional correctness. For example, all communication and synchronization with the MediaStreamGraph real-time processing thread is asynchronous, using message passing. Updates to Web Audio and MediaStream graphs are batched so all changes performed by a script happen atomically on the real-time thread. But we haven't done any profiling, tuning, or optimization of the actual processing code. In particular we'll clearly need SIMD implementations of basic audio primitives such as mixing to get near-maximum performance, especially on mobile.
- Test and fix bugs, needless to say.
Contributors welcome! The Web Audio bug (779297) has a lot of dependencies to choose from :-).
One interesting issue that Jean-Marc Valin brought up recently is the prospect of a loudness war on the Web. Some areas, such as Sony's Playstation products and some broadcast TV regions, are trying to mitigate the loudness war by standardizing acceptable dB levels for all content. It might be a good idea to do this on the Web too, and have browsers automatically limit the volume of content that exceeds those levels. We're still thinking about whether and how this should be done, and talking about it on public-audio.
We had a lovely few days away. On the drive to Rotorua we stopped at Waihi and rode the old railway up to Waikino in an open carriage. Later we stopped at Mount Manganui and walked to the top --- always a great view.
We stayed by the lake at Waiteti, just out of town, at Waiteti Lakefront Motel. I think that was a pretty good decision; very peaceful, great view, relatively cheap, and free use of kayaks which we took advantage of on Saturday morning, paddling up the Waiteti Stream a bit.
On Friday morning we did the gondola and luge ... especially the luge, which everyone enjoyed. After that we visited Kuirau Park, which I always enjoy a lot --- it's so great to have a geothermal park right in the city. Then we went to Waimangu Valley, which I still think is the best geothermal attraction in the area because of its unique size and features, and its brilliant bush and lake setting. It's changed noticeably since I was last there; Warbrick Terrace is growing quite rapidly.
After kayaking on Saturday we went to the Redwoods for a short walk. I hadn't been there before and it's really great --- not as picturesque as some other places near Rotorua, but large and lovely, especially I imagine for running and biking. Then we went to Lake Okareka and did the new walkway there. Brilliant.
On the way back to Auckland yesterday we stopped near Putaruru and did the Te Waihou walkway. The Waihou river is stunningly clear and beautiful due to having flowed underground through filtering rock in the Kaimai Ranges (for fifty years, supposedly). We saw a lot of trout, but a couple of guys fishing complained they hadn't caught any because the clarity of the water made it too hard to estimate depth!
All in all, another wonderful central North Island getaway. I love this place.
Postbox 3.0.8 is now available. Here’s what’s new in this release:
To update, select About Postbox from the Postbox menu on Mac OS X, or select About Postbox from the Help menu on Windows, then click the Apply Update button once the update has finished downloading.
We drove out to the Upper Mangatawhiri Dam on Sunday afternoon and took a couple of hours to get to Piggotts campsite. It's a pretty small patch of flat grass, so I don't know how you'd get 20 people camping there, but whatever. There's also a small hut which I haven't seen mentioned anywhere. In fact we passed by it, thinking that couldn't be the place, but quickly turned back when it became clear that it was, in fact, the place.
A thunderstorm passed over during the night. It was the first time any of us have been in a tent during a thunderstorm, so that was exciting for everyone.
The next day we got up early and hit the trail about 8:15am. Based on the warnings about central Hunua tracks being "for experienced trampers only", and that we hadn't ever hiked a long distance carrying all our gear, I wanted to give us the maximum possible time to get to Adams campsite. As it turned out even the warning-est track (Upper Mangatawhiri) was just fine. Less fine was that the Adams campsite was a lot further along the track than where my map shows it, and when we finally found it at about 3pm, it looked pretty awful. The ground was waterlogged and, while there was a sign saying "toilet", there wasn't one to be seen. We decided to skip it and push on to our final destination --- Waharau Regional Park. (Now that I've looked a bit closer online, it seems Thousand Acres campsite is a better bet ... but it's not even on my map. Lesson: use up-to-date maps and do more research!)
So our three-day tramp turned into a two-day tramp and we arrived at Waharau about 5:15pm after nine hours of tramping, covering about 18km of reasonably rugged terrain with all our gear. Everyone was tired but I'm proud of my kids for handling it very well.
If the weather forecast isn't too horrible I'll be away the coming Sunday afternoon to Tuesday morning tramping in the Hunua hills southeast of Auckland.
Thursday is Anzac Day, a public holiday, and I'll be taking Friday off to go on a holiday with my family. So I'll probably be in the office/online only on Wednesday next week (that's Tuesday for those of you on the wrong side of the date line).
About a week later, Sunday May 5, I have a flight to San Francisco. I'll be in the Bay Area on Monday and Tuesday, and at LEAD training on Wednesday and Thursday.
About week after that, Friday May 17, I'm flying to Taiwan for a Mozilla layout/graphics/media work week.
The head of "Google NZ", Tony Keusgen, has been talking about New Zealand's shortage of "IT experts". And apparently, unlike most people who complain about it, he's actually tried to do something to help. That's great.
However, what's not so great, and of course not mentioned at all in the article, is that Google itself is contributing to the problem in a significant way by aggressively recruiting for NZ developers to move to their Sydney engineering office --- since they don't have an engineering office in New Zealand. That works for Google, for their recruits, and even for me and Mozilla, since there's basically no competition to Mozilla for NZ developers who want to do the sort of platform engineering work we do. It sucks for New Zealand though.
It's too bad the writer, Ben Chapman-Smith, didn't know about or declined to mention this. And if no-one called Tony Keusgen on it, that's bad too.
I would love to see a real Google office here. Some pretty high-profile Googlers are NZers. Make it happen!
I just sent a message to public-audio replying to Chris Rogers, Chris Pike and Chris Lowis. Fortunately Chris Wilson wasn't involved in the thread, although he could join at any moment.
It reminded me of a Mozilla meeting discussing multi-process video playback, which I attended with Chris Double, Chris Pearce, Chris Jones and Chris Blizzard.
Something is deeply wrong here.
I went to an orienteering event on Saturday. Orienteering is a race through a set of waypoints on a map; what sets it apart from a regular running race is the need to navigate via the map. Obviously it would be easy to cheat with a smartphone. Currently it's not hard to ensure people don't carry or use smartphones during the race. However, it's going to get increasingly difficult to detect cheating as technology progresses into smartphone watches, Google Glasses, and ultimately body implants. It doesn't seem practical to use X-rays or MRI scans on every participant, even if that would work.
Similar cheating problems are already happening in chess, and in written exams. Casinos grapple with these issues too.
It seems likely that any competitive event where real-time computer assistance (including communication with other humans) would be useful will sooner or later become practically impossible to secure against cheating. This will have profound effects. Even when people choose not to cheat, not knowing whether the game is fair is corrosive. Enjoy competitive games while you can.
This is going to be a problem for job interviews too.
I blogged last time the browser engine count changed, so I think to be fair I should blog about this one too.
I think this is good news for the Web. When we lost an engine, that was bad for engine diversity and the open Web. Now we're gaining one, and that's good for engine diversity and the open Web. It's not a direct reverse of the Opera situation though. Compared to Presto, Blink will have much more market share, and therefore a bigger impact. On the other hand, Blink is a promise to deliver a different engine over time, not a new engine right now, and even in the long term one presumes it will share a lot of code with Webkit --- especially if people port code between the two projects. So it contributes less diversity than Presto did.
One immediate benefit for the open Web is that today it's difficult for mobile Web developers to advocate "just coding to Webkit" as the way forward.
One issue we'll need to figure out in standards groups is when a Webkit implementation and a Blink implementation of a feature count as two independent implementations to allow a spec to proceed to REC. It's tough; even if the implementations are developed independently, the shared context (both code and architecture) will make the implementations less independent than they should be. We may need to address this on a case-by-case basis.
I am a bit worried about how this will impact Apple's support for the open Web. Safari has lagged behind other browsers in various ways, but they were also dragged along by Google to some extent in supporting new features whether they cared or not. Now they're falling completely off that train and we'll see a true test of whether Apple is willing to step up their investment to keep up with the progress of the open Web. Apple has obvious incentives to hobble Web apps on iOS, so I worry.
Of lesser importance, this is probably good for Mozilla. Even if it means Chrome moves faster, the fracturing of the Webkit community benefits us. It's not something to gloat over though.
Back to work!
Update One other thought occurred to me: now, a company adopting Webkit has to choose between a fork dominated by Apple and a fork dominated by Google. That's going to be less appealing than when Apple and Google were providing some counterweight to each other.
The latest browser usage stats are out at Net Applications:
Firefox has been mostly stable over the last year with Chrome down about 15% from its high. The increasingly solid IE 9 and 10 browsers have helped reverse Microsoft's slide, putting them solidly in positive growth over the last year.
A lot of exploit styles (e.g. "return-oriented programming") rely on jumping or calling into code that was never meant to be executed "stand-alone" --- i.e., jumping to an instruction that was only ever supposed to be executed by falling through from the previous instruction or via a branch within its function. On x86 this includes destination "instructions" that are actually part of another multi-byte instruction. It seems to me these exploits could be made much harder by somehow marking the start of "valid" branch/call/return targets and faulting when control is transferred to other instructions inappropriately.
Here's a more specific proposal for x86:
- Add a new flag bit for code pages to enable "destination checking" on a per-page basis.
- An indirect control transfer is any return instruction that pops EIP off the stack, or any jump or call instruction whose operand is not a constant. When an indirect control transfer jumps to a page marked for destination checking, and the instruction at EIP is not 0x90 (NOP), fault.
- A toolchain would take advantage of this feature by marking code pages for destination checking, avoiding use of 0x90 for regular NOPs, and placing a 0x90 at every function entry point and after every call instruction. For bonus points, avoid generating 0x90 bytes inside other instructions.
Obviously there are a lot of ways to tweak this. For example "PUSH EBP" is very often the first instruction of a function, so you could whitelist that instruction as a valid function entry point. You could avoid having to place a NOP after a direct CALL instruction by checking if the instruction at EIP-5 is 0x9A (direct CALL). You could make false returns even harder by extending that special case to require the address we're returning from to be "close to" the destination of the direct CALL instruction.
This is obvious enough that I presume someone's worked on it already.