Gecko developer Boris Zbarsky answered this question last December. Firefox 3 will support Acid 2, while Firefox 2 could not have supported it without being delayed until around the time Firefox 3 will ship.
I'm pretty sure the option I mentioned controls target="_blank" links (perhaps in addition to links from other apps). I just tried toggling it and it did affect what happened when I clicked a target="_blank" link.
Probably, but I doubt it's hard for phishers to avoid or adds any significant amount of security to what really is a default-allow system. (I'm not saying "default-allow" as if that's always a bad thing...)
I think it's more important for feeds to be consistent with other feeds, and offer useful subscription options, than for them to be consistent with the rest of the site. After all, if you wanted the look of the site you'd just go to the front page of the site.
That said, there are some who agree with you. See bug 338621. I suggest that you vote for it (but not add a comment unless you really have something to add, since the bug already has plenty of angry/ranty comments that don't add anything).
I personally prefer using separate windows for each page, not tabs. This behaviour is no longer customizable in the Options and it took quite a while finding the about:config option for this. Frankly why this was left out of the tabs tab in the Options is beyond me since that tab is half empty anyway.
Which option are you talking about? I see a "new pages should be opened in..." option under Tabs in Options, and selecting that does what at least 80% of users mean when they say "I prefer windows to tabs". There are dozens of ways to open new windows or tabs by default, and only some of them can be configured to open tabs instead of windows or windows instead of tabs. (For example, "Open Link in New Window" can't be configured to open a new tab instead.)
I wouldn't go as far as saying that it's "clearly wrong". Firefox is able to display the feed nicely *and* show subscription options; XSLT can't do that. The XSLT is probably there primarily to keep the feed from being ugly in old versions of Firefox.
This argument is unclear. One of the antiphishing modes uses a blacklist and the other submits URLs to Google. So it at worst is not both weak and privacy-violating at the same time.
It's still a blacklist if it's on the server. Blacklists are limited in effectiveness against targeted attacks or phishing pages distributed across a botnet.
I'm not sure why the author of the article is unhappy with this. The arguments I've heard are (1) advertising that Firefox includes anti-phishing may make users complacent in checking the URL before entering a password, and (2) it would be nice if Firefox could also (or instead) use some heuristics to detect things that look like phishing sites.
I don't think (1) makes having blacklist-based anti-phishing worse than not having it at all. (2) is wishful thinking given CSS and JavaScript.
But IMO, browser makers can't rely on blacklist-based protection. We need to improve the UI for authenticating sites (e.g. highlight part of the hostname in the address bar) and should do things to educate users (make sure they know what a hostname is, how a phishing attack works, and why relying on The Law to protect them will not work).
(Of course, given that Google doesn't actually do anything with this data other than feed it into their anti-phishing database, I don't consider it a violation of privacy regardless, but we have options precisely because not all users will feel this way.)
That's good to know. Google loves to sell other aggregate data, so it's nice to know that they've promised to keep this data extra-private.
I actually got used to the NoScript addon... and when I go to that page nothing happens to me
Neither the too-much-recursion crash nor the security hole requires JavaScript. The too-much-recursion crash can be triggered by deeply nested XML, and the bug for the security hole crash has a testcase that doesn't involve JavaScript at all, afaict.
Many annoyances and security holes do involve JavaScript, of course; I'm just saying that these two don't.
as a matter of fact I think mozilla should include it by default, seriously.
I agree. Not on by default, because it would break half the web, but included as part of a good site-specific-options UI.
A few months ago, someone reported a security hole using a testcase that caused two types of crashes, one exploitable and the other not. The security hole was fixed reasonably quickly, but the other crash is a hard-to-fix collection of too-much-recursion crashes, so it hasn't been fixed yet. The security hole is bug 348514 and the too-much-recursion crash is 323394.
I can understand a few people getting confused due to an old security-hole testcase still causing a crash, but having it come up in mainstream news articles and Slashdot articles as "Firefox 2 might have shipped with a known security hole" day after day is getting annoying.
Afaik, adding new elements to the HTML namespace is orthogonal to whether the parsing is SGML-inspired tag-soup parsing or straightforward XML parsing. It will not become harder to use XHTML.
Firefox includes a fairly easy way for JavaScript to tell you whether some XML is well-formed or not. So if you use a WordPress blog (which defaults to XHTML) and this user script, you can get a helpful but unobtrusive warning when a blog post you're about to submit isn't well-formed. (This trick works even if you plan to serve the XHTML as text/html.)
With XHTML, you can embed SVG, MathML, and XUL elements if the browser supports them. With HTML, you can't (except using JavaScript and document.createElementNS).
And in the future, I imagine that browsers will be able to parse XHTML a bit faster than HTML. But for now, Firefox is slower for XHTML (see bug 18333).
Official version of Firefox for Windows are compiled with MSVC. You can also compile it with gcc on Windows, but currently not with Intel's compiler. If you're interested in fixing it to work with Intel's compiler, I don't think it would be too hard to get your patches checked in.
Opera, which has to run on small devices such as cell phones, is quite a bit better at handling memory allocation failures. As Firefox is ported to cell phones and its code is simplified, I imagine it will get significantly better at handling OOM situations. But for now, with Firefox only running on desktop OSes that pretty much never fail when you call malloc or new, I don't see why anyone would care that it crashes when you artificially limit the amount of memory it is allowed to use. Unless you're encountering really bad memory leaks, in which case you'd be thrashing well before hitting OOM anyway.
Not quite a complete rewrite. The JavaScript engine "Spidermonkey" survives from Netscape 4, at least. (That's just the JavaScript language implementation, not DOM functions.)
It also depends on what sites you visit. For example, Firefox 1.5.0.x leaked quite a bit on Gmail. Firefox 2 includes a fix for this leak, and I think Google also worked around the bug to avoid triggering leaks in Firefox 1.5.0.x.
I agree that calling this release Firefox 1.6 would have made more sense in some ways, but that hardly sounds like a reason to recommend Opera over Firefox.
The new "yield" and "let" keywords only work if you specify version 1.7. The other new features (array comprehensions, destructuring assignment, and maybe catchguards) are always enabled. Trying to use them in an older version would cause a syntax error, so you shouldn't have to worry about incompatibilities.
XUL pages don't have any privileges (or abilities to toss up dialogs that request privileges) that HTML pages don't have, unless I'm missing something. Do you have a demo?
Yeah, right. What they are really saying is, why give away a bug for $500 when we can sell it for much more on the black market?
If CNET hadn't cut off my quote mid-sentence, it would have been clear that that was what (jokingly) saying too. I was not trying to bribe them. I was trying to say that I hoped they would change their minds and report the holes to Mozilla despite the fact that they (claimed they) could make much more money exploiting the holes or selling information about the vulnerabilities on the black market.
Slashdot Mirror
Gecko developer Boris Zbarsky answered this question last December. Firefox 3 will support Acid 2, while Firefox 2 could not have supported it without being delayed until around the time Firefox 3 will ship.
I'm pretty sure the option I mentioned controls target="_blank" links (perhaps in addition to links from other apps). I just tried toggling it and it did affect what happened when I clicked a target="_blank" link.
Probably, but I doubt it's hard for phishers to avoid or adds any significant amount of security to what really is a default-allow system. (I'm not saying "default-allow" as if that's always a bad thing...)
I think it's more important for feeds to be consistent with other feeds, and offer useful subscription options, than for them to be consistent with the rest of the site. After all, if you wanted the look of the site you'd just go to the front page of the site.
That said, there are some who agree with you. See bug 338621. I suggest that you vote for it (but not add a comment unless you really have something to add, since the bug already has plenty of angry/ranty comments that don't add anything).
I personally prefer using separate windows for each page, not tabs. This behaviour is no longer customizable in the Options and it took quite a while finding the about:config option for this. Frankly why this was left out of the tabs tab in the Options is beyond me since that tab is half empty anyway.
Which option are you talking about? I see a "new pages should be opened in..." option under Tabs in Options, and selecting that does what at least 80% of users mean when they say "I prefer windows to tabs". There are dozens of ways to open new windows or tabs by default, and only some of them can be configured to open tabs instead of windows or windows instead of tabs. (For example, "Open Link in New Window" can't be configured to open a new tab instead.)
I wouldn't go as far as saying that it's "clearly wrong". Firefox is able to display the feed nicely *and* show subscription options; XSLT can't do that. The XSLT is probably there primarily to keep the feed from being ugly in old versions of Firefox.
This argument is unclear. One of the antiphishing modes uses a blacklist and the other submits URLs to Google. So it at worst is not both weak and privacy-violating at the same time.
1 0/sometimes_its_j.html and http://www.squarefree.com/2006/10/28/san-diego-fir efox-party/ for how it could be improved. But I'm willing to attribute that to being rushed rather than being sneaky.
It's still a blacklist if it's on the server. Blacklists are limited in effectiveness against targeted attacks or phishing pages distributed across a botnet.
I'm not sure why the author of the article is unhappy with this. The arguments I've heard are (1) advertising that Firefox includes anti-phishing may make users complacent in checking the URL before entering a password, and (2) it would be nice if Firefox could also (or instead) use some heuristics to detect things that look like phishing sites.
I don't think (1) makes having blacklist-based anti-phishing worse than not having it at all. (2) is wishful thinking given CSS and JavaScript.
But IMO, browser makers can't rely on blacklist-based protection. We need to improve the UI for authenticating sites (e.g. highlight part of the hostname in the address bar) and should do things to educate users (make sure they know what a hostname is, how a phishing attack works, and why relying on The Law to protect them will not work).
(Of course, given that Google doesn't actually do anything with this data other than feed it into their anti-phishing database, I don't consider it a violation of privacy regardless, but we have options precisely because not all users will feel this way.)
That's good to know. Google loves to sell other aggregate data, so it's nice to know that they've promised to keep this data extra-private.
It does seem suspicious that in the "server-side blacklist" mode, we're sending Google much more data than they need in order to implement blacklist-based anti-phishing. See comments on http://weblogs.mozillazine.org/asa/archives/2006/
I actually got used to the NoScript addon ... and when I go to that page nothing happens to me
Neither the too-much-recursion crash nor the security hole requires JavaScript. The too-much-recursion crash can be triggered by deeply nested XML, and the bug for the security hole crash has a testcase that doesn't involve JavaScript at all, afaict.
Many annoyances and security holes do involve JavaScript, of course; I'm just saying that these two don't.
as a matter of fact I think mozilla should include it by default, seriously.
I agree. Not on by default, because it would break half the web, but included as part of a good site-specific-options UI.
It's not actually a security issue.
A few months ago, someone reported a security hole using a testcase that caused two types of crashes, one exploitable and the other not. The security hole was fixed reasonably quickly, but the other crash is a hard-to-fix collection of too-much-recursion crashes, so it hasn't been fixed yet. The security hole is bug 348514 and the too-much-recursion crash is 323394.
I can understand a few people getting confused due to an old security-hole testcase still causing a crash, but having it come up in mainstream news articles and Slashdot articles as "Firefox 2 might have shipped with a known security hole" day after day is getting annoying.
Thanks, anonymous coward, for turning the bulleted list into a numbered list. It helps to be able to reference numbers when replying.
Sure, there's restore session, great. Does it restore the text of the email/post/whatever that I was typing? No, of course not.
Actually, it does.
Afaik, adding new elements to the HTML namespace is orthogonal to whether the parsing is SGML-inspired tag-soup parsing or straightforward XML parsing. It will not become harder to use XHTML.
Two small advantages to using XHTML:
Firefox includes a fairly easy way for JavaScript to tell you whether some XML is well-formed or not. So if you use a WordPress blog (which defaults to XHTML) and this user script, you can get a helpful but unobtrusive warning when a blog post you're about to submit isn't well-formed. (This trick works even if you plan to serve the XHTML as text/html.)
With XHTML, you can embed SVG, MathML, and XUL elements if the browser supports them. With HTML, you can't (except using JavaScript and document.createElementNS).
And in the future, I imagine that browsers will be able to parse XHTML a bit faster than HTML. But for now, Firefox is slower for XHTML (see bug 18333).
Official version of Firefox for Windows are compiled with MSVC. You can also compile it with gcc on Windows, but currently not with Intel's compiler. If you're interested in fixing it to work with Intel's compiler, I don't think it would be too hard to get your patches checked in.
Opera, which has to run on small devices such as cell phones, is quite a bit better at handling memory allocation failures. As Firefox is ported to cell phones and its code is simplified, I imagine it will get significantly better at handling OOM situations. But for now, with Firefox only running on desktop OSes that pretty much never fail when you call malloc or new, I don't see why anyone would care that it crashes when you artificially limit the amount of memory it is allowed to use. Unless you're encountering really bad memory leaks, in which case you'd be thrashing well before hitting OOM anyway.
Not quite a complete rewrite. The JavaScript engine "Spidermonkey" survives from Netscape 4, at least. (That's just the JavaScript language implementation, not DOM functions.)
It also depends on what sites you visit. For example, Firefox 1.5.0.x leaked quite a bit on Gmail. Firefox 2 includes a fix for this leak, and I think Google also worked around the bug to avoid triggering leaks in Firefox 1.5.0.x.
You'd rather not be able to customize toolbars?
Which Google plugin -- the official Google Toolbar? Do David Baron and Google know about the problem?
I do see something about the Google Toolbar listed on the problematic extensions page but not on Hendikins' Firefox memory usage FQA. Hmm.
I agree that calling this release Firefox 1.6 would have made more sense in some ways, but that hardly sounds like a reason to recommend Opera over Firefox.
The new "yield" and "let" keywords only work if you specify version 1.7. The other new features (array comprehensions, destructuring assignment, and maybe catchguards) are always enabled. Trying to use them in an older version would cause a syntax error, so you shouldn't have to worry about incompatibilities.
I wonder why the New in JavaScript 1.7 page doesn't say anything about this.
XUL pages don't have any privileges (or abilities to toss up dialogs that request privileges) that HTML pages don't have, unless I'm missing something. Do you have a demo?
No. Those three bugs were holes I found before ToorCon.
Yeah, right. What they are really saying is, why give away a bug for $500 when we can sell it for much more on the black market?
If CNET hadn't cut off my quote mid-sentence, it would have been clear that that was what (jokingly) saying too. I was not trying to bribe them. I was trying to say that I hoped they would change their minds and report the holes to Mozilla despite the fact that they (claimed they) could make much more money exploiting the holes or selling information about the vulnerabilities on the black market.
It's interesting that this is the only one on the top five list that has anything to do with the programming.
I disagree. #2 and #5 also refer to software vulnerabilities (indirectly). If software didn't have vulnerabilities, #2 and #5 wouldn't be issues.