Page 1 of 2

NSA and the future of Noscript

Posted: Thu Mar 22, 2012 2:39 pm
by tlu
Giorgio,

I sincerely hope that you don't mind the following questions.

When you introduced Noscript for Mobile in October 2011 you said in comment #7 that the desktop version of NSA would be available "anyway before the end of this year" ( =2011). We all know that this did not happen (which is a pity as its new features are really amazing). In another thread you said that it's postponed "because of the sudden move of Mozilla to drop Electrolysis". After thinking again about your answer, I must admit that I don't understand it. NSA desktop was planned by year-end 2011, but E10 - even if it had not been put on hold by Mozilla - would definitely not have been available by then. For me as a layman it seems therefore logical that NSA doesn't require E10 in order to work properly. If this is correct, I wonder why the decision by Mozilla changed the situation for NSA at all. Am I missing something? Are there perhaps other reasons (like the plan to introduce click-to-play for plugins in Firefox) for the postponement?

I'm also asking these questions as you wrote in that same thread that your top priorities are "1) Android native UI compatibilit 2) investigation on new Clickjacking techniques and countermeasures 3) Chrome porting". Regarding 3) - does that mean that you see more potential for Chrome compared to FF, and does that even mean that new NS versions for FF have a lower priority for you?

If you don't want to comment these things - fair enough. After all, NS is your "baby" and its future development is your decision alone. Nevertheless, I'm sure that I'm not the only long-time supporter who would welcome some clarifying remarks. Thank you!

Re: NSA and the future of Noscript

Posted: Fri Mar 23, 2012 7:28 am
by Tom T.
Hi tlu, long time, no see. :)

Until Giorgio has a chance to reply personally, let me just throw this out there:

That Giorgio told us near the end of last year that he would be relocating, with all the headaches of moving, setting up a new ISP (somewhat more complicated for running an Internet business and a Web server than for us home users), etc. -- and got backed up a bit. Not very active here for a couple of months; at one time, only access was via a very expensive satellite connection, IIRC. I used to have a link to that thread; can't find it now; no matter.

Also, take a close look at the changelog, and the zillion new web threats discovered/protected, bug fixes, finer-grained controls on injection-checking and various other XSS and ClearClick tweaks, a number of enhancements, etc. Still a lot on the TODO list for existing stuff.

Having said that, I'm as eager as you are to see the NoScript 3.x for the desktop. It should save us having to answer hundreds of questions and writing stickies like Site-Specific-Permission Questions? PLEASE READ THIS FIRST!, etc.

Cheers,
- Tom

Re: NSA and the future of Noscript

Posted: Fri Mar 23, 2012 9:17 am
by GµårÐïåñ
Besides personal matter which come first always, he has been on top of many emerging and new zero day and new vector threats that I believe, as does he, come with a higher priority timeline than hopes and dreams and best wishes for the new version that might be needed to push back in lieu of all that. One man, being pulled in million directions, providing one of the most amazing tools, for free mind you, I think we can cut him some slack don't you?

Re: NSA and the future of Noscript

Posted: Fri Mar 23, 2012 9:53 am
by Giorgio Maone
tlu wrote:NSA desktop was planned by year-end 2011, but E10 - even if it had not been put on hold by Mozilla - would definitely not have been available by then. For me as a layman it seems therefore logical that NSA doesn't require E10 in order to work properly. If this is correct, I wonder why the decision by Mozilla changed the situation for NSA at all. Am I missing something? Are there perhaps other reasons (like the plan to introduce click-to-play for plugins in Firefox) for the postponement?

