Somehow installing, configuring, and using NoScript in K-Meleon 1.5 via Wine

I am assuming that you probably already know how to use Wine and know your way around the computer.

The conditions: Knoppix 4.0.2, because it runs passably with 128 Mb of RAM, in a situation where no swap space is available. This version of Knoppix has a really outdated version of Wine, which makes it difficult to use Windows programs there. There may be people stuck with either that version of Knoppix or that old version of Wine. At least this post provides a case study, which I hope could be of some interest.

The only reasonable place I could find NoScript for K-Meleon 1.5.4 is from extensions.geckozone.org/KMES-NoScriptEn. The version is 1.7.8.0 and it's from 17.06.2008 (that's 2 and 3/4 years old as of April 2011).

First off, change installer's .exe file rights for it to be an executable. Like this from the command line:

chmod u+x "K-Ext(1.1-1.5-1.6)_NoScript(1.7.8.0).exe"
^ u = for current user; + = add/enable; x = executing;
The filename is wrapped in double quotes, because it contains parentheses "()".

In my case, the first round of installation didn't work. Later I specified this target install directory:

z:\mnt\hda1\Program Files\K-Meleon
^ can't remember if I specified an upper- or lowercase letter z

and installation worked after that.

K-Meleon should not be running during installation, so run it after installation.

27.04.2011.–: After a relatively quick-and-dirty article which turned out to be far more specific than originally anticipated and still quick-and-dirty, I've updated the following with information which will make K-Meleon slightly easier to use as it is, with what the setup is and all...

When running K-Meleon through Wine in Knoppix 4.0.2 (remember that it's from 2005 and very outdated) and when you're stuck with such a set-up:

• The NoScript button menu can be used with a mouse by right-clicking on the NoScript button and holding the pointer device button down and dragging the cursor to the necessary command (shortcut menus will otherwise turn off after right-clicking on an item and hovering a mouse cursor over its menu; I've seen this in TWM, don't know how it works in other window managers).
  Other ways:
  • Click on the NoScript button, then use menu hotkeys (underlined) to perform a function;
  • or consider dragging the pointer through the NoScript menu via the main Tools menu.
• Saving configuration changes in the NoScript Options window does not work, because it's impossible to save settings by clicking the OK button, but you can otherwise close the window (saving options may work with newer versions of Wine; haven't tried this myself).
  Workarounds:
  
  • Configuring NoScript is possible only at about:config for settings (use the noscript text pattern in the about:config search bar to get NoScript-specific settings);
  • ^ Consider removing some default domains there from the noscript.default string;
• Worse, the NoScript menu in K-Meleon (at least in the given configuration and set-up) won't show domain names in its menu (Shock! Horror!).
  • Now, the whitelist, which is not shown in about:blank, is only configurable in prefs.js at the local K-Meleon profile folder on the hard drive (from where K-Meleon is run). If you don't know what the prefs.js location of the current profile is, open Preferences, go to "Privacy & Security" preference category, click on the Cache tab and see the "Cache Folder:" entry, which shows the location of the current profile folder.
    An example location is here:
    

    "/mnt/hda1/Program Files/K-Meleon/Profiles/g1bb3r1sh.default"

    So, edit the prefs.js file with a text editor at this line:
     
    user_pref("capability.policy.maonoscript.sites","place.doma.in nam.es here.com in.alphabetic.al ord.er.com ea.ch doma.in na.me separated.wi.th a.space.com and.do not.break.the.li.ne");
     
    Make sure just in case that K-Meleon is not running when editing the file, because if you've saved the file and then exit K-Meleon, then K-Meleon is highly likely to overwrite your changes.
    13.09.2011.

    Given that I had been using K-Meleon like that for a longer while, I created a menu item in the TWM window manager, where I could directly open the prefs.js file from the menu.
  • Alternately, adding sites to whitelists works from the menu (see above), but since the above configuration does not make it possible for the K-Meleon URL bar to function and display addresses, then a user is limited to knowing the site domain and web page address in the following ways:
  • In K-Meleon, the tab bar is typically shown by default, so it should be enough to hover the mouse cursor over a page's tab button: This displays the tool tip, which then shows the site/page title and its partial address.
  • A user might know the site's domain name, if they've entered it themselves (because of limitations, entering a URL goes through editing bookmarks and accessing a bookmark set up for just that).
    A user can specify that only top-level domain names are added, by setting this in NoScript preferences through about:config, only that the whole point of NoScript to me is the fine-grained way in which some subdomains can be whitelisted, so that disruptive ones are duly excluded. Unfortunately, not directly seeing a site's domain name in the URL bar has security implications, including the fact that the non-functioning URL bar doesn't change color when visiting a secure site, though a bottom-right status bar indicator should work. Preferably, only safe sites should be visited. (Avoid clicking e-mail links, if you know they're dubious, but this requires at least some user education and this is where NoScript is useful. There is nevertheless a greater amount of security in running K-Meleon equipped with NoScript, no matter how limited it is, through Wine in Linux than in Windows 9x);
  • Some necessary domain names pulled by a page from (a) differently-named domain/s to fetch scripts and/or stylesheets across sites and subdomains are not displayed anyway (not even in the NoScript menu), so there is no direct way of learning which other domains must be allowed for scripting.
  • Consider disabling NoScript for the duration of the session, if you're using a service which requires logging in and if it's been impossible to learn what are the exact outside domains with necessary scripts.
  • The third option is to import domain names from other NoScript settings in other prefs.js files. This actually works. But what if using a new service that users a non-primary domain name for scripting? Or what if an existing service sometimes changes its subdomains?