InformAction Forums

(This lengthy, but very interesting, discussion was split from NoScript > General, "Chrome, NoScript, and WebRequest API", as the specific questions in the OP there had been answered. The responses in this post are to the divergent issues that came up in the resolving reply to the other thread. -- Tom T.)


Hi Tom,

Thanks for the response - I don't mind waiting.

I'll respond in bits and pieces now that I've read the full post.

Why would a huge corporation that makes its living selling advertising (mostly targeted) and user data ever want its users to install an add-on that would block advertising scripts and data-mining scripts, including Google's bread-and-butter, google-analytics.com? ... which NoScript blocks *by default*, and runs a Surrogate Script in its place. This makes the page happy that the script ran, but sends no actual data to Google. Yeah, they'll really let that happen on *their* browser.

Google as a company makes (literally) 99% of their revenue from ads alone. And yet the WebRequest API allows for ads to not only be blocked but for the ad-requests to be blocked entirely.

Furthermore, all Google ads are "by-click" and not "by-view" so even the old method of adblocking, which has been on Chrome for about 2 years now, is killing profits just as effectively as one that stop tracking/ ads simply from being viewed. It is a matter of clicks and not downloads.

So why would Google allow for this? I wouldn't really try to guess. It could simply be "If we can't beat them join them" issue or, as I suspect, it's actually a movement to have the "annoying" ads blocked - Google recently began patenting differences between what "good" and "bad" ads are and the rumor is that Chrome will outright block "bad" ads by default leaving not much to the competition.

So right there it's quite easy to see how and why a company like Google would allow for ads to be blocked in their browser.

I think it's also important to note that in 2008 we saw adblockers on ~3% of Firefox browsers. In the grand scheme of things that isn't a hell of a lot. Maybe it's doubled in the last 3 years and even still.... not a ton of people.

Whereas Giorgio Maone has 20 years, not months, in developing, and freely gives his real name, e-mail address, company address and telephone number. You would trust an anonymous person to take complete control of your browser? What is he so afraid of?

There is no obfuscated Javascript in the extension - we both know how simple it is to unpack and view them.

I myself am a student and I plan on writing a program. I have definitely wondered how public I'd be willing to go about the project. The nice thing about a project running in Javascript is that you can deobfuscate code easily and I don't believe there's anything hidden in the Google code, which can be viewed here:
http://code.google.com/p/scriptno/source/checkout

"A 'NoScript-like' extension"... Really? Aside from the name rip-off, does it have NoScript's level of:

XSS protection?
Clickjacking protecton?
CSRF protection and WAN-LAN boundary protection?
Ability to force HTTPS security on sites that should have it (your bank), but may carelessly send insecure cookies?

Nope. I don't think it claims to - the main feature would certainly be the whitelisting of page elements by page and/or domain.

As for XSS protection I've seen Chrome's own filter bypassed but it's there.

As for HTTPS I can assume it'll be coming fairly soon as the WebRequest API continues development, it does solve the issues (you block and redirect sites rather than reloading with the https as the extensions currently do.)

Plus many other protections, like "Forbid WebGL", a technology that has already been expoloited), and more to come, in a product that is constantly evolving and improving, thanks in part to suggestions from users through this forum, which ATM has more than 20,000 registered members + guest posting allowed, and almost 30,000 posts on almost 5,000 topics. And which was once a part of Mozilla support, but when the user base and the feature list demanded more than *ONE* thread at Mozilla, Mr. Maone chose to host this forum on his own servers, *at his own expense*.

WebGL is one of the most interesting exploitable techs to come out in a while - it's been of great interest to me.

WebGL does need JS to run, of course, so ScriptNo protects just fine with that (though it could block canvas specifically.) And, of course, Chrome has an about:flags to disable WebGL globally.

Can you link to WebGL being exploited? I don't think that's the case. Maybe a Proof of Concept... if even.

it still slipped up in letting your post go unanswered for so long, but genuine bugs, user support, and enhancements get first priority -- I'm sure you understand.

Absolutely - as I said I don't mind waiting for a proper discussion. I'm just happy that you put so much work into the response - I hate waiting only to get a "no, topic closed" =p

I could be mistaken, but I don't see Google letting NS rob them of the revenue from their Chrome users, nor do I see their "NoScript-like" add-on ever coming close to this one. But please browse the NoScript "Features" Page and the NoScript FAQ, and decide for yourself.

Like I said, it's already been happening. Not only can we see Google already allowing for an API that blocks ads properly, we can see in the past how this has already done enough to hit revenue, and in the future we can see how this can be turned to their advantage.

Also keep in mind that chromium is open source. There's definitely community devs.

Regarding browser sandboxing, it might be nice for Firefox and SeaMonkey to implement this. But IMHO, letting the browser sandbox itself is like trying to lift yourself up by your bootstraps. If the browser is compromised, how can it protect its own sandbox? Much better is to let your sandboxing solution run on your operating system, *independently of the browser*. Then, if the browser is compromised, the malware cannot escape through to the hard drive. After all, much of MS' security issues with IE were based on, or worsened by, the fact that IE *is an integral part of the Windows OS*.

A fair point but I'd say you misunderstand the sandboxing mechanism. Chrome does not handle the sandbox to most extents - it is based on the Windows integrity system and then only hardened from within. That's the basis of it.

So the sandbox is very much a separate mechanism from the Chrome browser though there are certainly mechanisms within the program as well (individual tab separation as opposed to file access restrictions for every process/ broker.)

