NS blocking SmartSearch JS bookmarklet execution

[al_9x]

SmartSearch opens keyworded bookmarklets, based on the selected text, in a new tab. If the keyworded bookmarklet is a javascript one "javascript:alert('%s')", NS blocks its execution. The new tab opens with the right JS url, but it doesn't get executed. Without NS, it runs.

Fx 3.6.13, NS 2.0.8.1

[Giorgio Maone]

Probably WONTFIX.
NoScript needs to patch the bookmark system in order to get bookmarklets to execute.
If SmartSearch called into the bookmark API, it would likely work, but they seem to open the URL directly which, in this case, cause the JavaScript to run with a null principal which NoScript needs to block, obviously.

[al_9x]

Probably WONTFIX.
NoScript needs to patch the bookmark system in order to get bookmarklets to execute.
If SmartSearch called into the bookmark API, it would likely work, but they seem to open the URL directly which, in this case, cause the JavaScript to run with a null principal which NoScript needs to block, obviously.

Please reassess this in light of Fx 6.0 ban on javascript:. The workaround of manual reissuing of a smartsearch attempted, and blocked by NS, javascript: navigation will no longer work. Is there anything you can do? A javascript: url is being opened from privileged code so it should be allowed, if possible. If not, can you suggest something for smartsearch that will work in the presence of NS?

[Giorgio Maone]

They could use Components.utils.Sandbox to emulate JavaScript URL execution (that's what NoScript does for bookmarklet execution on non-whitelisted pages).

[al_9x]

They could use Components.utils.Sandbox to emulate JavaScript URL execution (that's what NoScript does for bookmarklet execution on non-whitelisted pages).

I emailed the author. So there is no way to know that a javascript url is being opened from privileged code (an extension calling openUILinkIn)? Also, you mentioned bookmark API, did you mean that it supports the invocation of bookmarks (something like: bookmark.open('keyword_arg', 'tab') as opposed to extracting the bookmark data and issuing the navigating oneself?

[Giorgio Maone]

So there is no way to know that a javascript url is being opened from privileged code (an extension calling openUILinkIn)?

Yes there is, but I should patch yet another browser function (fragile!) just to support this very rare use case.

it supports the invocation of bookmarks (something like: bookmark.open('keyword_arg', 'tab') as opposed to extracting the bookmark data and issuing the navigating oneself?

More or less, yes.

[al_9x]

So there is no way to know that a javascript url is being opened from privileged code (an extension calling openUILinkIn)?

Yes there is, but I should patch yet another browser function (fragile!) just to support this very rare use case.

I guess I was hoping that it could be patched once at a sufficiently low level to catch all possible javascript: url openings from privileged code.

it supports the invocation of bookmarks (something like: bookmark.open('keyword_arg', 'tab') as opposed to extracting the bookmark data and issuing the navigating oneself?

More or less, yes.

Please point to it. So if they used this api, instead, it would work with NS? Is that not better than the sandbox?

[Giorgio Maone]

So there is no way to know that a javascript url is being opened from privileged code (an extension calling openUILinkIn)?

Yes there is, but I should patch yet another browser function (fragile!) just to support this very rare use case.

I guess I was hoping that it could be patched once at a sufficiently low level to catch all possible javascript: url openings from privileged code.

Address bar JavaScript (which we don't want to allow) is "javascript: url opening from privileged code", and at that level it cannot be discriminated anymore.

it supports the invocation of bookmarks (something like: bookmark.open('keyword_arg', 'tab') as opposed to extracting the bookmark data and issuing the navigating oneself?

More or less, yes.

Please point to it. So if they used this api, instead, it would work with NS? Is that not better than the sandbox?

Any PlacesUIUtils method which calls checkURLSecurity() will do.

[al_9x]

Yes there is, but I should patch yet another browser function (fragile!) just to support this very rare use case.

To defend this use case, the ability to process text from pages with parameterized javascript bookmarklets, transform it and make arbitrary requests based on it, is a pretty powerful extensibility mechanism, there is value in preserving it. Sure it's an advanced feature, but so is NS for the most part, so it's NS users who are more likely to use and miss it.

Address bar JavaScript (which we don't want to allow) is "javascript: url opening from privileged code", and at that level it cannot be discriminated anymore.

I debugged it a bit. It looks like you are patching loadURI. If you patch one "level" lower, loadURIWithFlags, you should be able to:

1. intercept the SmartSearch load(openUILinkIn->openLinkIn->loadOneTab->addTab->loadURIWithFlags), fixing this issue
2. know when the nav is user typed javascript (javascript: url and LOAD_FLAGS_DISALLOW_INHERIT_OWNER flag set)
3. here's a nice bonus, you could optionally strip/ignore the LOAD_FLAGS_DISALLOW_INHERIT_OWNER flag, overriding the 6.0 ban on user typed javascript: this would be a welcome feature apart from this issue

Any PlacesUIUtils method which calls checkURLSecurity() will do.

I don't think openNodeIn (or anything else there) supports parameterized invocation, does it? Doesn't look like that's an option.

[al_9x]

loadURIWithFlags patching is also needed to make built-in keyword bookmarklet invocation work in 6.0.

[Giorgio Maone]

Fixed in latest development build 2.1.2.4rc2.

[al_9x]

Fixed in latest development build 2.1.2.4rc2.

When addTab calls loadURIWithFlags on an a newly created browser, you haven't replaced loadURIWithFlags yet. Is it possible for you to somehow get at it earlier? I noticed they are dispatching a TabOpen event prior to calling loadURIWithFlags, can that help?

The good news, is that with allowURLBarJS the manual workaround works. By the way, I think many would be happy to know that NS now has an option to override the 6.0 urlbar js ban, you should advertise that somehow.

[Giorgio Maone]

I'm investigating the cleanest way to do this early enough, thanks.