Lair of the Wolf

This past Monday marked the release of the Mozilla Firefox 0.8 web browser. It features a new change from Firebird to Firefox and a lot of changes since 0.7. To find out more and to download, go here.

I can only describe the aftermath of that announcement as a flood of people hitting the mozilla.org and the other related servers of mozillazine.org, mozdev.org and texturizer.net, which hosts the Firefox Help site.

Mozilla.org hit a bandwidth high of using 24.4Mb/s and was partially unavailable for a bit, because of the flow of traffic, but returned quickly and responded very well under such an intense load. MozillaZine.org also suffered slowness under the load, having to disable the Forums to get the site responsive. Texturizer.net went down entirely, and Mozdev.org as of this writing is just coming back, but is still slow.

I've been recently paying more attention to the extensions-side of the Firefox project. Mozilla.org does not maintain a website for extensions, as most are third-party developed. A lot of extensions are mozdev.org projects, and the MozillaZine forums provide some user-to-user support for help and troubleshooting. There are two sources that are trusted, in general for Extensions; they are Firefox Help's Extensions page and The Extension Room. Both sites use the same database of extensions maintained by the MozDev database project. During the release, and even before that, stuff that needed improving had been coming to me, with the way that Extension Room itself is laid out and works. I pick Extension Room to discuss specifically here, because it hosts extensions for all Mozilla products that support them (Mozilla Suite, Firefox and Thunderbird). It's a good concept, but it really needs a lot of changes to make it more usable for visitors.

The most critical of which is that neither site seems to be truly reliable. Especially during releases, when the servers they're on get loaded with traffic, and become unavailable. This is to be expected to a point given the increasing popularity of the releases, but is not really acceptable when it comes to trying to serve people with add-ons to the new product. It passes a feeling of unreliability on the availability of extensions to the user. Both Firefox Help and Extension Room both have been down a lot, during the release. Though, Firefox help is down by choice, as far as hosting extensions go, to focus on the help content and keep the server, which is private, and has a corporate website also hosted on it, operational. One problem which has been an issue with the Firefox Help Extensions page in the last month was a problem with syndicating the database to texturizer.net for Firefox extensions. The database would be incompletely transferred, breaking it entirely, or listing only half of the extensions. Though, this has not occurred in the last couple of weeks. Extension Room has also had some database-related downtime, because of errors with human-error in entry to the database.

The other issues I've found are usability issues, with the sites. Starting with the most serious, and more or less going to least important'

Extensions Listed on Extension Room are not really marked as being compatible with a new version of Firefox. This has created problems and some confusion for new Firefox 0.8 users recently, who expected any of the extensions on the list to be 0.8 compatible, because nothing said otherwise. The site assumes that the listed extensions are current, and does not have a maximum version they're verified as being compatible with listed. They list the fact that the extension is for Firefox, and in some cases starting and ending dates for which builds it works with, but those cases are few. This is misleading, users assume that because the site says it works with Firefox that it works with all versions, and most are quite surprised when they have problems. Rather than assuming the max version, it should be defined, the current version it works with when the extension was added, as it's better to assume it may break in the next release than to assume it works. Testing the extension with the newer release, once the code freezes for the release, would enable someone to update the information for the extensions with either a works (Verified) or a doesn't work (Incompatible), for the newest release prior to it's release date. Any extensions that remain untested should show that state (Untested). and not be listed by default, but it should be possible to find a list of such extensions, fairly easily, since they do need testing by more experienced end-users, who are capable of dealing with problems if they're incompatible, and reporting back that information, and to bury them would create a wasteland of lost extensions, after each release. The default state for a new release for all existing extensions should be Untested, unless otherwise noted, as it's possible for nobody to have time to do such testing, and defaulting to incompatible make that state more ambiguous by creating a degree of doubt, is this extension actually in incompatible, or just untested? This three-state system makes it very obvious to the end-user if an extension is or isn't going to work. Though the middle state, untested, is still ambiguous, and encourages testing prior to a release. It also allows for expandability, for other states, such as certified extensions, in the future. As for the UI for the website for a list broken down like this, the page should auto-determine the version the visitor is visiting with, and present them with the list of verified extensions for that version of that product. With links to also view the other states for that version of the product, keeping a clean layout, so that the extensions on the page, are what's emphasized, and not the links.