Nope. Let the sandboxer run on the OS, and then let the browser run in the *independent* sandbox thus created. (I have been satisfied with Sandboxie, but that's just personal experience and opinion only, not an endorsement. But it meets the above criterion of being outside the browser instead of inside it.)

I had a conversation with Tzuk recently actually but I won't go into that. I will say that no third party security software will be able to compete with what's built into the kernel (in terms of security.)

As for the topic there, "Safest browser?" Firefox and SeaMonkey, in their default states, ... wouldn't know. Always using NoScript. Fx and SM + NoScript (properly configured): I defy anyone to show another readily-available, mass-market browser suitable for both home and enterprise use that is equally protected from such a wide range of Web exploits, *and whose developer responds so rapidly to emergent threats*.

This will possibly sound like I'm knocking NoScript but I would not call it enterprise-ready. I can only imagine the nightmare of deploying it at an enterprise level "Why won't my site work? How do I do this?"

And of course a fair portion of NoScripts protection is down the drain as soon as the user whitelists the site - not by any means all of it, of course, but a fair bit.

As for being equally protected from exploits? I dare you to find a single Chrome exploit that breaks out of the wild - Vupen managed to... apparently, but it was never released and I sincerely doubt it still works.

In the end NoScript + Firefox and Chrome (vanilla) are both very strong. Both are weak to social engineering (I believe Chrome has an 18% block rate and Firefox a 13%?) and that's not much to brag about for either party.

Anyways, it's a bit of a silly argument to have here.

I was really just curious how many issues with NoScript for Chrome could be solved with the latest experimental extensions APIs (most notably WebRequest.)

As to whether or not I consider Firefox as secure as Chrome it's a matter of my own basic principles - I will almost always find that the software that utilizes OS-based security is the most secure.

Hungry Man wrote:Can you link to WebGL being exploited?

There was potential for being exploited:

• Potentially exploitable WebGL crashes
• String crash using WebGL shaders
• WebGLES vulnerabilities
• Stealing of cross-domain images using WebGL textures
• Multiple WebGL crashes

No I meant an in-the-wild exploit. I know there have been vulnerabilities shown and proven.

Hungry Man wrote:Google as a company makes (literally) 99% of their revenue from ads alone. And yet the WebRequest API allows for ads to not only be blocked but for the ad-requests to be blocked entirely.

Furthermore, all Google ads are "by-click" and not "by-view" so even the old method of adblocking, which has been on Chrome for about 2 years now, is killing profits just as effectively as one that stop tracking/ ads simply from being viewed. It is a matter of clicks and not downloads.

So why would Google allow for this? I wouldn't really try to guess. It could simply be "If we can't beat them join them" issue

Interesting info, thanks. I suspect that they realize that if there were no ad-blocking capability at all, most users would choose another browser.

They still get a good deal of marketable user data from Google searches, and my tinfoil-hat side tends to, uh, "doubt" their statements that the browser doesn't send some marketable data to Google about their users. I can't prove that, partly because I've never used Chrome, and partly because I don't care to go to the trouble of setting up Wireshark or vetting their code. [[ I found evidence of it later in this post.]] But when Chrome first was announced, the gut instinct was, "Who in the world would use a browser *made by an advertising company*?" -- especially since Google now owns Doubleclick, one of the most notorious privacy-violators.

or, as I suspect, it's actually a movement to have the "annoying" ads blocked - Google recently began patenting differences between what "good" and "bad" ads are

Huh? "patenting differences between ads?" I hereby claim a patent on my tech support methods and writing style. Anyone who uses them has to pay me royalties.

and the rumor is that Chrome will outright block "bad" ads by default leaving not much to the competition.

Ahhh, the light dawns --- all non-Google ads will be blocked, and Google ads will not. Oh, for the early days, when their motto was, "It is possible to make money without doing evil."

I think it's also important to note that in 2008 we saw adblockers on ~3% of Firefox browsers. In the grand scheme of things that isn't a hell of a lot. Maybe it's doubled in the last 3 years and even still.... not a ton of people.

I don't have an adblocker on my Fx 3.6.24, and hardly ever see ads.
For one thing, the days when ads were just text and still images are pretty much gone. Most are served by scripting, often with Flash videos. NoScript takes care of both. I also use a HOSTS file service that blocks any *attempts* to connect with 16,000+ sites. (If I type www dot doubleclick.net, I get a "can't connect" error message.)

For another, any ads based on still images are easily blocked by adding the source to Firefox Tools > Options > Content > Load images automatically > Exceptions.

So I'm in your 97% without an ad blocker. Maybe it's because Firefox + NoScript doesn't *need* one?

Tom T. wrote:Whereas Giorgio Maone has 20 years, not months, in developing, and freely gives his real name, e-mail address, company address and telephone number. You would trust an anonymous person to take complete control of your browser? What is he so afraid of?

Hungry Man wrote:There is no obfuscated Javascript in the extension - we both know how simple it is to unpack and view them.

Who said anything about obfuscated Javascript? I'm talking about obfuscated developer.
I merely visited the ScriptNo web site, looked at some of the FAQ, etc., and found that one about his anonymity.

It's not just a matter of spyware or malware -- definitely *not* making such accusations. I'm talking about being willing to stake your name and reputation on your product. Too buggy, or even worse, doesn't do its job -- user gets pwned -- no accountability. Start somewhere else under another pseudonym, and make another product.

As said, this type of program, whether NoScript or ScripNo, has complete control of your browser. You want me to trust you, but you don't want me to know who you are, where you are, or even what you look like? Whom do I sue?

Giorgio has a complete bio and profile at his own home page. Check it out. And compare its level of detail to the "mystery man" behind ScriptNo.

I myself am a student and I plan on writing a program. I have definitely wondered how public I'd be willing to go about the project.

I've had this same discussion with another student. He wanted to host his product at PortableApps.com, but Webmaster John T. Haller quite properly told him that if he wanted credit, he'd have to give his real name. Else, he could be listed as a contributor under his screen name, with a known, non-anonymous developer being in charge and getting prime credit.

Every add-on I have that has anything to do with security or privacy has the developer's real name (hopefully verified by Mozilla) attached to it.

"A 'NoScript-like' extension"... Really? Aside from the name rip-off, does it have NoScript's level of:

XSS protection?
Clickjacking protecton?
CSRF protection and WAN-LAN boundary protection?
Ability to force HTTPS security on sites that should have it (your bank), but may carelessly send insecure cookies?

Hungry Man wrote:Nope. I don't think it claims to - the main feature would certainly be the whitelisting of page elements by page and/or domain.

Well, as long as it doesn't claim to ... That will be comforting to the user who is pwned by an XSS, Clickjack, or CSRF attack, or has his bank login cookie stolen, or finds that his router has had its settings changed without him knowing it, including creating future remote access to the router's admin page without the user knowing. Whereupon, your .. well, just start thinking of all the evil a bad guy could do once he has complete control of your router.

But at least the poor user can say, "Well, he didn't claim that it would protect against it."
Or maybe not. Calling it a "NoScript-like extension", when it isn't even close to NoScript's capabilities -- it's "a whitelist-based script-blocker", and that's a better description. And the name is so close that we actually had a private discussion of whether Giorgio Maone could sue for trademark infringement, not that he would. But the name clearly tries to associate itself with NoScript, as does much of the promo material. Which could lead users into thinking that the two are roughly equivalent. Not even close.

Incidentally. to the extent that there may be an element of sarcasm in the language here, I'm sorry, but the above paragraph sums up what is actually irritating, if not irresponsible, about ScriptNo and its proponents. Which undoubtedly shows a bit in the style here.

As for XSS protection I've seen Chrome's own filter bypassed but it's there.

So what good is it?

Side note: It takes a hacker to stop a hacker. Giorgio Maone and his good friend, Sirdarckcat, tied for first place in a contest to write the smallest possible, fully self-replicating worm, in 161 bytes. So by one criterion, Giorgio is among the world's best hackers, and thank goodness he's on our side.

And his friend Sirdarckcat often tries to poke holes in NoScript, and if he can, he of course notifies Giorgio privately, and an update is issued.

Writing sw is one thing. Writing security sw is another. Writing sw to breach security is entirely different, and knowing how to do it gives one a huge leg up in knowing how to protect against it. In fact, many "new" web threats have been found to be *already defeated* by NoScript's existing protections.

How much hacking, white- or black-hat, has Mr. ScriptNo done?

Hungry Man wrote:As for HTTPS I can assume it'll be coming fairly soon as the WebRequest API continues development,

NoScript users have had it for more than three years now. NoScript is very often on the leading edge of security innovation. If you want to use the ones playing "catch-up", who never quite catch up, and hope that this issue doesn't affect you before the "assumed" improvement...

it does solve the issues (you block and redirect sites rather than reloading with the https as the extensions currently do.)

Not sure what you mean there. My bank is already secure. If they carelessly send me an insecure cookie, which could be accessed via some other technique, does your product force the cookies to be HTTPS only?

Tom T. wrote:Plus many other protections, like "Forbid WebGL", a technology that has already been exploited), and more to come, in a product that is constantly evolving and improving, thanks in part to suggestions from users through this forum, which ATM has more than 20,000 registered members + guest posting allowed, and almost 30,000 posts on almost 5,000 topics. And which was once a part of Mozilla support, but when the user base and the feature list demanded more than *ONE* thread at Mozilla, Mr. Maone chose to host this forum on his own servers, *at his own expense*.

Hungry Man wrote:WebGL is one of the most interesting exploitable techs to come out in a while - it's been of great interest to me.

WebGL does need JS to run, of course, so ScriptNo protects just fine with that (though it could block canvas specifically.)

With NoScript, you can allow a site's scripting while prohibiting WebGL. And since many sites break without scripting, using ScriptNo's "protection" (blocking JS), may break the site.

And, of course, Chrome has an about:flags to disable WebGL globally.

Didn't know that, thanks. But how conspicuous is it? I'm assuming about:flags is similar to about:config in Firefox? NoScript has a simple checkbox in the GUI so that novices who hesitate to tread past Firefox's warnings of dire consequences from mis-configuring about:config don't have to go there.

Hungry Man wrote:Can you link to WebGL being exploited? I don't think that's the case. Maybe a Proof of Concept... if even.

A Google search for "WebGL+exploit" gave about 1,200,000 results. No, I'm not going to go through them and give you a link , so pick your own favorite(s).

Tom T. wrote:it still slipped up in letting your post go unanswered for so long, but genuine bugs, user support, and enhancements get first priority -- I'm sure you understand.

Hungry Man wrote:Absolutely - as I said I don't mind waiting for a proper discussion. I'm just happy that you put so much work into the response - I hate waiting only to get a "no, topic closed" =p

Thank you. The topic deserved a very thorough reply, as does your response. So it needed some time that was not required for helping users with issues in the immediate moment.

