Controlling Content in Mozilla

1. The host file
   This is really a browser-independent way of controlling content.


2. The Proxy Auto-Config File
   This is another browser-independent way of controlling content. This approach is based in a feature first introduced by Netscape in the past millennium which has subsequently been adopted by other browsers, notabily by Internet Explorer. The PAC or Proxy Auto-Config file is actually a plain text file containing a bit of javascript. The main requirement is that a function

 FindProxyForURL(url, host)

must be defined in it. This function must return a string that is a semicolon-separated list of the following:



DIRECT

PROXY host:port

SOCKS host:port


This decides whether for a given http request a direct connection is attempted or a given proxy server is used.
Setting PROXY to a non-existent server (it could be a port on localhost) has the effect of blocking all content coming from the urls matching the argument of the above function.

The main disadvantage of this method is that the browser's attempts to contact the non-existing proxy have an impact on the browser's performance. This can theoretically be solved by setting up a real proxy server (on localhost, for example) that would reject the request on the first attempt. While effective, this reduces the original merits (should I say 'beauty'?) of the method, namely simplicity.
The advantage is that the maintenance costs are low: the same file can be used by multiple browsers. The could even exist a central PAC file for a whole network within a company or the private network at home.


3. CAPS (Configurable Security Policies)
   See the article by Jesse Ruderman in Mozilla.Org.
   Basically, this is an approach for setting access permissions on DOM objects, their properties and methods. Site specific rules can be created. The system is integrated in the preferences system, that is, extensios are able to set and change them during a browser session, and users are able to specify user-defined ahm... well, preferences ;-) in the user.js file of their (current) mozilla profile.
   
   In addition to DOM objects, a special javascript object can be controlled through the same mechanism. This is the technique used by the NoScript extension:
   
   
   • The overall preference (not related to CAPS) "javascript.enabled " must be enabled, otherwise javascript is completely disabled accross content:
     
     user_pref("javascript.enabled", true);
     
     (or, alternativelly, delete the preference altogether)
     
     
   • The default (special) capability for javascript is set to not allow script execution
     
     user_pref("capability.policy.default.javascript.enabled", "noAccess");
     
     
   • A special maonoscript policy is created:
     
     user_pref("capability.policy.policynames", "maonoscript <other policy names here>");
     
     
   • Sites that are to be controlled by this policy are specified under the sites kewword:
     
     user_pref("capability.policy.maonoscript.sites", "192.168.2.1 www.trusted-domain.com trusted-domain.com, another-trusted-domain.org resource: wyciwyg:")
     
     
   • The permission for sites controlled by the maonoscript policy is set to allow script execution:
     
     user_pref("capability.policy.maonoscript.javascript.enabled", "allAccess");
     
     