The next problem, which has been recently improved, with Extension Room specifically, is by being verbose and trying to give as much information about the extensions as possible, the page is way too large, and took too long to load especially on dial-up connections, as the page was 250k to load, before images. Now the page is not verbose enough, furthering the problems with point 1 above and gives a short description and extension title only, though it is grouped by category. In order to get any more detail you have to click the name of the extension and go on to the 'more-info' page. One extreme is as bad as the other. In theory, at a glance you should be able to see the Extensions Title, Date, Version, and Compatibility info (or at least the simple version of it for the version of whatever product you're viewing), more info and download/install links. The other flaw with page size is the fact that the page attempted to show the entire list on one page, which is not feasible by any means, once the list gets above a certain size. To make such a list viewable by the most clients, is has to support the ability to customize the number of extensions per page, depending on the total number, anywhere from 5 to 20 per page should do it, to allow sufficient customization for dial-up to broadband users.

The last point is subject to debate, though some users might find it useable, and that would be the ability to sort the extensions in multiple methods, specifically by name, category, and date (newest to oldest), with the default being by name, as people looking for a specific extension are most likely to find what they want quickly, and those casually browsing won't be hindered by the organization. Given a good placement, such options should not over-complicate the interface and make it cumbersome, in my opinion. Though if such options aren't feasible while maintaining a clean user-interface, then they should be dropped in favor of the default alpha order.

Overall, the user-interface of the site should be clean, with good graphics and an emphasis on the content, while not being hard to use, the placement of links being where they're easily accessible from a usability standpoint.

A point that may be a problem with the first point above, that I'm thinking now, the auto-detection of the browser that's being used, may create problems for people hoping to just download the extensions in one place and install them on another machine. Particularly if that machine is running a different version of the product. Also, this would apply to Thunderbird users, who don't qualify under auto-detection, for obvious reasons, therefore, there'd have to be some way to be able to generate such a list from user-selected product/version values as well. Such items may be more likely to complicate the interface, but unfortunately, are most likely required.

My last idea for how to improve the way extensions are handled from the website is a feature similar to the PHP project's my php.net page, where most of UE settings are storable as cookies in the browser. That way a user could customize their view of the extensions pages to suit their preferences and store them. So they don't have to customize that view every visit like with some sites of a similar nature. Options such as sort order, extensions per page, and other customizable options in the final layout, should have an option to be set permanently, to make it useable quickly. For those cases where the defaults don't work for the user, such as a broadband user who prefers more than 5 extensions per page, while the default shouldn't be higher than say 10, else making it difficult for dial-up users, such a page would solve the problem.

With these issues addressed, I'd say that an Extension website would be much more useful to the new and current users of Mozilla products, and considering the growing emphasis on extensions with Mozilla Firefox and Thunderbird over the Mozilla Suite, the issue of lacking a good usable site grows.

Well, this has to be the weirdest bug I've been apart of. It's Bug 249787 which is about update.mozilla.org not being browsable in Internet Explorer. Strangely enough though, it's a blocking-aviary1.0RC1+ bug.. Go figure. Guess I can't say I have no blocking bugs anymore.

Mozilla.org launched its new look.. which I must say is a big improvement over the previous. So congrats to Steven Garrity / silverorange and all the people who took part in that.

Update.Mozilla.org Update
Many people have expressed alot of views, to put it diplomatically over update.mozilla.org's current state. So, briefly i'm going to try to address some of the comments I've seen.

(1) Update's look/design sucks. (or doesn't match moz.org etc.). I'm working on a new style for the site, based on the cavendish theme by Steven Garrity that was just launched for mozilla.org and Planet Mozilla. I hope to address alot of the site inconsistencies at the same time. So far, its looking pretty good. I'll post some screenshots here when it's closer to being done. There may also be a beta period for it for testing before it goes live.

