It was a glitch in dynamic inclusion of external scripts through the document.write("<script...></script>") hack used by some AJAX libraries (e.g. Scriptacolous on Digg).
This was an rare problem under normal conditions, but NoScript filters used to make it appear more frequently.
While I agree that free software fits well with marxism (but they're not the same and the former doesn't imply the latter), the most important alleged reason for the switch is something that every government (other than U.S.?) and every business/individual (U.S. citizens included) should focus:
Cuban officials, ever focused on U.S. threats, also see it as a matter of national security.
We're not talking about Linux being less prone to viruses than Windows, here. It's a deeper flaw:
Communications Minister Ramiro Valdes raised suspicions about Microsoft's cooperation with U.S. military
Stallman also warned that proprietary software is a security threat because without being able to examine the code, users can't know what it's doing or what "backdoor" holes developers might have left open for future entry. "A private program is never trustworthy," he said.
And he's damn right. It scares the hell out of me how many people, and even governments, are blindly putting their lives in the hands of one single corporation which even
boasts its ties with an espionage agency.
The main difference is that new features and "risky" fixes (i.e. large patches with high regression danger) are almost never accepted in a branch, unless they answer an urgent security need.
Trunk, instead, is considered a playground for innovation, but changes are nevertheless bound to the same proposal/discussion/review/commit life cycle.
Every single change in the Mozilla code base is proposed/discussed in a Bugzilla entry, usually called "a bug" no matter if it refers to a defect to be fixed, an enhancement or a new feature.
Patches are attached to those "bugs", and they always require peer review to be accepted and eventually committed, even if they come from Mozilla Corporation paid staff.
Joost, formerly known as The Venice Project, gets most of its "cool factor" in the geek circles from being built over the Mozilla XUL Runner. In other words, its client is based on XUL, SVG, JavaScript and XPCOM, just like Firefox, as outlined in this article.
Re:I failed to see how this'll help
on
HTML Encoded Captchas
·
· Score: 2, Informative
Gecko is absolutely overkill there: the HTML "encoding" is pretty lame, as the image is entirely made of 1px table cells, each one carrying its color information inlined in the style attribute.
Just one Perl line can extract the color matrix and pass it straight to your OCR algorithm.
Maybe if they used JavaScript to render the table on the client side, that would require Gecko or something like that (SpiderMonkey or Rhino would likely suffice), but still the complexity of a captcha cracker is noise reduction and character recognition, rather than image decoding.
That said, I've seen no "Content-encoding: gzip" in their response: gzip encoding cannot be remotely compared to jpeg compression, but it would nevertheless cut the weight of a very redundant HTML table by a 1:16 factor or more... (hurry up guys, you've been slashdotted!)
VideoLAN - VLC Media Player is an all-in-one open source and cross platform program which does much more than WMP: it's an user-friendly player, but also a powerful and flexible transcoder for almost every audio/video format and even a stream server supporting various network protocols.
Worth a try as a better replacement, especially for power users.
I wrote this Firefox add-on just after one of these disclosures, because the majority of the browser vulnerabilities was JavaScript related, and the suggested work-around was always "turn off JavaScript".
Disabling JavaScript as a whole seemed quite an impractical advice to me in this AJAXified Web 2.0: I thought that maintaining a white-list of trusted sites allowed to run JavaScript and keeping all the unknown web content "static" until I decided otherwise was a still safe but more convenient approach.
Since then I've been browsing the web with my shields up (NoScript can block also Java, Flash and other plugins), but I allow on the fly with one click, either temporarily or permanently, those sites which I trust and which do need dynamic client side technologies to work properly.
To my surprise in 1 year and half I found few sites belonging to this category, because most places I usually browse are well designed enough to work with plain XHTML/CSS and nothing else (like Slashdot itself).
Notice: Firefox is a very safe browser because its vulnerabilities gets patched very quickly, once they're found by developers. I'm a Firefox contributor myself, and I'm very proud of the quality of the Mozilla developers community. NoScript, though, provides some extra protection even against those JavaScript/Java related vulnerabilities which have not been found yet...
But NoScript can be configured to block Flash movies as well and behave like FlashBlock (i.e. enabling them on demand with one click): NoScript FAQ 1.3.
"Levy and Gribble didn't set out to verify that, but they did note that the few successful spyware attacks on Firefox were made by Java applets", but they can be easily blocked and allowed on trusted domains only using the NoScript Firefox extension, which takes care the same way of JavaScript, Flash and other plugins for a paranoid yet usable security level:)
I'm already testing and I'm about to release a NoScript version (1.1.3.6) which neutralizes this lovely ping attribute on untrusted sites, and offers also an user-accessible option, not implemented by Firefox (yet?), to disable it globally. I hope this will calm down the tinfoil hats;)
NoScript users have been asking for black-list JavaScript/Java blocking since the beginning, but I'm still convinced white-list approach is the only way to go, when it comes to security. How can you tell for sure the link you're about to follow with a careless click (or, worse, the popup that is about to open without your consent) leads to a "safe place"?
The bug has been disclosed by Mozilla staff and a patch fixing the reported buffer overflow has already been applied to the CVS tree, so expect a public security update very soon. In the meanwhile, as a temporary work-around, you can fully protect your browser opening "about:config" and setting the network.enableIDN preference to false, see the full story here.
Slashdot Mirror
I guess ZoneAlarm registered customers may be surprised in finding how their own original login page works.
Even if you're not a registered user, just follow the link above and enter fake credentials.
The game becomes spicier if you have auto-completion enabled for that form...
Have fun with those antiphishing toys ;)
Original proof of concept courtesy of Elio, original XSS courtesy of .mario.
An add-on leaking a lot on window closure is Firebug, and I bet you've got it...
Toby, care to tell me where you got this info about leaks?
A "leak on window closure" regression appeared in NoScript 1.1.4.6.070322 (an "unofficial" development build) and was fixed 3 days later.
Since then I keep Leak Monitor in my development profile, even if it's a pain because of Firebug's and Venkman's leaks... ;)
Later NoScript versions are completely leak-free (see the changelog).
It was a glitch in dynamic inclusion of external scripts through the document.write("<script...></script>") hack used by some AJAX libraries (e.g. Scriptacolous on Digg). This was an rare problem under normal conditions, but NoScript filters used to make it appear more frequently.
Good news is that current NoScript 1.1.4.7 Release Candidate fixes this issue once (hopefully) for ever.
Obviously enough, NoScript users were immune from all these vulnerabilities, and from most of the yet to be discovered ones too :P
While I agree that free software fits well with marxism (but they're not the same and the former doesn't imply the latter), the most important alleged reason for the switch is something that every government (other than U.S.?) and every business/individual (U.S. citizens included) should focus:
We're not talking about Linux being less prone to viruses than Windows, here. It's a deeper flaw:
Suspicions?And he's damn right. It scares the hell out of me how many people, and even governments, are blindly putting their lives in the hands of one single corporation which even boasts its ties with an espionage agency.
Yes, peer review applies to the trunk as well.
The main difference is that new features and "risky" fixes (i.e. large patches with high regression danger) are almost never accepted in a branch, unless they answer an urgent security need.
Trunk, instead, is considered a playground for innovation, but changes are nevertheless bound to the same proposal/discussion/review/commit life cycle.
--
There's a browser safer than Firefox, it is Firefox, with NoScript.
Still accepting candy from the strangers?
Default permit is the dumbest idea in security (well, default passwords can't even qualify as "ideas" ;) )
--
There's a browser safer than Firefox, it is Firefox, with NoScript.
This is not true.
Every single change in the Mozilla code base is proposed/discussed in a Bugzilla entry, usually called "a bug" no matter if it refers to a defect to be fixed, an enhancement or a new feature.
Patches are attached to those "bugs", and they always require peer review to be accepted and eventually committed, even if they come from Mozilla Corporation paid staff.
So, "they just commit" applies to nobody.
Joost, formerly known as The Venice Project, gets most of its "cool factor" in the geek circles from being built over the Mozilla XUL Runner. In other words, its client is based on XUL, SVG, JavaScript and XPCOM, just like Firefox, as outlined in this article.
Gecko is absolutely overkill there: the HTML "encoding" is pretty lame, as the image is entirely made of 1px table cells, each one carrying its color information inlined in the style attribute.
Just one Perl line can extract the color matrix and pass it straight to your OCR algorithm.
Maybe if they used JavaScript to render the table on the client side, that would require Gecko or something like that (SpiderMonkey or Rhino would likely suffice), but still the complexity of a captcha cracker is noise reduction and character recognition, rather than image decoding.
That said, I've seen no "Content-encoding: gzip" in their response: gzip encoding cannot be remotely compared to jpeg compression, but it would nevertheless cut the weight of a very redundant HTML table by a 1:16 factor or more... (hurry up guys, you've been slashdotted!)
VideoLAN - VLC Media Player is an all-in-one open source and cross platform program which does much more than WMP: it's an user-friendly player, but also a powerful and flexible transcoder for almost every audio/video format and even a stream server supporting various network protocols.
Worth a try as a better replacement, especially for power users.
The motivation has changed... (sorry gerv, I couldn't resist)
... it is Firefox with NoScript :)
I wrote this Firefox add-on just after one of these disclosures, because the majority of the browser vulnerabilities was JavaScript related, and the suggested work-around was always "turn off JavaScript".
Disabling JavaScript as a whole seemed quite an impractical advice to me in this AJAXified Web 2.0: I thought that maintaining a white-list of trusted sites allowed to run JavaScript and keeping all the unknown web content "static" until I decided otherwise was a still safe but more convenient approach.
Since then I've been browsing the web with my shields up (NoScript can block also Java, Flash and other plugins), but I allow on the fly with one click, either temporarily or permanently, those sites which I trust and which do need dynamic client side technologies to work properly. To my surprise in 1 year and half I found few sites belonging to this category, because most places I usually browse are well designed enough to work with plain XHTML/CSS and nothing else (like Slashdot itself).
Notice: Firefox is a very safe browser because its vulnerabilities gets patched very quickly, once they're found by developers. I'm a Firefox contributor myself, and I'm very proud of the quality of the Mozilla developers community. NoScript, though, provides some extra protection even against those JavaScript/Java related vulnerabilities which have not been found yet...
But NoScript can be configured to block Flash movies as well and behave like FlashBlock (i.e. enabling them on demand with one click): NoScript FAQ 1.3.
"Levy and Gribble didn't set out to verify that, but they did note that the few successful spyware attacks on Firefox were made by Java applets ", but they can be easily blocked and allowed on trusted domains only using the NoScript Firefox extension, which takes care the same way of JavaScript, Flash and other plugins for a paranoid yet usable security level :)
I'm already testing and I'm about to release a NoScript version (1.1.3.6) which neutralizes this lovely ping attribute on untrusted sites, and offers also an user-accessible option, not implemented by Firefox (yet?), to disable it globally. I hope this will calm down the tinfoil hats ;)
NoScript 1.1.3.5 prevents all the possible variants anyway truncating titles (JavaScript forged or not) to 255 characters by default.
NoScript users have been asking for black-list JavaScript/Java blocking since the beginning, but I'm still convinced white-list approach is the only way to go, when it comes to security. How can you tell for sure the link you're about to follow with a careless click (or, worse, the popup that is about to open without your consent) leads to a "safe place"?
The bug has been disclosed by Mozilla staff and a patch fixing the reported buffer overflow has already been applied to the CVS tree, so expect a public security update very soon. In the meanwhile, as a temporary work-around, you can fully protect your browser opening "about:config" and setting the network.enableIDN preference to false, see the full story here.