Making mobile and desktop codebase to converge (at this moment they're very disjointed, albeit overlapping in some areas, codebases) was a major goal of the planned backport of NSA into NoScript 3.
E10s being put on hold is one side of the problem (notice that NSA contains a lot of E10s cruft which would likely be a pity to put in a desktop version where it would be useful), the other side being that current NSA will be mostly incompatible with the upcoming Android-native Firefox (currently Aurora Mobile).
Therefore if I backported NSA in its current state (which is compatible with stable Firefox Mobile but not with beta) to the desktop, I'd have in a few months yet another desktop version (completely incompatible with Fx 3.6 which has not been decommissioned yet) to maintain separately from a new Mobile version to be made compatible with Android native.

In other words, until the Mobile situation is not settled, with a stable Android native (notice this has been postponed as well), it would be unwise to attempt a big and risky merge with a mostly end-of-line codebase. Much better to focus on future-proof things such as adding protection against new emerging threats to existing back-end modules (e.g. InjectionChecker and ClearClick) and improve their usability.
tlu wrote:I'm also asking these questions as you wrote in that same thread that your top priorities are "1) Android native UI compatibilit 2) investigation on new Clickjacking techniques and countermeasures 3) Chrome porting". Regarding 3) - does that mean that you see more potential for Chrome compared to FF, and does that even mean that new NS versions for FF have a lower priority for you?

Quite the contrary. Chrome as a platform is very limiting: for instance, I still need to figure out -- and I'm pressuring Chrome engineers to help in this field -- how to implement a ClearClick feature on Chrome which is remotely comparable to the one available on Firefox. Therefore, the main development line will always be conducted on Firefox and then retrofitted as much as possible to work on Chrome. Actually, I put a Chrome porting among my priorities because I keep seeing people lured in a false sense of security by the Chrome sandbox (which can be worked around as demonstrated in the recent Pwn2Own and Google's own hacking contests, and most important provide zero protection against webappsec attacks) and by the presence of so-called NoScript-like extensions which are very limited in protection breadth and effectiveness. My goal there is providing a "NoScript for Chrome" with the guarantee of superior quality code and "the best protection available in Chrome", even though I will always recommend the Firefox counterpart.

On the other hand, if by "new versions" you mean a major architectural overhaul (like the one made in NSA), as much as I'd like to make it, as I stated above there are some roadblocks to be passed (and mainly the lack of a clear outlook on the future of Firefox Mobile and multi-process/multi-threading choices in the platform) which currently advice against such a dangerous effort, especially since the day-to-day experimental work to enhance and extend NoScript's protection features is never missing.

Re: NSA and the future of Noscript

Posted: Fri Mar 23, 2012 10:38 am
by tlu
@Giorgio: Thank you very much for your detailed answer which makes a lot of sense. I hope that you didn't interpret my questions as an attempt to put unbecoming pressure on you to reveal your business plans or whatever. I was just a bit nervous that you mentioned a Chrome version as a top priority but did not say anything about NS 3.0. Being someone who's been called a "Noscript evangelist" in other forums and who was successful in bringing Chrome users back to Firefox (because of Noscript being a superior product), I was unsure about your roadmap. But your answer perfectly clarified my misinterpretations. Thanks again!

@Tom T. and GµårÐïåñ : Please understand that my intention was not at all to question Giorgio's work - far from it! And Tom: I'm perfectly aware of the large changelog ;) As mentioned above I was just unsure about the future development of Noscript as I misinterpreted some of Giorgio's remarks.

Re: NSA and the future of Noscript

Posted: Sat Mar 24, 2012 1:25 am
by Tom T.
@ Giorgio:

Giorgio Maone wrote:... Actually, I put a Chrome porting among my priorities because I keep seeing people lured in a false sense of security by the Chrome sandbox (which can be worked around as demonstrated in the recent Pwn2Own and Google's own hacking contests, and most important provide zero protection against webappsec attacks) and by the presence of so-called NoScript-like extensions which are very limited in protection breadth and effectiveness.

We've had entire threads on those topics - the false sense of security and the alleged "NoScript-like extensions" -- no need for you to read them, since you know it ;) -- but thanks for stating this explicitly. It's a good post to which to point users who ask about these NS wanna-bes, or about Chrome's "superior" security. (Perhaps vs. OOB Fx, perhaps not, but nothing matches FX/SM+NS.)

Also, thanks on behalf of the team for giving a more complete status update, since we get asked about that, too.

@ tlu:

No offense was taken or intended. Just some "explaining" of what GµårÐïåñ and I *did* know, like the many 0-day protections, etc., that were delaying longer-term projects.

And thanks for your "evangelism". ;) I try to do that, too, pointing out where NS makes Fx/SM the safest browser around, but of course, I'd be thought of as "biased". Well, d'oh, yeah, I'm biased in favor of the safest browsing possible. :roll: -- for my *own* sake as well as others'. (Or why would I be donating my time here instead of elsewhere? -d'oh^2)

You *might* be interested in one of those threads matching Chrome vs. Fx/NS - or not. I contacted a professional who specializes in custom-designing so-called "high-assurance" (high-security) systems and programs, for Gov, military, and corporate, and his commentary was excellent.

Not to mention the fact that he used Fx-NS for his personal browsing. What an endorsement! :)

Re: NSA and the future of Noscript

Posted: Sun Mar 25, 2012 4:47 pm
by tlu
@Giorgio: Let me ask another question. I mentioned in the first post that Mozilla is planning a click-to-play functionality for FF14 (as a matter of fact, plugins.click_to_play has already been available in about:config since FF11). Are you planning to support that in Noscript 2.x? This would be a very valuable first step towards site-specific permissions - hopefully without the need of rewriting large parts of NS ...

