InformAction Forums

Web security has come along way. HSTS, DNT, X-Frame-Options, and X-Content-Type-Options, to name a few, are technologies that make the web more civil and less of a jungle. I'm glad that NS implements some of these recent security technologies that enables previous Firefox versions to be on par with modern browsers. With this, more and more NS is securing its place to be an essential security appliance rather than just another optional add-on.

Now we're seeing some overlapping implementations of these technologies between NS and the upcoming Firefox 4 (donottrack, x-frame-options, hsts, xss - to some extent, etc...). In this regard, a number of thoughts come to mind:

1) Is there a significant difference to NS's implementation _per technology_ over the built-in, once Firefox 4 hits mainstream?

2) If there exists a significant difference between the two, how do this affect page handling and rendering when using NS's? Built-in?

3) Would there be significant performance advantages or disadvantages if opting to use NS's implementation over the built-in functions, considering that there is redundancy?

4) In terms of options flexibility, how does NS's implementation differ over the built-in function?

As Firefox 4 draws near, it would be great to be able to weigh the options made available to end users.

/m

milithruldur wrote:1) Is there a significant difference to NS's implementation _per technology_ over the built-in, once Firefox 4 hits mainstream?

Yes, implementations are usually very different, because NoScript's always pre-dates Firefox and core developers usually prefer doing thing "their" way and hook the C++ code directly, since they can afford recompiling the whole browser

milithruldur wrote: 2) If there exists a significant difference between the two, how do this affect page handling and rendering when using NS's? Built-in?

So far there's no significant difference in outcome, except for CSP vs NoScript's XSS filter (if you mean that by "xss - to some extent"), because the former is a way for web authors to specify restrictions on their web application in order to limit the XSS attack surface, while the latter (NoScript's Injection Checker) works no matter what the web developers did (or not did) and is the first and still most effective protection against reflective XSS available on the client side.

milithruldur wrote: 3) Would there be significant performance advantages or disadvantages if opting to use NS's implementation over the built-in functions, considering that there is redundancy?

I wouldn't say there's any significant overhead on either side. On the other hand, having a double layer with different implementations may shield against possible bugs in one of the two, since they're very unlikely to have the same implementation flaws.

milithruldur wrote: 4) In terms of options flexibility, how does NS's implementation differ over the built-in function?

NoScript's implementations are usually more flexible and configurable, with pattern-based exceptions.
So if you run into any problem with, for instance, the DNT header on a certain site, you may want to disable the native implementation and edit NoScript's exceptions for that feature.

Yes, implementations are usually very different, because NoScript's always pre-dates Firefox and core developers usually prefer doing thing "their" way and hook the C++ code directly, since they can afford recompiling the whole browser

Indeed it is an advantage to be able to integrate functions to the code. However, this makes NoScript more flexible in that adding support for technologies to browsers that are otherwise left by the times in NoScript requires no recompilation of program code. And when bugs do arise, they can be addressed much more quickly, sometimes providing workarounds available via NoScript's prefs, with relative ease.

So far there's no significant difference in outcome, except for CSP vs NoScript's XSS filter (if you mean that by "xss - to some extent"), because the former is a way for web authors to specify restrictions on their web application in order to limit the XSS attack surface, while the latter (NoScript's Injection Checker) works no matter what the web developers did (or not did) and is the first and still most effective protection against reflective XSS available on the client side.

Then NoScript's XSS is a "catch all" implementation that handles cases where CSP is unable to do otherwise.

I wouldn't say there's any significant overhead on either side. On the other hand, having a double layer with different implementations may shield against possible bugs in one of the two, since they're very unlikely to have the same implementation flaws.

I agree on having layered security even from within the browser, as it avoids a single point of failure. Hopefully there wouldn't be problems unforseen in this setup.

NoScript's implementations are usually more flexible and configurable, with pattern-based exceptions.
So if you run into any problem with, for instance, the DNT header on a certain site, you may want to disable the native implementation and edit NoScript's exceptions for that feature.

Now this makes things on NoScript's side more interesting. The ability to workaround, or make exceptions as needed, on problems with some implementation as they are found is a great avenue for PowerUsers wanting more control.

Giorgio Maone wrote:On the other hand, having a double layer with different implementations may shield against possible bugs in one of the two, since they're very unlikely to have the same implementation flaws.

But then it's also more likely that there is a bug in one of both that might prevent normal usage of something.

NoScript's implementations are usually more flexible and configurable, with pattern-based exceptions.
So if you run into any problem with, for instance, the DNT header on a certain site, you may want to disable the native implementation and edit NoScript's exceptions for that feature.

That's true and also why I like NoScript. Mozilla needs to be pressurised to make their implementation flexible as well.