(2) Search! Yes! Update is getting a search feature. It will most likely be Winamp.com like, and let you search extensions or themes *seperately* though. Since combining the two is impractical.

(3) Theme Previews?!? The theme preview bustage that currently exists will be going away. I'm also going to try to expand the preview system to extensions and let multiple previews (the first of which, must be the one on the list.) be added.

(4) Developers Adding their Own Extensions. No it's not a myth. The functionality exists, and will be finished and finally brought online.

All of that work will be completed by September 20th (for Firefox 1.0RC1). Just because it's not on the list above, doesn't mean it won't get done. If you have a specific feature or bug you want to know the status on. You can e-mail me directly or leave a comment in my blog. :-)

Update.mozilla.org is currently managed by a small group of editors, they handle the everyday operations, including, most importantly, adding/updating new extension and themes as they're released and we get notification of them via bugzilla. Due to life constraints though, these relatively few editors, there's 4 plus myself, are currently unable to handle the load of extensions/themes, so updates are suffering.

We're on the edge of a Firefox release, which makes this situation particularly bad. So I'm calling for some help from the Mozilla community.

This is the list of bugs that need attention, Mozilla Update: New/Updated Items as well as anything added to Bug 264603. They had been reassigned to a new editor who volunteered to help out, but unfortunately, in a bit of a bad karma situation, he's unable to volunteer for a few weeks.

Basically what needs to happen is this:
- The new versions of each (probably near the bottom of the comments for each bug) need to be tested on the newest version of the application (probably Firefox or Thunderbird) that they're compatible with, if that's 1.0, then the latest 1.0RC1 nightly, if it's only 1.0PR then the 1.0PR release.
- Extensions: Test and make sure they install and uninstall ok, and that they add chrome to the browser UI that looks like it'll do what the author says it will, and that the browser still works.
- Themes: Test that they install/uninstall ok and are complete, I.E. have all the icons like Software Update and LiveBookmarks and that they don't break the browser.

If they work, comment in the bug, and say you've tested it, and if it works or not and the User_Agent of the browser (or Thunderbird version/buildid) you tested with. (include the OS). (If you have editbugs permissions, add tested+ to the status whiteboard)

Once they're marked as having been sucessfully tested, adding them doesn't take alot of time, and I'll be able to add them and approve them so they'll be available for the 1.0RC1 users. :-)

Thanks in advance to anybody who helps out and tests these.

So, those of you who watch bugzilla closely have definitely noticed alot of changes lately. The new Core, Toolkit and Mozilla App Suite products for example, and alot of moving bugs.

Update has also moved, from a pairing of two components in Webtools and Mozilla.org it is now its own Product "Update".
For those filing bugs, this might be a bit confusing, as Update's now broken up into 4 components, "Administration", "Listings", "Developers", and "Web Site"

Administration deals with user account troubles and just general site admin issues that don't seem to fit elsewhere.

"Listings" is the most obvious, it's for Extension/Theme bugs for changes to their listings, problems with them or new ones/updated ones. This is the component where we need the most help from the community, getting the bugs filed here QA'd, the items tested, so the editors can upload them, hopefully, pretty quickly.

"Developers" is for the Developer Control Panel, I've seen speculation of if it exists at all. It does. :-) but it's a core part of update-beta, and can't be used with the existing site. Most bugs here will be filed by the current editors, until update-beta goes live, then authors will be also filing.

Everything else about the visitor facing website, "Web Site" covers. but this isn't for listing bugs, even if there's an SQL error. :-)

Hopefully this new product will help us orginize better and grow easier.

and for those of you hoping I'll mention update-beta again in this entry, it's coming...

Meet Netscape Browser...

Now that you've been scared by the initial look... I'll give you a minute to recover and visit the bathroom if needed.........

Supposedly this is based on Firefox 0.9.3, which IMO was the worst Firefox milestone, pre-release or not. Though you can't tell that Firefox is burried in there, behind the UI clutter. Absolutely everything has a option. Including closing a tab. (The tab bar context menu is 13 options.) What's worse, you can select an "Display Like Internet Explorer" mode, which embeds IE in the browser. In place of Gecko. So you get the standards non-compliance *plus* all the security issues you might've been wanting to get away from.