Tom T. wrote:You *might* be interested in one of those threads matching Chrome vs. Fx/NS - or not.


Tom, I read that thread - an interesting read which didn't change my opinion, though. ;) Nevertheless, it would be a good thing if FF had a sandbox, too - and a whole process sandbox without E10 is actually planned and is part of the Security Roadmap. Side note: It's not really that important for me as I'm running FF in Ubuntu tightly confined in an AppArmor profile.

Re: NSA and the future of Noscript

Posted: Sun Mar 25, 2012 10:33 pm
by Giorgio Maone
tlu wrote:Are you planning to support that in Noscript 2.x?

What do you mean by "support", exactly?
As far as I can tell, NoScript's own content blocking mode is already considerably more flexible and fine grained than Click to Play, at least in its initial iterations as they're planned.

Re: NSA and the future of Noscript

Posted: Mon Mar 26, 2012 2:50 am
by Tom T.
tlu wrote:...it would be a good thing if FF had a sandbox, too

Agree, of course.

As for restricted rights, before I finally said a not-so-fond farewell to IE, I did d/l "DropMyRights", which allowed one to run IE without admin privilege, even though user is logged on as admin. It would stop a lot of things, since you couldn't install sw, etc. -- meaning most malware can't install either.

Or one can simply browse as a Limited User or Guest. But a PITA when you do need to d/l something. Guess that's why they added UAC in Vista, which seemed to be even more of a PITA, and bypassable. But the internal sandoxing is great. Unfortunately, it seems to be only in the very early planning stages.
Side note: It's not really that important for me as I'm running FF in Ubuntu tightly confined in an AppArmor profile.

I run Fx inside Sandboxie. Nothing's perfect, but it's worked so far....

And what Giorgio said about NS being much better than what was described at your links, which I did read.

Guess they gave up on adding NS to default, OOB Fx, even as opt-in, with a first-run (of Fx, including of updates) splash screen briefly explaining the benefits and usage .... and perhaps a quick toggle switch for those who are a bit overwhelmed at first, but would like to try it here and there until they get used to it. Make it readily available at one's fingertips, and some who otherwise would never install it might be tempted to give it a few tries, perhaps further piquing their curiosity...

Re: NSA and the future of Noscript

Posted: Mon Mar 26, 2012 12:29 pm
by tlu
@Giorgio and Tom: What I meant is the following. In Noscript you have AFAIK basically 3 options how to manage plugins:

1. By default, if you whitelist a site not only scripts but also plugins are allowed. Disadvantage: Plugins are allowed on all whitelisted sites which is not always desirable.
2. By toggling "NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too" plugins are blocked even for whitelisted sites. Disadvantage: Exceptions for specific sites like youtube are not possible, IMHO.
3. You can create an ABE rule like

Site *
Deny INCLUSION(OBJ, SUBDOC)

and manually add exceptions. Disadvantages: a) Very laborious, b) placeholders no longer show up -> temporarily allowing plugins no longer possible.

I don't know if the planned click-to-play functionality would circumvent these disadvantages. Perhaps it will be possible to choose option 2 above as default, and Firefox will remember the sites where you allow plugins permanently (through the click-to-play UI) by sort of "bypassing" Noscript. Will it work that way? (EDIT: This is similar to the click-to-play functionality in Chrome.)

EDIT: This is what I meant with a first step towards site-specific permissions.

Re: NSA and the future of Noscript

Posted: Mon Mar 26, 2012 5:34 pm
by heavyweight
Hi Giorgio do you plan on releasing a beta or developer build for chrome sometime soon if so i would love to try it out i try out many betas of extensions. just curious have a great work week.

Re: NSA and the future of Noscript

Posted: Mon Mar 26, 2012 6:02 pm
by Giorgio Maone
tlu wrote: Disadvantage: Exceptions for specific sites like youtube are not possible, IMHO.

They are, just not permanent (until you exit the browser only, which may be a very long time these days): NoScript menu, Blocked Objects|Temporarily allow shockwave-flash@http://youtube.com.
Correct me if I'm wrong, but click-to-play permissions' lifespan seem the same and they're less granular AFAIK.

Re: NSA and the future of Noscript

Posted: Tue Mar 27, 2012 9:28 am
by tlu
Giorgio Maone wrote:
tlu wrote: Disadvantage: Exceptions for specific sites like youtube are not possible, IMHO.