Still, if you should ever post again, and you don't get at a reply within a week or so, *definitely* within two weeks, please feel free to give it a bump and ask for a response. Especially if it falls off of the home page for that forum -- "out of sight, out of mind". Nothing wrong with bumping it back up and asking if anyone's looking at the issue. (I'll PM you a short note later about this.)

Tom T. wrote:I could be mistaken, but I don't see Google letting NS rob them of the revenue from their Chrome users, nor do I see their "NoScript-like" add-on ever coming close to this one. But please browse the NoScript "Features" Page and the NoScript FAQ, and decide for yourself.

Hungry Man wrote:Like I said, it's already been happening. Not only can we see Google already allowing for an API that blocks ads properly, we can see in the past how this has already done enough to hit revenue, and in the future we can see how this can be turned to their advantage.

Thanks for the info on ads, and as you said, it may be merely an attempt to monopolize. Sort of MS-like behavior.

Also keep in mind that chromium is open source. There's definitely community devs.

But not one who's created something with all of NoScript's capabilities. The thing is, as you said, Google asked Giorgio to port NoScript to Chrome, but refused to supply a *sufficient* API. I think you'll like that article, and the links in it to POCs defeating Chrome's "protections". For readers here who aren't going to go to that *December 2009* article, here's the gist without the links:

Giorgio Maone wrote:On April the 1st (!) 2009 I had a phone call with Mickey Kim of Google. The Chromium development team was starting to design a browser extension API, and they wanted to know what kind of hooks were needed for FlashGot and NoScript to be ported on Chrome. I gave them detailed answers with references to related Mozilla technologies, and they promised to keep me updated with progresses.

Eight months later, Chrome extensions are here but NoScript is not among them yet, and people are asking why. The reason is very simple: Chrome is still lacking the required infrastructure for selective script disablement and object blocking.

Maybe Google plans to implement the missing stuff later, maybe they’re still trying to figure out whether it can be done without enabling effective ad blocking, but in the meanwhile the pale AdBlock and FlashBlock imitations which have been hacked together by overwhelming popular demand, are forced to use a very fragile CSS-based hiding approach, ridiculously easy to circumvent.

Just install the most popular FlashBlock clone for Chrome and visit this page I put together in 3 minutes to see what I mean…
Update

Sam Hasler came to the rescue:

The top rated FlashBlock clone for Chrome does block your example page.

Of course, it took another 3 minutes to fix “the top rated” as well

***********************

Tom T. wrote:Regarding browser sandboxing, it might be nice for Firefox and SeaMonkey to implement this. But IMHO, letting the browser sandbox itself is like trying to lift yourself up by your bootstraps. If the browser is compromised, how can it protect its own sandbox? Much better is to let your sandboxing solution run on your operating system, *independently of the browser*. Then, if the browser is compromised, the malware cannot escape through to the hard drive. After all, much of MS' security issues with IE were based on, or worsened by, the fact that IE *is an integral part of the Windows OS*.

Hungry Man wrote:A fair point but I'd say you misunderstand the sandboxing mechanism. Chrome does not handle the sandbox to most extents - it is based on the Windows integrity system and then only hardened from within. That's the basis of it.

Isn't "Windows Integrity System" an oxymoron? ... You're right, that's much better. As said, I've never looked into Chrome; never been interested. Thanks for clarifying.

(individual tab separation as opposed to file access restrictions for every process/ broker.)

I do like the ability to sandbox individual tabs. Perhaps Mozilla will implement it.

However, with NoScript's strong XSS and CSRF protections, the necessity for sandboxing individual tabs is probably much less. Still, IMHO it's Best Practice *never* to have any other browsers or tabs open when doing sensitive stuff like online banking, no matter what browser or what protections. ("Defense in Depth".)

Tom T. wrote:Nope. Let the sandboxer run on the OS, and then let the browser run in the *independent* sandbox thus created. (I have been satisfied with Sandboxie, but that's just personal experience and opinion only, not an endorsement. But it meets the above criterion of being outside the browser instead of inside it.)

Hungry Man wrote:I had a conversation with Tzuk recently actually but I won't go into that. I will say that no third party security software will be able to compete with what's built into the kernel (in terms of security.)

Look up how many times the Windows kernel has been patched over the past two years, across all versions. Tzuk has to install a kernel-level driver, but if it succeeds in rendering the kernel (and everything else) read-only to the (sandboxed) browser, then kernel flaws won't be exploited by the browser.

I haven't followed Sandboxie vulns; I know there might have been a few, but not so many that the product isn't still going strong years later. Again, not an endorsement (My lawyer makes me say that. USA is famous for too many lawyers and too many frivolous lawsuits, and justifiably so. ), but it's never failed me. And in doing support here, sometimes the user says, "SiteX works with NS disabled, but not with it enabled." I may have to disable NS temporarily in the course of diagnosis, and some of these sites are, well, ... ones I wouldn't visit on my own. So i have to trust Sandboxie and the other defense-in-depth methods. (On that note, I'm certainly not advocating that NoScript is the *only* security you need, *of course".)

Tom T. wrote:As for the topic there, "Safest browser?" Firefox and SeaMonkey, in their default states, ... wouldn't know. Always using NoScript. Fx and SM + NoScript (properly configured): I defy anyone to show another readily-available, mass-market browser suitable for both home and enterprise use that is equally protected from such a wide range of Web exploits, *and whose developer responds so rapidly to emergent threats*.

Hungry Man wrote:This will possibly sound like I'm knocking NoScript but I would not call it enterprise-ready. I can only imagine the nightmare of deploying it at an enterprise level "Why won't my site work? How do I do this?"

"My" site? Anyone at work who is visiting non-work-related sites is stealing from their employer (who is paying for their time, equipment, and bandwidth). Of course it happens all the time, but if you're using your work time to shop at eBay or whatever, no sympathy here if the site doesn't work right. More in a minute on that.

Hungry Man wrote:And of course a fair portion of NoScripts protection is down the drain as soon as the user whitelists the site - not by any means all of it, of course, but a fair bit.

It's a poor sysadmin who gives his users admin privilege on their workstations. Lock the prefs.js file file, or for that matter, the entire profile. And most large corporations filter sites anyway, or should. My own $40 home router will let me block anything - Yahoo, eBay, Google-whatever, Amazon, etc.

Hungry Man wrote:As for being equally protected from exploits? I dare you to find a single Chrome exploit that breaks out of the wild - Vupen managed to... apparently, but it was never released and I sincerely doubt it still works.

http://en.wikipedia.org/wiki/Google_Chr ... rabilities

On January 12, 2011 versions of Chrome prior to version 8.0.552.237 were identified by US-CERT as "contain[ing] multiple memory corruption vulnerabilities...By convincing a user to view a specially crafted HTML document, PDF file, or video file, an attacker can cause the application to crash or possibly execute arbitrary code." The vulnerability was subsequently patched and a new stable version was released to the public with Chrome's auto-update mechanism.[91]

Although it was quite encouraging to read:

No security vulnerabilities in Chrome have been successfully exploited in three years of Pwn2Own.[92]

They do indeed seem to be very prompt in fixing flaws. At the time this was posted, neither Chrome nor Firefox 3.6 and 8.0 had any known, unpatched vulns, whereas IE 6, 7, 8, and 9 come off much worse.

It was amusing to read that one critical flaw in Chrome was reported by a Mozilla person, to collect the $1,000 reward, rather than maliciously releasing it into the wild to embarrass the competition. Nice ethics there. (and greed lol).

The other factor is visibility. Mac users were always smug about "better security", because why would you spend time targeting something with 5% market share vs. 90+%? When Vista flopped, and the famous "Mac vs. Vista" commercials provided increased market share to Mac, they discovered that they were not in any way immune to security flaws -- as experts in the field had long said.

Chrome has been out for only three years, and according to various sources, didn't reach double-digit percent market share until a little over a year ago, at which time Firefox had triple the market share of Chrome; more if one adds in SeaMonkey and other Gecko-based browsers. Attacks on Chrome may grow if its market share continues to grow.

And someone made a very perceptive observation: that Firefox and SeaMonkey market share may be undercouted by the number of NoScript users, because NS blocks the very stat-counters from which some browser-usage stats are drawn.

Hungry Man wrote:In the end NoScript + Firefox and Chrome (vanilla) are both very strong. Both are weak to social engineering (I believe Chrome has an 18% block rate and Firefox a 13%?) and that's not much to brag about for either party.

It's a very old truism in ITsec that the weakest part of computer security is between the eyes and the keyboard.
Can't protect people from their own carelessness or stupidity.

Hungry Man wrote:I was really just curious how many issues with NoScript for Chrome could be solved with the latest experimental extensions APIs (most notably WebRequest.)

I *think* this is an all-or-nothing for NoScript. The API either supports all of NS, or it doesn't. Bad enough that Giorgio would have to do all of the (unpaid) work to port NS to Chrome, but to create a separate, weaker fork of NS to suit whatever the present *experimental* (meaning, re-write the NS code when the next experimental version, or the final release version, appears) API?

As to whether or not I consider Firefox as secure as Chrome it's a matter of my own basic principles - I will almost always find that the software that utilizes OS-based security is the most secure.

If only it weren't true that all presently-available OSs, open-source or proprietary, are inherently and irreparably insecure... Search Bruce Schneier's blog, especially for terms like "high-assurance", "EAL-7", or just posts by "NickP", who specializes in doing exactly that (ultra-high-security hw and sw) for high-level customers.

We have to do the best we can with what we have. IMHO only, that's MZ + NS (+ RequestPolicy + RefControl). Chrome appears to be doing well in practice (not exploited in the wild), but the with the info leaked back to its master, and the attempt to monopolize searches and ads:

In April 2011, Google was criticized for not signing onto the Do Not Track feature for Chrome that is being incorporated in most other modern web browsers, including Firefox, Internet Explorer, Safari, and Opera. Critics pointed out that a new patent Google was granted in April 2011, for greatly enhanced user tracking though web advertising, will provide much more detailed information on user behavior and that do not track will hurt Google's ability to exploit this. Software reviewer Kurt Bakke of Conceivably Tech wrote, "Google said that it intends charge advertisers based on click-through rates, certain user activities and a pay-for-performance model. The entire patent seems to fit Google's recent claims that Chrome is critical for Google to maintain search dominance through its Chrome web browser and Chrome OS and was described as a tool to lock users to Google's search engine and – ultimately – its advertising services. So, how likely is it that Google will follow the do-not-track trend? Not very likely." Mozilla developer Asa Dotzler noted, "It seems pretty obvious to me that the Chrome team is bowing to pressure from Google's advertising business and that's a real shame. I had hoped they'd demonstrate a bit more independence than that.

... it seems to me that I'd fear my browser maker more than I'd fear any remote evildoer. I have tools to deal with the latter, but I'm kind of helpless if the browser-maker itself is the enemy. (OSS? Who has time to vet every line of code in every release?)

Interesting discussion.

Cheers!

I see that dhouwn and you had an exchange whist I was composing this essay. No problem. No change in what's said. Just so you know, started replying a few hours ago, with interruptions.

Well that is one heck of a post I'll certainly be getting to that... probably tonight, maybe tomorrow.

Hungry Man wrote:Well that is one heck of a post I'll certainly be getting to that... probably tonight, maybe tomorrow.

Hopefully, it may be of interest to others -- the topic already has more than 500 views -- and perhaps may be linked or quoted at other forums and blogs. (Noting that except where cited, it's MHO only, and not speaking for Giorgio, NoScript, or the Forum, although trying to back up everything with facts.)

btw, although the profanity was relatively mild, it's unnecessary. Exclamations and intensifiers that are more refined would be preferred, and show more class.
The site is intended to be user-friendly to those of all ages, sensibilities, etc. TUVM.

Interesting info, thanks. I suspect that they realize that if there were no ad-blocking capability at all, most users would choose another browser.

They still get a good deal of marketable user data from Google searches, and my tinfoil-hat side tends to, uh, "doubt" their statements that the browser doesn't send some marketable data to Google about their users. I can't prove that, partly because I've never used Chrome, and partly because I don't care to go to the trouble of setting up Wireshark or vetting their code. [[ I found evidence of it later in this post.]] But when Chrome first was announced, the gut instinct was, "Who in the world would use a browser *made by an advertising company*?" -- especially since Google now owns Doubleclick, one of the most notorious privacy-violators.

http://www.mattcutts.com/blog/google-ch ... unication/

This is usually my go-to article for Chrome privacy issues. I have another that essentially points out the dedicated Chromium privacy team.

Let's keep in mind that Chromium is an entirely open source project and it's got plenty of eyes on it, I assure you of that. Chrome is Chromium originally with just the Flash player built in (as well as the Google logos etc) and now it also includes the closed source PDF reader.

Users have definitely been running wireshark and checking up on what Chrome is doing.

Ahhh, the light dawns --- all non-Google ads will be blocked, and Google ads will not. Oh, for the early days, when their motto was, "It is possible to make money without doing evil."

It's certainly dangerous and they'll need to be careful or get slapped with an anticompetition lawsuit. But at the moment multiple ad companies besides google (such as Facebook ads) would be allowed - it's really those noisy flash ads that would be blocked.

And this is an entirely unsubstantiated rumor but we do know that the patent was in the works and in my opinion the logic follows.

I don't have an adblocker on my Fx 3.6.24, and hardly ever see ads.
For one thing, the days when ads were just text and still images are pretty much gone. Most are served by scripting, often with Flash videos. NoScript takes care of both. I also use a HOSTS file service that blocks any *attempts* to connect with 16,000+ sites. (If I type www dot doubleclick.net, I get a "can't connect" error message.)

For another, any ads based on still images are easily blocked by adding the source to Firefox Tools > Options > Content > Load images automatically > Exceptions.

So I'm in your 97% without an ad blocker. Maybe it's because Firefox + NoScript doesn't *need* one?

Possibly.

I remember when I ran Firefox (it's been... about one year since I used FF as my main every day browser) I absolutely used NoScript and an Adblocker though I found that NoScript was blocking just fine on its own.

When I switched to Chrome I was unsatisfied with its ability to block ads so I did use the host file. It was... not great. It did the job but there were certainly issues and questionable performance... hiccups that were hard to track to anywhere.

Who said anything about obfuscated Javascript? I'm talking about obfuscated developer.
I merely visited the ScriptNo web site, looked at some of the FAQ, etc., and found that one about his anonymity.

It's not just a matter of spyware or malware -- definitely *not* making such accusations. I'm talking about being willing to stake your name and reputation on your product. Too buggy, or even worse, doesn't do its job -- user gets pwned -- no accountability. Start somewhere else under another pseudonym, and make another product.

As said, this type of program, whether NoScript or ScripNo, has complete control of your browser. You want me to trust you, but you don't want me to know who you are, where you are, or even what you look like? Whom do I sue?

Giorgio has a complete bio and profile at his own home page. Check it out. And compare its level of detail to the "mystery man" behind ScriptNo.

Welllll I wouldn't quite say complete control over the browser but I certainly see your point.

Still, this is very similar to any real closed source project. I run Windows and use other closed source projects and while I may know the devs name I have no clue about the code inside.

One thing I've learned is that you can't audit everything. And really, in the end, that's alright.

Thankfully Chrome's limited API, while hindering some extensions, does limit what they can do in the case of an exploit.

've had this same discussion with another student. He wanted to host his product at PortableApps.com, but Webmaster John T. Haller quite properly told him that if he wanted credit, he'd have to give his real name. Else, he could be listed as a contributor under his screen name, with a known, non-anonymous developer being in charge and getting prime credit.

Every add-on I have that has anything to do with security or privacy has the developer's real name (hopefully verified by Mozilla) attached to it.

And I understand the personal need for that. Absolutely 100% I get that. Being able to hold someone accountable is a huge boon to security but in my opinion it's reactionary.

Let's look at the certificate authorities (and I hate to get too far off track here, but purely for the sake of understanding trust.) We know who the CA's are. We know to some extend what their process for vetting (or lack their of) is. We (our OS's) trust their signed certificates.

And yet those certificates get hacked and compromised or simply handed out by the CAs.

And only recently have companies like Microsoft started holding them accountable. But that doesn't matter - accountability is a reactionary security mechanism. At best it's a scare tactic to say to the others "shape up" and while I think it can be effective I'm not going to put too much stock in it. Certs are still going to get hacked whether MS blacklists companies or not.

DigiNotar went out of business for their mistakes and just a few months later we see the same thing happening.

Accountability is nice but, as I said, it's reactionary.

Sorry for the side-track =p

Well, as long as it doesn't claim to ... That will be comforting to the user who is pwned by an XSS, Clickjack, or CSRF attack, or has his bank login cookie stolen, or finds that his router has had its settings changed without him knowing it, including creating future remote access to the router's admin page without the user knowing. Whereupon, your .. well, just start thinking of all the evil a bad guy could do once he has complete control of your router.

Well, let's not forget that Chrome isn't exactly helpless without NoScript =p

XSS - built in auditor. I've seen it beaten but it's there.
Clickjacking - Certainly an issue though it would still need to "clickjack" the user to an exploit page, no?
CSRF - I'm fairly certain Chrome has had protection against this since like... v5 though I maybe way off base there and I'm not sure how effective it is.

I would hope a bank cookie is encrypted - wouldn't you?

Chrome may not be perfect but I think it's a bit unfair to say it's naked without the 3rd party protections of a NoScript or Noscript-like extension. I'd certainly like to see an improved XSS auditor for one thing but it is not entirely absent by any means.

But at least the poor user can say, "Well, he didn't claim that it would protect against it."
Or maybe not. Calling it a "NoScript-like extension", when it isn't even close to NoScript's capabilities -- it's "a whitelist-based script-blocker", and that's a better description. And the name is so close that we actually had a private discussion of whether Giorgio Maone could sue for trademark infringement, not that he would. But the name clearly tries to associate itself with NoScript, as does much of the promo material. Which could lead users into thinking that the two are roughly equivalent. Not even close.

Well I agree. The similar names may give a false impression and I think the dev should probably make some things clearer as to the shortcomings of the extension and why those exist.

I wouldn't say it's purely a whitelist-based script/element blocker. I personally like it for the referrer spoofing, blacklist, and user-agent spoofing.

I agree that there are some big differences and that it should be a bit clearer to the users what they are.

So what good is it?

Because I'm not entirely sure how the exploit works I can't say - I do know that the chromium devs are aware of it and it may be a "by-design" thing for compatibility. Not sure - I may have a longer look at it tomorrow.

Side note: It takes a hacker to stop a hacker.

I read this a lot - my hacker friends and my security researcher friends have very very different ideas about security haha I'm not always sure that this statement is quite right.

Giorgio Maone and his good friend, Sirdarckcat, tied for first place in a contest to write the smallest possible, fully self-replicating worm, in 161 bytes. So by one criterion, Giorgio is among the world's best hackers, and thank goodness he's on our side.

And his friend Sirdarckcat often tries to poke holes in NoScript, and if he can, he of course notifies Giorgio privately, and an update is issued

I don't think anyone would question whether he's a competent programmer or not. He's certainly impressive.

NoScript users have had it for more than three years now. NoScript is very often on the leading edge of security innovation. If you want to use the ones playing "catch-up", who never quite catch up, and hope that this issue doesn't affect you before the "assumed" improvement...

Firefox has been around for quite a bit longer than Chrome - it will always be ahead of the game in some areas purely because it's been in the game 3x as long (if not longer.)

Not that it belittles the technologies at all. I've been waiting for Chrome to open up the APIs for ages but I think the devs are overly cautious about anything that might add a hole into their software due to their longstanding no-exploit reputation.

Not sure what you mean there. My bank is already secure. If they carelessly send me an insecure cookie, which could be accessed via some other technique, does your product force the cookies to be HTTPS only?

If your bank sends you an encrypted cookie only the bank can read that cookie.

http://thinkvitamin.com/code/encrypting ... e-browser/

Cookies are generally set server-side using the ‘Set-Cookie’ HTTP header and sent to the client. This makes them a target for network sniffing. You can use SSL/TLS to prevent this by encrypting the network packets, but many sites, such as Facebook, only use HTTPS during login, and then switch to standard unencrypted HTTP for ensuing requests. Tools like FireSheep make sniffing and hijacking session cookies (just another cookie!) trivial in certain conditions.

tl;dr if you encrypt you're fine. Most issues arise when sites like Facebook encrypt the initial login page but then don't encrypt anything else and send you a cleartext cookie.

http://devcentral.f5.com/weblogs/macvit ... ption.aspx

SSL, of course, does almost nothing to assist in addressing vulnerabilities related to cookies because SSL is designed to secure transmissions in flight, i.e. while it is on the network being transferred between the client and the server. The reason Google can so easily force a move to all SSL for GMail is because it requires no action on the part of the user. SSL encrypted transmissions are automatically handled by the browser and decrypted upon being received by the client so it can be interpreted and rendered for the user.

But that means cookies are still in the clear on the client-side and could be potentially exploited in a variety of ways, accidently via malware or intentionally through tampering. To truly secure cookies and prevent tampering and exploitation by malware cookies should be encrypted themselves.

Didn't know that, thanks. But how conspicuous is it? I'm assuming about:flags is similar to about:config in Firefox? NoScript has a simple checkbox in the GUI so that novices who hesitate to tread past Firefox's warnings of dire consequences from mis-configuring about:config don't have to go there.

I wouldn't say Chrome has anything comparable to about:config. It's a short list of experimental/ hidden features (enable global GPU acceleration, enable experimental extensions API) and it's not quite as scary as the about:config though there's certainly a warning.

A Google search for "WebGL+exploit" gave about 1,200,000 results. No, I'm not going to go through them and give you a link , so pick your own favorite(s).

I just haven't heard of any in the wild.

Thank you. The topic deserved a very thorough reply, as does your response. So it needed some time that was not required for helping users with issues in the immediate moment.

Still, if you should ever post again, and you don't get at a reply within a week or so, *definitely* within two weeks, please feel free to give it a bump and ask for a response. Especially if it falls off of the home page for that forum -- "out of sight, out of mind". Nothing wrong with bumping it back up and asking if anyone's looking at the issue. (I'll PM you a short note later about this.)

Well you provided a very thorough reply haha. I appreciate that.

But not one who's created something with all of NoScript's capabilities. The thing is, as you said, Google asked Giorgio to port NoScript to Chrome, but refused to supply a *sufficient* API. I think you'll like that article, and the links in it to POCs defeating Chrome's "protections". For readers here who aren't going to go to that *December 2009* article, here's the gist without the links:

MHm, like I said before Google's been very very slow to implement new APIs. I think that's been a large part due to it not being a huge priority (Chrome hasn't had any sandbox breaking exploits in the wild) and because implementing APIs can be dangerous - you give extensions more tools to mess with users.

They have been working on this WebRequest API and I think that's proof enough that projects are underway.

Isn't "Windows Integrity System" an oxymoron? ... You're right, that's much better. As said, I've never looked into Chrome; never been interested. Thanks for clarifying.

Haha well I wouldn't call Windows the pinnacle of security at all. The integrity system policy is strong though whether the closed-source code behind it is or isn't. It has its issues though but Chrome is built on it.

I do like the ability to sandbox individual tabs. Perhaps Mozilla will implement it.

They're working on it. The project is electrolysis.
https://wiki.mozilla.org/Electrolysis

Currently it's a performance project but it's noted that they may eventually work to use it as a security feature.

However, with NoScript's strong XSS and CSRF protections, the necessity for sandboxing individual tabs is probably much less. Still, IMHO it's Best Practice *never* to have any other browsers or tabs open when doing sensitive stuff like online banking, no matter what browser or what protections. ("Defense in Depth".)

I think as a developer it's best practice to assume your users will never follow best practice =p

I think that there is no real "perfect" approach to security. I can' tsay "oh well sandboxing is 50 points and XSS is 25 and CSRF is 25" and it's impossible to truly benchmark security because security isn't about that. I do think that we can use our heads though and weigh up certain things and say "Yeah, but I've got this so that's not really too necessary."

Look up how many times the Windows kernel has been patched over the past two years, across all versions. Tzuk has to install a kernel-level driver, but if it succeeds in rendering the kernel (and everything else) read-only to the (sandboxed) browser, then kernel flaws won't be exploited by the browser.

Ohh it certainly will be =p

Kernel level exploits are something no program is going to protect you from. You can't go lower than the kernel.

Tzuk had a really good topic on it but I can't find it right now. I may PM it to you tomorrow if I find it.

haven't followed Sandboxie vulns; I know there might have been a few, but not so many that the product isn't still going strong years later. Again, not an endorsement (My lawyer makes me say that. USA is famous for too many lawyers and too many frivolous lawsuits, and justifiably so. ), but it's never failed me. And in doing support here, sometimes the user says, "SiteX works with NS disabled, but not with it enabled." I may have to disable NS temporarily in the course of diagnosis, and some of these sites are, well, ... ones I wouldn't visit on my own. So i have to trust Sandboxie and the other defense-in-depth methods. (On that note, I'm certainly not advocating that NoScript is the *only* security you need, *of course".)

There have been some vulnerabilities, I'm sure there are quite a few more out there. But there's certainly more to security than vuln numbers. I personally use Sandboxie (or I did when I was on Win7, I'm on 8 now.) I rely on it and EMET as well as Chrome - that's really it.

"My" site? Anyone at work who is visiting non-work-related sites is stealing from their employer (who is paying for their time, equipment, and bandwidth). Of course it happens all the time, but if you're using your work time to shop at eBay or whatever, no sympathy here if the site doesn't work right. More in a minute on that.

I'm sorry, I meant "this site."

It's a poor sysadmin who gives his users admin privilege on their workstations. Lock the prefs.js file file, or for that matter, the entire profile. And most large corporations filter sites anyway, or should. My own $40 home router will let me block anything - Yahoo, eBay, Google-whatever, Amazon, etc.

Oh I certainly agree users need rights restricted in an enterprise environment. But that also means the sysadmin has to anticipate what sites their employees will go to because you don't know if that site will break. So what then? You make your user come into work to get the site whitelisted?

This isn't a NoScript problem it's a whitelist problem. It's why corporations rarely use whitelisting and stick to general policies, VPN, and an AV. It's less secure but it costs less.

http://en.wikipedia.org/wiki/Google_Chr ... rabilities

I have to research further... the general concensus is that there has not been a single exploit to break out of Chrome's sandbox though perhaps it is in fact only applying to Chromium? The fact that the prize was 1337 dollars (and not the 20k that a sandbox breaking exploit gets) makes me think that remote code execution was forced to read-restricted low integrity.

They do indeed seem to be very prompt in fixing flaws. At the time this was posted, neither Chrome nor Firefox 3.6 and 8.0 had any known, unpatched vulns, whereas IE 6, 7, 8, and 9 come off much worse.

It was amusing to read that one critical flaw in Chrome was reported by a Mozilla person, to collect the $1,000 reward, rather than maliciously releasing it into the wild to embarrass the competition. Nice ethics there. (and greed lol).

Almost all browsers have stepped up patch releases.

Most Chromium devs used to be Firefox devs - Google was the main provider of support for Mozilla (and still is.)

The other factor is visibility. Mac users were always smug about "better security", because why would you spend time targeting something with 5% market share vs. 90+%? When Vista flopped, and the famous "Mac vs. Vista" commercials provided increased market share to Mac, they discovered that they were not in any way immune to security flaws -- as experts in the field had long said.

Definitely true. Security through obscurity isn't really true security.

Chrome has been out for only three years, and according to various sources, didn't reach double-digit percent market share until a little over a year ago, at which time Firefox had triple the market share of Chrome; more if one adds in SeaMonkey and other Gecko-based browsers. Attacks on Chrome may grow if its market share continues to grow.

They certainly will. Hackers don't just give up.

I think we'll probably start seeing more Java exploits though if Chrome gains popularity. It cuts out the need for a 3rd party PDF reader for some users, sandboxes flash, and sandboxes everything else but Java's still one hell of an attack vector.

OR, as I've said for probably a year now, malicious extensions.

It's a very old truism in ITsec that the weakest part of computer security is between the eyes and the keyboard.
Can't protect people from their own carelessness or stupidity.

Haha, it's certainly one of the more prevalent ideas I hear. I personally believe that while users are the weakest link in security that no security issues can ever be blamed on the user - ever.

I *think* this is an all-or-nothing for NoScript. The API either supports all of NS, or it doesn't. Bad enough that Giorgio would have to do all of the (unpaid) work to port NS to Chrome, but to create a separate, weaker fork of NS to suit whatever the present *experimental* (meaning, re-write the NS code when the next experimental version, or the final release version, appears) API?

I kinda figured. I doubt the API will support everything necessary for quite some time.

One main issue with Chrome security for me is the lack of vetting process for extensions whereas Firefox has a very strong one. This means that when APIs get built extensions get more powerful and there is virtually no auditing system. That's why unleashing APIs can be dangerous.

If only it weren't true that all presently-available OSs, open-source or proprietary, are inherently and irreparably insecure... Search Bruce Schneier's blog, especially for terms like "high-assurance", "EAL-7", or just posts by "NickP", who specializes in doing exactly that (ultra-high-security hw and sw) for high-level customers.

A sentiment I 100% agree with. I don't think there's a single OS or security product out there that suits my needs.

... it seems to me that I'd fear my browser maker more than I'd fear any remote evildoer. I have tools to deal with the latter, but I'm kind of helpless if the browser-maker itself is the enemy. (OSS? Who has time to vet every line of code in every release?)

=p I assure you people look at Chrome. They can ensure their monopoly without breaking blatant privacy laws.


just reloaded >_>

btw, although the profanity was relatively mild, it's unnecessary. Exclamations and intensifiers that are more refined would be preferred, and show more class.
The site is intended to be user-friendly to those of all ages, sensibilities, etc. TUVM.

Slips out without me even realizing it! I'll attempt to censor myself. A quick ctrl + f for some 4 lettered words didn't show anything in this post >_> so I think I'm safe.

Hungry Man wrote:http://www.mattcutts.com/blog/google-ch ... unication/

This is usually my go-to article for Chrome privacy issues.

My go-to is well-sourced Wikipedia articles, rather than self-serving corporate blogs and press releases, as linked in previous posts.
Like this one:

On September 2, 2008, a CNET news item drew attention to a passage in the Terms of Service statement for the initial beta release, which seemed to grant to Google a license to all content transferred via the Chrome browser. The passage in question was inherited from the general Google terms of service. On the same day, Google responded to this criticism by stating that the language used was borrowed from other products, and removed the passage in question from the Terms of Service.

In other words, they did it until they got caught. So does any thief.

Had CNET not cited that, woud that TOS still be with us today? Any reason why it wouldn't?

There was subsequent concern and confusion about whether and what information the program communicates back to Google. The company stated that usage metrics are only sent when users opt in by checking the option "help make Google Chrome better by automatically sending usage statistics and crash reports to Google" when the browser is installed.

The optional suggestion service included in Google Chrome has been criticized because it provides the information typed into the Omnibox to the search provider before the user even hits return. This allows the search engine to provide URL suggestions, but also provides them with web usage information tied to an IP address. The feature can be selected off in the preferences-under the hood-privacy box.

So, unless you opt out, it sniffs what you type in the address bar and sends it to Google, even if you delete that typing and never hit "Enter" (or whatever - you don't go to the site.) Anything that can read my typing in the browser before I send it is a category of keylogger, very malicious ware. The add-on Lazarus came up in that regard in another thread. It's just a local backup tool for, say, form coimpletion where you lose the connection and everything you typed in it, but it wasn't well secured, according to one expert. This is worse -- reads and sends to Google everything typed in the address bar *unless the user opts out*.

News flash: 99% of home users almost never change defaults on *anything*. The other 1% are here and at other tech/security forums.
I did see that they've changed some of these from opt-out to opt-in, which is definitely good, and the way it should all be. ... btw, is geolocation enabled by default? Fx is, which makes me mad. Disabled.

Hungry Man wrote:It's certainly dangerous and they'll need to be careful or get slapped with an anticompetition lawsuit

Look up how long the Gov antitrust suit against MS went on. Three years, ending in a "settlement" that pretty much meant that MS won on most counts.
http://en.wikipedia.org/wiki/United_States_v._Microsoft

http://en.wikipedia.org/wiki/Criticism_of_Google is way too long to summarize here, but what's pertinent are their data practices, found to violate some countries' data privacy laws. Two quickies:

Italy

Google-Vividown: in February 2010, three Google executives were handed six-month suspended sentences for breach of the Italian Personal Data Protection Code.

Norway

The Data Inspectorate of Norway (Norway is not a member of the EU) has investigated Google (and others) and has stated that the 18- to 24-month period for retaining data proposed by Google was too long.

Hungry Man wrote:But at the moment multiple ad companies besides google (such as Facebook ads) would be allowed - it's really those noisy flash ads that would be blocked.

What if I want to block non-Flash ads? ... and I browse with the volume muted, anyway.

Hungry Man wrote:When I switched to Chrome I was unsatisfied with its ability to block ads so I did use the host file. It was... not great. It did the job but there were certainly issues and questionable performance... hiccups that were hard to track to anywhere.

Which HOSTS service did you use? There are many. I use http://winhelp2002.mvps.org/hosts.htm (Tom's lawyer: "That's a free-speech personal opinion, not an endorsement!). Hiccups can be caused by the fact that most use the localhost, 127.0.0.1, to "redirect" (block) unwanted sites. Better to use 255.255.255.0 or 0.0.0.0. I just open it with Wordpad, do a find/replace for 127xxx to 0.0.0.0, *then change the very first entry back to

127.0.0.1 localhost

which *must* be the first entry, always.

Performance should be faster, not slower, because it's way faster to do a local lookup in HOSTS than to send a DNS query and wait for the reply.

I assume Chrome acts as all connected machines have since there were only five of them on the planet (all in the US)? -- *always* looks in Hosts for a match first, then, if and only if no match is found, does whatever lookup it's configured to do?

Anyway, no ads here and no need for an ad-blocker. A negative for Chrome if it doesn't support 100% ad-blocking. Fx users who do use AdBlockPlus (I don't), seem to be quite satisfied with it overall.

Hungry Man wrote:Welllll I wouldn't quite say complete control over the browser but I certainly see your point.

If it's less than complete, it's because it doesn't have NoScript's powerful protections against multiple threats beyond just script-blocking. One way or another, thought, it's still intercepting HTTP or HTTPS requests , and once a tool has the power to do that...

Hungry Man wrote:Still, this is very similar to any real closed source project. I run Windows and use other closed source projects and while I may know the devs name I have no clue about the code inside.

You have a major company (MS) whose stock trades on the public markets, and for whom bad press can cost billions. (Did someone say, "Vista?" ) That's even greater accountability than a private individual, although they've been pretty clever in avoiding responsibility for damage. Still, the pocketbook hit and the angry shareholders whose stock drops in value are *some* check. Same for other corps -- the coders' names aren't important; the reputation (and profits and stock price) of Cisco, Apple, etc. are on the line.

(FWIW, I looked at some of the code inside XP, and deleted 95% of it. Not recommended. My risk only. But, wow! %windir% = ~ 175 MB vs lots of GB.

Hungry Man wrote:Being able to hold someone accountable is a huge boon to security but in my opinion it's reactionary.

"Reactionary"? What is this, Mao's Peoples' Revolution? -- don't know what that means in this context.

Oh... I read farther on. You meant, "reactive" (vs."proactive"). No, the idea is that there's also a deterrent effect. Those who know they'll be held accountable, or suffer financially, are more likely to do it right in the first place.

OK, Certs get forged. Is Giorgio's name forged? Considering that I handle the US bank account for those who wish to donate to NoScript and Flashgot without using Paypal, I don't think so.

Hungry Man wrote:Accountability is nice but, as I said, it's reactionary.

So we should ditch it completely? ... instead of keeping it while adding other protections for ourselves. ("Defense in Depth".) User reviews, tech writers' reviews, mywot and others, etc.... lots. But don't throw away accountability. And the underlying character issue -- devs who hide behind anonymity while asking me to install their sw *at least* raise the question, "Why?"

Hungry Man wrote:XSS - built in auditor. I've seen it beaten but it's there.

I have a fence around my pool. Kids jump over it all the time, but at least it's there.

Hungry Man wrote:Clickjacking - Certainly an issue though it would still need to "clickjack" the user to an exploit page, no?

Absolutely *NOT*, as per our PMs and the very detailed FAQ.

Hungry Man wrote:CSRF - I'm fairly certain Chrome has had protection against this since like... v5 though I maybe way off base there and I'm not sure how effective it is.

That must be very comforting.

Seriously, if/when you find the documentation of it, please point to it.

Hungry Man wrote:I would hope a bank cookie is encrypted - wouldn't you?

Yes, but I also hope for a winning lottery ticket. Haven't had one yet.

Whereas NoScript *forces* secure cookies from any site you choose (that supports https in the first place -- some non-sensitive sites may not.) And in my experience, banks have the *worst* knowledge of security of all websites. That's a topic for another discussion (or not), but I've told two of my online institutions how easy it was to defeat some of their "security measures". No details, partly because I don't want to say where I bank, and partly not to encourage others of lesser character.

This feature came about because Bank of America, one of the US's largest, (and many other financial institutions) were serving an *insecure* login page. To make it worse, BofA.com put a huge black padlock icon next to the user/pass boxes, which is both false reassurance and to distract the user from the fact that the browser didn't display the padlock in the lower-left. (Color-coded address bars were implemented to help with this issue also. They did *send* your login creds via htttps, to a secure server. But serving the login page insecurely makes phishing and MITM attacks soooooo much easier, no?

After the NoScript Force HTTPS feature had been implemented for a while, every financial institution I use corrected this situation. I like to think that the publicity generated by the fact that NS was compelled to do this was a motivator. But you may still encounter others who do this, and sending insecure cookies from secure sites hasn't disappeared off the planet AFAIK. Sure, your chances, as one in 7 billion people, of being hit by this are fairly low, but do you really want to take the chance, while waiting for this feature that you *assume* will come along, as this *experimental* API unfolds? It's your nickel, not mine...

As said, NS users have had this protection for three years already.

Hungry Man wrote:Chrome may not be perfect but I think it's a bit unfair to say it's naked without the 3rd party protections of a NoScript or Noscript-like extension. I'd certainly like to see an improved XSS auditor for one thing but it is not entirely absent by any means.

I never said it was naked. I said that ScriptNo was far inferior to NoScript (as well as being misleading), and that since Chrome can't support NoScript, it's by definition weaker than browsers that can. Despite their excellent record of fixing flaws rapidly and avoiding in-the-wild exploit (easier to do with that very limited API, as you said, but also limits flexibility in add-ons, not just for personalization but for security and privacy), I stand by that statement.

Side note: A flaw in Flash or Adobe Reader (they have been numerous) would not be counted as a Chrome vuln, even if Chrome users were affected by it, because it's not browser-specific. Or Java, or Silverlight, or... you get the picture.

Stopping here for now. Will answer the rest later, probably in a day or two.
Cheers.

In other words, they did it until they got caught. So does any thief.

Had CNET not cited that, woud that TOS still be with us today? Any reason why it wouldn't?

It was removed retroactively. I seriously doubt they'd try to slip something into the TOS, which is going to get reviewed to hell and back if any product gains any popularity.

They also provided adequate proof that it was a mistake, they had used the EULA from another product where it did apply.

So, unless you opt out, it sniffs what you type in the address bar and sends it to Google, even if you delete that typing and never hit "Enter" (or whatever - you don't go to the site.) Anything that can read my typing in the browser before I send it is a category of keylogger, very malicious ware. The add-on Lazarus came up in that regard in another thread. It's just a local backup tool for, say, form coimpletion where you lose the connection and everything you typed in it, but it wasn't well secured, according to one expert. This is worse -- reads and sends to Google everything typed in the address bar *unless the user opts out*.

It's not like it reads it, stores it, and that's it. It reads it and then sends information back.

There are no "sniffs" that don't result in something going back to the user. For Chrome to provide a service it needs to sniff something. Most browsers actually exhibit some form of keylogging behavior, I believe Firefox is included in that.

https://mikewest.org/2011/09/chrome-privacy

There's plenty of very legitimate people saying Chrome isn't a privacy issue. You can argue night and day about trust but there's never anything to substantiate claims against Chrome.

is geolocation enabled by default? Fx is, which makes me mad. Disabled.

It's prompt-based.

What if I want to block non-Flash ads? ... and I browse with the volume muted, anyway.

Than get an adblocker, of course.

Which HOSTS service did you use? There are many. I use http://winhelp2002.mvps.org/hosts.htm (Tom's lawyer: "That's a free-speech personal opinion, not an endorsement!). Hiccups can be caused by the fact that most use the localhost, 127.0.0.1, to "redirect" (block) unwanted sites. Better to use 255.255.255.0 or 0.0.0.0. I just open it with Wordpad, do a find/replace for 127xxx to 0.0.0.0, *then change the very first entry back to

127.0.0.1 localhost

which *must* be the first entry, always.

Performance should be faster, not slower, because it's way faster to do a local lookup in HOSTS than to send a DNS query and wait for the reply.

I used that one.

Yep, I actually didn't experience performance issues - others did.

I assume Chrome acts as all connected machines have since there were only five of them on the planet (all in the US)? -- *always* looks in Hosts for a match first, then, if and only if no match is found, does whatever lookup it's configured to do?

Chrome would check it's DNS cache first and then the Windows cache and then host and then do a lookup, I believe in that order.

Anyway, no ads here and no need for an ad-blocker. A negative for Chrome if it doesn't support 100% ad-blocking. Fx users who do use AdBlockPlus (I don't), seem to be quite satisfied with it overall.

It does. The same dev for Firefox also makes the ABP for Chrome.

If it's less than complete, it's because it doesn't have NoScript's powerful protections against multiple threats beyond just script-blocking. One way or another, thought, it's still intercepting HTTP or HTTPS requests , and once a tool has the power to do that...

Well it's not complete because it's sandboxed and all extensions have to declare their rights - it doesn't declare all of the rights that it could.

You have a major company (MS) whose stock trades on the public markets, and for whom bad press can cost billions. (Did someone say, "Vista?" ) That's even greater accountability than a private individual, although they've been pretty clever in avoiding responsibility for damage. Still, the pocketbook hit and the angry shareholders whose stock drops in value are *some* check. Same for other corps -- the coders' names aren't important; the reputation (and profits and stock price) of Cisco, Apple, etc. are on the line.

Like I said, reputation is important and accountability is important as well.

When I say reactionary I meant hat accountability is something that happens after the fact. You don't hold someone accountable until they've done something wrong - at that point it's a bit late, isn't it?

Those who know they'll be held accountable, or suffer financially, are more likely to do it right in the first place.

Hence the cert metaphor.

Certificates have been getting in trouble for a while. DigiNotar was hacked out of business. And yet just a few months later we see the same issues arise. How effective was watching an entire CA go bankrupt as a deterrent? Not very effective at all.

So we should ditch it completely? ... instead of keeping it while adding other protections for ourselves. ("Defense in Depth".) User reviews, tech writers' reviews, mywot and others, etc.... lots. But don't throw away accountability. And the underlying character issue -- devs who hide behind anonymity while asking me to install their sw *at least* raise the question, "Why?"

I'm saying it's superfluous. Anything superfluous can be added or taken away without serious consequence as long as there's core security - the code is the core security.

I have a fence around my pool. Kids jump over it all the time, but at least it's there.

A bit more complicated than that. To bypass Chrome's XSS auditor you need to already have control over part of the page. I'm not sure NoScript could protect in this scenario either.

Absolutely *NOT*, as per our PMs and the very detailed FAQ.

I responded to the PM - I stand by what I said.

As I said in the PM while clickjacking is a function not of an exploit but of html, js, css its intentions are to lead to an exploit or social engineering.

That must be very comforting.

Seriously, if/when you find the documentation of it, please point to it.

http://blog.chromium.org/2010/01/securi ... tures.html

Yes, but I also hope for a winning lottery ticket. Haven't had one yet.

Whereas NoScript *forces* secure cookies from any site you choose (that supports https in the first place -- some non-sensitive sites may not.) And in my experience, banks have the *worst* knowledge of security of all websites. That's a topic for another discussion (or not), but I've told two of my online institutions how easy it was to defeat some of their "security measures". No details, partly because I don't want to say where I bank, and partly not to encourage others of lesser character.

This feature came about because Bank of America, one of the US's largest, (and many other financial institutions) were serving an *insecure* login page. To make it worse, BofA.com put a huge black padlock icon next to the user/pass boxes, which is both false reassurance and to distract the user from the fact that the browser didn't display the padlock in the lower-left. (Color-coded address bars were implemented to help with this issue also. They did *send* your login creds via htttps, to a secure server. But serving the login page insecurely makes phishing and MITM attacks soooooo much easier, no?

After the NoScript Force HTTPS feature had been implemented for a while, every financial institution I use corrected this situation. I like to think that the publicity generated by the fact that NS was compelled to do this was a motivator. But you may still encounter others who do this, and sending insecure cookies from secure sites hasn't disappeared off the planet AFAIK. Sure, your chances, as one in 7 billion people, of being hit by this are fairly low, but do you really want to take the chance, while waiting for this feature that you *assume* will come along, as this *experimental* API unfolds? It's your nickel, not mine...

As said, NS users have had this protection for three years already.

Certainly a MITM attack is marginally more difficult with ssl (though not really in practice) and I agree that forcing HTTPS helps. Of course, the site has to support it.

Of course... you don't need noscript to use https. And there are extensions that will redirect to HTTPS, which is less effective but will work.

And yeah haha I assume the extension that developers have put considerable time into and has been consistently worked on will continue to be worked on =p

Side note: A flaw in Flash or Adobe Reader (they have been numerous) would not be counted as a Chrome vuln, even if Chrome users were affected by it, because it's not browser-specific. Or Java, or Silverlight, or... you get the picture.

Yes it would be. Not Java or Silverlight, of course - those aren't bundled with Chrome. But yes, a Flash exploit that breaks the Chrome sandbox is in fact a Chrome exploit, I've talked to Chrome engineers personally and seen comments about it online and they agree though a few think it's a bit of a cheap-shot.

I never said it was naked. I said that ScriptNo was far inferior to NoScript (as well as being misleading), and that since Chrome can't support NoScript, it's by definition weaker than browsers that can. Despite their excellent record of fixing flaws rapidly and avoiding in-the-wild exploit (easier to do with that very limited API, as you said, but also limits flexibility in add-ons, not just for personalization but for security and privacy), I stand by that statement.

ScriptNo is definitely missing some things that NoScript are. No arguing there from anyone.

No, the fact that Chrome can't support NoScript certainly does not by definition mean it's weaker, it means it has a far more closed API - a way of limiting extensions, in other words a security feature.

Their lack of exploits though is far less to do with their limited API and much more to do with their sandbox.

Yes, there's definitely limits on personalization but not so much on privacy. Adblock Plus has DNT and you can easily block cookies (3rd party or selectively.)

I need to apologize on the sandboxing issue. As said, I haven't looked deeply into Chrome, partly because of the aforementioned reluctance (rightly or wrongly) to use a browser produced by an advertising company. And partly because I would not browse without NoScript, so I'm limited to those browsers that support it, and that it supports. (Explanation: There are some projects that have made their own forks of Fx/SM. Giorgio says that NS *may* work on them, but he can't guarantee it -- how could he? -- and can't promise support for issues on those forked browsers.)

So I consulted a very trusted and extremely knowledgeable ITsec professional, who explained that yes, Chrome does make substantial use of the OS for its sandboxing functions, versus the picture I had of a browser attempting to sandbox itself from within. (Though isolating elements within the browser from each other is still a fine idea.) Therefore, there's no reason why Chrome's sandboxing function should not be *at least* as effective as Sandboxie's. It could even be better, perhaps.

For the record, I'm not a Sandboxie fanboy or anything. It's just the only sandbox solution I've ever used. Which means I'm comfortable with it, and I've not had any problems with it that would motivate me to search for a different solution, that's all. Most of the times that I've mentioned it, or any other product besides NoScript, I've added the following "boilerplate" (as we call it in the US) disclaimer:

DISCLAIMER: I have no connection to the above product. There have been newer versions released, which I did not get. I can't speak to those versions. I can't control the product or your use of it, and therefore cannot take any responsibility or liability for your use of it, or the consequences of using it. This is not an official endorsement by this forum, its Admin/Developer, or anyone else. It is my own personal experience, offered in the hope that it may be of use. but comes with no guarantees or warranties, express or implied. IF YOU DO NOT AGREE TO THE ABOVE TERMS, DO NOT CONSIDER, HEED, OR USE THE ABOVE PERSONAL OPINION.

Just didn't take it to that level here. ... and for sandbox/VM, I usually add that there are many such solutions out there, and each user should investigate and find the one that they prefer.

Having said the above, I don't think I have any more to add to this topic. We've agreed on some things, and on the others, there is little point in each repeating the same things to the other. (I may look into the link to Chrome CSRF protection if time permits, thanks.)

The OP asked two very legitimate questions:
1) Does the newer Chrome API support NoScript? ... Answer: No, unless and until Giorgio Maone tells us it does.
2) Is ScriptNo equivalent to NoScript, or an effective substitute for it? ... Answer: OP and I both agree that it is not.

I have invited said IT security pro to contribute to this thread if desired. If the thread does continue for several more posts, I would probably split it into Forum Extras > Security, since the OP has been resolved.

Always happy for another opinion. If your friend would like to throw his opinion out there I'd absolutely love to hear it.

As always, thanks for your time.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chrome's design comes from the OP web browser from Univ. of Illinois. I independently invented a similar design around that time, although mine would've run on a Ring 1 microkernel or -1 hypervisor w/ capability-based security. (And NO STANDARD JAVA!) I loved running into the OP paper in 2008 & seeing that someone actually implemented some of these ideas.

http://www.cs.uiuc.edu/homes/kingst/Res ... rier08.pdf

OP was designed to be secure from ground up. It's very similar in nature to microkernel-based trusted OS's with secure decomposition of applications. (The rest is an abstract of the abstract. OP is a browser security kernel and a collection of subsystems/components isolated into separate processes. Like a microkernel system, they communicate with message passing. The design allowed plugins to run safely. They also used formal (mathematical) methods to prove the address bar displays the correct address. They incorporated info-flow tracking for post-mortem analysis. They implemented it Java to avoid security issues so prevalent in C/C++ apps, even more beneficial due to the speed of HotSpot. Performance was only slightly slower than Firefox.

Sounds great. So, Google then invested money in OP, gave it a bunch of new features & created the most secure browser out there, right? Not quite. Instead, they created their sandbox technology & Chromium. Chromium is written in C++ (for decent reasons), making it much more vulnerable to attacks. The good news is they still use partitioning & message passing. Bad news: as of mid-2010, only renderer and "untrusted" plugins are sandboxed (Mark). "Trusted" plugins fully privileged by default (Mark). They've added tons of extra features, including overprivileged ones like WebGL. This increases the attack surface & bypass potential quite a bit. There's some privacy issues. There were no formal methods used to prove claimed security properties hold & I have no idea if it still does info-flow tracking.

So, we essentially have a browser similar to OP on the surface with solid protection against system level attacks, inferior protection against web app layer attacks, privacy invasions & a good process for reducing vulnerability count (i.e. $$$ incentives). It's a decent option for people who lack the will or technical capability to manage something like NS. It's also decent for people who don't value privacy or can take all the steps necessary to ensure Chrome surfs privately. However, a properly sandboxed FF running NS currently provides the best level of protection for the web user if they are taught how to use NS properly. The latter point isn't as hard as it seems for many users.

I've avoided Chrome because Google isn't following their motto. When Chrome was released, one of my hacker friends did an analysis of it. His packet sniffer showed that every single thing he typed into the address bar was sent to Google, even if he hit backspace. This was before Google Instant (probably a precursor feature). We found that ethically questionable as most people think something only happens when they hit enter. There were other issues. We and many media sources blasted Google for being silent about that. Over time, things have gotten to the point where many of these things can be disabled & Google is quite clear on what they're doing:

http://www.google.com/chrome/intl/en/privacy.html

On the sandbox technology. There's been quite a few analyses on Google's sandboxing method. These resulted in mixed opinions. There are two main problems: overprivileged components & dependency on OS to help it stay secure. The OS issues make it where I'm pretty sure state-level people have compromised Chrome already. The overprivilged components, WebGL, plugins, etc. may lead to compromises by black hats, especially combined w/ social engineering.

Mark's analysis (pro-Chrome, mainly)
http://blog.azimuthsecurity.com/2010/05 ... rview.html

Keetch on several sandboxes (paints darker picture)
http://media.blackhat.com/bh-eu-11/Tom_ ... xes-WP.pdf

Keetch's on practical sandboxing
http://www.slideshare.net/tkeetch/black ... -sandboxes

A LiveCD, carefully constructed browser VM, or proven 3rd party sandbox with Firefox/NS is more trustworthy at the moment. So, Chrome's main strength is stopping common system-level attacks at the browser level. Alternatives are better in every area. Chrome continues to gain new features & inch closer to the capabilities of FF/NS. I always pick the most secure & useful option I can get. Right now, it's not Chrome, but it might be in the future. They've invested more effort into security than any other group (except OP). I wish them luck on trying to surpass my alternatives in security: we benefit regardless.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJOzcWvAAoJEFvQ0aBVJJxWuN8H/RfO52uslvbcCgULw1N4vPf7
UZYYJASH3lVcMXUbYQYuudjOVO5dZINYJ7CiDQACytesn8a3pGDkSnihJJLBXhkA
WipP3fjBdKO4h1lQ11mgdaIUsrJrdn9j0UuXwdXBCeurbTGjeaXX61jDccC8A9xn
jsfMEu4j/QnTxHGg4bSvDhhW0Y/rN0jBeUzBn/tteUkNpC+gSpWLNSPmXj7aLbrS
E21GG3UfF+jmSougCZNKb2exF+lh8ccDtkXBQR17rgJkvvQ84/8a62i5nSgT7raU
oneMR2yFsawGUsSPSVXq3NyVpzFKwiGiiaroQqVq7oOtt2DWMIRv/yIjitHQocY=
=L4xw
-----END PGP SIGNATURE-----

@ NickP:

Thank you for not only taking the time to reply, but for also taking the time to do the research and to cite original sources for those who wish to see for themselves. You and I have discussed in another context that corporations are inherently self-serving (it's their duty to the stockholders), so I'd rather look to independent researchers than to corporate press releases -- regarding *anything*.

NickP wrote: ... they created their sandbox technology & Chromium. Chromium is written in C++ (for decent reasons), making it much more vulnerable to attacks. The good news is they still use partitioning & message passing. Bad news: as of mid-2010, only renderer and "untrusted" plugins are sandboxed (Mark). "Trusted" plugins fully privileged by default (Mark).

I came away from our private conversation thinking that you thought Chrome sandbox to be excellent, possibly/probably better than Sandboxie. Do I retract any portion of the above apology?

NickP wrote:They've added tons of extra features, including overprivileged ones like WebGL. This increases the attack surface & bypass potential quite a bit.

As said before in this thread, NS users can disable WebGL with a single click in the GUI, Options > Embeddings > Forbid WebGL.

NickP wrote:There's some privacy issues. There were no formal methods used to prove claimed security properties hold & I have no idea if it still does info-flow tracking.

So, we essentially have a browser similar to OP on the surface with solid protection against system level attacks, inferior protection against web app layer attacks, privacy invasions & a good process for reducing vulnerability count (i.e. $$$ incentives).

Yes, to the incentives. But Mozilla offers bounties, too, and for a critical vuln, it's *always* USD $3,000 (and don't forget the T-shirt, too! ) vs. the news item about Google paying a "record" $3,133 for a critical vuln. (No T-shirt.)

NickP wrote: It's a decent option for people who lack the will or technical capability to manage something like NS. It's also decent for people who don't value privacy or can take all the steps necessary to ensure Chrome surfs privately. However, a properly sandboxed FF running NS currently provides the best level of protection for the web user if they are taught how to use NS properly. The latter point isn't as hard as it seems for many users.

Thanks for essentially confirming my message. As to the last statement, we have the NoScript Quick Start Guide, an extensive NoScript FAQ, and now, even a listing of some sites that may be unnecessary to allow, to help users make these decisions.

After the short learning curve, using NS becomes almost second-nature. And if not, a support team willing to help. (cough)

NickP wrote:I've avoided Chrome because Google isn't following their motto. When Chrome was released, one of my hacker friends did an analysis of it. His packet sniffer showed that every single thing he typed into the address bar was sent to Google, even if he hit backspace. This was before Google Instant (probably a precursor feature). We found that ethically questionable as most people think something only happens when they hit enter. There were other issues. We and many media sources blasted Google for being silent about that. Over time, things have gotten to the point where many of these things can be disabled & Google is quite clear on what they're doing:

http://www.google.com/chrome/intl/en/privacy.html

Which is what I said earlier: They do it for as long as they can get away with it. When exposed, they say, "Oops, sorry, accidental. Fixed now."

NickP wrote:On the sandbox technology. There's been quite a few analyses on Google's sandboxing method. These resulted in mixed opinions. There are two main problems: overprivileged components & dependency on OS to help it stay secure. The OS issues make it where I'm pretty sure state-level people have compromised Chrome already. The overprivilged components, WebGL, plugins, etc. may lead to compromises by black hats, especially combined w/ social engineering.

Again, do I retract my apology about the sandboxing? ... I *did* make the point that all publicly-available OSs are insecure.

Overall, which do you think more effective, ceterus parabus: Chrome sandboxing or Sandboxie? Or is there another third-party sandboxing solution (for those who don't want to go to the expense or effort of full-on VM) that you think is more secure than all others?

NickP wrote:A LiveCD, carefully constructed browser VM, or proven 3rd party sandbox with Firefox/NS is more trustworthy at the moment. So, Chrome's main strength is stopping common system-level attacks at the browser level. Alternatives are better in every area. Chrome continues to gain new features & inch closer to the capabilities of FF/NS. I always pick the most secure & useful option I can get. Right now, it's not Chrome, but it might be in the future. They've invested more effort into security than any other group (except OP). I wish them luck on trying to surpass my alternatives in security: we benefit regardless.

Indeed, competition always benefits the end user, eventually. Thanks for your time and insights.

btw, although the digital sig ID's you as the originator of this post, you do know that I can copy it, minus the header and footer, and post it as my own, anywhere on the planet? ... kidding.

****************************

I do think it's now appropriate to move this to Forum Extras > Security, because as said before, the question in the OP were answered, and the rest is a more general discussion of comparative security, not NS-specific, though certainly interesting and useful.

Thanks for the new topic. I think the last topic had clearly answered the question asked.

I'll get to this later but for now I need to read through the links provided. So far they're fun.

EDIT:
@NickP

I get some of the issues you mentioned about Chrome but many of those issues apply directly to Firefox + NS as well. I can't say "This is where Firefox + NS is weak therefor Chrome is better" =p I have to say why Chrome isn't weak in those areas.

I'll respond further later. I don't feel like writing an essay on thanksgiving =p