Planet Mozilla — 2008-09-06 Trunk builds
Fixes:
- Fixed: 263942 - Reload button should have middle click support (open same URL in new tab, clone tab).
- Fixed: 407216 - DOM fast stubs.
- Fixed: Merge from Tracemonkey branch Sep 2 and again Sep 4. (javascript.options.jit.content should now be stable enough for daily use. Try it out!)
- Fixed: 418343 - Autocomplete results (search and form history) no longer sorted.
- Fixed: 430061 - Replace imglib's use of necko memory cache with an imglib-specific cache.
- Fixed: 135007 - Transfer mode of images should be relevant for shown lock icon state (mixed content).
- Fixed: 394416 - Feed sniffing should apply to fewer mime types.
- Fixed: 442291 - Very slow scrolling.
- Fixed: 346337 - Sessionstore does not maintain form input field data.
- Fixed: 368677 - Sessionstore should ignore popup windows.
- Fixed: 212316 - [Windows] Mozilla must handle WM_ENDSESSION message to cleanly unload in case of exiting or restarting windows.
Fixes for recent regressions:
- Fixed: 452083 - [Windows] Drag and Drop not working.
- Fixed: 451204 - Highlighted text is white on white text on a yellow background, difficult to read.
mozilla-central pushlog for 2008-08-29 04:00 to 2008-09-06 04:00
Planet Mozilla — JavaScript Benchmark Quality
Summary: JavaScript Benchmarks aren't adapting well to the rapid increase in JavaScript engine performance. I provide some simple tests for verifying this and propose a modified setup which could be used by all JavaScript Benchmarks to achieve high-quality results.
There now exists three, what I would consider to be, major JavaScript performance benchmarks. Each are released by a major browser vendor. WebKit released SunSpider, Mozilla released Dromaeo, Google released the V8 Benchmark.
Each suite has a variety of tests and a test runner. I'm currently interested in one thing: The quality of the test runner that each of these suites provides.
There are three points that any test runner tries to achieve:
- Retrieving accurate numbers. Another way to phrase it: "Retrieving stable numbers." If you run the test suite multiple times will you get identical, or near-identical, numbers?
- Reducing the possible error. Does the suite attempt to quantify how much possible error there could be in their results? How large is the error?
- Reducing run time. How long does it take to run each test?
The ideal suite would be one that's capable of running an individual test as quickly and accurately as possible with virtually no error. However, in order to get those numbers you need to carefully chose what style of tests you wish to run.
I quantify the current field of tests into three categories:
Slow-running tests: These tests generally take a couple hundred milliseconds on an average consumer machine. This is the style of tests that you generally see in SunSpider and occasionally in Dromaeo. These tests have a distinct advantage: They are generally quite accurate. You don't need to run them very many times (say about 5) in order to get a consistent picture of how the test will run.
Moderate-running tests: These tests take less than one hundred milliseconds. You'll see these tests in Dromaeo. These tests need to be run quite a few times (20-30) in order to get a better picture of their speed.
Fast-running tests: These tests take less than ten milliseconds. You'll see these tests in the V8 Benchmark and in Dromaeo. These tests must be run many, many, times (usually close to a thousand) in order to weed out any possible error. If you were to run one 10ms test 5 times - and get a single result of 11ms that would introduce a significant level of error into your results. Consider tests that take 0-1ms. A deviation within that range can instantly cause error levels around 50% to occur, if enough test iterations aren't completed.
Looking at the above categories the solution seems obvious: Use slow-running tests! You get to run them fewer times and you get accurate results - everything's peachy! But here's the problem: The speed of JavaScript engines are increasing at a rate faster than test suites can adapt. For example, SunSpider was initially developed with all tests running at equal speeds on a modern computer. Now that speed improvements have come along, though, (WebKit improvements, then Mozilla, then SquirrelFish, then TraceMonkey, then V8) those results don't even remotely resemble the tests of old. Most of the results have moved down into the moderate-running range of tests, some even into the fast-running range - but here's the problem: They're still only running the originally-designed number of loops. An example of the difference:
This means that a browser is running a test for 5-10 loops (in both SunSpider or Dromaeo) but the speed of the test no longer matches that assigned number of iterations. At first glance you could say one of two things: 1) Increase the difficulty of the tests or 2) Have them run for more iterations. There are problems with this, though.
While you certainly could increase the complexity of existing tests the result would be a never-ending battle. Improvements would have to land every couple months in order to keep up with the pace of improvement. This would work ok in Dromaeo (since it has versioned tests) but not all suites can handle this behavior. Additionally this now makes the tests less-useful for measuring slower browsers (the tests now take an absurd amount of time to complete as opposed to the very-plausible numbers from before).
Additionally, you could increase the number of test iterations that would occur but not without assigning specific iteration counts to each individual tests. And this is the full problem: How do you know what numbers to choose? Raising the number to 20 iterations may help one browser - but what about another browser which will need 100 iterations to get a proper count?
This leaves us in a bind. Browsers keep getting faster at tests, test suites do the wrong number of iterations, causing the error level to continually increase:
We should take a step back and look at what the test suites are doing to counter-act the above trend from happening - if anything at all.
SunSpider was originally dominated by long-running tests running 5 times each. The tests use to be long-running but are now only in to the medium to fast-running range (depending on the browser). This has caused the accuracy to decrease and error level to increase. Increasing the number of iterations would help (but hinder older browser performance).
Dromaeo has a range of tests (fast, moderate, and long-running) each running 5-10 times each. Dromaeo attempts to correct the number of iterations run, right now, but kind of fails when doing so. It looks at the results of past iterations (especially the error level generated by the results) and decides to run more tests until a stable error level is achieved. The problem with this is the samples are no longer being independently determined. Whereas test runs 1-5 were independent, test runs 6-10 were not (they're only being run due to the fact that previous test runs provided poor results). So while the results from Dromaeo are hyper-stable (they're the most stable performance test that we run at Mozilla) they're not determined in a proper statistical manner. Thus Dromaeo needs to be changed in order for people to be able to gather accurate results without sacrificing its statistical integrity.
The V8 Benchmark takes a completely different strategy for its fast-running tests: Instead of running for a pre-determined number of iterations each test is run continuously until a second of time has passed. This means that individual tests frequently run anywhere from 50-200 times (depending on the machine and browser they run on). Currently the V8 Benchmark does suffer from one shortcoming: There is no error calculation done. Both SunSpider and Dromaeo fit the results to a t-distribution and compute the possible error of the results whereas the V8 Benchmark just leaves them as is.
However, the V8 Benchmark does bring up a very interesting strategy. By picking tests that are simpler (and, arguably, most current complex tests will become "simple" as engines rapidly improve) and running them more times (relative to the complexity of the test) the results become much more stable.
Consider the result: Fast-running tests end up having a smaller error range because they are able to run more within a given allotment of time. This means that the test runner is now self-correcting (adjusting the number of iterations seamlessly). Since all JavaScript engines are getting faster and faster, and complex tests are running in shorter and shorter amounts of time, the only logical conclusion is to treat all tests as if they were fast tests and to run them a variable number of times.
We can test this hypothesis. I've pulled together a simple demo that tests the computational accuracy of the three styles of test (Simple - or Fast-running, Moderate, and Complex - or Slow-running) against the two different types of suites: "Max" style (the style implemented by the V8 Benchmark) and "Fixed" style (the style implemented by SunSpider and Dromaeo). The results are quite interesting:
Fast and moderate-speed tests are incredibly accurate with the max-style of test running. Often their error is no more than 2% (which is really quite acceptable). The quality degrades for the complex tests, but that's ok. Complex tests could be tweaked to consume less resources (thus allowing them to iterate more times and become more accurate).
Right now the accuracy of slow-to-moderate tests in fixed run test suites are suffering from increased rates of error as the engines get faster (as can be seen in the above chart).
The major change that would need to be made to the flexible style of execution (at least the one implemented in the V8 Benchmark) would be some form of error checking and t-distribution fitting. In V8 a series of tests are run over the course of one second. I propose that the resulting number (the total number of tests executed) be saved and the tests are repeatedly run again (perhaps 5 times, or so). The resulting set of 5 numbers (representing, potentially, thousands of test runs) would then be analyzed for quality and error level. I have this measure completely mocked up in my sample test measurement.
The relevant portion of the code is here:
var runs = [], r = 0;
setTimeout(function(){
var start = (new Date).getTime(), diff = 0;
for ( var n = 0; diff < 1000; n++ ) {
test();
diff = (new Date).getTime() - start;
}
runs.push( n );
if ( r++ < 4 )
setTimeout( arguments.callee, 0 );
else {
done(name, runs);
if ( next )
setTimeout( next, 0 );
}
}, 0);
}
Switching to a flexible style of text execution has many benefits:
- It'll help to keep the rate of error small for most tests (especially if the tests are tailored to be smaller in nature).
- It'll allow the suite to gracefully adapt over time, as engines speed up, without sacrificing the ability to work on old engines.
- The maximum number of runs (and, thus, the maximum amount of accuracy) will occur for the engines that are able to complete the tests faster. Since the greatest amount of competition is occurring in these high numbers (as opposed to in older user agents, where there is no progress being made) granting them the most accurate numbers possible makes this ideal.
I plan on prototyping this setup into Dromaeo and releasing it shorting. It'll take much longer to run the full test suite but the result will be quite worth it.
Planet Mozilla — Back in a land with internet
In relation to the previous post, I am now back - sort of. Wednesday 10 until Thursday 18 I will be in Sweden for another small holiday, and the 26th I move to London to start studying for my Master’s degree. I should be settled in there somewhere after the first week of courses (think October 10th).
If there is something you need me to take care of urgently, please let me know. Right now my priorities are with moving out of the Netherlands for a year and possibly more (which is not trivial). In some spare time I try to work on ChatZilla accessibility (specifically, my long overdue halfway report) and some of the bug reports about Chrome List that I’ve been getting. There is also Venkman demanding some attention. If anyone would like to help out with that, please have a look at the wiki page that Alex et al. created. You can usually find either of us on IRC if you’re interested in helping out. It’s really quite necessary because in its current state it is not doing that well (several basic features are broken with Firefox 3(.0.1) and on trunk).
Planet Mozilla — Brian Krausz: Antiantisocial Networks
Today TechCrunch reported on a paper describing a way to use Facebook for malicious means. The paper describes a DDoS attack that can be done, leveraging the large number of users of an application to attack a victim site.
While this attack vector is legitimate, I see a number of things that make it inherently infeasibly, and don’t think it really warrants being called a “FaceBot” (implying similar power to a botnet).
In order to create an application, one obviously needs to create a Facebook account, though that can be done anonymously. The real issue is that in order to execute such an attack, one would need to make an application that is incredibly popular. The attacker would need to devote a large number of resources to keeping such a popular app up, which would all need to be done anonymously (though would need to be paid for in one way or another).
Let’s say an attacker has gone through all of this to make a popular application: why doesn’t he/she just use those resources for a direct attack? One possibly answer is that the Facebook DDoS would be hard to shut down, or better in some other way in executing the attack. This is false because as soon as someone realizes that their traffic is coming from Facebook (whether by referrers, or FB trying to pull images for its cache, or some other mechanism), it can in most instances be stopped immediately, especially considering how most Facebook calls to other sites include the application’s API keys. Even barring that, IP addresses and Facebook’s logging can be used to determine what application a user was in when they requested the victim’s site.
Additionally, DDoSs using this attack vector are relatively easy to mitigate. If a hacker already has all of these resources dedicated to keeping an application up, why wouldn’t they just launch a TCP SYN flood or similar lower-level attack, much more potent DoSs, even if launched from a more limited IP range.
Let’s take a different route: suppose a hacker attacks one of Slide’s applications and somehow manages to break in and add an attack iframe. This is a completely legitimate and anonymous way of attacking a site (though it begs the question of why the hacker didn’t just break into the target site in the first place, assuming both have similar levels of security). While this is a legitimate issue, the same holds true for all websites. Should someone hack into Yahoo! and figure out how to deploy a new home page (somewhere between almost-impossible and no-freaking-way on the difficulty scale), almost any site on the internet could easily be taken down. I certainly hope top app developers take security as seriously as top website owners, but this is nothing special for Facebook.
On the topic of information theft, this is why Facebook requires you to explicitly permit an application to access your information. The concept of an API implies this potential for theft…users are trusting applications to access their information and not keep it. There is no way to prevent this for the same reason DRM doesn’t work: if people can view things they can store things. While this is a legitimate concern, again it is nothing new, and not much can be done about it short of user education.
Planet Mozilla — Making the Cut
As you may know John Slater and I have been creating a new Firefox logo style guide with the help of the Royal Order and a small team of community members who’ve volunteered as our informal panel of advisers. We’ve made a lot of progress so far and hope to have the beta version of the site ready this month. In the meantime both John and I will continue blogging about our progress at various stages to keep you apprised of all the details. With that said, here is a quick behind the scenes look at one of the first challenges we worked on and the thought process going into it.
The Firefox logo is pretty straightforward, but over time we’ve actually accrued lots of alternate variations and lockup combinations - with the wordmark, product number, partner co-branding, etc. When we took an inventory of all these we found around 32 different logos, which from a branding perspective was a pretty large amount of visual identities to have on tap. So before we could work on the guide itself, we had to conduct an internal audit to clean and consolidate everything. With careful consideration given to each one, we narrowed down the set to eight key logos that we felt had the strongest brand presence and represented the most common use cases. Here they are:
Looking at all the existing logos, the first group that we decided to retire were the different partner lockups. These can serve as a general template for co-branding, but each partnership is unique and requires specific treatment. So going forward we felt its best to work directly with each partner and create new ones on a case by case basis. Next, we chipped away ones that felt redundant or busy. Including lockups that were communicating a little too much at once and confusing the information hierarchy. For example this one which shows: the Logo (core product), Mozilla wordmark (parent company), Firefox wordmark (core product name), version number (product specific information), and of course the registered trademark symbol.
Our breakdown for the final eight goes something like this:
- Firefox logo is one of the primary visual identities and widely recognized by millions around the world. So this should be used as often as possible.
- Lockup with both wordmarks reinforces product name and Mozilla as the parent company. This should be for more general use such as press materials, T-shirts or posters.
- Lockup with a strong link to version number is best for communications specifically promoting Firefox 3, such as a download page or product info sites.
- Wordmark lockups without the logo are available for times when that is necessary. Featuring the Firefox logo is always preferred, so if using the wordmark by itself, do so only when the Firefox logo is presented somewhere nearby.
- If you don’t have space for a horizontal logo, you can use one of the two vertical lockup options.
We put a lot of thought into these guidelines and feel pretty good about them, but if you have any questions or comments please don’t hesitate to share with us!
Planet WebKit — Skia graphics library in Chrome: First impressions
With the release of the WebKit-based Chrome browser, Google also introduced a handful of new backends for the browser engine including a new HTTP stack and the Skia graphics library. Google’s Android WebKit code drops have previously featured Skia for rendering, though this is the first time the sources have been made freely available. The code is apparently derived from Google’s 2005 acquisition of North Carolina-based software firm Skia and is now provided under the Open Source Apache License 2.0.
Weighing in at some 80,000 lines of code (to Cairo’s 90,000 as a ballpark reference) and written in C++, some of the differentiating features include:
- Optimised software-based rasteriser (module sgl/)
- Optional GL-based acceleration of certain graphics operations including shader support and textures (module gl/)
- Animation capabilities (module animator/)
- Some built-in SVG support (module (svg/)
- Built-in image decoders: PNG, JPEG, GIF, BMP, WBMP, ICO (modules images/)
- Text capabilities (no built-in support for complex scripts)
- Some awareness of higher-level UI toolkit constructs (platform windows, platform events): Mac, Unix (sic. X11, incomplete), Windows, wxwidgets
- Performace features
- Copy-on-write for images and certain other data types
- Extensive use of the stack, both internally and for API consumers to avoid needless allocations and memory fragmentation
- Thread-safety to enable parallelisation
The library is portable and has (optional) platform-specific backends:
- Fonts: Android / Ascender, FreeType, Windows (GDI)
- Threading: pthread, Windows
- XML: expat, tinyxml
- Android shared memory (ashmem) for inter-process image data references
Hello world
In this simple example we draw a few rectangles to a memory-based image buffer. This also demonstrates how one might integrate with the platform graphics system to get something on screen, though in this case we’re using Cairo to save the resulting image to disk:
#include "SkBitmap.h" #include "SkDevice.h" #include "SkPaint.h" #include "SkRect.h" #include <cairo.h> int main() { SkBitmap bitmap; bitmap.setConfig(SkBitmap::kARGB_8888_Config, 100, 100); bitmap.allocPixels(); SkDevice device(bitmap); SkCanvas canvas(&device); SkPaint paint; SkRect r; paint.setARGB(255, 255, 255, 255); r.set(10, 10, 20, 20); canvas.drawRect(r, paint); paint.setARGB(255, 255, 0, 0); r.offset(5, 5); canvas.drawRect(r, paint); paint.setARGB(255, 0, 0, 255); r.offset(5, 5); canvas.drawRect(r, paint); { SkAutoLockPixels image_lock(bitmap); cairo_surface_t* surface = cairo_image_surface_create_for_data( (unsigned char*)bitmap.getPixels(), CAIRO_FORMAT_ARGB32, bitmap.width(), bitmap.height(), bitmap.rowBytes()); cairo_surface_write_to_png(surface, "snapshot.png"); cairo_surface_destroy(surface); } return 0; }
You can build this example for yourself linking statically to the libskia.a object file generated during the Chrome build process on Linux.
Not just for Chrome
The Skia backend in WebKit, the first parts of which are already hitting SVN (r35852, r36074) isn’t limited to use in the Chrome/Windows configuration and some work has already been done to get it up and running on Linux/GTK+ as part of the ongoing porting effort.
Planet Mozilla — New position for the comment box when editing bugs. Do you like it?
While talking on IRC about how to make editable fields and the comment box closer so that you can easily comment and edit fields, especially the bug status, I suggested this mockup (ignore the fields you never heard about in the right column, those are custom fields). Is that something you would like to see officially implemented in Bugzilla? Or do you think it’s not better than what we have currently, i.e. the comment box just below the attachment table?
Brad Blassey (Mozilla) — Gates and Seinfeld
So, I’m sure I’m not the first to say….. huh?
Planet Mozilla — Knock, Knock, Alpha.
The SeaMonkey has you...
Follow the frozen tree.
Knock, knock, Alpha.
Whoever can read this matrix code should realize by now:
Yes, we're knocking at the door of our first Alpha. It's been dozing along in our repositories long enough - the real story of its life is about to begin. The code is supposed to freeze for SeaMonkey 2 Alpha 1 on Tuesday - after that line we will only accept changes to SeaMonkey code that are either blocking the Alpha (pref panels!) or have explicit approval.
We will release the actual Alpha 1 as soon as all the blockers are fixed and we get a QA run to confirm it's ready for testing by a greater community than nightly testers. It will still be a testing-only preview of what SeaMonkey 2 has to offer, but it will be a very huge step compared to the current stable 1.1.x series.
Additionally, I think we should set up a collection of SeaMonkey-themed desktop wallpapers and SeaMonkey-themed web button images somewhere, I'd need good ideas of where to do that.
For now, I can only provide low-quality images of those two I have designed for my personal fun, but if we have a good place to put up such thing, I have the first one as a 1024x768 PNG, the second one in sizes up to 1600x1200 as PNGs.
Planet Mozilla — Firefox 3.1 Alpha 2 now available for download
The second developer milestone of the next release of Firefox - code named Shiretoko Alpha 2 - is now available for download. Shiretoko is built on pre-release version of the Gecko 1.9.1 platform, which forms the core of rich internet applications such as Firefox. Please note that this release is intended for developers and testers only.
This Alpha of Shiretoko / Gecko 1.9.1 introduces several new features:
- Support for the HTML 5 <video> element
- Initial support for web worker threads
- You can now drag and drop tabs between browser windows
- New selector to create areas of Aero-style “glass” in XUL
- Support for CSS 2.1 properties: ::before and ::after, and white-space:pre-line
- Support for CSS 3 properties: -moz-border-image, word-wrap: break-word, text-shadow, box-shadow and column-rule
- Performance improvements and new preference values for color management profile support
Anyone interested in Shiretoko should read the release notes, as well as the “Firefox 3.1 For Developers” article on the Mozilla Developer Center before downloading. Please use the following links to download Shiretoko:
- Windows: Shiretoko Alpha 2 Setup.exe
- Mac OS X: Shiretoko Alpha 2.dmg
- Linux: shiretoko-alpha2.tar.bz2
We would appreciate hearing about any feedback you have, or any bugs you may find.
(Those interested in testing Mozilla’s new JavaScript engine “Tracemonkey” should note that it is not included in this development milestone. If you’re interested in that technology, please obtain a nightly build and follow these instructions)
Planet Mozilla — the message you should take to your weekend
“I think that the next 18 months we’re going to see a 100 to 1,000 fold speed increase in JavaScript as Google and the guys at Mozilla are going to kick us all in the arse and make our JavaScript jittered,” Microsoft senior program manager Scott Hanselman told the audience, days after Google released its Chrome browser, which features faster JavaScript technology.
[...]
“It’s going to be hard to tell if it’s going to be Silverlight or JavaScript we’re going to use for our applications,” he said. “I think in the end JavaScript is going to be a bigger competitor to Silverlight than Flash is.”
Hell yes, we’re making the web kick ass.
Planet Mozilla — Skinning the Fennec
I've been working with the talented Sean Martell (of Kit and the Firefox 2 theme fame) on taking my Fennec interaction wireframes and creating a default theme for the browser. We're trying for something that nods back in the direction of Firefox on the desktop while still striking out in a direction that's appropriate for a small-screen finger-directed device.
He's posted some of the recent work to his blog, and he'll be posting more there as we go. This is a effort still very much in progress, so please jump in with your suggestions (generally or even about specific glyphs/icons). There's a Fennec UI discussion thread ripe for contribution.
This first set takes us through some basic Fennec operation.
1. Initial page load
When a page first loads, and you're still at the top, you see a Title Bar at the top, with an identity button and a reload button. You also have access to your bookmarks.
2. Movin' on down
As you pan down the page, the Title Bar scrolls off the top. The entire screen is dedicated to web content.
3. Take a step to the right
Panning to the right of a webpage causes the Control Strip to snap elastically into place — it provides most of the primary UI, including a starring (bookmarking) button, back and forward, and access to page actions (e.g. SMS this page to a contact) and browser tools (Preferences, Add-ons, and Downloads). There's more how these sections work in the wireframes, with pixel-designed screens on their way.
4. What about the other side?
Similarly, panning off the the left of the webpage gets you to your tab area, which also snaps into place. The bottom button, on the left, creates a new tab. The idea behind the button on the right is that you should be able to pull up, via Weave, a tab that you have/had open on your desktop.
More to come!
Update: My comments are broken, so please leave your thoughts in the Google group or on Sean's post. Sorry and thanks!
Internet Explorer blog — August Chat with the IE Team on Thursday
Join members of the Internet Explorer team for an Expert Zone chat next Thursday, September 11th at 10.00 PDT/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team. Thank you to all who have attended the chats to date!
If you can’t join us online, all chat transcripts are published here.
Hope you can join us on Thursday for our first chat sine IE8 Beta 2 released!
Kristen Kibble
Program Manager
P.S. Upcoming IE chat dates are posted here.
Planet Mozilla — Static analysis newslets
I’ve been in interpreter-land lately, but I do help out a bit with static analysis projects when I get the chance. So I’d better post an update here on some interesting developments that haven’t been publicized yet.
First, Keith Schwartz (one of our interns) is making great progress on automatic const-correctification for Mozilla. The basic idea is to put const on as many declarations as possible without breaking the code or introducing casts. Keith has devised an algorithm based on type inference. Currently, he’s working on the Treehydra code to extract the type constraints from code. Because C++ is so complicated, there are a ton of details, and he’s had to master the insanity of GCC intermediate representations of pointers to member functions and calls through them. (If by chance, any readers know of a non-insane way to access them in GCC, let us know.)
Second, the Cairo folks were kind enough to give me an hour to talk about static analysis with the Hydras at their recent meetup. They already had 2 static analysis applications in mind. One was ensuring that internal-only return codes aren’t returned from the public API. The other was checking that integer and fixed-point values, both represented by C ints, aren’t mixed together. I think both of these can be formulated as type checking or inference problems.
I’m hoping we can extract a generic Treehydra type inference library from Keith’s code for the Cairo problems and others. One issue here is that Cairo is C, while Keith’s been using the C++ ASTs for his work. I don’t even know if Treehydra can read C ASTs at this point, but I think Treehydra’s design makes extending to C not too hard.
Planet Mozilla — there's whitelisting, and then there's whitelisting
First, he talked to Tom Murphy, chief strategy officer for Bit9 about whitelisting. Link
He also talked to Eva Chen, co-founder and CEO of Trend Micro about anti-virus protection. Link
Ms. Chen said that historically Trend Micro has seen the addition of 1,000 - 2,000 new virus strains in the wild each year. She also said that the numbers were exploding, and that they saw 5.5 million new unique virus samples in the wild in 2007. It's been clear for some time that blacklisting the "bad" apps was a losing battle. These new figures (new to me at least) really underscore that point. There are more illegitimate apps than legitimate apps.
Whitelisting, as Mr. Murphy describes it, allows you to define a set of applications or vendors and to mark them as trusted. Only specifically trusted apps, or apps from specific companies, can execute. Any app that is not on this white list is not able to run.
That technique will help in some cases to be sure, but what about the times when those apps themselves are tricked into performing malicious tasks for the attacker? The "trusted" app is running, but you've still been p0wned. Is there a cure for that problem?
Systems like SELinux attempt to solve this problem by not just whitelisting apps, but application behavior. (And it's built into Fedora and RHEL, naturally.)
Dan Walsh has some thought on how SELinux might be applied to something like Google's Chrome browser. He also includes some links to other posts on this same topic.
In one of those posts, Joshua Brindle writes:
This is a really important point: even "trusted" apps can be made to go bad, and you still need to find a way to be safe. I'll be interested to see how systems like Firefox and Chrome adapt to these kinds of controls over application behavior.
Planet Mozilla — What’s your feedback about Bugzilla 3.2?
As most of you know, Bugzilla 3.2rc1 is available for download since August 12 and bugzilla.mozilla.org upgraded to this version two weeks later, last Thursday. As I wrote in my last blog, b.m.o is not the first major installation to upgrade to 3.2rc1, so now seems a good time to get some feedback from people using this version of Bugzilla to know what’s their feeling with it, both about its UI and about its usability and new features. Mozilla folk reported a pretty large number of bugs, usability regressions, and complains, but as someone told me, they didn’t file bugs for things they like. So I thought this blog would be a better place to get your feedback, both positive and (highly?) negative, to get a better picture of what people think before releasing the final version of Bugzilla 3.2.
Note that this feedback can come from everybody using Bugzilla 3.2rc1 (or 3.1.4+), such as users of RedHat’s Bugzilla or OpenSSH’s Bugzilla, or even from smaller installations which already upgraded to this version. The wider the audience, the better. 
Planet Mozilla — Self-Signed Certs
Recently there has been a lot of discussion on the topic of Firefox 3's warnings about SSL certificates which are invalid or not signed by a known authority ("self-signed"). Following on from johnath's earlier excellent blog post, our position on the subject is set out in "Firefox 3 and Self-Signed Certs".
This page explains why Firefox 3's SSL UI was designed the way it was, and why we think it's right.
Planet WebKit — Pushing things forward
This shows parts of the TinySVG spec and the video was replaced with Code Rush. It is dog slow and needs some refactoring to SVGSMILElement and parts of the SVG RenderObjects to be merge able. The code should popup in my holger/dims branch soon.
Hacking on the WebKit codebase is so much fun that I seriously wonder if I want more of that...
Planet Mozilla — planet.mozilla.org and Web Tech blog readers may completely ignore this post
If you don’t read planet.mozilla.org or the Mozilla Web Tech blog, you’ve just missed out on a nice little article I wrote about some web developer features I implemented in Firefox before starting my A.T. thru-hike. If you’re into web development it might be interesting; I can assure you, however, that if you aren’t, it’ll be complete gobbledygook. In any case I’m sure at least some people in the latter category might be interested to see the sort of things I do beyond absurdly long backpacking trips, even if they won’t be able to understand them. 
Planet Mozilla — The text, the whole text, and nothing but the text
Hello, web tech enthusiasts! I’m going to talk about a little feature I implemented back before taking a little hike, as part of fixes for Acid3: support for the DOM 3 Core Text.replaceWholeText() and Text.wholeText. Most likely you’re familiar with neither, as browsers only started implementing them in the last year or so, and I don’t recall hearing web developers clamoring for support for them, so here’s a brief summary.
Suppose you have the following simple paragraph within your webpage (with some whitespace added to aid formatting throughout the code samples here), whose DOM node is stored in the variable para:
<p>Thru-hiking is great! <strong>No insipid election coverage!</strong> However, <a href="http://en.wikipedia.org/wiki/Absentee_ballot">casting a ballot</a> is tricky.</p>
You decide you don’t like the middle sentence, so you remove it:
para.removeChild(para.childNodes[1]);
Later, you decide to rephrase things to, “Thru-hiking is great, but casting a ballot is tricky.” while preserving the hyperlink. So you try this:
para.firstChild.data = "Thru-hiking is great, but ";
All set, right? Wrong! What happened was you removed the strong element, but the removed sentence’s element separated two text nodes, one for the first sentence and one for the first word of the last. Instead, you now effectively have this:
<p>Thru-hiking is great, but However, <a href="http://en.wikipedia.org/wiki/Absentee_ballot">casting a ballot</a> is tricky.</p>
You’d really prefer to treat all those adjacent text nodes as a single one. That’s where wholeText comes in: if you have multiple adjacent text nodes (text and CDATA nodes for XML wonks), you can access the contents of all of them using wholeText. Let’s pretend you never made that last mistake. In that case, we have:
assert(para.firstChild.wholeText == "Thru-hiking is great! However, ");
wholeText is just a property of text nodes that returns the string of data making up all the adjacent (i.e. not separated by an element boundary) text nodes together.
Now let’s return to our original problem. What we want is to be able to replace the whole text with new text. That’s where replaceWholeText comes in:
para.firstChild.replaceWholeText("Thru-hiking is great, but ");
We’re removing every adjacent text node (all the ones that constituted the whole text) but the one on which replaceWholeText is called, and we’re changing the remaining one to the new text. What we have now is this:
<p>Thru-hiking is great, but <a href="http://en.wikipedia.org/wiki/Absentee_ballot">casting a ballot</a> is tricky.</p>
With that, we’re all set.
Some uses of the whole-text functionality may be better served by using Node.textContent or the longstanding innerHTML; that’s fine and probably clearer in most circumstances. If you have to work with mixed content within an element as here, however, wholeText and replaceWholeText may be useful.
Opera Desktop Team — 9.60 beta 1 RC
Thats right, Opera 9.6 is soon ready for its first beta flight. We have now frozen all features and only critical fixes go in. Really soon now, the beta will be released, but we want more feedback from you guys before we do so.
Changelog
- Added Core version (currently "Presto/2.1.1") to the User-Agent header; all our products will include this feature soon
- Sites using HTTP Auth are now saved in typed history
- Added setting to prevent bookmarks from showing in the Address field auto-completion drop-down
- Properly stop loading pages with iframes when closing the page or pressing stop
- Fixed problem where dynamically added xml-stylesheet processing instructions were ignored
- Removed the document property from iframe objects for compatibility with Gecko, WebKit, and the Acid3 test
- Added support for the caller property on functions
- Fixed yet another case of having to press the back button twice
- Improvements to feed preview page
- Made feed preview page template location customizable
- Made reloading Speed Dial while offline actually reload all thumbnails
- Fixed Opera Link issue where notes could end up blank after being synced
- The Opera Link queue file is no longer created before using Link
- The fraud protection dialog now works when using a proxy
- Made it possible to remove Speed Dial search again by unchecking the "Use as default Speed Dial search"
- Fixed text input on Windows Tablet PC Edition 2005
- Fixed open/save of images in Opera Mail when using the image context menu
- Made all top-level access points (except All Messages) selectable
- Fixed a problem deleting drafts from the Drafts view
- UNIX: Additional fixes to flash plugin handling. Freezes when using flash should now be mostly gone.
Download
Windows
Windows Classic
Macintosh
UNIX
Planet Mozilla — Amaya, Mercurial m-c & c-c bundles, and Ubiquity commands
So I decided to try out some new stuff over the weekend:
The first is using Amaya in place of Adobe Dreamweaver CS3, sometimes I think Dreamweaver is overkill for what I need and Nvu / KompoZer somehow didn’t cut it anymore. Yes, I kind of prefer WYSIWYG capability, so Amaya seemed to fit the bill, moreover it’s free and open source.
Second, I have lots of bandwidth to spare, and I just encountered the pain of trying to clone mozilla-central from scratch with a flaky and unreliable internet connection. No matter how long you try, it does not seem to finish, so I resorted to Benjamin Smedberg’s bundle file that saved me lots of agony.
mozilla-central:
Metalink
to the mozilla-central
bundle: (downloaded >400 times)
changeset
18525, updated as of 20080829-10:05:02 PDT. (74M)
SHA-1: 7d069e0a186c556ef1039ad03d0ebb5edb2b48d4
comm-central:
Metalink
to the comm-central
bundle: (downloaded >250 times)
changeset
227, updated as of 20080829-16:27:14 PDT. (7.6M)
SHA-1: ade283eca96c354d8b8eac63f2c17258e5bc5c57
Please try out the metalinks (generated here) as they will verify the download automatically with the SHA-1 hashes. The instructions below are adapted from his page.
Unbundle the above repositories using the following steps, substituting
mozilla-central and comm-central as necessary:
1 - Create a new repository
$ hg init mozilla-central
2 - Unbundle it.
$ cd mozilla-central
$ hg unbundle /<path>/<to>/mozilla-central.bundle
3 - Tell Mercurial where you normally want to pull from by copying the
following content into your mozilla-central/.hg/hgrc file:
[paths]
default = http://hg.mozilla.org/mozilla-central/
4 - Pull the latest changes and update your local repository.
$ hg pull -u
This way, the repositories should set up much faster if you have a flaky
connection; you can always resume and verify your download if you are getting
the bundle files.
Finally, I have also joined the current craze of writing Ubiquity commands, and I did up one (adapted from the MDC one by Eric Shepherd) that uses Google Search for NUS’s (my school) webpages, however, no matter how I try, I can’t seem to get it to work successfully. Basically, I set up everything properly, permit the javascript at the red permissions page, but nothing seems to occur after I type in the “nus” keyword.
Any ideas about this?
Edit: Upgrading to Ubiquity 0.1.1 fixed this issue for me. Note that you will have to unsubscribe and re-subscribe to each javascript subscription for it to work properly.
Planet Mozilla — Meet the new SUMO team!
There has been some changes to the SUMO team recently. Jason Barnabe, who maintains the Support Forum, unfortunately doesn’t have enough time to maintain a full-time job and administrate the Support Forum at the same time. He has made awesome contributions to the project over the year, and we’re incredibly thankful for that. Fortunately, he will remain an active SUMO contributor, so we certainly haven’t seen the last from him!
Also, our Live Chat maintainer Majken Connor (most of the SUMO contributors know her as “Lucy”) is moving on to explore other opportunities. We have all valued her contributions to the project and we wish her every success.
With that said, I’m very excited to announce the new team:
- Chris Ilias remains the “keeper of the Knowledge Base,” as he likes to call it.
He is responsible for, among other things, reviewing article edits by the community, training and answering questions from contributors, improving our contributor documentation, gathering article feedback and statistics and ensuring that it is shared with the community. - Matthew Middleton is the new Live Chat maintainer. Matthew started as a Live Chat volunteer back in January, and since then he’s become more and more active. He has actually been a Live Chat administrator in over a month now, but will now take an even more active role withing the SUMO community. He has impressed a lot of people at Mozilla recently with his incredible dedication, so I’m very happy to have him as part of the SUMO team.
- Cheng Wang is the new Support Forum maintainer, and will work on various things in the project, like administrating the forum, room monitoring Live Chat shifts, and collaborating with the rest of the team and even other parts of Mozilla like the QA team, to figure out our most commonly reported issues with Firefox. Cheng also started contributing back in January and has already made a huge difference by introducing new volunteers and helping the planning and organizing of events like the Support Firefox Days.
This picture was taken from the Mozilla Summit in Whistler, BC. From left to right: Nelson Ko, Jason Barnabe, Laura Thomson, Matthew Middleton, Majken Connor, me, Cheng Wang, Brian Krausz, and Chris Ilias.
Together we will work hard to make our users happy, grow our community, interact with other teams at Mozilla to share insights and information, and shape what we think will become the future definition of Open Source Support.
Stay tuned for part four of The vision for SUMO…
Planet Mozilla — Google Chrome accessibility commitment
Planet Mozilla — The Evolution of Open - notes from Open Everything
Day 1 of Open Everything at Hollyhock has passed and I’m now up far too late blogging about it.
Numerous insights, but possibly the most interesting occured during the spectrogram exericse where we asked participants to physically locate themselves along an axis (in our case a piece of tape along the floor) in response to questions we asked them.
The most interesting was a two dimensional spectrogram where we first asked people if “The Organization I work for is open.” Then, after participants chose their spot along this first axis we asked them to migrate along a Y axis according to the question “I personally work in an open manner.” Below is a re-creation of how the participants distributed themselves around the room.
Obviously definitions of “open” and “how open” one is was up to each participant - but then this is the point of a spectrogram!
At first blush it simply seemed that many people were personally open (or trying to act in an open manner) in their jobs and that there was pretty equal distribution between who was in an open vs. closed organization.
However, the distribution of people in the quadrants was not random. Those in the bottom right quadrant (quadrant 2) tended to be people who were in more conservative institutions like universities, governments and traditional companies. These people were the IT professionals, consultants, organizers, etc… but more importantly, they were rabble-rousers within their respective organization, trying to initiate change. In short, you had CHANGE MAKERS trying to shift their org into a more open space.
In the top right-hand quadrant (quadrant 3) were people in emerging open source projects and generally smaller organizations that were striving to be open. This was a group of people who’s organizations were become increasingly open. These ACTIVISTS believed in the open idea and were excited about where they - and their organizations - were.
Finally, in the top left hand quadrant (quadrant 4) were the VETERANS of the open movement. Here were people who worked in well established open source or open projects. Their challenge was they were experiencing the limits and issues of being and acting consistently in an open manner. As they push about against the most extreme limits of open they saw the necessity and value of not always been completely and totally open (for example, there are only so many thinking processes, conversations, and discussion, I can take the time to share).
So the big ah-ha was realizing the growth curve that people and organizations go through as they engage in, and become, more open. First you have change makers who agitate and work to enable organizations to adopt open methodologies. Then as the organization becomes more open people become activists, celebrating the open idea and pushing it into all areas of the organizations. Then those within the organizations begin to run into the operational and practical limits of open and, importantly, recognize the importance and role of “private” or “closed” as essential and so guard it. Critically, I also think that those in quadrant 2 or 3 are often measuring open differently then those in quadrant 4 - who because of their boards and/or stakeholders, hold themselves to a very high bar.
The best part about this is that it means there are individual and organzations lessons to be drawn as one migrates through these stages. It also means thatt those passionate about open, but in radically different quadrants (say 2 vs 4) may have very different priorities and/or concerns. This doesn’t mean that they aren’t both equally committed to a common ideal, just that they are looking at it from very different places.
Planet Mozilla — Friendly Feedly
During the last day, I’ve been playing with a Firefox extension called “Feedly.” The home page for the extension is at feedly.com. As the extension describes itself:
Feedly is a new kind of RSS start page which weaves Google Reader, Digg and Delicious into a more fun, magazine-like user experience. The integration with Twitter, Yahoo Mail, Gmail, Friendfeed and Delicious makes sharing a breeze. You can get up to speed quickly by importing your existing Netvibes, Bloglines or MyYahoo accounts, your bookmarks or an OPML file.
What it does is act as a new way of viewing your feed content for those of us who read a lot of blogs (I scan at least 200, though some of those only update once a week). It uses Google Reader as its backend for accessing your feeds. For me, this is very convenient because I was already using Google Reader. This means that it reads my existing reader subscriptions, including folder organization, and presents views on it. When I mark items as read, save them for later, or share them, this is reflected on the Google Reader site. This makes it perfect for me and very easy for others to try if they are already playing with Google Reader.
Feedly offers various roll up views of top readers for blogs or other Google Reader information. It also allows you to use the “River of News” model for reading if you want to do so. One thing that I appreciated is that you can tweak a couple of different settings on how it presents feed contents to you. In the view below, I am using a short summary view with a small picture on a roll up page for one of my folders (personal-blogs). This gives me the first few sentences of each item and a picture. If I click on any item, it will expand in place to show me the full feed item. I can click on it again to collapse it or to choose options to save it, etc.
The only problem that I’ve run into so far is that it occasionally loses its synchronization with Google Reader so I see some of the same feeds or it offers me feed items that show as read in Reader if I go to it directly. This has only happened a few times but it is something that the software needs to work on. As a whole, I’ve found it to be a much friendlier way to use Google Reader and I plan to keep using it.
I’m not sure what the business model of the feedly.com site is for this but I expect that the search box at the top of each page may play a role. I haven’t noticed any ads or similar on pages yet. They do have a blog available and seem to be doing regular updates for the overall software.
This is for Firefox 3, only, of course. :-)
This work is licensed under a Creative Commons License.
Planet Mozilla — Web Workers, Part 1
Some computations in JS take a long time, like this (incredibly poor!) implementation of the Fibonacci sequence:
function fibonacci(n) {
if(n == 0)
return 0;
if(n == 1)
return 1;
return fibonacci(n - 1) + fibonacci(n - 2);
}
Any developer that puts this function on a web page and then asked for the 35th number in the sequence would succeed in locking up most browsers until the number was either calculated or the user got fed up and aborted the script.
Thankfully preliminary support for web workers has landed in Firefox 3.1 Alpha 2 so that expensive computations like this can be moved off to a background thread. The user interface will remain responsive while the JS engine churns and navigating away from the web page will even pause its execution.
Web workers are isolated from the main web page and can only communicate by passing string messages. Currently workers may only use timeouts, but there are lots more features that are just about ready:
- Creating workers from a url (rather than passing the text of the script)
- Dynamically importing additional scripts from the worker context
- Using XMLHttpRequest (with one caveat - access to the DOM is not allowed)
- Passing JSON-able objects as messages
The spec for web workers is still in (slight) flux and can be tracked here and here. Documentation and a simple example (of bad fibonacci) can be found here although please keep in mind that the current syntax is being changed to match the spec before Beta 1.
Planet Mozilla — Profiling Dromaeo Testcases with Shark
I’m taking a break from garbage collection for a week or so: I got stuck, and there are lots of other things going on I wanted to help out on. Yesterday and today’s project was profiling some DOM testcases.
Two days ago, Jason recently landed a great patch to minimize the XPConnect overhead of DOM calls (fast-path DOM). Prior to this patch, many profiles of DOM scripting were dominated by XPConnect overhead (marshaling calls from JS to binary XPCOM). So I decided to re-do some of these profiles and see if there were any easy wins lurking, now that the noise was gone. I first ran the Dromaeo tests in a build from mozilla-central and compared the results to Safari on the same machine. Now, I’m taking some of the comparatively worst performers and using Shark to profile the tests.
I figured that getting shark to profile individual tests would require some major hacking. But it turns out that Dromaeo already has support for wrapping tests with calls to generate Shark profiles! All I needed to do was hack a little bit to generate a single profile at a time.
I started by profiling the following test: DOM Modification (Prototype): update(). mozilla-central was 8x slower than Safari on this test.
- Start with a shark-enabled Firefox.
- Download or clone Dromaeo from here.
- Type `make web` to build a local copy of Dromaeo.
- Start shark for programmatic control as documented here.
- Point your browser at the test like so:
file:///builds/dromaeo/web/index.html?dom-modify-prototype&shark=update&numTests=1
- Shark should do a little dance and pop up a profile viewer. For a quick overview on using the Shark profile viewer, see Vlad’s blog.
- By using the top-down view, I quickly discovered that over 70% of runtime was spent in a single function:
- By double-clicking this function, I could see a heatmap of execution within the function: just two lines of code were responsible for most of the time!:
.
- This was more than enough evidence to file a bug.
- After a bit of conversation with Brian Crower on IRC, I found that my initial hypothesis was wrong: The JS_ISSPACE
macro is not really to blame. Every time it encountered a \s or \S in a regular expression character class, the code would loop over all 65,536 characters in the unicode basic plane and ask a series of lookup tables “is this character a space?” Because there are a small number of actual whitespace characters, I could replace this large loop with a small table of whitespace character ranges. - The patch made this particular test 77% faster, from 850ms to 195ms.
I’ve already filed a bug on another test and will be working through at least four more significant slowdowns. Doing this profiling has been a lot of fun, and a nice change of pace from the garbage collection slog. I really encourage anyone who has a mac to spend a little time with Shark and a performance issue: it actually makes visualizing and analyzing performance problems fun.
Planet Mozilla — Firefox Has Located Your File
This one has potential for alternative captions. If your feeling creative, leave a comment.
Hat Tip: I Can Has Cheezburger
Planet Mozilla — Mozilla Scheduled Maintenance - 09/04/2008, 7pm - 11pm PDT (0200 - 0600 09/05/2008 UTC)
We will have a scheduled maintenance window tonight from 7pm to 11:00pm PDT. The following changes will take place:
- 7:00pm PDT (0200 UTC) addons.mozilla.org DNS change. As part of our CDN trial/test, we’ll be offloading addons.mozilla.org to CDNetworks and pushing a DNS change to make that active. See bug 450745 for details. No downtime is expected.
Please let me know if you have any reason why we should not proceed with this planned maintenance. As always, we aim to keep downtime to as little as possible, but unexpected complications can arise causing longer downtime periods than expected. All systems should be operational by the end of the maintenance window.
Feel free to comment directly if you see issues past the planned downtime.
Planet Mozilla — The vision for SUMO – Part 3: Increasing community participation
In the past, there has been some discussion about how SUMO interfaces with existing local community work. SUMO has been in place for one year now and we have shown many ways where local communities are working directly on support issues for end users. As SUMO grows, we need to be even more efficient as we work together.
SUMO and the local support communities
For many locales, I believe SUMO can really add value to their communities because we can provide things like a solid server infrastructure and an established wiki with a useful review system. But it really doesn’t stop there. SUMO is designed from the ground up to be a platform specialized on support. With the already existing SUMO community, we have shared access to a lot of interesting things, such as an overview of our most critical issues with Firefox, and a way to determine the quality of our content. We also have a pretty close collaboration with the rest of the Mozilla project, such as the amazing QA team. They can provide us with a lot of useful information, and we can do the same thing for them.
How does this relate to the support for your locale? For one thing, it gives you a better overview of what our users are most frequently asking, which helps determining what support content we should focus on. It also gives you the ability to determine the overall quality of your support by looking at things like which articles users find hard to understand. By working more closely with other Mozilla teams like QA and Firefox development, it might also help making your local community feel more involved with the rest of the Mozilla community.
On a more general note, I think we should all think about Mozilla as one united community. The important thing should be the fact that we come together to do all the great things that we do, not on what domain or server our accomplishments take place.
That said, for communities that still prefer to keep their support on their own infrastructure, how can we better promote that content on SUMO? Right now we’re linking to these sites on the “Other Firefox Support” menu item on the start page. Is that enough, or can we do other things to make it easier for our users to get help?
SUMO and Firefox
Another concern some local communities have with SUMO, or at least have had in the past, is its Firefox-centric focus. Readers of my personal blog might have already read my post The scope of SUMO, where I explained the reasons for starting with Firefox, and my thoughts on the project expanding in the future. Let me quote a part of it that I think summarizes it well:
In the future, when Firefox Support is doing really well, I could definitely see the scope being expanded to make the solution work for other Mozilla projects as well (and with the open source nature of the knowledge base and forums, it could even be used by other non-Mozilla projects, just like Bugzilla is used by almost every open-source project out there).
The work we’re doing on SUMO now is there to be done for other projects as well and will come in time. We’re not limiting ourselves to Firefox because we don’t care about the other projects, but because we need to focus on where our resources are needed the most first, and then broaden the scope.
Since that was written, the Thunderbird team has expressed interest in using the SUMO infrastructure to build a similar support site. What this means is that SUMO is not the equivalent of Firefox Support — SUMO really stands for Open Source Support.
How can we make the SUMO community stronger?
Let’s get back to the vision for SUMO. What can we do to strengthen and ignite our already amazing community? Well, an obvious answer would be to just ask the community members, and we’ve obviously done that a lot over the year. I’ve also talked to people at Mozilla closely involved with community building in other projects, to get their feedback. Based on that, we have some ideas to start with:
Understanding the bigger picture
I’ve already covered this in part two of this blog series, but this is definitely very related to building our community. To summarize:
- Work together – Closer collaboration with QA and developers to get a shared understanding of our users.
- Get everyone on the same page – Clear escalation paths for emerging issues that should be handled by other areas of the Mozilla project.
Karma
An online moderation/rating system –- also known as “karma” –- is important for a couple of reasons. First of all, it’s a way to encourage participation and allow contributors to really take pride in their work. How many users have you helped using Live Chat? How many have you helped in the Support Forum?
The other interesting thing a karma system would give us is better knowledge about which contributors are our most valuable. This is very useful information when e.g. surveying contributors about how we can improve the site — before making changes to the Knowledge Base article editor, which contributors have the most experience using it?
Showing more gratitude
What impact does a person writing a Knowledge Base article for SUMO make for fellow Firefox users around the world? The answer is, without a doubt, more than most people think. How can we make that clearer? Some things I’d love to see:
- Make the community more personal – Allow contributors to have a personalized profile with info such as full name, location, photo, and description. Make the people behind SUMO more than just a username.
- Show a photo of each contributor at the bottom of each Knowledge Base article under “Contributors to this article” — if they want to show their picture, that is. Make it more obvious to our readers that the content is written by people just like them!
- Add a plain and simple thank you note where appropriate, for example under “Contributors to this article” at the end of each Knowledge Base article.
A thank you note might seem trivial, but it really highlights some of the fundamental elements of a community: helpfulness, friendliness, and appreciation of each other. We’re not like any typical corporate support division. The motivator here isn’t money — it’s gratitude, appreciation, recognition, and a feeling of belonging to the community that motivate people to make a difference by helping people with Firefox.
SUMO is all about that.
Planet Mozilla — Google Chrome Promoted On Homepage
Google is now promoting Google Chrome on it’s homepage. Just a few days after release. Previously Firefox 2.0 was promoted on the homepage, a privilege normally reserved for Google products. The text link is a bit more subtle though. Maybe that’s because it’s beta and not 2.0.
It’s being shown to Firefox Safari and IE users. Interestingly it’s being shown to Mac users in addition to Windows users, despite no Mac support as of yet.
Planet Mozilla — toirneach éan
I've been recently working on bug 449202:
Get Thunderbird L10N builds working on comm-central. It's been mostly about using KaiRo's existing work for SeaMonkey and s/SeaMonkey/Thunderbird/g in the right places.
Ran into a few more problems, mostly my fault, and some having to do with the way the MoCo build network is setup.
Turns out it's also fairly complex to test this stuff, as the current setup relies on notifiers kicking on changes to the l10n repositories, so triggering a l10n build on purpose is a bit tricky. Instead, it was simpler to just wait for somebody to change something in one of the many l10n repositories and see what happens.
Well, I am happy to report that the first localized build of Thunderbird since the move to Mercurial has been produced and can be downloaded. It's only a single build, and for Windows, but more will follow as the normal churn in l10n repositories will trigger some more.
Then, the fun begins tonight, as the nightly builders should trigger a build of all of Thunderbird supported locales in one go. So, by tomorrow morning, we should have tons (43 locales per platform, to be precise) of new localized builds waiting for us, sweet!
Oh, and in case you had been wondering, the first successfull build is here. I think it's pretty cool that the first locale that successfully build turned out to be ga-IE, so that will explain the topic of this post. Hopefully, somebody from that locale will understand the title (and apologies if I butchered your language, feel free to correct me please)
Planet Mozilla — MobileHCI 2008 tutorials
MobileHCI 2008 is on right now, and Tuesday was the workshop and tutorial day. They've posted the slides for all six introductory tutorials, along with quick abstracts. If you want to leap right in, they are, individually:
- Text input for mobile devices by Scott MacKenzie
- Mobile GUIs and Mobile Visualization by Patrick Baudisch
- Understanding Mobile User Experience by Mirjana Spasojevic
- Context-Aware Communication and Interaction by Albrecht Schmidt
- Haptics, audio output and sensor input in mobile HCI by Stephen Brewster
- Camera-based interaction and interaction with public displays by Michael Rohs
They're all worth flipping through if you're new to and interested in this space.
Planet Mozilla — Language-Based Interfaces, part 3: Report Card for Ubiquity 0.1.1
I believe in tough love for my brain-children. It’s report card time. Let’s see how Ubiquity 0.1.1 holds up to my exacting standards.
For ease of learning, it should:
- Accept input in something very close to the human language I’m already familiar with.
B. It’s cool that I can put the modifiers in any order and use “this” and stuff, but the commands-are-hyphenated-requirement means that I often find myself typing awkward stuff like “add-to-calendar this”, which is not natural at all.
- Give me clues about what commands are available.
C. We’ve got the “command list” command and the context-menu to help people learn commands they don’t already know about, and you might notice a few commands in the suggestion list on your way to the one you want. But judging by the number of requests we get from the community for commands that already exist, I think this is still a major unsolved problem. And that’s just the commands you already have installed — finding out about a command that’s on the web somewhere that you might want is currently nearly impossible. We need a search engine for commands!
- Give me clues about what I can type next.
B. I think the suggestion list does a pretty good job of this — but it will do a lot better when there are more specific nounTypes and better sorting.
- Give me clues about what the current command will do if executed.
A. I think our preview feature pretty much nails this one.
- Give me suggestions about other commands it thinks I might be looking for.
F. Nothing is implemented for this yet, at all. I have some thoughts about how to implement synonyms, which I’ll be explaining in an upcoming post.
- Help me understand what ranges of arguments to a command are valid, and what the arguments mean.
C. The completions from nounTypes, combined with the preview pane, can give you a pretty good idea in some cases. But too many commands are using arbitrary-text arguments instead of more specific noun types. Mostly, we need to implement more noun types, and implement them better. Also, we don’t have a sensible system of defaults for command arguments yet, just a bunch of ad-hockery.
- Propose commands appropriate to my working context or to the type of data I have selected.
D. While this is technically implemented in the form of noun-first completions, the generic arbText commands push the specific stuff off of the bottom due to lack of sorting, so it’s an unusable feature.
For efficiency, it should:
- Allow the user to start with the noun or to start with the verb.
B. This works! But noun-first completion isn’t very useful right now, again, due to lack of sorting.
- Let me autocomplete a partial word with a keystroke.
D. Not implemented yet at all, though I can get some of the same effect by leaving my partially-typed word in place, hitting spacebar, and going on to type the arguments.
- Recognize words even if they’re super-abbreviated.
C. You can abbreviate the verb and most nouns, if you start at the beginning, and usually get the parser to recognize what you want in two or three letters. But you can’t abbreviate starting in the middle, or use a disjoint completion.
- Remember what suggestions I’ve chosen in the past and pop them up next time I give the same input.
F. Not implemented yet at all. I’ve got some ideas for how to do it.
- Let me partially enter something, see the suggestions, choose one as mostly-right, and edit that one some more before executing it.
F. Not implemented yet at all. However, I hope to implement the autocomplete-with-a-keystroke feature (see above) in such a way that it achieves this one too.
- Guess, from my context and my selection, what I want, and fill most of it in for me, while letting me easily override it if it’s wrong.
C. Noun-first completion and interpolation of the selection are a good start. But it will be a lot better once the suggestions are sorted, and once there are a few more magic words, and once interpolation of the selection can automatically go to any argument in the sentence. Ubiquity should be able to guess what I mean from context much more often than it currently does, as I described in this post.
For expressiveness, it should:
- Handle commands with multiple arguments, including optional arguments, that can take various data types.
A. We handle this pretty well! We just need arguments to be able to define defaults and whether they’re optional or not.
- If I have data selected, let me use that selection as an input for any of the multiple arguments — or for none of them.
B. Easy to do this with “this”. Need to make it better at automatically figuring out where the selection should go when there’s multiple arguments, though.
- Let me chain commands together, with the output of one going to the input of the next, like Unix pipes.
C. A very preliminary version of this is implemented as an undocumented feature. Needs a lot more work.
- If my input could mean more than one thing, give me a sensible way to resolve the ambiguity.
C. Suggestion list. It errs on the side of putting too many possible parsings in the suggestion list, though, so potentially useful completions are pushed out by trivia.
- Let me compose a complex command out of small parts, in the flexible way that natural language does.
D. You can’t do it yet, but I think we’re laying the foundation for it. The command chaining is a step in this direction, for instance. The potential is there to do a lot more of this.
- Let me save a complex command that I’ve created and give it a simple name so I can re-use it in the future.
F. Not yet implemented at all.
- Give me an easy way to create my own commands — and to share them with others.
A. I’ve been amazed by the quantity of third-party commands which have appeared and the speed with which they did so. We only launched last week and we already have a thriving third-party development community. What we need most now is a search engine for commands so that people can find what’s out there.
Needs Improvement
Given all that, here are the improvements which I think are most important to make to the parser next:
- Sorting the suggestion list, both by the inherent quality of a match, and by what completions the user has chosen before for similar input.
- Get rid of the hyphenated-command-names!
- Add an autocomplete function, perhaps triggered with the tab key.
- Allow abbreviations to match to the middle of words, not just the beginning. Also allow disjoint abbreviations, such as allowing “yts” to match “youtube-search”.
- Implement synonyms for commands.
Additionally, we need to build that search-engine for commands, which is not technically a parser improvement but will make the Ubiquity as a whole much more usable.
Finally, there’s the internationalization issue. Making the parser easily localizable to various languages is a huge priority, but it deserves a post (or several) of its own, so I’m not going to get into it here.
Coming up next: Anarchy in the namespace, and what to do about it.
Planet Mozilla — Advertising Firefox on Wednesdays
We’ve previously talked about search engine marketing as one of the key marketing efforts here at Mozilla. Those previous analyses have pointed to experiments we’ve performed that helped increase our efficiency by approximately 50% earlier this year (that’s pairing a reduction in total spend with an increase in total clicks). While those are some great gains, we’re always considering additional ways to improve our efficiency, and ultimately the new user’s experience, through this marketing channel.
An example of a potentially untapped area for improvement is day/time parting, i.e., better targeting by day of week or hour of day. Intuitively, it’s easy to imagine that a particular day (e.g., Fridays) or a particular hour (11pm PT) might see a lower price (cost per click) or differing interest among new users (click through rate).
Fortunately, this is a fairly easy hypothesis to test thanks to regression analysis. With our AdWords account, we can grab hourly data and see what variables (e.g., particular hours of the day) cause the price/interest changes mentioned above. Continuing our example, perhaps most advertisers run out of their daily ad budget by the end of day, causing late night hours to see a lessened competitive bidding environment, and consequently, a cheaper cost per click. Regression analysis would be able to tell us exactly that - and tell us that perhaps we should be diverting more resources to such market inefficiencies.
Below is the regression equation and full regression output. We used a recent data set from our primary campaign containing more than 4,300 hours, which equates to about six months worth of data. Clearly our equation could be strengthened in different ways (more instances, more control variables). For example, the results did improve when we substituted the day of week and month variables with a dayofweek*month interaction variable. For any stats fans reading this, we’re open to other suggestions for improving our work (comments encouraged).
Cost per Click = α + β1hour_of_day + β2day_of_week + β3month + ε
Note: hour of day results are relative to the midnight to 1am hour (pacific time), day of week results are relative to Fridays, and month results are relative to April.
So, how do we interpret these results?
- For hour of day, it looks like there’s little inefficiency to be found.
- However, the day of week findings are generally very robust. Tuesdays, Wednesdays and Thursdays are relatively less expensive, and Saturdays and Sundays are relatively more expensive.
- At a macro level, these findings tend to point to a generally efficient market, meaning we likely won’t be changing our marketing decision making based on this information alone.
Planet Mozilla — I (Mozilla) need a Network Engineer
When I started at Mozilla two years ago the biggest challenge was handling a release and pushing very close to 100Mbps. Right around that point the firewalls would fall over. We had one data center and essentially one provider and I could count the number of app servers on my two hands.
That was two years ago. Today’s steady state is around 600Mbps and it’s not uncommon to push closer to 1.5Gbps during a release. We have a growing global presence with four data centers and have enough redundancy built in that it wasn’t any problem to lose one provider this past weekend (well, it was a problem but it wasn’t user impacting).
The environment has grown from a bunch of switches strung together with a mess of cables to an orderly mess of cables and a switching infrastructure that’s allowed us to be more nimble and do more complicated things more easily, often without ever having to physically visit the data center(s). And there are something like 51 app servers.
The network has grown and I need help. I’m looking for someone to join the team and continue to grow and support Mozilla’s network and systems infrastructure (job description is after the jump).
<