BetaNews has more information about the Netscape Browser Prototype.
Henrik Gemal has posted some more screenshots of the horror on his blog.

Update: MozillaZine has an in-depth review of the new prototype.

Well, its obvious by now, things haven't exactly gone as planned with Mozilla Update Beta. While it's online, it's not exactly operating as designed, with new submissions/updates having not been processed for one month now. This, of course, rumors of a situation or conflict within Mozilla Update, Its even been on MozillaZine, though in a rather surprising and unexpected way. In this post, I'm going to try to explain what happened, with as little bias as possible with regard to the events.

For the record, I'm no longer the module owner of Mozilla Update, as of January 16, 2005. That role now belongs to Scott Kveton. With the way rumors go around Mozilla, I should say this up front, I wasn't forced out or anything of the sort. I've chosen to step down from that role because of time, mostly, along with an increasing lack of motivation to remain owner of the code. The project's growing size requires quite a bit of time to manage, which is something I don't have anymore, my life situation changed quite a bit since I started working on it almost a year ago. Also, Hendikins is no longer working on the project either, he was co-administrator and spent *alot* of time pruning the comments section for spam, contributing alot to the increasing accuracy of the ratings.

In November, after the Firefox 1.0 release, there was a meeting held about the status of Update-beta, which was originally planned, but never really scheduled (in fact, it was opposed by Mozilla QA) to launch for Firefox 1.0. At that meeting, the general plan was for a release the second week of December. There was also discussion of QA, and several bugs were filed. My understanding was QA would begin testing update-beta.mozilla.org, as evidenced by bugs that got filed, etc.
Unfortunately, communication didn't maintain at this good level for December, because of both mistakes made by myself, as well as mozilla.org. In the absense of good communication, I operated based on my own assumptions and information about the December time-table, expecting formal QA plus community members to be testing update-beta as they'd test a nightly release of Firefox, the development pace wasn't that ambitious. All of the big changes were complete, and the update-beta site was open for testing, many authors were testing the functionality and many bugs, although most of them minor, were reported.
Several days before update-beta launched, the database and backend were migrated to the new site, so that new submissions would be processed by the new code, this froze update.mozilla.org in favor of update-beta.mozilla.org, and allowed the admins/editors and authors to use the new code to find any major showstoppers.
With a rather sucky turn of events, it was much closer to the Christmas holiday than I would've liked, with the positive feedback and already overdue 2nd week of December launch date hanging around, along with my desire not to keep update.mozilla.org frozen any longer than it had to be from new arrivals (if I knew then what I know now. heh), I chose, failing to ensure mozilla.org was ok with the idea, but also without any feedback about what the status of update-beta in their view was, to launch update-beta late on December 23rd.

In short, this action would prove bad very quickly. 2 security bugs were found within the first 24 hours in the Developer backend. Neither of these bugs affected author-level access, only editors. The first, was in the user manager, which would accidentally erase all admins/editors if used by an editor (Bug 275904), the other, allowed an editor to create an admin account (Bug 275905). Now, while these are serious bugs, they're not critical for 2 reasons, (1) Mozilla Update has no editors that are untrusted, and (2) All Editors for Mozilla Update were admins less than 24 hours before. Meaning, that they wouldn't get any privledges from Bug 275905 that they wouldn't have had before anyway, and they were perfectly trustable and could've been bumped to admin status to workaround Bug 275904. Situation contained right? Wrong.

That action wasn't taken, instead, in an alarmist move by mozilla.org, they locked permissions on the server, and disabled (403 Forbidden) any script that touched the DB, including the entire DeveloperCP (including Admin access) as well as comments/ratings. At this point, the only thing that gets updated is downloadcounts, presumably because it appeared to critical to mangle.
Now, I can understand the alarmist handling, the holidays leaves them without the full staff, and I wasn't available all day on the 24th/25th, but, it also says there was a complete ignorance of how Mozilla Update operated within mozilla.org.