4. The Mozilla Permission Manager.
   This is a mechanism based on a XPCOM component
   @mozilla.org/permissionmanager;1 which implements the interface nsIPermissionManager. See the article by Mvl in Mozilla.Org and the one in Mozilla Knowledge Base, in particular the following statement:
   

   Because hostperm.1 is an outlet for Gecko's nsIContentPolicy code, it deals only with loading files, not with inline tags. As a result, rules in hostperm.1 will not affect inline styles, inline scripts, or DOM event scripts, to name a few common examples. Tags with a src= attribute are affected, because the src attribute specifies an external file to load (which is therefore controlled by nsIContentPolicy).

   The Permission Manager can control different types of objects:
   
   
   • image
   • object (plugins, that is <embed> und <object> tags)
     
   • script (not inline scripts!)
     
   • stylesheet (tested: works fine)
     
   • document (the whole document; could this be used to completely block a site/domain?)
     
   • subdocument (frames)
     
   • refresh (refresh meta tag)
     
   • other (according to the article in Mozilla KB this refers to XBL)
     
   
   Firefox already comes with a built-in UI that supports setting permissions for images, cookies, popups and javascript. Manual configuration is also possible just by editing the file hostperm.1 in the profile folder. This file contains lines with the following format:
   
   host image 2 example.com
   
   The word host is fixed. In the future new keywords can be introduced; as of today only host is supported. Following this word, and separated by tabs, are the type of resource subject to control (image), the type of control impossed upon it (2=block), and the domain for which the restriction applies (example.com). Typical values are:
   
   
   • 1=allow
   • 2=block
   • 3=no third party
     
     
   although the number and meaning of the possible values depends on the specific type of object. So for example, the cookie object also supports the value 8 = allow for session.
   
   The Firebug extension also makes use of this functionality to determine on a per-site basis whether the debbuging service should be enabled. To this end it provides the firebug permission type, and the values 1=enable and 2=disable .
   
   Update 25/02/07 11:59:
   Starting with Firefox 3 the hostperm.1 text file is being substituted by a sqlite database located in the "permissions.sqlite" file in the profile folder (similarly cookies are now stored in cookies.sqlite instead of cookies.txt, which is a pity since it breaks the ability of wget to use Firefox's cookies database). Fortunately, Nag. MATSUI hat put together an extension which provides a user friendly management console for this database.
   
   Update 06/09/2008 22:27:
   There is a new extension called "ExExceptions" by Nag. MATSUI which offers a unified permissions management console for the following objects: Cookie, Install, Image, Popup, Script, Document, Dtd, Object, ObjectSubRequest, Ping, Refresh, Stylesheet, Subdocument, Xbl, XmlHttpRequest.
   There is also Content Security Policy by Brandon Sterne, which seems to be a similar take at this, although not identical. For more info see the extension's home page.
   
   
5. XPCOM components implementing the nsIContentPolicy interface.
   This interface requires two methods to be implemented, of which only shouldLoad seems to be of relevance. In order for a component that implements the nsIContentPolicy interface to be taken into account it is necessary to have it registered with Firefox's Category Manager. See Alex Vincent's article on this topic. Also take a look at the Mozilla Cross Reference for a list of the various places in which the interface is used.
   
   A number of popular blocking content extensions make use of this interface, among others:
   
   NoScript
   Adblock Plus 0.7
   Greasemonkey
   Karma Blocker (beta as of this writting)

    Current configuration for Karma Blocker:
 [Settings]
 threshold=10
 cutoff=100

 # "Whitelist" a particular domain
 [Group]
 score=-100
 rule=$origin.host=='millionenklick.web.de'
 rule=$url.host=='adimg.uimserv.net'

 # Block web pages from accessing chrome files
 # url.host='global' must be allowed; otherwise XML bindings for scrollbars and textareas break
 # In addition a couple of extension-specific exceptions might be necessary;
 # note that this also makes these extensions detectable from content.
 [Group]
 score=100
 match=all
 rule=$origin.scheme!='chrome'
 rule=$url.scheme=='chrome'
 rule=$url.host!='global'
 rule=$url.host!='browser'
 rule=$url.host!='webdeveloper'
 rule=$url.host!='itsalltext'
 rule=$url.host!='firebug'
 rule=$url.host!='branding'

 # Assign karma to third party resources
 [Group]
 score=5
 rule=$thirdParty==true

 # Assign karma to URLs with a word that starts "ad" or "banner"
 [Group]
 score=5
 rule=$url=~'\b(ad|banner)'

1. The set of preferences dom.disable_window_open_feature.*.
   Specifically, the following features can be controlled:
   
   
   • dom.disable_window_open_feature.close
   • dom.disable_window_open_feature.location
   • dom.disable_window_open_feature.resizable
   • dom.disable_window_open_feature.status
   • dom.disable_window_open_feature.directories
   • dom.disable_window_open_feature.menubar
   • dom.disable_window_open_feature.minimizable
   • dom.disable_window_open_feature.personalbar
   • dom.disable_window_open_feature.scrollbars
   • dom.disable_window_open_feature.titlebar
   • dom.disable_window_open_feature.toolbar
   
   
   There is no UI for this series of preferences in the standard distribution of Firefox, but one is provided by the Javascript Options extension.
   
   
2. XBL bindings.
   This is the approach taken by the Flashblock extension. The original idea belongs to Jesse Ruderman.
   
   [TODO: Comment on this]