1.1

Q:   What is that strange, evil blue being in the NoScript logo?
A:   It is Jesse the JavaScript Worm, an extra-dimensional menace trapped by NoScript. He's said to be the evil cousin of Trogdor, but I swear by the Flying Spaghetti Monster I did not know anything about StrongBad and his dragon when I designed NoScript logo ;)

1.2

Q:   Can GreaseMonkey work with NoScript?
A:   Yes, it can. Some GreaseMonkey user scripts just work only on pages where JavaScript is allowed, but most of them will work anyway.
For instance, if you're a Mozillazine forum user, you may want to install the GreaseMonkey script featured in this FAQ, making your life easier if you prefer to keep JavaScript off on message boards (wise choice, BTW).

1.3

Q:   Can FlashBlock work with NoScript?
A:   FlashBlock will work on pages where JavaScript is allowed. This is a Firefox limitation, and there's an open bug about it, but it's unlikely it will be fixed any time soon, because of its security implications. Obviously enough, it would be more useful blocking Flash on sites you don't trust. Good news: you can block Flash using NoScript itself!

1.4

Q:   Can adblockers work with NoScript?
A:   Even if NoScript does block many advertisements as a side effect, its main focus is on security, hence it misses some fine-grained controls over ads delivery which you can find in proper adblocking products. Fortunately, Adblock Plus is compatible with NoScript: you can use them together for a secure and quiet browsing.

1.5

Q:   What websites are in the default whitelist and why?
A:   If you're a security-minded user, you probably want to build your own customized whitelist suiting your needs and keep it as short as you can.
Therefore, when you install NoScript for the first time, you've got a very short default whitelist of sites you can trust:

1. chrome:
   It's the only "permanent" one. It can't be removed because it is the privileged pseudo-protocol used by Firefox internal scripts: disabling it would prevent the browser itself from working.
2. about:xyz
   A bunch of about: internal pseudo URLs. You'd better keep them there because they help your browser working as expected.
3. addons.mozilla.org
   It's the add-ons Mozilla website. You probably installed NoScript and any other extension you've got from there. You trust these guys, don't you?
4. noscript.net, flashgot.net, informaction.com, maone.net
   My own websites. You just installed a software of mine on your system, running with the privileges of your web browser. If you don't trust me, you've got a much bigger problem than JavaScript on my websites ;)
   Notice that I intentionally left out hackademix.net, because it contains user-generated content (blog comments) and it could occasionally host security-related proof of concepts for didactic purposes, which you may want to allow explicitly.
5. • gmail.com and google.com (GMail)
   • hotmail.com, live.com, microsoft.com, msn.com, passport.com, passport.net, passportimages.net (Microsoft webmail services)
   • yahoo.com, yimg.com (Yahoo! Mail)
   All these sites have been added to enable JavaScript on the most popular AJAX-based webmail services "out of the box". This way, even if an user installed NoScript without understanding what she was doing, and she's got no idea about how NoScript works, she can still cry for help by email using the shiny user interface she's accustomed to :)
6. googlesyndication.com
   This is the Google Adsense domain. From a security standpoint, it is as trustworthy as google.com, or even more because most of the Google money depends on its safety. It's in your default whitelist because many websites and projects (including NoScript and Firefox) are directly on indirectly sustained by the Google Adsense program: if you use NoScript to "Forbid googlesyndication.com", you're automatically opting out from contributing this way to all those websites and projects at once.
   If you don't trust Google at all, fine with that and go ahead forbidding all its related domains.
   Otherwise, if you're just annoyed by Google Ads (and with ads in general), the best way to disable them is using a proper adblocker, which will also let you set exceptions, i.e. websites you want to support allowing them to display ads.

Obviously, if any of the entries above (except chrome:) bothers you for any reason, you can delete it at any time by using either NoScript Options|Whitelist|Remove or the regular Forbid commands.

1.6

Q:   What is that weird sound that I hear when I open a web page?
A:   This is a sound that Markus kindly offered me while suggesting to provide audio feedback notifying when pages containing <script> tags are opened. I believe it's a wise suggestion, since I've heard of people who installed NoScript and after that were surprised to find some sites not working anymore: at least they would be reminded that there's a nasty little extension doing its work :-)
On the other hand, many people seem not to like this distinctive toilet cover sound that much ;-)
Of course, you can disable it whenever you want changing NoScript Options|Notifications options. 1.0.7 version and above use a more discreet "Zap" sound and an alternate standard "Popup blocker" style notification (Firefox only).

1.7

Q:   Have I got to disable JavaScript from Firefox options to browse safely with NoScript?
A:   You must not disable JavaScript in Firefox! NoScript will allow/forbid scripts, but they have to be enabled by default, i.e. Tools|Options|Content|Enable JavaScript* option must be checked (JavaScript enabled), otherwise JavaScript is disabled everywhere even if allowed by NoScript.

1.8

Q:   Have I got to disable Java and/or Plugins from Firefox options to browse safely with NoScript ?
A:   You don't need to: NoScript can block Java™, Flash® and other plugins.

1.9

Q:   Why can I sometimes see about:blank and/or wyciwyg: entries in my NoScript menu? What scripts are causing this?
A:   about:blank is the common URL designating empty (newly created) web documents.
A script can "live" there only if it has been injected (with document.write() or DOM manipulation, for instance) by another script which must have its own permissions to run.
It usually happens when a master page creates (or statically contains) an empty sub-frame (automatically addressed as about:blank) and then populates it using scripting.
Hence, if the master page is not allowed, no script can be placed inside the about:blank empty page and its "allowed" privileges will be void.
Given the above, risks in keeping about:blank allowed should be very low, if any.
Moreover, some Firefox extensions need it to be allowed for scripting in order to work.
Sometimes, especially on partially allowed sites, you may see also a wyciwyg: entry. It stands for "What You Cache Is What You Get", and identifies pages whose content is generated by JavaScript code through functions like document.write(). If you can see such an entry, you already allowed the script generating it, hence the above about:blank trust discussion applies to this situation as well.

1.10