They are, just not permanent (until you exit the browser only, which may be a very long time these days): NoScript menu, Blocked Objects|Temporarily allow shockwave-flash@http://youtube.com.

Well, I meant permanent exceptions.

Correct me if I'm wrong, but click-to-play permissions' lifespan seem the same and they're less granular AFAIK.


I must admit that I don't know. I will try to find out - but that will take some time as I won't have any internet access in the next few days :(

Re: NSA and the future of Noscript

Posted: Wed Mar 28, 2012 4:59 am
by Tom T.
tlu wrote:
Giorgio Maone wrote:Correct me if I'm wrong, but click-to-play permissions' lifespan seem the same and they're less granular AFAIK.

I must admit that I don't know. I will try to find out - but that will take some time as I won't have any internet access in the next few days :(

Being totally unbiased ;) , IMHO Giorgio is 100% correct. From your linked thread, which won't be available until at least Fx 14 anyway:

Open issues/risks

* What type of UX to have for allowing users to opt in (or out) of enabling plugins on a (semi)persistent basis? See below in "Use Cases".
NS does that... can disable restrictions on whitelisted sites.
* What determines if a plugin is click-to-play vs always disabled vs always enabled? See "Use Cases" below.

See above. All user-configurable in NS GUI.
* How do we manage these click to play settings? It would bad to hard-code them, and much better to deliver via our existing blocklist mechanism.
Oh, I don't know, maybe delivering them by delivering NS in the basic FX? Scripting allowed globally still allows blocking of Flash, Java, MS Silverlight, etc.
* Differentiating plugins by type - should enabling (or clicking) Flash enable Java on a given page, for example?

*That* is totally unworthy of any "developer". ("Unworthy" was the mildest adjective that came to mind. :mrgreen: ) How about "D'oh, of course not!" -- as NS Temp-Allow Flash does *not* temp-allow Java on that page. As for enabling, the user who chooses to disable restrictions on w'/l sites (I keep them Image) is aware that all of these plug-ins will run at the w/l sites. So again, NS has already invented the wheel that they're trying to re-invent. :roll:
* Adverse reactions between content plugin sniffing and click-to-play
o Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."

Not a problem in NS, with its Blocked Objects menu, color-coded icon, placeholders etc., is it?
o Can content differentiate between "click to play" and "hard-disabled for security reasons"?

NS users can enable anything, or leave default-denied, or tighten the OOB settings. Not sure what MZ is proposing, in terms of them deciding for you what's unsafe, other than the already-available options of "Block attack/forgery sites". The remainder seems more like an anti-virus or anti-malware product's concern, IIU them C.
* Whether to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin content loaded over HTTP. Trusting content served over HTTPS is not the same as trusting content over HTTP, which is why they are usually treated as separate origins for security purposes.

NS Options > Advanced > HTTPS > Behavior.
* Risk of clickjacking - is this something we should try to mitigate ?

Definitely. But if you start from scratch, do you think you'll ever catch up to the many refinements that NS has evolved over the years?

Again, load NS into OOB, perhaps with scripts globally allowed and a splash screen notifying of the availability of the script-blocking, and presto! -- instant Clickjacking protection, plug-in block/enable as the user wishes, differentiation between HTTP and HTTPS, -- and they never even mentioned XSS protection.

Plus ABE, which may require fewer user-created rules when NS 3.x is released.

Overall, NS *is* more finely-grained, and I don't know why they want to duplicate/reinvent it. MHO. YMMV.

Re: NSA and the future of Noscript

Posted: Wed Apr 04, 2012 4:52 pm
by tlu
Tom T. wrote:Plus ABE, which may require fewer user-created rules when NS 3.x is released.

Overall, NS *is* more finely-grained, and I don't know why they want to duplicate/reinvent it. MHO. YMMV.


Tom, I don't doubt that NS 3.x is more flexible and finely-grained. Note, however, that my question was if NS 2.x would support click-to-play for plugins as a, well, kind of interim solution as Giorgio didn't reveal a new time span for the release of NS 3.x (which is understandable considering the difficulties he mentioned in his answer).

I still think that such an interim solution (provided that no major code rewrite for NS 2.x is necessary) would be beneficial. The ability to remember plugin-activation settings on a per-site basis is planned by Mozilla, possibly even plugins control on a per-plugin basis for a given site. Once this comes true, a combination of this solution with toggling "NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too" would reduce the attack surface considerably as plugins are no longer allowed for each and every whitelisted site while it would be easy to define permanent exceptions for specific trusted sites.

But again, NSA would be definitely a better solution ... :)