NSA and the future of Noscript

[Tom T.]

...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.

Now, I understand your point better, and I agree. I have several places where I run a Flash object at whitelisted sites -- my ISP's bandwidth speed test, e. g., -- but prefer to keep everything checked on Embeddings, including Apply > Whitelisted.

As Giorgio told me in regard to that issue, ABE can only tighten NS settings; it can't loosen them. So I need NSA to get rid of the click-to-play-that every time.

If it could be done on NS 2.x without the major rewrite, definitely, but I kind of got from Giorgio's reply that it would be a major change, needing much testing, which would merely delay NSA even more.

Note that Giorgio was replying to "at least in its initial iterations as they're planned." Your later link of "plugins control on a per-plugin basis for a given site" is a horse of a different color.

If MZ could *reliably* give control to enable default-allow Flash (or whatever) *only* at sites I designate, then I could remove the NS restriction.
But MZ's product seems to be a ways off, and untested, vs. the years of testing NS's protections.

With any luck, we'll have NS 3.x by the time MZ releases that, anyway.

[tlu]

With any luck, we'll have NS 3.x by the time MZ releases that, anyway.

Yes, that would be great. Let's hope that other plans by Mozilla (like the Supersnappy project that aims to run chrome and content on different threads) will not cause further problems and delays.

[Tom T.]

Let's hope that other plans by Mozilla (like the Supersnappy project that aims to run chrome and content on different threads) will not cause further problems and delays.

Yikes. That looks like an unsettled mess, a long way off (or as one or two posters called it, "dreaming"), more questions left unanswered than answered, and it was, how far through the thread, before someone even raised the issue of the effect on add-ons?

It may well come to pass. But sounds like it's not coming anytime soon, esp. since at least one opinion was "major Gecko rewrite". So probably, both Click-to-Play and NS 3 will be up and stable, before they break it all again.

(Seriously, it sounds like a lot of add-ons would have to have major adjustments, depending on how they finally implement that).
Interesting link, thanks.

[tlu]

Regarding click-to-play: The latest Noscript 2.3.8rc1 changelog says:

Smart integration with the new browser-native click to play: if a plugin object is manually allowed from NoScript's UI, it gets also natively activated (noscript.smartClickToPlay about:config preference)

That's good (although I haven't tested it yet as click-to-play doesn't work in FF 12). So perhaps it will also be possible in a later version that NS will allow executing plugins (even with "NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too") once the planned click-to-play UI allows permanent exceptions as suggested above. Would be really great

[Tom T.]

... So perhaps it will also be possible in a later version that NS will allow executing plugins (even with "NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too") once the planned click-to-play UI allows permanent exceptions as suggested above.

Is this not the case already? I have always had everything checked on Embeddings, incl. Apply to W/L, and use the click>placeholder or click>Blocked Objects menu to play. No problem. So it seems that you already have what you wish for. Am I mistaken?

btw, thought of PM-ing you or posting here when the dev changelog came out with that entry, but I knew you'd see it anyway (and be happy).

[tlu]

... So perhaps it will also be possible in a later version that NS will allow executing plugins (even with "NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too") once the planned click-to-play UI allows permanent exceptions as suggested above.

Is this not the case already? I have always had everything checked on Embeddings, incl. Apply to W/L, and use the click>placeholder or click>Blocked Objects menu to play. No problem. So it seems that you already have what you wish for. Am I mistaken?

Tom, I was actually referring to permanent exceptions. Once you define them in the planned UI, they should be automatically executed on the respective websites and not blocked by Noscript. The question is what will take precedence in those cases: The exceptions defined in the click-to-play UI or the Noscript settings.

btw, thought of PM-ing you or posting here when the dev changelog came out with that entry, but I knew you'd see it anyway (and be happy).

Thanks You're right that I'm always having an eye on that site.

[Tom T.]

... So perhaps it will also be possible in a later version that NS will allow executing plugins (even with "NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too") once the planned click-to-play UI allows permanent exceptions as suggested above.

Is this not the case already? I have always had everything checked on Embeddings, incl. Apply to W/L, and use the click>placeholder or click>Blocked Objects menu to play. No problem. So it seems that you already have what you wish for. Am I mistaken?

Tom, I was actually referring to permanent exceptions. Once you define them in the planned UI, they should be automatically executed on the respective websites and not blocked by Noscript. The question is what will take precedence in those cases: The exceptions defined in the click-to-play UI or the Noscript settings.

Ahh, thanks for clarifying. The name "Click-to-play" somehow gave me the idea that one would, uh, still click to play the given object. Now, where would I have gotten that idea?

While I don't yet know exactly how this will work, let's look at the latest development build changelog:

v 2.3.8rc1
+ Smart integration with the new browser-native click to play: if a plugin object is manually allowed from NoScript's UI, it gets also natively activated (noscript.smartClickToPlay about:config preference)

(emphasis is mine, not in the original)

I infer from this that if and when you click a NS placeholder or BO-menu item, then NS will also take care of telling Firefox, "Hey, this one is OK. Whitelist it (or TA it?)"

Your question is the other way around: Can Firefox's native whitelist override NS's config?

I would think not, in the same way that ABE can only tighten NS's permissions, not loosen them.
IOW, you must whitelist example.com before you can apply ABE restrictions to permit example.com to run only at sites X, Y, and Z, and nowhere else.

