The reward for finding eligible security vulnerabilities will increase from $500, and the program extended to cover more Mozilla software
Mozilla, the organization behind the Firefox Web browser, has upped the amount it will pay security researchers for information on security bugs in its products from $500 to $3,000.
The change is part of what Mozilla calls a refresh of its Security Bug Bounty Program, which launched in 2004.
"A lot has changed in the six years since the Mozilla program was announced, and we believe that one of the best ways to keep our users safe is to make it economically sustainable for security researchers to do the right thing when disclosing information," wrote Lucas Adamski, director of security engineering, in a blog post.
Mozilla has also expanded the scope of the reward program, which will continue to apply to Firefox and the Thunderbird email client, and also to the Firefox mobile browser and other services the products rely on. Release and beta products are also eligible.
"These are products we have traditionally paid bounties for in a discretionary basis anyway, but we wanted to make that explicit," Adamski wrote.
Mozilla can deny a reward to a researcher, however, if the organization deems the person has not acted in the best interests of users, Adamski wrote.
Other parts of the program will be retained, however. A reward will still be paid even if a researcher has published information on the vulnerability or if the researcher doesn't have time to work closely with Mozilla's security team.
Sure, Firefox 4's new Chrome-like UI is nice, but the real story is under the hood
While it's impossible to sum up the thousands of enhancements and bug fixes both big and small, the Firefox 4 beta version brings the browser that much closer to taking over everything on the desktop. There are fewer reasons for anyone to interact with an extra plug-in or the operating system. Remember when people cared about whether a machine was Windows or Mac or a Commodore 64? Remember when software needed to be written in native code? Those days are fading away quickly as the browser is more able than ever before to deliver most of the content we might want.
You've no doubt heard about or even seen Firefox 4's new Chrome-like interface. More important are the many new features generally lumped together under the catchall standard HTML5, a specification that's still a draft but has become more of a rallying cry for AJAX, JavaScript, endless tags, and life beyond plug-ins. [ Also on InfoWorld: HTML5 will spawn richer, more sophisticated websites while also easing development. Read about the nine ways HTML5's impact will be felt in "How HTML5 will change the Web." Learn how to take advantage of HTML5 in "What to expect from HTML5." ]
Many of the enticing new features open up new opportunities for AJAX and JavaScript programmers to add more razzle-dazzle and catch up with Adobe Flash, Adobe AIR, Microsoft Silverlight, and other plug-ins. The CSS transitions, still "partially supported" in Firefox 4 Beta 1, give programmers the chance to set up one model for changing the CSS parameters without writing a separate JavaScript function to do it. The browser just fades and tweaks the CSS parameters over time.
There are plenty of other little parts of HTML5 that have been slowly arriving in previous versions of Firefox but are now being more fully integerated. MathML and SVG data are now a bit easier to mix right in with old-fashioned text. The Canvas and optional WebGL layers can create custom images at the browser without waiting for a server to deliver a GIF. A handful of new tags like and offer a more document-centric approach, so the browser can present information more like the data on the printed page. The tag can be matched with a tag and the browser will keep the two together and try to put the results near the tag.
These are just some of the options that programmers can use to add more zip to static text. Firefox 4 also adds an implementation of the Websockets API, a tool for enabling the browser and the server to pass data back and forth as needed, making it unnecessary for the browser to keep asking the server if there's anything new to report. If there's a need to store some of this data locally, the JavaScript programmer now gets access to indexed databases. They're not exactly flat files, but they're useful if you want to store and index name/value pairs data.
Converting this information to the HTML tags is becoming more fluid. The Mozilla release notes, for instance, brag that Firefox 4's parser is 20 percent faster at interpreting the innerHTML calls generated by dynamic JavaScript. The frames are supposedly going to be evaluated in a lazy manner so that the page resembles its final form a bit sooner. And now plug-ins are running in separate threads, offering so-called Crash Protection against glitches.
Some of this is clearly paying off. Firefox 4 Beta 1 scored 3,573 on the Peacekeeper benchmark, much better than 2,470, the score produced by Firefox 3.6.4 on the same machine. These values, though, still lag behind the competition. Other browsers, including Chrome, Opera, and Safari, score between 5,000 and 7,000. There is a similar gap in the JavaScript-centric SunSpider benchmarks: 970ms for Firefox 4 Beta 1 versus 750ms for Chrome.
Are these differences notable during normal browsing? Not really. I felt like the latency of the Internet was the real bottleneck, not whether some complicated JavaScript loop was finishing 10 percent faster; after all, I don't see many complicated loops on the Web pages I visit. Most JavaScript does little more than dutifully fetch information and render it. The amount of memory in the computer is probably a bigger killjoy than the measured speed. Version 4.0 is just a beta, of course, and the best JavaScript engine still isn't included yet. Mozilla's release notes say that a better JIT (Just In Time) compiler for JavaScript and layered rendering engine are "coming soon."
There are areas in which Firefox still leads. Firefox's collection of extensions and plug-ins is still broader and more developed than any other. Firefox 4 nurtures this advantage by making it possible to turn the different extensions on and off without restarting. Firefox is also taking the lead by implementing Google's WebM video standard, a wise decision given that Firefox is largely supported by ad revenue from the Google search box. Chrome's own support for WebM is found through the early release version, but that should change soon.
Many people may come away from this beta feeling that Firefox is still catching up with the other browsers. The speed doesn't leapfrog the competition. The tabs are now arranged across the top of the window more like Chrome. Some of the buttons feel just like Opera's versions. It's clearly a competitive market these days, and the best innovations are quickly copied. The browser programmers are taking the best from each other, and this is competition at its finest.
Google's Chrome uses gimmicks to make it seem fast at startup, says designer
An interface designer interning at Mozilla has suggested that the company mimic gimmicks in Google's Chrome to make users think Firefox starts up faster. In an entry on his personal blog that was reposted to Mozilla's uber-blog, Planet Mozilla, John Wayne Hill, an Indiana University masters student interning this summer at the open-source company, spelled out changes that would give users the feeling that Firefox starts quicker. "Firefox is fast, no doubt about it. But for many people it feels pretty slow when starting up," said Hill, who is studying human-computer interaction and design. "Chrome, while only marginally faster than Firefox at starting, feels much faster. By analyzing videos of these start-up processes we can start to understand what makes Firefox feel slow." Along with Alex Faaborg, a Firefox principal designer, Hill put Firefox and Chrome through speed trials that showed Google's browser finished most start-up tasks milliseconds faster than Firefox, in some cases because the former skipped steps. Hill then compared how both browsers handled specific start-up tasks or informed users of start-up progress. For example, while Chrome simultaneously draws both the browser window and its "chrome," or interface, before rendering the opening Web site, Firefox does each of the three tasks separately and sequentially. "Chrome seems to do everything at once [which] allows Chrome to feel fast because once the window is [drawn], everything is pretty much ready to go," Hill said. Google's browser also uses a smaller page loading indicator -- the animated circle at the left side of each Chrome tab -- while Firefox splashes the word "Loading" across the entire tab. "This is visually 'bloated' and makes Firefox seem slower," Hill said. "Furthermore, because Chrome's loading icon animation goes 'around' faster, Firefox's loading icon takes more time (seemingly) to get 'around.'" Other pluses for Chrome include its practice of displaying the page title only when the site has been drawn, whereas Firefox fills in the title as a page renders. "This is a simple trick that allows Chrome to feel faster in that once the title is shown, the page is ready," Hill pointed out. "In Firefox, a page's title makes it seem like a page has loaded but in fact the page isn't ready to be interacted with quite yet and [so] the user has to 'wait longer.'" To better compete with Chrome on perceived startup speed, Hill recommended that Firefox copy some of Google's tricks, including drawing the browser window and chrome at the same time, not sequentially; reduce the "visual weight" of the page loading icon and animate it faster; and delay displaying the page's title until the site has loaded and can be used. He also suggested that Mozilla update Firefox when the user closes the browser, not when it's first opened, as is currently the case. "With just a few changes in the Firefox start-up process, we could greatly enhance the feeling of Firefox's speed," Hill argued. Mozilla has already devoted resources to reducing Firefox's actual startup time, as opposed to Hill's suggestions to give users the illusion of speed. The startup team publishes gains-losses metrics weekly on the Mozilla site, and blogs about its progress almost as frequently. Firefox has long been bashed as sluggish compared to Chrome and other rivals, with various benchmarks used to illustrate Firefox's lethargy. (In fact, the Mozilla-maintained "Are We Fast Yet" site that monitors the progress of its work on boosting Firefox's JavaScript speeds shows Chrome and Safari far faster.)