Q:   Why should I allow JavaScript, Java, Flash and plugin execution only for trusted sites?
A:   JavaScript, Java and Flash, even being very different technologies, do have one thing in common: they execute on your computer code coming from a remote site.
All the three implement some kind of sandbox model, limiting the activities remote code can perform: e.g., sandboxed code shouldn't read/write your local hard disk nor interact with the underlying operating system or external applications.
Even if the sandboxes were bullet proof (not the case, read below) and even if you or your operating system wrap the whole browser with another sandbox (e.g. IE7+ on Vista or Sandboxie), the mere ability of running sandboxed code inside the browser can be exploited for malicious purposes, e.g. to steal important information you store or enter on the web (credit card numbers, email credentials and so on) or to "impersonate" you, e.g. in fake financial transactions, launching "cloud" attacks like Cross Site Scripting (XSS) or CSRF, with no need for escaping your browser or gaining privileges higher than a normal web page. This alone is enough reason to allow scripting on trusted sites only.
Moreover, many security exploits are aimed to achieve a "privilege escalation", i.e. exploiting an implementation error of the sandbox to acquire greater privileges and perform nasty task like installing trojans, rootkits and keyloggers.
This kind of attack can target JavaScript, Java, Flash and other plugins as well:

1. JavaScript looks like a very precious tool for bad guys: most of the fixed browser-exploitable vulnerabilities discovered to date were ineffective if JavaScript was disabled. Maybe the reason is that scripts are easier to test and search for holes, even if you're a newbie hacker: everybody and his brother believe to be a JavaScript programmer :P
   
2. Java has a better history, at least in its "standard" incarnation, the Sun JVM.
   There have been viruses, instead, written for the Microsoft JVM, like the ByteVerifier.Trojan. Anyway, the Java security model allows signed applets (applets whose integrity and origin are guaranteed by a digital certificate) to run with local privileges, i.e. just like they were regular installed applications. This, combined with the fact there are always users who, in front of a warning like "This applet is signed with a bad/fake certificate. You DON'T want to execute it! Are you so mad to execute it, instead? [Never!] [Nope] [No] [Maybe]", will search, find and hit the "Yes" button, caused some bad reputation even to Firefox (notice that the article is quite lame, but as you can imagine had much echo).
   
3. Flash used to be considered relatively safe, but since its usage became so widespread severe security flaws have been found at higher rate. Flash applets have also been exploited to launch XSS attacks against the sites where they're hosted.
   
4. Other plugins are harder to exploit, because most of them don't host a virtual machine like Java and Flash do, but they can still expose holes like buffer overruns that may execute arbitrary code when fed with a specially crafted content. Recently we have seen several of these plugin vulnerabilities, affecting Acrobat Reader, Quicktime, RealPlayer and other multimedia helpers.
   

Please notice that none of the aforementioned technologies is usually (95% of the time) affected by publicly known and still unpatched exploitable problems, but the point of NoScript is just this: preventing exploitation of even unknown yet security holes, because when they are discovered it may be too late ;)
The most effective way is disabling the potential threat on untrusted sites.

1.11

Q:   What is a trusted site?
A:  A "trusted site" is a site whose owner is well identifiable and reachable, so I have someone to sue if he hosts malicious code which damages or steals my data.*
If a site qualifies as "trusted", there's no reason why I shouldn't allow JavaScript, Java or Flash. If some content is annoying, I can disable it with AdBlock.
What I'd like to stress here is that "trust" is not necessarily a technical matter.
Many online banking sites require JavaScript and/or Java, even in contexts where these technologies are absolutely useless and abused: for more than 2 years I've been asking my bank to correct a very stupid JavaScript bug preventing login from working with Firefox. I worked around this bug writing an ad hoc bookmarklet, but I'm not sure the average Joe user could.
So, should I trust their mediocre programmers for my security? Anyway, if something nasty happens with my online bank account because it's unsafe, I'll sue them to death (or better, I'll let the world know) until they refund me.
So you may say "trust" equals "accountability".
If you need to take more info "on the fly" about a certain site you're visiting, you may want to use SiteAdvisor or the WOT add-on.
If you're more on the technical side and you want to examine the JavaScript source code before allowing, you can help yourself with JSView.

* You may ask, what if site I really trust gets compromised? Will I get infected as well because I've got it in my whitelist, ending to sue as you said?
No, you won't, most probably. When a respectable site gets compromised, 99.9% of the times malicious scripts are still hosted on a different domain which is likely not in your whitelist, and gets just included by the pages you trust. Since NoScript blocks 3^rd party scripts which have not been explicitly whitelisted themselves, you're still safe, with the additional benefit of an early warning :)

1.12