Now, a month later, the situation is unchanged, as far as end-users are concerned. The site remains closed to new additions and the only note about any of this is this revised disclaimer on the front page.
"Please note that the Mozilla Update site is undergoing a design update and a rewrite based on user input." The security bugs found have been long fixed, even thoguh I'm told that mozilla.org hasn't blessed the patches to land on the live site. Why not? If they were worth closing the site for, arent' they worth landing?

Security of UMO is a phrase that's being thrown around quite a bit as the excuse for why its remained in a stagnate state for a month. In fact, there's a security audit in progress, or will be soon if it isn't underway already. Hopefully the completion of that audit will calm some nerves and find remaining issues that haven't been found in Update 1.x already. Though its certainly not a good excuse for keeping Update 1.0 disabled while Update 0.9 was allowed to function normally. Update 1.0 closes many security issues known at the time to be 100% exploitable in Update 0.9.
A short list of fixed security bugs in update 1.0: (of varying size, the SQL Injection and CSRF bugs are quite large patches, IIRC)
Bug 247318 Prevent cross-site request forgery
Bug 250596 URL parameters not cleaned
Bug 256972 SQL injection all over update php code
Bug 257516 Disclosure of author's email address

So, while I'm not going to argue for the DevCP to be opened to be public, if they're afraid of it. Comments/Ratings should be openable, particularly with the SQL Injection bug in it fixed. DevCP can also be open to trusted users, just as it was with update 0.9, the code is certainly no worse, and is quite a bit more usable.
The current situation has left authors and users without official updates for a month, which breaks Firefox 1.0's extension update mechanism that end-users expect to function in the 1.0 version of the product. It prevents authors from distributing updates (even security updates) to their extensions/themes.

In my opinion, this situation is unacceptable. and shouldn't have been allowed to blossom into an update freeze for a month. There's no good excuse for it. Admins/Editors could be allowed to push items through, if the server restrictions were changed. If they're waiting for the Developer CP to be trustable to allow updates at all again, then there's a real obvious answer, editor laziness, because the only thing a fully-open Developer CP gives them (which presumably is coming with Update 1.0.1/1.1, whichever they're calling it), that a restricted to trusted-users only one doesn't, is author-added items, which is less work on the editors. Which means, that not only does Mozilla Update need a security audit, it needs a check of its staff.
They've also dropped the ball by not telling any of this to authors. There's been no official announcement to authors as to why their items have not been touched in the bugs that were pending, or that Mozilla Update is closed to new listings (in fact, all changes to any listing. heh)

So, in closing, I accept my responsibilty to what happened with regard to my failing to maintain communication, and while I'm still going to volunteer with Mozilla, I'm not likely to spend much time with Update anymore, except for questions/support where needed.

Though I'm also going to call on the Update team to be more transparent with what's going on with the community who supports it. Mozilla Update isn't the only source for extensions, just because it's linked with Firefox/Thunderbird makes it the most obvious, but trust is earned, and is not automatic. Never telling authors who you depend on for listings what's going on, isn't going to get you anywhere, and neither is claiming you're redesiging based on user input. (Particularly when the sites largest form of user feedback is 403 Forbidden.)
Remember, Mozilla Update has a target audience, just like Firefox does. That audience isn't its developers, or its Admin/Editor staff, never has been. It should not be the Mozilla Foundation or MF Sysadmins either, Its the end-users of the site, who are its target audience, most of them are Firefox or Thunderbird users, and Mozilla Update plays an important role in the success of both of those products.
Its time to publish an announcement to MozillaZine (and MozillaNews or anywhere else it should be seen), no matter how unpopular, as to what's going on, what it means to end-users (that they're not getting updates) and authors (that they can't make any) and when both groups of users of Firefox can expect to have the situation restored.

I've made a few changes to firebot, the IRC bot that gives bugzilla bug information for Devs/QA/users in #firefox and #thunderbird tonight.

* Added kick handling, auto-rejoins channel when kicked.
* Added invite handling, bot can join a channel when invited.
* Added ping to test if hte bot is alive. just say firebot: ping
* Added per-channel op lists. in addition to the global list, so
* cleaned up a few hacks I threw into an otherwise clean codebase, restoring channel op speed to original.
* Attempt #2 to fix the ping-out and never reconnect bug.

Still to do, is to fix the milestone status reports to be cross-product and available in a /msg instead of in channel, then they can be enabled again. :-)