Thinking along those lines, NS probably would apply its restrictions to items that you w/l in Fx. To get auto-allow from both, one would probably have to uncheck NS "Apply to w/l sites", or else uncheck "Forbid Flash", relying on Fx's permissions and restrictions exclusively.

I'm not sure I want that. Consider YouTube. Will Fx CTP w/l be video-specific? It can't be, since signatures change, even on the same video, with each d/l.
(Note that Giorgio has introduced a workaround so that reloading the same video doesn't require re-allowing the object.)

If Fx needs me to whitelist youtube.com, I'd rather not, thanks. Or at least, if I do, I'd still like the NS icon and a click-to-look before OK. Else, any default video starts playing as soon as I arrive, at that or other w/l sites -- annoying.

Also, NS's plug-in protections have been tested and vetted for years, while the new Fx feature, like any new implementation, may need time to mature.
Being the cautious type, , I'd want to see it in action for some number of months, and see user feedback, before giving it full trust and reliance and abandoning NS's. Or before allowing Fx w/l to override NS. IMHO. YMMV.

Your thoughts?

[Tom T.]

This just in, courtesy of another user:

http://news.softpedia.com/news/Firefox- ... 4545.shtml

Firefox is on its way to getting a click-to-play feature for plugins, Flash in particular. A similar option is available in Chrome, though it's not enabled by default. The click-to-play option is now available in the latest Firefox Nightly releases, but has to be enabled first.

As you can expect, it's still highly experimental. Google spent more than a year before making the option available to all users by default, but even so it's not enabled by default.

For good reason too, it's a feature best left to more advanced users since it can break sites in non-obvious ways....

ETA: Also just saw this entire thread, which explores some of the above issues.
I missed it, because I was not involved in the thread (not subscribed).

Note Giorgio's warning that at this time, the feature is still highly experimental, and bugs are to be expected.

[tlu]

Your question is the other way around: Can Firefox's native whitelist override NS's config?

I would think not, in the same way that ABE can only tighten NS's permissions, not loosen them.

Well, we'll see From my layman's perspective I'd say that it might depend on where FF stores those permanent exceptions. If they are stored in, say, places.sqlite, then I'm not sure if Noscript would be able to read them. If they are stored in about:config (-> prefs.js), then Noscript should definitely be able to read them and allow the execution of plugins on those sites (with a, hopefully, small change in the NS code).

Consider YouTube. Will Fx CTP w/l be video-specific? It can't be, since signatures change, even on the same video, with each d/l.
(Note that Giorgio has introduced a workaround so that reloading the same video doesn't require re-allowing the object.)

If Fx needs me to whitelist youtube.com, I'd rather not, thanks. Or at least, if I do, I'd still like the NS icon and a click-to-look before OK. Else, any default video starts playing as soon as I arrive, at that or other w/l sites -- annoying.

Also, NS's plug-in protections have been tested and vetted for years, while the new Fx feature, like any new implementation, may need time to mature.
Being the cautious type, , I'd want to see it in action for some number of months, and see user feedback, before giving it full trust and reliance and abandoning NS's. Or before allowing Fx w/l to override NS. IMHO. YMMV.

Your thoughts?

I agree that that new FF feature will need time to mature. And I also agree that a "cautious type" might not want to use permanent exceptions at all. However, I think it will definitely be an improvement compared to the default NS setting which allows plugins on all whitelisted sites as it would be an improvement security-wise without giving up too much comfort

[Tom T.]

Your question is the other way around: Can Firefox's native whitelist override NS's config?

I would think not, in the same way that ABE can only tighten NS's permissions, not loosen them.

Well, we'll see From my layman's perspective I'd say that it might depend on where FF stores those permanent exceptions. If they are stored in, say, places.sqlite, then I'm not sure if Noscript would be able to read them. If they are stored in about:config (-> prefs.js), then Noscript should definitely be able to read them and allow the execution of plugins on those sites (with a, hopefully, small change in the NS code).

Perhaps, but until the Fx feature is matured, I'd rather that NS not trust that the Fx feature is specific enough and reliable enough.

However, as you say, if they're in prefs.js, it's easy enough to open the file and read it, to make a couple of test cases (some w/l, some not), to make sure Fx is reading and executing its own prefs correctly.

Still doesn't address the issue that I'd rather not w/l all of YouTube for Flash (or ogg, for that matter), but only on a per-video basis.
Which seems impossible to implement - I have to select the desired video first, then add it to w/l. Which is useful for replaying the same one later...

Anyway, thoughts (or knowledge of the implementation) on how broad/specific it would be at a site like YT?

I agree that that new FF feature will need time to mature. And I also agree that a "cautious type" might not want to use permanent exceptions at all. However, I think it will definitely be an improvement compared to the default NS setting which allows plugins on all whitelisted sites as it would be an improvement security-wise without giving up too much comfort

Agree. However, Giorgio added those defaults because non-tech users complained that NS was breaking all of their favorite sites, and they couldn't be bothered to spend a few minutes learning how to use the new safety tool. Driving a car or using a chain-saw, yes, but Internet safety (can't lose an arm or your life, but you can lose "an arm and a leg" ) -- can't be bothered.

Of course users with any tech-savvy -- or novices who spend a bit of time with the FAQ etc. at their leisure -- will trim the Default Whitelist and reconfigure the default settings to a higher degree of lockdown.