Q:   When I enable "JavaScript" globally, Java and Flash are enabled too. Is there a way to have JavaScript enabled but keeping Java and Flash blocked until I click above the NoScript placeholder?
A:   Even if you trust JavaScript to be enabled everywhere (and you shouldn't), you can still use NoScript as an effective annoyance blocker.
To setup this "Annoyance Block" mode, you just need to:

1. Check NoScript Options|General|Temporarily allow top-level sites by default and select 2nd level domain
2. Check the NoScript Options|Plugins|Apply these restrictions to trusted sites as well preference

This way, the main address of each site you visit will be temporarily allowed to run JavaScript (you may still need to check 3rd party scripts, but they're usually ads and tracking stuff), while the content blocking restrictions you setup for untrusted sites (NoScript Options|Advanced|Plugin) will be applied everywhere.
Notice that this setup, even if useful in blocking annoyances and still safer than vanilla Firefox, is considerably weaker from a security standpoint than the default NoScript configuration.

2.1

Q:   How do I install NoScript?
A:  

• Go to this page and follow the instructions.
  Should it not work, with a message about installation not permitted or disabled, follow these steps:
  1. Open Firefox's Tools|Options|Security (on Windows; Preferences|Security on Mac OS X, Edit|Preferences|Security on Linux)
  2. Click on the exceptions button next to Warn me when websites try to install add-ons
  3. Type "noscript.net" in the text box
  4. Hit "allow" button
  5. Retry installation
• If Firefox still refuses to install the xpi,
  1. Open about:config in your address bar (like it was a normal web site address)
  2. Find the xpinstall.enabled preference and set it to true
  3. Retry installation
• If you get an Invalid package error (Firefox) or an Error -239 (Mozilla/Seamonkey), you're facing a (temporary) network failure. Please clear your cache and try again (maybe half an hour later). You may also try the direct link on this page.
• If you face other troubles and you're using Mozilla/Seamonkey, please read FAQ 3.5.

More about the above and other useful hints for special cases (e.g. "Error -203") in this Mozillazine knowledge base article.
It's also been reported that certain security applications, such as ThreatFire, may prevent some Firefox extensions from being installed. If you see this happening, try to temporarily disable the offending application (thanks Emil Baldwin Jr. for reporting).

2.2

Q:   So I've downloaded this XPI thing. I've never seen such a file type! What the hell am I supposed to do with this kind of file?
A:   Just drag and drop this file onto your browser window. If it doesn't work, select the Tools|Add-Ons menu item: the Extension Manager window opens, and you can drag and drop your XPI file there.

2.3

Q:   How can I uninstall NoScript?
A:   Well, this is not exactly a frequently asked question, but nevertheless someone (very few) actually wondered about it...
If you just prefer to restore Firefox's default (less safe) behavior of allowing JavaScript and plugins by default, but you'd like to retain Anti-XSS protection and the ability to selectively blacklist sites, you can just click the NoScript icon and select "Allow Scripts Globally (dangerous)" command.
But if, for some imperscrutable reason, you really want to uninstall, you can proceed as follows:

1. If you're using Firefox, open the Extension Manager by selecting the Tools|Add-ons menu and choosing the Extensions tab.
   Highlight the "NoScript" row and click the Uninstall button.
   In the rare case it doesn't work, read next points.
2. If your Extension Manager does not open or your extensions are not shown there, your Mozilla/Firefox Profile is probably corrupted: migrating your data to a new profile may help.
3. If you're using Mozilla or SeaMonkey, please refer to this article.
4. Finally, if you installed NoScript into Netscape 7.x, well you're in trouble. Netscape 7.x is not a supported browser for NoScript. Actually, is not a supported browser at all. It's too much an old software, it's very flawed and if you're even a bit security concerned you should get rid immediately of that archaeological item and install an up-to-date browser such as Firefox. Anyway, an adventurous user reported he managed to uninstall NoScript from Netscape 7.x this way:
   1. Close your browser gracefully using the Quit or Exit menu (this is important to let it in a consistent, script-enabled state)
   2. Use the search facility of your operative system to find all the files whose name begins with the "noscript" word.
   3. Delete the files you found, cross your fingers and restart your browser
   (thanks to Ralph Gierish)

2.4

Q:   Where's the NoScript whitelist stored? How can I backup / migrate it? How can I erase it?
A:   Your NoScript whitelist is stored with all your Firefox preferences, inside your profile folder (prefs.js file). If you backup your profile, you are saving NoScript configuration as well.
If you want a copy of your whitelist as a text file, which you can transfer to other profiles or computers, you can use the Export and Import commands from NoScript Options|Whitelist.
If you want to erase your whitelist you can either use the NoScript Options user interface (recommended option) or manually remove from the aforementioned prefs.js all the preference entries whose name starts with "capability.policy.maonoscript".

2.5

Q:   I don't like NoScript redirecting the browser on its welcome page every time I upgrade it. Is there any way to prevent this?
A:   First time you install NoScript and every time you upgrade it to a newer major version, Firefox opens an additional tab containing the NoScript welcome page, where you can read the release notes, the latest announcements and an introduction to the most important NoScript features (plus a link to this very FAQ...)
If you're a power user and you feel you don't need such heads up, you can disable this feature by opening about:config (just like it was a normal web address) and toggling off the noscript.firstRunRedirection preference.
Notice that if the above "fix" doesn't work or, worse, you keep being redirected on the welcome page every time you restart Firefox, chances are there's something (like a buggy extension) preventing your preferences from being saved: you may need to follow this advice, then.

2.6

Q:   Yes, I love NoScript, but releasing new versions every few days is getting tedious, can't you limit updates to once a month?!
A:   NoScript is a security software, hence its users expect it to do every effort to keep their browsing experience as safe as it can be, always.
This means that every time a new browser weakness is reported, a new kind of web threat is discovered or a bug is found in NoScript itself (hey, no software is perfect!), NoScript is immediately updated to react as needed.
Notice that almost daily builds containing cosmetic bug fixes or experimental features are available from http://noscript.net/getit#devel, but the updates pushed automatically through the addons.mozilla.org channel are only the "stable" ones, containing either important security features or major functionality additions.
At any rate, if you want automatic updates to be delivered with a lower frequency, you can raise the extensions.update.interval about:config preference.
You could also disable NoScript automatic updates by creating a new about:config preference named extensions.{73a6fe31-595d-460b-a920-fcc0f8843232}.update.enabled and setting it to false.
Furthermore, if you want to completely turn off automatic updates and perform all your upgrades manually whenever you want, you can simply set the extensions.update.enabled about:config preference to false.
Even more control over updates and other aspects of extension management is given by the excellent MR Tech's Local Install Extension by Mel Reyes.
Even if you disabled automatic updates, you could still catch up with new releases by subscribing the NoScript changelog feed.
Finally, if you're fine with automatic updates but you're just bothered by the welcome page displaying NoScript's release notes, you may want to read FAQ 2.5.

3.1

Q:   Since I installed NoScript some Firefox crashes happen. What can I do?
A:   Upgrade to most recent stable Firefox version. Firefox up to 1.0.4 was affected by the 2 years old Bug 217967 which used to randomly crash the browser after security permissions have been changed. I fixed it with a patch that was landed in the Mozilla source tree on 30 June 2005, hence Firefox 1.0.5 and above doesn't crash anymore with NoScript :)
Notice that other crashes happening in buggy plugins as soon as you allow JS on a page, may be wrongly perceived as NoScript related even if they're not.
The most commonly reported are caused by Windows Media Player plugin, by the Yahoo Application State plugin or by the VLC plugin. The latter is installed by VLC, a cool audio/video streaming application, but notwithstanding the VLC coolness (I'm an enthusiast myself), this plugin is behind "Firefox Sudden Death" phenomena (i.e. Firefox abruptly disappear with no error message). To cure this disease, you need to remove the npvlc.dll from your Firefox plugins folder.

3.2

Q:   I cannot find the NoScript toolbar button. Where is it?
A:   Right+click on any toolbar and choose the "Customize" menu item.
A window will appear where you'll find the NoScript button: just drag and drop it on the toolbar you prefer.

3.3

Q:   I can't use hotmail (gmail, name.your.mail) / ebay / my online bank account. What's happening?
A:   Those services use JavaScript intensively also in subframes and dialogs which not necessarily have the same URL as the login page. Easiest (even if not safest) thing you can do to fix your problem is right-clicking on the page, opening the NoScript menu and Allowing the base domain (i.e. hotmail.com or google.com) rather than the full URL. The really safest behaviour would be right-clicking on every page which doesn't work and allow one by one those address entries which are marked as forbidden, starting with the ones apparently more connected with the main site and stopping when the page works.
Some common settings:

• Ebay: right-click|NoScript|Allow ebay.com, ebaystatic.com, ebayobjects.com, ebayrtm.com, yahoo.com, about:blank
• Yahoo: Allow yahoo.com, yimg.com, about:blank
• Bloglines:, Allow bloglines.com, ask.com
• Trillian browser integration, Allow file://localhost

3.4

Q:   I met a page where a movie clip is supposed to be played, but I get a popup saying that the Windows Media Player (WMP) plugin has performed an illegal operation. If I uninstall NoScript, this doesn't happen. What's going on?
A:   This is (was?) a Windows Media Player (WMP) plugin bug, not a NoScript problem. On some pages, WMP crashes if JavaScript is not enabled. If you uninstall NoScript but disable JavaScript using the built-in Firefox interface, you get the very same error. A work-around is keeping WMP disabled on untrusted sites, using NoScript Options|Advanced|Untrusted|Forbid other plugins.
Good news is that this bug seems to be fixed in the latest version of the WMP plugin for Firefox, so you should just need to upgrade.

3.5

Q:   I've got a little trouble installing the extension using Mozilla Suite (or SeaMonkey). After downloading the install starts, but I get one of the following messages:
- You probably don't have appropriate permissions (write access to your profile or chrome directory).
- WARNING: PARTIAL INSTALLATION
A:   Due to a limitation in Mozilla Suite and SeaMonkey (which lacks the true extensions support introduced with Firefox), installing an addon which delivers its own XPCOM components (such as FlashGot, NoScript, FoxyTunes, ColorZilla and many others) can be a bit cumbersome.
You need write access to the Mozilla/SeaMonkey installation directory when you install the extension. You can either:

1. Install NoScript first as an unprivileged user; when you get the PARTIAL INSTALLATION warning, restart SeaMonkey as root/Administrator and install the package again. This time the component will be properly written, and NoScript will be available to your unprivileged profile as well.
2. Alternatively, you can install a local copy of mozilla in your home directory and use it. In this case, you can install the extension just once as an unprivileged user because you have write access to the install directory.

Firefox doesn't suffer of this problem because XPCOM components are installed in the profile directory (where you always have write permissions).
Upcoming SeaMonkey versions (2 and above, AKA "Suite Runner") will borrow a similar extensions management system.

3.6

Q:   I've just upgraded to the latest version of Mozilla Suite / SeaMonkey, and NoScript has ceased working. I can still see icons and all, but when I click they do nothing!
A:   Due to a limitation in Mozilla Suite and SeaMonkey (both lack true extensions support, introduced with Firefox), addons delivering their own XPCOM components (such as FlashGot, NoScript, FoxyTunes, ColorZilla and many others) must be reinstalled every time you install/upgrade your browser.
Just reinstall NoScript as an administrator or root if needed (see FAQ 3.5 if you're wondering why) and everything should be fine again.

3.7

Q:   I've got troubles with Yahoo / Yahoo! Mail, but they go away when I disable NoScript or allow scripts globally. What should I do to selectively allow Yahoo?
A:   You just need to allow the following entries from the NoScript contextual menu:

1. yahoo.com
2. yimg.com

Advanced users may want to be more restrictive than this, but the above will catch all the Yahoo services.
Yahoo! Mail attachments:
Yahoo! launches attachment downloads in an invisible frame from a different domain (usually an IP starting with "216."). Therefore, if the file is of a kind handled by Firefox plugins (e.g. PDF, MP3 or WMV), it will get blocked by NoScript. After the first download fails, please check your NoScript menu and select the Allow 216.xxx.yyy.zzz command you'll find there. Next Yahoo! Mail attachment download will just work.
Notice that if you've got NoScript Options|Advanced|Plugins|Apply these restrictions to trusted sites as well checked (not the default), you'll need to use Blockable Objects|Temporarily allow *@http://216.xxx.yyy.zzz instead.

3.8

Q:   I cannot copy and paste formatted text in a rich text field (e.g. my webmail composer or my CMS editor). The suggested remedies (setting some capability.policy preference or using the AllowClipboard Helper extension) do not work. Is this caused by NoScript?
A:   Those "suggested remedies" are not compatible with NoScript, but enabling clipboard operations on trusted sites is even simpler: just open NoScript Options|Advanced and check the Allow rich text copy and paste from external clipboard preference in the "Additional permissions for trusted sites" section. Don't forget to uninstall the AllowClipboard Helper extension and remove the clipboard-related capability.policy entries from your preferences files.

3.9

Q:   I've got some images on my hard disk which need to be loaded inside a remote web page (a common online game setup). As long as NoScript is active, I cannot see my images. What can I do, other than disabling NoScript?
A:   Just check NoScript Options|Advanced|Allow local links.

3.10

Q:   I added good-site.com to the black list (Untrusted|Mark as Untrusted good-site.com), but it was an error. How can I revert my choice?
A:   Just reopen the Untrusted menu (on the same page as before) and you'll find the Allow good-site.com command there.

3.11

Q:   One of the NoScript keyboard shortcuts overrides a shortcut used by another important extension of mine (e.g. Web Developer). What can I do?
A:   NoScript keyboard shortcuts have been carefully chosen not to overlap any Firefox built-in function (it's harder than it looks) and also not to impact with any extension likely to be used by non-technical people. Notwithstanding, there are literally thousands of Firefox add-ons out there, hence a collision is still possible. If you see this happening, you can easily reconfigure NoScript's keyboard shortcuts by editing the noscript.keys.* preferences in about:config.
Defaults are:

• noscript.keys.toggle: ctrl shift VK_BACK_SLASH.|
• noscript.keys.ui: ctrl shift S

As you can see, shortcuts are specified as a combination of some modifiers ("ctrl", "shift", "alt") followed by one character (e.g. "A", "1", "Z") or one virtual keycode (e.g. "VK_BACK_SPACE", "VK_X", "VK_Y"), all space separated. You can even specify a pair character/virtual keycode (separated by a dot character) to cope with keyboard glitches on different systems (useful if you use a roaming profile or a portable browser).
Virtual keycodes are listed below for your reference:

VK_0
VK_1
VK_2
VK_3
VK_4
VK_5
VK_6
VK_7
VK_8
VK_9
VK_A
VK_ACCEPT
VK_ADD
VK_AGAIN
VK_ALL_CANDIDATES
VK_ALPHANUMERIC
VK_ALT
VK_ALT_GRAPH
VK_AMPERSAND
VK_ASTERISK
VK_AT
VK_B
VK_BACK_QUOTE
VK_BACK_SLASH
VK_BACK_SPACE
VK_BRACELEFT
VK_BRACERIGHT
VK_C
VK_CANCEL
VK_CAPS_LOCK
VK_CIRCUMFLEX
VK_CLEAR
VK_CLOSE_BRACKET
VK_CODE_INPUT
VK_COLON
VK_COMMA
VK_COMPOSE
VK_CONTROL
VK_CONVERT
VK_COPY
VK_CUT
VK_D
VK_DEAD_ABOVEDOT
VK_DEAD_ABOVERING
VK_DEAD_ACUTE
VK_DEAD_BREVE
VK_DEAD_CARON
VK_DEAD_CEDILLA
VK_DEAD_CIRCUMFLEX
VK_DEAD_DIAERESIS
VK_DEAD_DOUBLEACUTE
VK_DEAD_GRAVE
VK_DEAD_IOTA
VK_DEAD_MACRON
VK_DEAD_OGONEK
VK_DEAD_SEMIVOICED_SOUND
VK_DEAD_TILDE
VK_DEAD_VOICED_SOUND
VK_DECIMAL
VK_DELETE
VK_DIVIDE
VK_DOLLAR
VK_DOWN
VK_E
VK_END
VK_ENTER
VK_EQUALS
VK_ESCAPE
VK_EURO_SIGN
VK_EXCLAMATION_MARK
VK_F
VK_F1
VK_F10
VK_F11
VK_F12
VK_F13
VK_F14
VK_F15
VK_F16
VK_F17
VK_F18
VK_F19
VK_F2
VK_F20
VK_F21
VK_F22
VK_F23
VK_F24
VK_F3
VK_F4
VK_F5
VK_F6
VK_F7
VK_F8
VK_F9
VK_FINAL
VK_FIND
VK_FULL_WIDTH
VK_G
VK_GREATER
VK_H
VK_HALF_WIDTH
VK_HELP
VK_HIRAGANA
VK_HOME
VK_I
VK_INSERT
VK_INVERTED_EXCLAMATION_MARK
VK_J
VK_JAPANESE_HIRAGANA
VK_JAPANESE_KATAKANA
VK_JAPANESE_ROMAN
VK_K
VK_KANA
VK_KANJI
VK_KATAKANA
VK_KP_DOWN
VK_KP_LEFT
VK_KP_RIGHT
VK_KP_UP
VK_L
VK_LEFT
VK_LEFT_PARENTHESIS
VK_LESS
VK_M
VK_META
VK_MINUS
VK_MODECHANGE
VK_MULTIPLY
VK_N
VK_NONCONVERT
VK_NUM_LOCK
VK_NUMBER_SIGN
VK_NUMPAD0
VK_NUMPAD1
VK_NUMPAD2
VK_NUMPAD3
VK_NUMPAD4
VK_NUMPAD5
VK_NUMPAD6
VK_NUMPAD7
VK_NUMPAD8
VK_NUMPAD9
VK_O
VK_OPEN_BRACKET
VK_P
VK_PAGE_DOWN
VK_PAGE_UP
VK_PASTE
VK_PAUSE
VK_PERIOD
VK_PLUS
VK_PREVIOUS_CANDIDATE
VK_PRINTSCREEN
VK_PROPS
VK_Q
VK_QUOTE
VK_QUOTEDBL
VK_R
VK_RIGHT
VK_RIGHT_PARENTHESIS
VK_ROMAN_CHARACTERS
VK_S
VK_SCROLL_LOCK
VK_SEMICOLON
VK_SEPARATER
VK_SHIFT
VK_SLASH
VK_SPACE
VK_STOP
VK_SUBTRACT
VK_T
VK_TAB
VK_U
VK_UNDEFINED
VK_UNDERSCORE
VK_UNDO
VK_UP
VK_V
VK_W
VK_X
VK_Y
VK_Z

3.12

Q:   Since I installed NoScript, I've troubles with the ScrapBook extension. What can I do?
A:   As noticed by Mr. T. Logan Scott, the ScrapBook extensions needs (quite oddly) the file:// "protocol" to be whitelisted in NoScript to correctly operate. So, if you absolutely need the ScrapBook extension and until ScrapBook authors don't work-around this limitation, you have to Allow file://, either from the NoScript menu or the NoScript Options Dialog.

3.13

Q:   Going to http://www.bloglines.com/myblogs and clicking 'Mark All Read' gives an error in the right panel.
A:   For that feature to work, allowing www.bloglines.com as you apparently did doesn't suffice.
You also need to add tm.ask.com to your whitelist. Should other similar problems happen after that, add ask.com as well.

3.14

Q:   Why do recent NoScript versions prevent me from using XMLHttpRequest in the Firebug console on untrusted sites?
A:   Firebug uses various hacks to allow JavaScript interactive execution for web developers in the "apparent" context of sites where JavaScript is otherwise disabled (e.g. by NoScript). Unfortunately one of these hacks, which allows XMLHttpRequest usage, doesn't work if the noscript.forbidData about:config preference is set to true. Just toggle it to false and Firebug will fully work again.
Notice that this change doesn't imply any special security weakening, as long as XSS protection is kept enabled.

3.15

Q:   Why do I find 127.0.0.1:1029 or localhost:1029 (the "1029" number may vary) in my NoScript menu on almost every page I visit?
A:   You're probably a personal firewall or a proxy injecting extra code inside your page.
An example is ZoneAlarm with its "Privacy Advisor" feature.
You may either disable this feature or use jolly port matching (i.e. http://127.0.0.1:0) to whitelist all those random instances.

3.16

Q:   I get an "Unresponsive Script" message from Firefox on some page or on startup. If I disable NoScript, it doesn't happen. What does it mean?
A:   The message you're getting is usually related to poor coded JavaScript in web pages. Under normal circumstances, you should get far less messages like that since you install NoScript (by logic). However, since Firefox extensions are written in JavaScript too and NoScript doesn't block scripts living outside web pages (i.e. the browser components, included extensions), if one of them misbehaves you get that message as well.
Now the tricky part: some extensions don't like JavaScript being disabled for web pages. Most of them simply refuse to work, but a very few enter infinite loops and cause the "Unresponsive Script" message to pop up.
One known offender is the Background Music (BGM) extension. If you've got it, you may need to choose: music or security? Otherwise, please use the Standard Diagnostic procedure to find the culprit. If you can't isolate a misbehaving extension, you may want to follow the other advices here.

3.17

Q:   Some pages display the little NoScript icon with one or more links on its left side. I thought this could be disabled by unchecking "Show placeholder", but it's still shown... How do I make it go away?
A:   That's not the ordinary plugin placeholder, but JavaScript links auto-detected on an otherwise empty page or sub-frame. If you don't want to see that anymore, set the noscript.jsredirectIgnore about:config preference to true. In case you're wondering what is the purpose of this feature, go to http://www.ford.com and http://www.fordvehicles.com with that preference set to true or false and watch the difference.

3.18

Q:   Galleries at smugmug.com are not working even though I whitelisted everything here. What's going on?
A:   NoScript 1.2 introduced a feature to make some sites which depend on urchinTracker work even if googleanalytics.com is forbidden, but after release we discovered this is incompatible with some other sites, like smugmug.com. Fortunately all you need to do to fix this situation is setting the noscript.jsHack about:config preference to an empty string.

4.1

Q:   What is XSS and why should I care?
A:   XSS stands for Cross site scripting, a web application vulnerability which allows the attacker to inject malicious code from a certain site into a different site, and can be used by an attacker to "impersonate" a different user or to steal valuable information. This kind of vulnerability has clear implications for NoScript users, because if a whitelisted site is vulnerable to a XSS attack, the attacker can actually run JavaScript code injecting it into the vulnerable site and thus bypassing the whitelist. That's why NoScript features unique and very effective Anti-XSS protection functionality, which prevents untrusted sites from injecting JavaScript code into a trusted web page via reflective XSS and makes NoScript's whitelist bullet-proof.
If you're the technical type and you want to learn more about XSS, you may enjoy reading the excellent Cross Site Scripting Attacks: Xss Exploits and Defense book.

4.2

Q:   Looks like the Anti-XSS feature causes problems with URLs containing some characters such as <, ' (single quote) or " (double quotes). What's happening?
A:   If you're following a link contained in an not trusted page and leading to a trusted page,, this behaviour is expected by design. The reason is that those characters can be used to inject malicious code in the destination page, and since the source site is not trusted, "extreme" measures are taken by default.
Possible work-arounds are:

1. Removing the target site from your whitelist. This is usually the best and safest option, unless the target site absolutely mandates JavaScript, and is also the wisest choice especially for sites containing user-generated content, e.g. message boards or Wikipedia, because it prevents persistent XSS (also known as "Type 2").
2. Clicking the "Options" button and choosing the XSS|Unsafe Reload command from the contextual menu, in order to replay the suspicious request skipping sanitization.
3. (Temporarily) adding the source site to your whitelist. Of course, you should do this only if you (temporarily) trust it, and is considerably less safe than #1 and #2*
4. For geeks only, selectively turning off the Anti-XSS protection for the target page, if you're confident it's immune from XSS attacks.

Cross-site requests from a trusted site to a different trusted site are checked through the InjectionChecker engine, which is more accurate and sanitizes only requests which contain conspicuous fragments of HTML or syntactically valid JavaScript.

4.3

Q:   Can I turn off Anti-XSS activity notifications?
A:   Yes, you can, just toggle the Noscript Options|Notifications|XSS preference. Of course you will still able to monitor NoScript Anti-XSS activity log in the Error Console, and you will get an extra "XSS" menu inside the NoScript contextual menu whenever an XSS attempt is detected, featuring all the actions usually accessed from the notification bar.

4.4

Q:   Can I bypass Anti-XSS filters for certain web pages?
A:   If you're a bit of the "geek" type, you know regular expressions and you're very confident the target web page is immune to XSS vulnerabilities, you can tweak the NoScript Options|Advanced|XSS|Anti-XSS Protection Exceptions rules, i.e. a list of regular expressions (one on each line) used to identify web addresses which you deem do not need to be protected against XSS.
For instance, the "advanced search" feature on Ebay uses a syntax which is very likely to form syntactically valid JavaScript, and thus triggers the XSS filters. If you use this feature often, you may want to copy this line at the bottom of your filter exceptions, paying attention not to add extra spaces:
^http://[\w\-\.]*\bsearch[\w\-\.]*\.ebay\.(?:com|de|co\.uk)[\/\?]
Notice that "de" and "co\.uk" match german and british Ebay respectively: you will need to add your own country code / top level domain if you use a different non-US local Ebay site.

4.5

Q:   Can I turn off the Anti-XSS protection?
A:   Even if it's not recommended for daily usage, temporarily disabling the Anti-XSS protection may be useful, e.g. for testing purposes if you're a security researcher hunting for XSS vulnerabilities. To do that, you just need to open NoScript Options|Advanced and toggle the cross-site restrictions preferences.

4.6

Q:   Why does NoScript block documents loaded from jar: URLs?
A:   As part of its anti-XSS protection, since version 1.1.7.8 NoScript prevents JAR resources from being loaded as documents: loading documents from within JAR files brings a serious XSS risk on every site allowing JAR files to be uploaded by users or, very common, allowing open redirects, e.g. Google. See Beford's proof of concept exploiting Google, the original GNUCITIZEN disclosure and bug 369814 for further references.
You can control JAR blocking from the NoScript Options|Advanced|JAR panel. Notice that this feature doesn't depend on your whitelist, i.e. it works on every site, no matter if you allowed it to run JavaScript or not.

4.7

Q:   Why are Flash applets originating from trusted sites (e.g. youtube.com movies) blocked if embedded on untrusted sites?
A:   Flash-based XSS can be performed by embedding a Flash object from a trusted site inside an untrusted web page. NoScript prevents this kind of attack by blocking plugins embedded on untrusted pages even if they ultimately come from trusted sites. Of course, you can still activate those objects on demand without whitelisting the embedding page, by simply clicking on the placeholder NoScript icon. At any rate, if you still prefer trusted plugin content to be allowed on untrusted page, you can toggle the noscript.forbidActiveContentParentTrustCheck about:config preference to false.

4.8

Q:   How does IFrame blocking work and why is it disabled by default?
A:   IFrame blocking is disabled by default because in its early stages it used to break too much stuff, while disabling scripts and blocking objects, combined with the anti-XSS protection, actually prevents most of the IFRAME-based attacks you could imagine. Anyway this feature has been tweaked and fine-tuned over time, and it should be much more usable now, especially after the Blocked objects menu has been implemented offering an alternate enabling UI, handy when placeholders are not easily accessible.
Furthermore, since clickjacking became popular, enabling it is probably a good idea
Here's how IFRAME blocking works, once enabled from NoScript Options|Plugins|Forbid IFRAMEs:

1. IFRAMEs embedded in untrusted pages are always blocked, unless they load content from the same site as their parent
2. IFRAMEs embedded in trusted pages are blocked if they try to load content from untrusted sites
3. If NoScript Options|Plugins|Apply these restrictions to trusted sites too is checked, no IFRAME can be loaded unless it loads content from the same site as its parent
4. In every case, IFRAMEs loading content from the same site as their parent are allowed.

When an IFRAME is blocked, you can see a clickable yellow placeholder which you can use either to examine its URL, save the document without opening it or activate it on the fly.

5.1

Q:   I don't want to allow forum.mozillazine.org (ehy, after all is user-provided content, unsafe by design!). Almost everything works, but the "quick reply" button fails. Of course I can use the regular reply link or Temporarily allow, but when I forget it I loose my post and it's quite annoying. What can I do?
A:   If you're a GreaseMonkey user, you can install this User Script, which provides also a few little goodies for Mozillazine posters.

5.2

Q:   When I change permissions, all the affected tabs/windows are reloaded, and sometimes this is annoying. I know I could turn off automatic reloading from NoScript Options|General, but can I disable it for background tabs/windows but keep it for the current tab only?
A:   Yes, you can: just toggle the noscript.autoreload.allTabs about:config preference to false. Another preference you may want to check is noscript.autoreload.global: if false, it disables automatic reloading when scripts get globally allowed.
Here's a list of all the reload-related noscript options:

• noscript.autoReload
  enables/disables autoreload for any action
• noscript.autoReload.global
  enables/disables autoreload for Allow scripts globally
• noscript.autoReload.allTabs
  if set to false, only the current tab is reloaded
• noscript.allTabsOnGlobal
  if set to false (default), only the current tab is reloaded if you allow script globally
• noscript.allTabsOnPageAction
  if set to false, only the current tab is reloaded when you use bulk permission change commands (e.g. Allow all on this page)

5.3

Q:   Movies are not working on the YouTube site. Why does it say I must enable JavaScript and Flash even if I already allowed youtube.com?
A:   YouTube recently split its content across two domains, likely for performance reasons. Therefore you must allow both youtube.com and ytimg.com (you're probably missing the latter).

5.4

Q:   I'm worried by the fact some sites require the akamai.net domain to be whitelisted. I'd prefer not to allow it everywhere, but only on some parent sites I trust. How can I do it?
A:   Akamai assigns to each customer an unique subdomain, e.g. a248.e.akamai.net. Therefore, you just need to allow the specific subdomain owned by the site you trust rather than the generic 2nd level akamai.net. Hint: checking NoScript Options|Appearance|Full Domains may help you in performing finer-grained whitelistings like this.

5.5

Q:   Why the NoScript menu does not disappear automatically after I allow/forbid one site?
A:   NoScript 1.8.4 introduced a long awaited enhancement for allowing multiple script sources on the same page at once, called the "sticky" UI. Now if you open the NoScript menu by left clicking on a NoScript icon, or using the ctrk-shift-S keyboard shortcut, you get the new "sticky" behavior, i.e. you can change multiple permissions without closing the menu and causing a page refresh. When you're done and ready for reload, you just click outside the menu or hit the Esc key.
You still get the old one-click/one-reload behavior when you open the menu by right clicking. If you want the old behavior back for left clicks, just toggle the noscript.stickyUI about:config preference to false. You can toggle the noscript.stickyUI.onKeyboard preference too if you don't want the keyboard-triggered menu to be sticky.
Another setting you may be interested in is noscript.stickyUI.liveReload, which causes quick reloads to happen when you change each single site even if the menu remains sticky (false by default).

6.1

Q:   What's HTTPS and why is that important for NoScript users?
A:   HTTPS stands for "Hypertext Transfer Protocol over Secure Socket Layer", and you can figure it as HTTP (the protocol you usually retrieve web pages with) over a secure encrypted connection. It is meant to protect you from eavesdroppers and man-in-the-middle attacks. An important feature of HTTPS is that if a web site has a valid digital certificate for its identity, as verified automatically by your browser, you can be reasonably sure it is the one it says to be. You can recognize HTTPS web sites by looking at their addresses, always beginning with "https://". Firefox hilights sites having a valid certificate turning part of the location bar to blue or green. Since NoScript security is largely based on domain names, a malicious party capable of spoofing a trusted site might work-around your whitelist. This kind of spoofing may happen through a DNS Hijacking attack or because you're using an untrusted proxy server, like many anonymizers including Tor. The former risk can be mitigated by configuring a static secure DNS, e.g. OpenDNS, and forcing its usage even if you're roaming with your laptop. Untrusted proxies or connectivity providers are harder to tame, because a man-in-the-middle could inject arbitrary content in any non-secure (non-HTTPS) page. In order to mitigate these issues, NoScript can be configured to honor your whitelist only if the current page is served through HTTPS, and therefore cannot be spoofed. Additionally, NoScript can help you forcing your most sensitive sites to always use HTTPS, and mitigating cookie hijacking.

6.2

Q:   How can I tell NoScript to allow only the sites of my whitelist which are served through HTTPS?
A:   Open NoScript Options|Advanced|HTTPS|Behavior, click under Forbid active web content unless it comes from a secure (HTTPS) connection and choose one among:

1. Never - every site matching your whitelist gets allowed to run active content.
2. When using a proxy (recommended with Tor) - only whitelisted sites which are being served through HTTPS are allowed when coming through a proxy. This way, even if an evil node in your proxy chain manages to spoof a site in your whitelist, it won't be allowed to run active content anyway.
3. Always - no page loaded by a plain HTTP or FTP connection is allowed.

6.3

Q:   Can NoScript force some sites to always use HTTPS?
A:   Yes, just open NoScript Options|Advanced|HTTPS|Behavior, entering the sites you want to force in the topmost box, and those you want to always leave alone in the bottom one.
You can use space-separated simple strings, which will be matched as "starts with...", glob patterns like *.noscript.net and full-fledged regular expressions. If, for instance, you want HTTPS to be forced on every Google application excluding Search and iGoogle, you can put

*.google.com

in the "Force" box and

www.google.com/search www.google.com/ig

in the "Never" box (the latter can be of course rewritten as a

^https?://www\.google\.com/(?:search|ig)\b.*

regular expression).

6.4

Q:   What can NoScript do against HTTPS cookie hijacking?
A:   HTTPS cookie hijacking happens when a site sets sensitive cookies (e.g. those identifying authenticated sessions) over HTTPS connections but "forgets" to flag them as "Secure". This means that subsequent unencrypted (non-HTTPS) requests for the same site will leak the session cookies away, even if you logged in securely. NoScript provides means to mitigate this issue, configurable in NoScript Options|Advanced|HTTPS|Cookies. If Enable Automatic Secure Cookies Management is checked, NoScript will try to "patch" insecure cookies set by HTTPS sites on the fly:

1. If the site matches the "Ignore unsafe cookies..." pattern list, NoScript lets its cookies pass through untouched
2. If the site matches the "Force encryption for all the cookies..." pattern list, NoScript appends a ";Secure" flag to every non-secure cookie set by this response
3. Otherwise, NoScript just logs unsafe cookies BUT if no secure cookie is set in a HTTPS transaction setting other (unsafe) cookies, NoScript patches all these cookies with ";Secure" like in #2. However, if a navigation from an encrypted to a non-encrypted part of the same site (i.e. sharing the same cookies) happens in the same tab, NoScript removes its ";Secure" patch to ensure compatibility. When it happens, this event is logged to the Error Console, along with a recommendation to try forcing HTTPS by listing this site in the HTTPS|Behavior|Force section.

6.5

Q:   Since I've got Automatic Secure Cookie Management enabled I cannot login on some sites. What's happening?
A:   Some web sites depend on very complicated domain interrelations and, while they handle sign on on a certain domain through a secure HTTPS channel, they need to propagate authentication across multiple domains which do not support HTTPS. NoScript tries its best to gracefully degrade in these situation which simply cannot be protected, but some sites are just too complex not to break and login fails. In this case, you've got two options:

1. If you're in a hurry, disable Automatic Secure Cookie Management, clear your cookies (at least those for the site you're trying to enter) from Firefox's Options|Privacy|Cookies and retry logging in. It should just work.
2. If you've got a few minutes to investigate,
   • check your Tools|Error Console output for lines starting with "[NoScript HTTPS] AUTOMATIC SECURE on https://www.somewebsite.com";
   • open NoScript Options|Advanced|HTTPS|Cookies and add "*.somewebsite.com" (without the quotes) to the Ignore unsafe cookies... list;
   • Close NoScript Options with "OK", clear your cookies (at least those for somewebsite.com) from Firefox's Options|Privacy|Cookies and try to log in.
   If, for instance, you can't login on www.ebay.com, the problem can be fixed adding *.ebay.com to NoScript Options|Advanced|HTTPS|Cookies|Ignore unsafe cookies... and possibly resetting your cookies. If the problem happens on http://twitter.com (notice there's no "www." there), you'll need to put both twitter.com and *.twitter.com to match both the top domain and the subdomains.

Whatever solution you choose, I'd appreciate you to send me any [NoScript HTTPS] line you may find in Tools|Error Console (possibly anonymizing authentication tokens) for analysis, so I can better tweak this very new feature.

7.1

Q:   What is Clickjacking?
A:   The word "Clickjacking" has been coined by Robert "RSnake" Hansen and Jeremiah Grossman, two security researchers (and, incidentally, NoScript users) which back in September 2008 had been prompted by Adobe to withdraw a speech about this matter because it revealed a critical exploitable flaw in the Flash player. The concept itself is not new, though, even if there was no previous systematic research. In facts, with "Clickjacking" we designate a class of attacks (also known as "UI Redressing") which consist in hiding or disguising an user interface element from a site you trust (e.g. the "Send" button of your webmail site or a pre-configured "Donate" Paypal button) in a way which leads you to click it without knowledge of what you're exactly doing. In the impressive proof of concept by RSnake and Jeremiah, you clicked anywhere in their apparently innocuous page, believing you were doing nothing dangerous, but in reality you were activating your microphone and/or your webcam for Flash access, allowing the remote attacker to spy on you instantaneously. More in general, an attacker can frame a portion of a certain web page you trust inside a different page under his control, decontextualizing it or making it transparent: this way he can easily trick you into interacting with it, and you end to perform a financial transaction or allow him special permissions, without remotely suspecting that something evil is going on. If JavaScript is allowed on the malicious site, this becomes much easier because the invisible target page can be automatically positioned exactly under your mouse pointer, so anywhere you clicks the evildoer wins. However this attack can work even without JavaScript being allowed: the attacker just needs to trick you into clicking on a seemingly innocuous link or button. Every web browser is affected, because this attack doesn't rely on any vulnerability or bug which might be fixed overnight: instead, it exploits very basic and standard web features which are implemented everywhere and are unlikely to be removed any time soon.

7.2

Q:   How can I protect myself from Clickjacking / UI Redressing attacks?
A:   If you're not an user of Mozilla Firefox or of another recent Gecko-based web browser, your pretty much out of luck: you would need to disable plugins and IFrames, which is always impractical and sometimes impossible, since most browsers have no mean to do it selectively. Protecting yourself if you're not a Firefox user is a real pain and never 100% effective.
On the other hand, if you use Firefox you can install the free and open source NoScript extension (yes, this one), which provides the only viable and safe protection available today: the ClearClick technology.

7.3

Q:   How does NoScript protect me from Clickjacking / UI-redressing attacks?
A:   Default protections that NoScript has provided for a long time, i.e. JavaScript and plugin blocking can prevent most clickjacking attacks. In older version, though, to be 100% protected against Clickjacking you needed to enable the Forbid <IFRAME> and possibly Apply these restrictions to trusted sites as well NoScript options.
Fortunately, since version 1.8.2, NoScript provides a new default kind of protection called ClearClick, which defeats clickjacking no matter if you block frames or not . Even better, ClearClick can protect you from Clickjacking / UI-redressing attack independently from JavaScript and plugins blocking: you can even Allow scripts globally (which is not recommended anyway), and you ClearClick still works.

7.4

Q:   What is ClearClick and how does it protect me from Clickjacking?
A:   ClearClick is a NoScript specific anti-Clickjacking protection module developed during the September 2008 "Clickjacking panic". It received testing and feedback from many involved security researches such as RSnake and Jeremiah Grossman (the fathers the term "Clickjacking"), Eduardo "Sirdarckcat" Vela and others, and now it's enabled by default, protecting NoScript users from Clickjacking everywhere: it even remains active if you switch NoScript in the less safe Allow scripts globally mode. How does it work? Clickjacking hides or displaces or partially covers something you wouldn't want to click, if you could see it in its original context. ClearClick does the opposite: whenever you click a plugin object or a framed page, it takes a screenshot of it alone and opaque (i.e. an image of it with no transparencies and no overlaying objects), then compares it with a screenshot of the parent page as you can see it. If the two images differ, a clickjacking attack is probably happening and NoScript raises a "ClearClick warning", showing you the contextualized and "clear" object you were about to click, so you can evaluate by yourself if that was really something you wanted to do. Of course there are many subtle technical details involved, but the basic concept is just simple like that.