Well, irc.mozilla.org now has services, thanks to the work of Stuart.

I'm not particularly a IRC services champion, but so far, it appears that with little effort on my part, the status quo is maintained and I don't have to change any behavior on my part. (register nick, register channel, add identify command to chatzilla on startup.)

The bots were another matter though, wolfbot got a new module enabled (ServicesLogin) which works nicely with a single command to configure. Firebot, on the other hand, needed new code so he'd /msg nickserv on startup.

Though, now that firebot/wolfbot aren't needed for channel op help anymore (firebot helped out with keeping docbot +o'ed, and wolfbot did similarly to firebot in other places), I'm wondering about the practicality of keeping 2 bots running 24/7. Firebot's primary goal is Bug status announcements (for #firefox, #thunderbird and #wolfbot.), and wolfbot's is informational, RDF announcements in #spreadfirefox, tinderbox in #firefox/#thunderbird, bugzilla in #wolfbot, etc. Neither goal requires a fully dedicated bot, so I'm thinking about merging the two bots into one. They'd be more manageable, and less channel clutter. Most likely, that'd require porting firebot to be a mozbot module, bzbot.bm, and then enabling that in wolfbot (which i'd rename firebot.). I'm sure there'll be some major reason why this won't work, but its worth a shot.

In my last blog post about the bots, I mentioned combining them into one bot. Well, as of a few days ago, this is now done. :-) So I thought I'd blog a follow-up post about it, before moving on to more interesting things. It wasn't exactly easy because of my inexperience with perl, but the new firebot seems to work decently.

If anybody wants the BotModule they can grab bzbot.bm here... Its pretty rough in places, but it works.

In addition to adding the new module, I also applied the patch from Bug 248450 to give firebot SSL support, and made him set his unmode +B so the server knows he's a bot. His /whois can't get much longer. heh.

Lastly, anybody looking for /just/ the Firefox/Tbird, etc Bug Info, and don't want to be in #firefox/#thunderbird and get confused with all the support,etc discussion. Feel free to join #firebot (formerly #wolfbot).

This past January I got one of the Firefox plush toys from the Mozilla Store. (though it took awhile to show up. :-/) I finally got around to taking a few photos of the little guy. The first shot being of his head from the front, and the second being a profile shot showing his rather large tail from the side. His tail is actually longer than his body which is about 9". After seeing this guy stuffed and the photos, I'd like to see one of these guys for real. :-)

Well, no software is perfect. So today saw alot of activity regarding a newly publicized exploit in Firefox 1.0.3. The exploit is a combination of several flaws, which make it appear that a software install comes from addons.update.mozilla.org, then another flaw in the iconURL paramter of installTrigger that JS can be inserted into, which runs with chrome privledges.

So, in an effort to mitigate the effects of this problem, the Update team and the Mozilla Foundation have redirected Mozilla Update to do-not-add.mozilla.org, which is outside the whitelist, and therefore can't install software (and blogs the installTrigger.install JS call).

Only one problem...
From the top of Mozilla Update...

"To address security concerns, we have made a number of changes, including temporarily changing the URL for this site. If prompted, please DO NOT add this new URL (do-not-add.mozilla.org) to your Allowed Sites or White List."

Umm, this is not only inexcusably vague, its basically misleading. End-users greeted by this message don't know what the security concern is, what to do, if its with the website or the Firefox browser, or anything...

From MozillaZine:
"I'm sorry if I'm coming off a little thick here but could someone please explain in plain english what the problem is. I downloaded an update for one of my extensions through the automatic extension updater today before I saw anything was going on. How can I tell if I downloaded this exploit and how do I get rid of it. Turning off Java just isn't practical though I have turned it off for now. Please any and help would be appreciated. Thanks in advance."

