Well double dumbass on the Mozilla developers for knowing about it and not taking steps to mitigate it even without an exploit in the wild. There was nothing the Mozilla developers COULD do to mitigate it. Only when we (the Mozilla Update devs) realized exactly how the exploit depended on the Mozilla Update website could we do anything - and we spent a few hours last night working on the first level of mitigation. We've been working on a better solution most of today.
Calling the person who released it a "jerk" just shows that you have no understanding that a security risk is severe, whether or not anybody knows about its existence. Yes, and it becomes a lot more severe once an exploit is posted for all the script kiddies to use. Do you really think we're better off now that any idiot can own a Firefox user's machine, rather than just the white hat who reported the hole (plus at most a few black hats)?
It's said time and time again, but nobody ever listens: security through obscurity is not security. Obscurity is a valid layer of security, so long as it's not the only one. The fact that somebody felt it was wise to strip us of one layer of protection is what is annoying.
If one of the doors to your house had a broken lock, would you rather have that be a secret until you can get to the hardware store and fix it, or have someone inform the whole neighborhood? Of course you'd PREFER to not have a broken lock at all, but in the real world, things don't always go the way you want.
The person who posted it wasn't a jerk - that's just blaming somebody else for the Mozilla developers' failures. Stop pointing the finger, fix the damn problem, and release a patch before Monday morning. Nobody blames the person who leaked it for the hole - I blame the person who leaked it for the people who get hacked as a result of the posted exploit.
The devs were already working on it before some jerk full-disclosured w/working exploit. It had already been marked as a bug that would block both the 1.0.4 and 1.1 releases. All this person did was cause a lot of headaches for Mozilla developers, and put many users at risk.
That is incorrect. The exploit works by loading a page from a trusted site (one of the mozilla.org sites on the whitelist), then taking advantage of another Firefox bug to run some javascript in the security context of the trusted site.
The "Gecko Browser" is what you get if you compile without setting --enable-official-branding. You can build your own if you want. Extensions should really work though - which ones aren't working? Plugins are a different story altogether (I suspect you will need different versions for plugins, and tehre's nothing the Mozilla people can do about it - talk to Adobe/Macromedia)
See my comment here - the autoscroll icon is causing it to do full screen repainting. AFAIK 1.1 will not fix this, but you can use other methods of scrolling if this really bothers you (just roll the wheel, use the scrollbar, etc).
Personally, I don't think it's a huge problem... it still scrolls smoothly, and an idle cpu is a wasted CPU;). Granted, it's not ideal, but it isn't a big deal. Even if you want to dedicate your cycles to something like SETI@home, the CPU time used in hours of surfing still adds up to very little.
Scroll by dragging the scrollbar or rolling the mousewheel - you'll see Firefox is also only repainting the part that was off the screen. The problem when you middle click is that the scroll icon is actually inserted into the document as a position:fixed object, and as such, every time the document is scrolled, as I understand it, it has to be re-laid-out. This causes the full repaint.
Mozilla debug builds include a tool called Layout Debugger that also lets you have it flash screen updates on all platforms.
The validity of the HTML is irrelevant - the bug was a type of bug known as a "reflow bug". Reflow bugs are timing-dependant, in that they only occur when things happen in a certain order. This is a large part of why people with fast connections were less affected by the bug. You could likely construct a page with 100% valid XHTML which would demonstrate the same bug.
The SeaMonkey project will keep the suite alive. While we pick different features to include, development is still very active. The "lack of resources" discussed in other stories was on the Mozilla Foundation side (there's a lot involved in pushing out a release), not on the developer side.
The reason releases that come after a given nightly don't have the same features is branches. Before each release, a branch is made (usually at the beta) so that the code is stable, and rapid (dangerous) development can continue on the trunk. Firefox 1.0.x were released off the 1.0 branch - branches usually only get very important bugfixes and security fixes. The trunk is where the day-to-day stuff happens, but as a result it can often be in pretty bad sahpe.
That isn't asynchronous. Asynchronous in the context of CPU designs means not clocked - running at double the clock speed means it's still clocked, and thus synchronous.
Simultaneous MPEG2 decoding, as shown here, is what computer architects call an embarrassingly-parallel problem. The easiest way to speed it up is just add more processors - with 8 processing units, the Cell is a great fit.
However, the really interesting problems are the ones that don't scale linearly in performance with the number of processors - these are the tasks for which the Cell processor will probably be running with 7 idle units and 1 active. These are also the tasks where we need actually new architectures; supercomputers like BlueGene will tear their way through extremely parallel problems.
One very cool approach to handling less parallel workloads (or even "sequential" workloads - like the majority of programs people usually run on PCs) is speculative threading - taking a sequential program, breaking it up into chunks, and running those chunks in parallel. Of course, when you do this, you have to make sure that the later work doesn't depend on the earlier operations, and check for violations of "sequential execution semantics" (programs expecting sequential execution semantics are ones that expect their instructions to execute in order - basically any program you'd write today). The Stanford Hydra project is an example that uses this technique; Wisconsin Multiscalar Group takes an approach that requires modified binaries to do something similar.
One thing people fail to mention when they talk about the supposedly-amazing performance of the Cell processor is its floating point precision: first, it only attains it's >200GFLOPS with single precision numbers (not accurate enough for many scientific applications), and second, it doesn't follow IEEE754 rounding requirements. The rounding policy in IEEE754 floats is specifically designed so that as you perform more and more calculations, the error doesn't grow rapidly. Cutting corners lets you calculate faster but even less accurate numbers. Basically, to get the high FLOPS ratings, Cell sacrifices precision in both the number of bits used, and the accuracy of the data in those bits.
Robert O'Callahan has a blog entry about Acid2 and Mozilla. Basically, gecko is currently very late in a cycle and the fixes for Acid2 are the kinds of things that really need to happen early in a cycle.
I wish someone would port the ability to open bookmarks in tabs to mozilla, Which bookmarks? Trunk (1.8 alphas, beta) has had the ability to middle click bookmarks and bookmark folders to open them in tabs for a long time now: see https://bugzilla.mozilla.org/show_bug.cgi?id=27280 0 (remove the space)
I didn't think it was worth requesting approval for 1.7.x for the patch.
XUL Error pages are in pretty bad shape in 1.7.x and 1.0.x - there's a reason they're off by default. For 1.1 and 1.8, many of the bugs have been fixed, and they work a lot better.
The Firefox developers have specifically rejected PATCHES (not just feature requests) for preferences that allow Firefox to act more like Mozilla (for example, unswap ctrl and alt in the URL bar). They're just not interested.
Hackarounds are looked down on. Based on what I've seen, I think the Firefox guys are more inclined to use hacks than the Mozilla Suite people... but there are a bunch of examples of bugs that could be fixed if the reviewers were willing to accept ugly hacks.
I suspect the big factor with this particular bug is a lack of caring - in an open source product developed mostly by volunteers, some people aren't inclined to worry about platforms they don't use, and those that do care may have more important things to worry about (security fixes, crash bugs, etc.). This bug is really trivial, and while a mild annoyance, not worth a developer's time that could be better spent improving other aspects of the product.
Actually, the Suite's net installer allows you to download just the components you want (for example, only the browser). Don't buy into the hype - Suite isn't bloatware.
The thing is, just because some group says "Firefox is the new Mozilla", it doesn't mean that Mozilla suddenly becomes a bad, inadequate, or obsolete product. As you note, they ARE very different applications, and this is the problem - the group that says "Firefox is the new Mozilla" doesn't appreciate that some of the Mozilla hackers and users don't *want* a new Mozilla.
Imagine you had a group of volunteers building a car like the Accord, and one year the "head honcho" says "next year's model will be a Civic". Many people love the Civic, and it becomes hugely popular. Is it so wrong for the Accord designers to still keep maintaining their Accord line if they have the necessary skills and resources?
What you have to understand is that this is not just a version increment - it's a new product which can live in parallel. The developers mentioned in the story mostly want to know whether the head honcho of the volunteer group will let them develope the same way they used to, or if they have to create their own group with its own things.
Sorry, I thought people != developers was implied.
Anyway, as I've mentioned in other comments, improving Firefox is not an option - for a couple of reasons. First, things I see as improvements the Firefox devs often don't. Suite developers have a more similar vision. Second, things Firefox devs may also see as improvements can't be done because they don't want to change things after 1.0 (now that users are used to them). If I wanted to fork Firefox to make my own "improved" version, I could, but it would have only one user (and take a lot of effort to maintain, if it diverged much). With Mozilla, other developers, and at least a few thousand other people use it.
Mozilla vs Firefox is not Linux 2.4 vs Linux 2.6, it's more like FreeBSD vs NetBSD or KDE vs GNOME. An even better analogy might be Sawfish vs Metacity (ignoring that these probably don't share much code).
I don't think there would be a significant security difference - the backend code is shared, and most holes (besides UI spoofing type holes) are in the backend (I don't think UI differences could create a buffer overflow hole, for example). However, when it comes to stability and reliability, that's when the coding pracitces come into play.
The new options window for Firefox introduced many new bugs - for example, the code that was checked in doesn't even WORK! (The window is 100% transparent and unusable). There are plenty of problems with it.
Another example is the yellow information bar (which I spoof in the link above) - when I was porting it to Mozilla, with minutes of testing I found serious problems it caused. After fixing those issues, I found and fixed more subtle ones. The Firefox code had been checked in, apparently with almost no testing, let alone code review. Yes, users found the bugs and filed them, but I don't trust users to find many of the less overt bugs.
Slashdot Mirror
The Mozilla Update team has taken steps to mitigate the problem - the default Firefox configuration is no longer exploitable, as far as I know.
Well double dumbass on the Mozilla developers for knowing about it and not taking steps to mitigate it even without an exploit in the wild.
There was nothing the Mozilla developers COULD do to mitigate it. Only when we (the Mozilla Update devs) realized exactly how the exploit depended on the Mozilla Update website could we do anything - and we spent a few hours last night working on the first level of mitigation. We've been working on a better solution most of today.
Calling the person who released it a "jerk" just shows that you have no understanding that a security risk is severe, whether or not anybody knows about its existence.
Yes, and it becomes a lot more severe once an exploit is posted for all the script kiddies to use. Do you really think we're better off now that any idiot can own a Firefox user's machine, rather than just the white hat who reported the hole (plus at most a few black hats)?
It's said time and time again, but nobody ever listens: security through obscurity is not security.
Obscurity is a valid layer of security, so long as it's not the only one. The fact that somebody felt it was wise to strip us of one layer of protection is what is annoying.
If one of the doors to your house had a broken lock, would you rather have that be a secret until you can get to the hardware store and fix it, or have someone inform the whole neighborhood? Of course you'd PREFER to not have a broken lock at all, but in the real world, things don't always go the way you want.
The person who posted it wasn't a jerk - that's just blaming somebody else for the Mozilla developers' failures. Stop pointing the finger, fix the damn problem, and release a patch before Monday morning.
Nobody blames the person who leaked it for the hole - I blame the person who leaked it for the people who get hacked as a result of the posted exploit.
The original (private) bug was filed less than a week ago.
We made some server-side changes on update.mozilla.org to mitigate the attack.
The devs were already working on it before some jerk full-disclosured w/working exploit. It had already been marked as a bug that would block both the 1.0.4 and 1.1 releases. All this person did was cause a lot of headaches for Mozilla developers, and put many users at risk.
That is incorrect. The exploit works by loading a page from a trusted site (one of the mozilla.org sites on the whitelist), then taking advantage of another Firefox bug to run some javascript in the security context of the trusted site.
The "Gecko Browser" is what you get if you compile without setting --enable-official-branding. You can build your own if you want. Extensions should really work though - which ones aren't working? Plugins are a different story altogether (I suspect you will need different versions for plugins, and tehre's nothing the Mozilla people can do about it - talk to Adobe/Macromedia)
See my comment here - the autoscroll icon is causing it to do full screen repainting. AFAIK 1.1 will not fix this, but you can use other methods of scrolling if this really bothers you (just roll the wheel, use the scrollbar, etc).
;). Granted, it's not ideal, but it isn't a big deal. Even if you want to dedicate your cycles to something like SETI@home, the CPU time used in hours of surfing still adds up to very little.
Personally, I don't think it's a huge problem... it still scrolls smoothly, and an idle cpu is a wasted CPU
Scroll by dragging the scrollbar or rolling the mousewheel - you'll see Firefox is also only repainting the part that was off the screen. The problem when you middle click is that the scroll icon is actually inserted into the document as a position:fixed object, and as such, every time the document is scrolled, as I understand it, it has to be re-laid-out. This causes the full repaint.
Mozilla debug builds include a tool called Layout Debugger that also lets you have it flash screen updates on all platforms.
The validity of the HTML is irrelevant - the bug was a type of bug known as a "reflow bug". Reflow bugs are timing-dependant, in that they only occur when things happen in a certain order. This is a large part of why people with fast connections were less affected by the bug. You could likely construct a page with 100% valid XHTML which would demonstrate the same bug.
The SeaMonkey project will keep the suite alive. While we pick different features to include, development is still very active. The "lack of resources" discussed in other stories was on the Mozilla Foundation side (there's a lot involved in pushing out a release), not on the developer side.
The memory usage depends heavily on your browsing patterns (what you have open, what you had open, whether you use tabs vs. windows, etc).
The reason releases that come after a given nightly don't have the same features is branches. Before each release, a branch is made (usually at the beta) so that the code is stable, and rapid (dangerous) development can continue on the trunk. Firefox 1.0.x were released off the 1.0 branch - branches usually only get very important bugfixes and security fixes. The trunk is where the day-to-day stuff happens, but as a result it can often be in pretty bad sahpe.
That isn't asynchronous. Asynchronous in the context of CPU designs means not clocked - running at double the clock speed means it's still clocked, and thus synchronous.
Simultaneous MPEG2 decoding, as shown here, is what computer architects call an embarrassingly-parallel problem. The easiest way to speed it up is just add more processors - with 8 processing units, the Cell is a great fit.
However, the really interesting problems are the ones that don't scale linearly in performance with the number of processors - these are the tasks for which the Cell processor will probably be running with 7 idle units and 1 active. These are also the tasks where we need actually new architectures; supercomputers like BlueGene will tear their way through extremely parallel problems.
One very cool approach to handling less parallel workloads (or even "sequential" workloads - like the majority of programs people usually run on PCs) is speculative threading - taking a sequential program, breaking it up into chunks, and running those chunks in parallel. Of course, when you do this, you have to make sure that the later work doesn't depend on the earlier operations, and check for violations of "sequential execution semantics" (programs expecting sequential execution semantics are ones that expect their instructions to execute in order - basically any program you'd write today). The Stanford Hydra project is an example that uses this technique; Wisconsin Multiscalar Group takes an approach that requires modified binaries to do something similar.
One thing people fail to mention when they talk about the supposedly-amazing performance of the Cell processor is its floating point precision: first, it only attains it's >200GFLOPS with single precision numbers (not accurate enough for many scientific applications), and second, it doesn't follow IEEE754 rounding requirements. The rounding policy in IEEE754 floats is specifically designed so that as you perform more and more calculations, the error doesn't grow rapidly. Cutting corners lets you calculate faster but even less accurate numbers. Basically, to get the high FLOPS ratings, Cell sacrifices precision in both the number of bits used, and the accuracy of the data in those bits.
Robert O'Callahan has a blog entry about Acid2 and Mozilla. Basically, gecko is currently very late in a cycle and the fixes for Acid2 are the kinds of things that really need to happen early in a cycle.
I wish someone would port the ability to open bookmarks in tabs to mozilla,0 0 (remove the space)
Which bookmarks? Trunk (1.8 alphas, beta) has had the ability to middle click bookmarks and bookmark folders to open them in tabs for a long time now: see https://bugzilla.mozilla.org/show_bug.cgi?id=2728
I didn't think it was worth requesting approval for 1.7.x for the patch.
XUL Error pages are in pretty bad shape in 1.7.x and 1.0.x - there's a reason they're off by default. For 1.1 and 1.8, many of the bugs have been fixed, and they work a lot better.
Amazingly enough, security fix releases tend not to change page rendering!
The Firefox developers have specifically rejected PATCHES (not just feature requests) for preferences that allow Firefox to act more like Mozilla (for example, unswap ctrl and alt in the URL bar). They're just not interested.
Hackarounds are looked down on. Based on what I've seen, I think the Firefox guys are more inclined to use hacks than the Mozilla Suite people... but there are a bunch of examples of bugs that could be fixed if the reviewers were willing to accept ugly hacks.
I suspect the big factor with this particular bug is a lack of caring - in an open source product developed mostly by volunteers, some people aren't inclined to worry about platforms they don't use, and those that do care may have more important things to worry about (security fixes, crash bugs, etc.). This bug is really trivial, and while a mild annoyance, not worth a developer's time that could be better spent improving other aspects of the product.
Actually, the Suite's net installer allows you to download just the components you want (for example, only the browser). Don't buy into the hype - Suite isn't bloatware.
The thing is, just because some group says "Firefox is the new Mozilla", it doesn't mean that Mozilla suddenly becomes a bad, inadequate, or obsolete product. As you note, they ARE very different applications, and this is the problem - the group that says "Firefox is the new Mozilla" doesn't appreciate that some of the Mozilla hackers and users don't *want* a new Mozilla.
Imagine you had a group of volunteers building a car like the Accord, and one year the "head honcho" says "next year's model will be a Civic". Many people love the Civic, and it becomes hugely popular. Is it so wrong for the Accord designers to still keep maintaining their Accord line if they have the necessary skills and resources?
What you have to understand is that this is not just a version increment - it's a new product which can live in parallel. The developers mentioned in the story mostly want to know whether the head honcho of the volunteer group will let them develope the same way they used to, or if they have to create their own group with its own things.
Sorry, I thought people != developers was implied.
Anyway, as I've mentioned in other comments, improving Firefox is not an option - for a couple of reasons. First, things I see as improvements the Firefox devs often don't. Suite developers have a more similar vision. Second, things Firefox devs may also see as improvements can't be done because they don't want to change things after 1.0 (now that users are used to them). If I wanted to fork Firefox to make my own "improved" version, I could, but it would have only one user (and take a lot of effort to maintain, if it diverged much). With Mozilla, other developers, and at least a few thousand other people use it.
Mozilla vs Firefox is not Linux 2.4 vs Linux 2.6, it's more like FreeBSD vs NetBSD or KDE vs GNOME. An even better analogy might be Sawfish vs Metacity (ignoring that these probably don't share much code).
I don't think there would be a significant security difference - the backend code is shared, and most holes (besides UI spoofing type holes) are in the backend (I don't think UI differences could create a buffer overflow hole, for example). However, when it comes to stability and reliability, that's when the coding pracitces come into play.
The new options window for Firefox introduced many new bugs - for example, the code that was checked in doesn't even WORK! (The window is 100% transparent and unusable). There are plenty of problems with it.
Another example is the yellow information bar (which I spoof in the link above) - when I was porting it to Mozilla, with minutes of testing I found serious problems it caused. After fixing those issues, I found and fixed more subtle ones. The Firefox code had been checked in, apparently with almost no testing, let alone code review. Yes, users found the bugs and filed them, but I don't trust users to find many of the less overt bugs.