Slashdot Mirror

Apparently the Bookmarks Synchronizer extension for Mozilla firefox (mentioned above) also uses XBEL to store the bookmarks on a ftp server. Bookmarks Synchronizer extension: http://update.mozilla.org/extensions/moreinfo.php? id=14&vid=15 or http://cgi29.plala.or.jp/~mozzarel/

Actually, the main problem is when an app tries to write to files that aren't in the user's home directory, i.e. tries to write to something in C:\Windows or C:\Program Files instead of assuming those locations are read-only and only trying to write to C:\Documents and Settings\username like it should. Sadly, Mozilla is still (intermittently) guilty of this (although it sounds like this time it's a new bug that will be fixed in the next release).

See the Mozilla Relicensing FAQ

How will the new Mozilla license scheme affect developers who want to use Mozilla code in creating and distributing proprietary applications?

Not at all; developers creating and distributing proprietary software incorporating Mozilla code will be able to continue to use that code under MPL terms and conditions, exactly as they have been doing all along.

The MPL was originally designed to allow source files distributed under MPL terms to be combined with source files under other licenses, and the resulting work to be distributed under a non-MPL license. (This right is contingent on the requirements of the MPL being fulfilled. For example, when distributing the resulting work to users, the distributor must also make available to users the source code for that portion of the code created from the source files distributed under the MPL.)

This feature of the MPL has allowed developers to distribute proprietary products incorporating Mozilla code. (Netscape 7 is one example of such a product.) Under the MPL/GPL/LGPL triple license scheme developers may continue to create and distribute Mozilla-based proprietary products, by taking advantage of the option to use the Mozilla code under the MPL terms and complying with the various requirements of the MPL for those portions of the proprietary products based on Mozilla code.

(In theory developers could also distribute Mozilla-based proprietary products using the Mozilla code under LGPL terms, if the Mozilla code were in the form of a library and the developers complied with the relevant requirements of the LGPL.)

I wouldn't take SANS's list of browser security holes too seriously. It lists the most publicized holes in Mozilla rather than the most serious holes. (To get a list of the most serious holes, look the "critical severity, high risk" holes (marked in red) on mozilla.org's list.) SANS's list includes Mozilla XPInstall Dialog Box Security Issue, which was fixed a few months ago, but fails to mention that a fully-updated version of IE in SP2 is still vulnerable. Under the list, SANS claims that Firefox does not have automatic updates, which is false.

Do the licenses of Mozilla and Netscape allow AOL to use developments in Mozilla for proprietary software? I'm not too clear on the specifics of how open source developments in Mozilla are migrated over to proprietary distributions of Netscape, if they actually are.

But if AOL has licensed Internet Explorer from Microsoft, then perhaps the deal includes the sharing of proprietary code both ways. If Mozilla code can become proprietary for AOL under the project's licensing scheme, then they could possibly pass it on to Microsoft. Microsoft could end up using developments for Mozilla for Internet Explorer to deal with all its current security issues under a closed source license. That could be the whole reason for this deal.

Nope. Firefox isn't a suitable replacement for IE until bug 36539 gets fixed.

Why on earth didn't you just go and download mozilla or firefox?!

not once have I had compatibility issues with those while using ebay, and that's on Windows as well as linux.

on the easy to use linux front, apparently SUSE is very easy to install, though it's not my distro of choice, and I even seem to recall that there's an AOL dialer available from somewhere if that's what's holding you back.

Why on earth didn't you just go and download mozilla or firefox?!

not once have I had compatibility issues with those while using ebay, and that's on Windows as well as linux.

on the easy to use linux front, apparently SUSE is very easy to install, though it's not my distro of choice, and I even seem to recall that there's an AOL dialer available from somewhere if that's what's holding you back.

Sorry, I'll consider firefox a decent browser when bug 36539 finally gets fixed after 3 years.

In Firefox, if I click on a link that wants to open up a new window, it opens up a whole new window instead of just a tab.

They've got a fix for that. See Bug 172962 (and don't forget that bugzilla won't let you click through that)

Ctrl+Tab, Ctrl+Shift+Tab.
Ctrl+W.
Single Window Extension or Tabbrowser Preferences.

Ctrl+Tab, Ctrl+Shift+Tab.
Ctrl+W.
Single Window Extension or Tabbrowser Preferences.

Wow, you just found a minor issue in Opera. Firefox sure doesn't have any bugs!

From the article:

When writing an article (especially big NDA launches), I'd have around 20 IE windows open, Outlook with another 5 - 15 emails, Power Point with NDA presentations, ...

20 IE Windows??? Man, this guy has got to get a copy of Firefox and learn the joy of tabbed browsing.

Try Bookmarks Synchronizer.

Gerv, who works for mozilla/bugzilla, already went through this, and found several ways around google's hackery. He then went and summarized the multiple ways to do it in good browsers.

This is a duplicate of a private bug about working with Google. So closing this one.

*** This bug has been marked as a duplicate of 213362 ***

This is a duplicate of a private bug about working with Google. So closing this one.

*** This bug has been marked as a duplicate of 213362 ***

A full exploration of the html obfuscation and DRM employed by Google would be very interesting

I've been looking at this - there's a blog post with some preliminary discussions, and a follow-up giving some ways of getting around it. The short answer is that if you just want to save the image to disk, it's not too hard in a decent browser.

Gerv

Well, they are not enabled by default, but gestures can be added to Firefox: http://update.mozilla.org/extensions/showlist.php? category=Mouse%20Gestures

From this article it appears that KDE is looking to use the gecko rendering engine (because it does a better job) for "enterprise" environments, instead of putting effort into KHTML.

No, the article talks about SUSE looking to use the Gecko rendering engine since it, unlike KHTML, is supported by companies like SAP. KDE itself will continue to use KHTML, there is no chance KDE will add a dependency to something which after years of promises still isn't separated out as runtime library. Also sadly SUSE is not putting effort either into improving KHTML nor into the Gecko port to Qt/KPart. This Qt/KPart port is done by Lars and Zack, both also KHTML developers, and obviously for shutting down all those people screaming for an "improved" khtml while doing nothing about it. With this port they pretty much outsourced the problem to Mozilla and the distributions while being able to continue their work at KHTML at the pace they prefer (just look how many bugs/wishes in KDE's bugzilla are reported for KHTML/KJS, seems to be about 10% of all reports).

seriously, I used IE for a while and got fed up with closing pop-ups and saying NO to installing INTERNET GAMBLING.EXE or PORNVIEWER.EXE. firefox is a breath of fresh air.

You're seeing the effect of bug 179944 ( http://bugzilla.mozilla.org/show_bug.cgi?id=179944 ). To learn how to apply for the "canconfirm" privilege on bugzilla.mozilla.org, which grants the ability to file NEW bugs or to change UNCONFIRMED bugs to NEW, read Bug Triagers' Guide and Before you mail Gerv. If you're good at reducing examples of Gecko misbehavior to test cases, you may want to apply for "editbugs" as well.

You're seeing the effect of bug 179944 ( http://bugzilla.mozilla.org/show_bug.cgi?id=179944 ). To learn how to apply for the "canconfirm" privilege on bugzilla.mozilla.org, which grants the ability to file NEW bugs or to change UNCONFIRMED bugs to NEW, read Bug Triagers' Guide and Before you mail Gerv. If you're good at reducing examples of Gecko misbehavior to test cases, you may want to apply for "editbugs" as well.

Quite a few Slashdot readers think Roland Piquepaille (rpiquepa is exploiting this site as a way of upping his ad impressions. There's a strong argument that he wants to turn the Slashdot effect into ad money, and this is supported by the habit he has of linking not to the article, but to a verbatim copy posted on his ad-supported blog. Engadget (ptorrone) are pretty dubious too, but at least they bother to write their own content.

Having said that, I don't think Roland etc are bribing the /. editors, and I don't necessarily think that their submissions should be rejected. Whether they are astroturf or not is up to the individual reader to decide, and some people seem to enjoy them. What I would like to see is the ability to let the individual block submissions from particular users somehow, either as a subscription feature (block by UID / foes list), or a Firefox extension (based on NukeAnything perhaps).

And I no, I don't have the time / skillset / influence to code the above myself. I'm just putting some ideas out for discussion.

First off, if someone reports a bug, it should be ASSUMED that there is a potential security issue there, until proven otherwise. Why? Because there are generally side-effects. Even if the bug doesn't directly do anything nasty, it may very well cause something unintended which, in turn, causes something else unintended, and so on.

Do you have any idea how many bugs are filed each day? It's usually dozens to hundreds. Security bugs can only be viewed by members of the security group, and there aren't that many of them, AND the people who are in the group are only there because they've demonstrated repeatedly their ability to contribute to the project. Do you really want to waste the time of some of *the best* developers by making them look through bugs like "This page looks better in Internet Explorer" or "Product doesn't fucking work with simple html files." (an idiotic and pissed off user, bug 260136)? Triaging is often done by people who want to help, but don't have the coding skills necessary to fix a lot of the bugs.

For what it's worth, I can't think of any bugs that ended up "snowballing" that we didn't know were major from the start.

There are two classes of bugs in a computer program. Those that cause the program to crash, and those that don't. The second type are much harder to track down (because you've no real indication of where the problem started), but they are generally much worse and much more prevelent.
Bugs that cause crashes can be hard to track down - for example, you may have code that caused corruption somewhere and the program won't crash until later. Bugs that don't cause crashes can also be very easy to track down - for example, various UI issues may be as simple to fix as just editing a few lines of javascript.

The "correct" way to handle bugs is to assume that (almost) any problem puts the software at risk of a non-fatal bug that could (eventually) destabilize the program or open an exploit.
Unless you have infinite resources, that's not a realistic approach (see above)

Spelling errors in text messages are probably OK, but even there, if you're placing them in fixed-length buffers, it is saner to check and be sure that the risks are low than to ignore apparently trivial "appearance" stuff that could be catastrophic.
Pretty much every string in Mozilla is localizable - when I write code with a string the user sees, there's no way I could put it into a static buffer. Spelling errors causing buffer overflows? PUH-LEASE!

I've seen programmers give themselves buffer overflows, I've even seen programmers rely on certain OS quirks when an overflow occurs. The code may not be portable, and it sure as hell isn't safe, but it does work.
The Mozilla apps are cross platform. It works the other way around for us - we have to work *around* quirks, not take advantage of them (see bug 255120, for example)

(I've actually seen some code that won't run, unless the debug flag is present. The code will actually segfault if the extra padding the debug data creates is not there. Not from the Mozilla team, this was in a prior place of employment, but it does demonstrate that coding is not just about making something "work" it's about making it work for the right reasons.)
Yes, software has bugs. So?

Now, the Mozilla team is probably simply too small to regard every bug entered in their database as a potentially critical show-stopping security hazard. This, however, reflects more on the userbase than on the Mozilla folks. Open Source works if, and only if, the "lots of eyes" out there looking for problems also translate into "lots of hands" for fixing problems.
...so what you said above is irrelevant? Every project has problems, and the team members do their best to do a good job.

Sure, not everybody is goi

First off, if someone reports a bug, it should be ASSUMED that there is a potential security issue there, until proven otherwise. Why? Because there are generally side-effects. Even if the bug doesn't directly do anything nasty, it may very well cause something unintended which, in turn, causes something else unintended, and so on.

Do you have any idea how many bugs are filed each day? It's usually dozens to hundreds. Security bugs can only be viewed by members of the security group, and there aren't that many of them, AND the people who are in the group are only there because they've demonstrated repeatedly their ability to contribute to the project. Do you really want to waste the time of some of *the best* developers by making them look through bugs like "This page looks better in Internet Explorer" or "Product doesn't fucking work with simple html files." (an idiotic and pissed off user, bug 260136)? Triaging is often done by people who want to help, but don't have the coding skills necessary to fix a lot of the bugs.

For what it's worth, I can't think of any bugs that ended up "snowballing" that we didn't know were major from the start.

There are two classes of bugs in a computer program. Those that cause the program to crash, and those that don't. The second type are much harder to track down (because you've no real indication of where the problem started), but they are generally much worse and much more prevelent.
Bugs that cause crashes can be hard to track down - for example, you may have code that caused corruption somewhere and the program won't crash until later. Bugs that don't cause crashes can also be very easy to track down - for example, various UI issues may be as simple to fix as just editing a few lines of javascript.

The "correct" way to handle bugs is to assume that (almost) any problem puts the software at risk of a non-fatal bug that could (eventually) destabilize the program or open an exploit.
Unless you have infinite resources, that's not a realistic approach (see above)

Spelling errors in text messages are probably OK, but even there, if you're placing them in fixed-length buffers, it is saner to check and be sure that the risks are low than to ignore apparently trivial "appearance" stuff that could be catastrophic.
Pretty much every string in Mozilla is localizable - when I write code with a string the user sees, there's no way I could put it into a static buffer. Spelling errors causing buffer overflows? PUH-LEASE!

I've seen programmers give themselves buffer overflows, I've even seen programmers rely on certain OS quirks when an overflow occurs. The code may not be portable, and it sure as hell isn't safe, but it does work.
The Mozilla apps are cross platform. It works the other way around for us - we have to work *around* quirks, not take advantage of them (see bug 255120, for example)

(I've actually seen some code that won't run, unless the debug flag is present. The code will actually segfault if the extra padding the debug data creates is not there. Not from the Mozilla team, this was in a prior place of employment, but it does demonstrate that coding is not just about making something "work" it's about making it work for the right reasons.)
Yes, software has bugs. So?

Now, the Mozilla team is probably simply too small to regard every bug entered in their database as a potentially critical show-stopping security hazard. This, however, reflects more on the userbase than on the Mozilla folks. Open Source works if, and only if, the "lots of eyes" out there looking for problems also translate into "lots of hands" for fixing problems.
...so what you said above is irrelevant? Every project has problems, and the team members do their best to do a good job.

Sure, not everybody is goi

See also http://mozcreator.mozdev.org/, and http://www.mozilla.org/projects/vixen/. Neither of these appear to be very far along though.

He seems to have gotten a bounty from the Mozilla Foundation for this.

It's here.

is not very positive. If you ever dare to ask if any progress has been made, or for an ETA on a fix, you're bound to get a "well why don't you fix it yourself" indignant reply.
If progress is made, you'll see patches added to the bug, or comments from developers discussing the fix. Parents get annoyed by incessant kids in the car asking "are we there yet?", and developers get annoyed by incessant users asking "is this fixed yet?". In both examples, the question's answer is obvious.

Spamming a bug with comments like "why isn't this fixed?", "this bug still annoys me", "don't wontfix this bug" and "this bug is really old and annoying, you guys suck and don't care" doesn't help fix the bug - I can't speak for other developers, but getting many useless emails about a bug only makes me more likely to remove myself from the CC list and forget about it. Having to read through 150+ "why isn't this fixed" comments to find relevant information doesn't help anything either. If someone takes the time to figure out where a fix for a bug needs to go, or contributes something, it's different.

I would be more than willing to contribute code under contract for this project. Unfortunately, my services do not come free.
Mozilla is free. Many of the people who fix bugs (for example, me - you'll have to copy and paste that URL) aren't paid. Whining about volunteers not fixing a bug you care about doesn't do anything. Insulting them is even less productive. If you don't have anything constructive to say, don't bother people.

Bug 69070

The bug was on bugtraq in 2001! It allows remote pages to open and use files on the local machine, and is also a denial of service on Linux, since Mozilla stupidly allows the opening of paths which are not regular files (/dev/tty).

My experience with 69070 has been educational. I've learned if there's a security bug you care about, you had better fix it yourself. Unfortunately I can't but maybe someone in the audience has the spare time to step up.

*Poof* It's gone. It's just temporary, but it always makes me feel better at the end of the day.

step one is the browser.
you can win this one on the positive user experience front when they experience less pop-ups, spyware and the ilk.

step two is the applications.
you'll win this battle with allies in the finanace department. they'll love not shelling out the big bucks for ms office licenses.

step three is the os.
Win the battles to win the war.

1. Format your computer
2. Reinstall Windows
3. Patch windows to the latest updates
4. Install Firefox
5. Never look back

I agree with Dave Winer, the author of the RSS format. With RSS feeds becoming more and more popular across a whole raft of different applications (including tasty new integration with Firefox), surely combining the two formats (Atom and RSS) would be beneficial, lest we end up with another VHS/Beta or DVD+/-RW/RAM situation... Rather than have the two battle it out to the death, why not get the best of both worlds?

I was right, it was that data: protocol bug I had seen a couple weeks ago.

Trying to save file from data: protocol wipes every file in target directory not marked read-only
https://bugzilla.mozilla.org/show_bug.cgi?id=25970 8

You can download a zip version of Firefox, instead of using the installer.
Unfortunately, Mozilla's site doesn't link directly to the zip, but you can find them by browsing the releases directory on Mozilla's ftp.
They also offer zipped versions of Thunderbird and the Mozilla Suite.

You can download a zip version of Firefox, instead of using the installer.
Unfortunately, Mozilla's site doesn't link directly to the zip, but you can find them by browsing the releases directory on Mozilla's ftp.
They also offer zipped versions of Thunderbird and the Mozilla Suite.

MSI packages are Microsoft's RPM. They are significant because Microsoft's and other companies' application deployment tools use it.

For example, I administer about 80 PCs in a school. First thing I need to do with a new application is to get it into MSI form becuase usually they come as executables. Some companies like Sun (Java) and Adobe (Acrobat Reader etc) provide tools that help you make your own package. They also aren't ready for multiuser systems where users are non-privileged. So a lot of work before I can deploy a new application.

Once they are in MSI form, I can stick them on a network share and tell all the PCs to install the programs on the next bootup. I don't have to go through 80 machines and install Firefox on every one.

Firefox comes as an executable or flat zip file. I've been working putting FF in an MSI lately and have had enough success to roll it out. There are plans to offer it as an MSI when it hits 1.0 final.

Another component they mention is group policies. You can configure IE centrally from a server, for instance now that I've deployed FF I've shut off "active scripting" (ECMAscript/Javascript/vbcript whatever) from all unknown sites. Not that it helps much because according to Secunia it's possible to circumvent IE's security zone settings due to a 7-month old unpatched security hole in IE. FF doesn't use the Windows registry so group policies are useless. Other means of enforcing settings are being developed, however.

MSI packages are Microsoft's RPM. They are significant because Microsoft's and other companies' application deployment tools use it.

For example, I administer about 80 PCs in a school. First thing I need to do with a new application is to get it into MSI form becuase usually they come as executables. Some companies like Sun (Java) and Adobe (Acrobat Reader etc) provide tools that help you make your own package. They also aren't ready for multiuser systems where users are non-privileged. So a lot of work before I can deploy a new application.

Once they are in MSI form, I can stick them on a network share and tell all the PCs to install the programs on the next bootup. I don't have to go through 80 machines and install Firefox on every one.

Firefox comes as an executable or flat zip file. I've been working putting FF in an MSI lately and have had enough success to roll it out. There are plans to offer it as an MSI when it hits 1.0 final.

Another component they mention is group policies. You can configure IE centrally from a server, for instance now that I've deployed FF I've shut off "active scripting" (ECMAscript/Javascript/vbcript whatever) from all unknown sites. Not that it helps much because according to Secunia it's possible to circumvent IE's security zone settings due to a 7-month old unpatched security hole in IE. FF doesn't use the Windows registry so group policies are useless. Other means of enforcing settings are being developed, however.

Even that wouldn't work, as firefox can be downloaded in zip form, unzipped anywhere, and run using only files in that directory. You can even run many different versions of moz/firefox simultaneously. You can't possibly control it all unless you have complete control of the entire hard drive. And that's just way too hard.

Call me when firefox finally gets https://bugzilla.mozilla.org/show_bug.cgi?id=36539 fixed. IE's had this working for over a decade.

How long does it take firefox to finally get https://bugzilla.mozilla.org/show_bug.cgi?id=36539 ?

Yup, do your worst. http://ftp.mozilla.org/pub/mozilla.org/firefox/rel eases/0.10.1/

Another option could be to compile Firefox yourself. It's not too difficult. This document describes the process. The compile took about 3 hours on my 800 MHz box.

Trojan Horse?

I thought you were refering the the possibility that they might put a trojan on their website that will pop up boxes or programs encouraging their visitors to switch.

Heheh, hijack IE's homepage to the Firefox or Opera download page... That'll teach 'em.

According to the article, Kodak purchased the patents in question from the now-defunct Wang Laboratories. Wang sued Netscape in the late 1990s, claiming that the Netscape browser infringed on its videotext patent. They lost. Back then, Wang was on the ropes, much more so than Kodak is now. Interesting how desperation can lead to shot-in-the-dark lawsuits (hi, SCO!).

You obviously don't use a Mozilla browser. Find as you type is usually faster than moving the mouse and clicking a link.

This patch is in violation of the MPL. It has the MPL license removed from:

http://lxr.mozilla.org/seamonkey/source/toolkit/mo zapps/downloads/content/nsHelperAppDlg.js

Which is in violation of clause 3.5