Mozilla Update operates on the basis of trust, between the users and the site, and the people/organization that operates it. I feel the vague security warning at the top, makes people question if Update is safe to use at all, and in the lack of any information regarding a Firefox flaw, the attempt to actually protect users, is hurting Update at the same time it helps it and Firefox both.

So, the warning on Mozilla Update really needs to be changed to not confuse the users hitting that site that are completely unaware of the flaw. Be clear that the changes are attempting to address the vulnerablity, as a workaround, to make them safer. and that the Update website was not compromised. Failure to explicitly mention details and rely on the user to find them on their own, is very likely to end up with the user just making uninformed and blind assumptions.

On a slightly different, but related note, (which should be in a seperate post, but I don't much feel like doing two posts tonight.) I really am starting to hate all the hype about Firefox security. Firefox is a secure browser, only because Mozilla.org puts effort into patching flaws that are found quickly, and in general, design considerations take security into account. Firefox is most certainly not a security utopia though. It seems like Firefox advocates, in their effort to make the case that Firefox is more secure than Internet Explorer, a topic which is very likely to convince people to switch browsers on, have over-hyped Firefox's security. To the point where people expect Firefox never to have a flaw. This is now starting to generate alot of bad press for Firefox, by over-eager reporters wanting to find the smoking gun in Firefox that brings it into the same field as IE. It makes even fairly minor security flaws have the same weight as every one of IE's usually much more critical flaws. Basically, allowing Microsoft to get off the hook with having to be accountable for their security problems. By being able to say, "look over there at the "more secure" Firefox browser, it has flaws too." Its fine and useful to use Firefox's security as a "selling" point for the browser, but try to keep it realistic. So when flaws are discovered and patched, you can use Mozilla's responsiveness to support the product, instead of having to defend it from overblown criticism because it had a flaw.

So, what else is new that I haven't blogged about...

I've *finally* added the music section to my website. Its nothing spectacular, but I've been meaning to add it for months, if not over a year. Its a combination of a list of artists that I like that came to mind while writing plus the music category blog posts. Which I think serves as a good foundation for the section, and its existance adds a little more of me into the site.

Oh yeah, and finally Deer Park 1.1 Alpha 1 (or Firefox 1.1 Developer Preview Release Alpha 1) was released. I'm personally hoping the agressive scheduling for Firefox 1.1 final doesn't slip, but this is Mozilla, so, the chances of that happening, aren't high, but I can dream.

This quote from the new irc.mozilla.org quote database fits. :-)

Dedicated to the victims of Hurricane Katrina, The men and women of the military fighting overseas in Iraq and Afghanistan, and to anyone suffering around the world. You're not alone.

From http://www.mozillazine.org/talkback.html?article=7479:

"The Mozilla Foundation's community marketing site Spread Firefox has been hacked for the second time in less than three months. According to an email sent to registered users of the site, unknown remote attackers exploited a vulnerability in the TWiki wiki software, which was installed on the server but not actually used by the public website. The TWiki software has now been disabled. The Spread Firefox Team does not believe that any sensitive data was taken but they have shut down the site as a precaution. Only Spread Firefox was affected by the security breach; no other Mozilla Foundation or Mozilla Corporation sites have been hacked and the flaw does not affect users of Mozilla software."

This is what happens when you have a website run by people who do their own thing entirely, who obviously don't pay enough attention to keeping things up to date, without keeping the mozilla system administrators in the loop, and to think, the new version of SFX is being done behind closed doors with limited community interaction. This should send plenty of messages of safety about a site that's already been hacked twice, that they're still not being open, and as a result, its the only mozilla site to be hacked. I think its time that the Mozilla Foundation/Corporation take some responsibility for what happens with SpreadFirefox.com.

Personally, I'm no longer comfortable with the way SpreadFirefox is maintained. I don't believe its admins are doing an acceptable job. (This is seperate from the Mozilla Sysadmins, who are doing the best they can) I'd like to see SFX have the ability for users to delete their account. Since obviously they're not safe. Might also make the number of accounts more realistic.

I also find it interesting, that Asa, spreadfirefox admin and frequent mozilla blogger, fails to mention on his blog at all either hacking. :-) Guess the only mozilla news is good news.

