Current NotScript Limitations

NotScripts for Google Chrome helps you be safer and more secure on the web by limiting what third party javascript, iframes, and plugins can run when used in conjunction with Google Chrome’s built in tools. Because of the way the Google Chrome extensions API is structured, there are some limitations to NotScript and these instructions will help you understand them.

Before NotScripts, it was not possible for a Google Chrome extension to provide a workable method of script/iframe/plugin blocking with whitelisting capabilities on the same level as that of the popular “NoScript” addon that Firefox users have. Even the methods used by adblock type extensions are not good enough to avoid breaking many sites when used in this case. This is due to the asynchronous nature of Google Chrome extensions where synchronous methods are avoided for performance reasons. NotScripts changes this by cleverly using HTML5 storage caching to overcome the timing issues.

Please note that NotScripts is not a guarantee of security and users should always practice secure web surfing habits. Currently NotScripts does not provide advanced protection for things such as clickjacking and other methods found in the “NoScript” addon for Firefox and a malicious website may still be able to successfully use such techniques.

However, there are 3 main issues with NotScripts at the moment in order of importance:

[1] Blocking Deprecated <APPLET></APPLET> Elements

NotScripts can block plugins like Flash and Silverlight. However, Java applets are a special case. Java applets embedded with the standard <EMBED></EMBED> or <OBJECT></OBJECT> tags can be blocked, but Java applets embedded with the old, deprecated <APPLET></APPLET> tags cannot be blocked because Google Chrome does not fire load events for this legacy method. The current workaround is to disable Java in your browser until this can be fixed.

[2] Inline Scripts

All scripts loaded from a source location (the vast majority) can be blocked. However, inline scripts that are directly written into the HTML code of a web page cannot be blocked by NotScripts because Google Chrome does not fire load events for them.

For example: <script src=”http://example.com/aScriptFile.js”></script> can be blocked without any issues. However, <script>alert(“Hello, World!”);</script> written directly into the HTML code by the site you are visiting cannot be blocked by NotScripts because it is not loaded from anywhere, it is a direct part of the web page you view. However, these inline scripts are usually useful and are often required for a site to function properly.

If you want to, you can set Google Chrome to deny javascript for all sites and use NotScripts to selectively pick the scripts to run on sites you enable javascript on.

UPDATE: As of NotScripts V0.9.2 there is some inline script mitigation as a stop gap measure.

[3] Caching Reloads

When you visit a web site for the first time with scripting enabled, you may see NotScripts quickly reload it once as it caches the whitelist and refreshes. Subsequently, there is no reloading needed unless you happen to change a part of your whitelist that directly affects the site. This is only a minor issue and happens less and less as NotScripts learns your desired whitelist.