From the SpreadFirefox Account page:
"The e-mail address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by e-mail."

So, how then, did I get an e-mail from "Spread Firefox team [asa@mozilla.org]" that had nothing to do with any of the above? This email is about the Firefox Flicks campaign. This is spam.

Echoing some of the points made here. http://nitin.wlkr.net/mozings/2006/02/spreadfirefox_spams.html

· There's no options in SpreadFirefox's e-mail options that deal with promotional e-mail.
· There's no way to cancel a SFX account, still.
· The unsubscribe link points to http://mozilla.cmail1.com, and not anything @spreadfirefox. Who I might (kinda) trust.

And two new points:
· The message has a bad plain text-component so that you have to follow a link to read it.
· The email contains a webbug at the end of it:

<img src="http://mozilla.cmail1.com/.aspx/o/----------unique id ------------/o.gif" width="1" height="1" border="0">

Both techniques are usually emplyed only by spammers. (In fact, Thunderbird even flagged the message as an e-mail scam. Ironic?)

I'd like to call on the Mozilla Foundation (which, to my knowledge is who provides support for SpreadFirefox and not the Corporation) as well as Asa Dotzler who's email address is personally on the spam in question, to take responsibility for spamming SpreadFirefox members.

Yes, I know, I'm late to the game.. and out of practice at blogging these days. Just wanted to get my own opinion out, since self-expression makes me feel all fuzzy....

So, yay, now we apparently have Icedove and IceWeasel (which for the sake of being anal and annoying must have a capital W in it. otherwise, hey, somebody might not realize what they're reading.) Sure, its completely free, as in freedom software. but then again, so is Bon Echo. (Firefox without the --enable-official-branding switch, you know, the thing Debian broke to make their problem worse).
The big problem here, isn't trademarks or patches, its a battle of egos. Mozilla (the Corporation, enforcer of all things trademarked.) is certainly taking a hard line stance. (To use the Firefox name (and its logo) you must be releasing something that we can certify meets the quality of "Firefox", which is an official designation for the software.) Other distros apparently do this successfully, but they aren't concerned about protecting themselves from every straw-man and mythical big-bad corporation beast that's (supposedly) determined to make their life harder.

Debian of course, is too good to have to ask permission for anything, or even make their patch set readable or answer straight questions about what the patches are they really are applying, avoiding it with (they came from bugzilla. and no more details about why.) and try to make it all about the evils of wanting patches included in something named Firefox approved.

I think its probably more about wanting to know why Debian builds with their included patchset, are far more buggy and cause users of them way more headaches than the Mozilla-released equivilent. Its those problems that led Mozilla to push Debian, to give details of those patches, or stop using the Firefox name, since it makes users think that Firefox itself, sucks, and not the distro provided packages.
So, let them rebrand IceWeasel, and include those patches, IceWeasel will of course suck as bad as the current Debian Fox builds do. Hopefully, somebody else will step-up and provide a base unbranded (or branded even, it shouldn't be hard.) Bon Echo or Deer Park build for Debian distros so that its users, (who aren't all FS zealots, i'm sure.) have an option to vote no to IceWeasel, and Ubuntu finds a better way independently of all this mess, like actually working with Mozilla and finding common ground and understanding. Instead of snobbish elitism and a nice big fork.
Oh, and the Mozilla side, should just let it go. If Debian wants to fork, let them, Firefox itself was a fork. As-is Flock, and Netscape 8. So what's one more, ignoring the politics?

And yes, Stephen Colbert is in the Firefox 2 credits.. Policital play? PR move? Nah, just a joke.. (I don't think its funny, but then again, I might if I actually /liked/ him.) Go find the name and tell your friends or something.

Oh yeah, Firefox 2 RC3 was released, go download it, poke at it and give feedback.

This Wednesday, the server that hosts firebot will be down for several hours (during the afternoon/evening EDT) for planned maintenance. This, of course, means that firebot will be offline and not available for your bug watching, tree burning, and factoid requesting pleasure. Thanks.