What can be done this way? Almost anything that will fit into the programming model and the user interface specifics. For instance a mail client can be written in ASP - in fact one can port many of the existing ASP WEB mail solutions by just removing a few features not needed or not available in the local ALP environment. Or one can create a link management application that allows the user see his/her links as a portal (again it is possible to port something existing, but in this case it will be good to include some more specific features to make this nice). Other ideas - news collectors, online shopping companions, tools for people working online and many many other applications that will do nicely if implemented as part of the browser that the user can bring up with its full functionality when needed and use it through a minimal user interface (the toolbar) in the rest of the time.

While the ideas for applications are infinite there is a technical details that may be interesting for many developers no matter if they are going to build simple applications or something complicated. Aside of using ALP to drive in-browser running applications it can be used also for some basic IE ScriptBar tasks. 

Using ALP to load the toolbar user interface and the Internet Security (including XP SP2)

By default most of the IE ScriptBar samples and the demo download are configured to load the toolbar UI HTML directly (see the setting (string)Protocol=Direct in the toolbar.cfg). What does this actually mean? The HTML resource designed for toolbar user interface is loaded into the toolbar through the persistence interfaces supported by IE. Thus the WEB browser control shown in the toolbar area is initialized with the UI HTML without performing file load operations on its own. The most important effect is that this way the Local Machine Lockdown is not in effect for the HTML page used as a toolbar user interface. However there is a set back - the toolbar UI is considered part of the Internet Zone (which is the default state for IE). While this is good enough for most of the applications, some of you may want to be able to avoid problems caused by paranoid security settings.

As a WEB developer you know that the user can edit the security settings of the browser and rise them to a level that would not permit anything - even any scripting. If that is the case you will not be able to run any scripts in the toolbar UI HTML. The toolbar script in the background will remain unaffected, but still this is not good enough if you cannot pass the control to it from the toolbar user interface programmatically. 

The solution is simple enough - the toolbar user interface HTML must be considered trusted content - i.e. it must fall into the Trusted Sites zone in order to make it work even if paranoid security settings are in effect (see below how to do this). Again, consider this once more from the user's point of view. In many cases this will not be any problem because an user who has done so is obviously too scared to allow any 3-d party applications to work in his/her browser. Thus the user will not be surprised by the fact that your IE application is blocked by his/her action. However it all depends on what the application does. If it is something that should work even under such circumstances then you must not rely on the IE ScriptBar defaults and using ALP is the best way to do so.

First you need to change the toolbar.cfg
(string)Protocol=ALP
Change the above setting from Direct to ALP (do not forget - to try this you must have them both installed on your machine - separately or you can download the combined IE ScriptBar with ALP package which is already configured this way).

Having this done you will have the toolbar UI HTML loaded through ALP instead of the Direct method. In other words the IE ScriptBar will form an ALP request for the UI page (no need to change the setting - the URL is automatically constructed internally). Besides this allows you to make the HTML page designed for the toolbar area an ASP page. This may give you some other benefits, but we will not discuss this here.

Now you must configure ALP to declare the content correctly so that it would be considered trusted by the browser. Note that by default ALP reports the content it serves "local". In other words by default the ALP served content is treated by the browser as like the content obtained directly from the file system (file: protocol). This is even worse in XP SP2 because it will suffer from the Local Machine Lock Down limitations. So, you need to do something more.

Using the ALP Settings shell extension (bring it up right clicking in the folder containing the toolbar UI and the DLL) edit/create ALP directory settings. There you must set the Security URL to alp:// like this:

In fact ALP Settings dialog will initialize the filed to alp:// if you are just creating the directory settings. This is done so because in more than 50% of the cases the developers are going to this dialog to do this.

Before continuing lets note that you should not mistake the "Declare content safe" option with the "Trusted sites zone" - this option has nothing to do with this!

Now anything served from that directory by ALP is reported to the security manager as belonging to the alp protocol's own domain (all the ALP content belongs to this same domain). This will return the things back on track, but still the content is treated by IE (the alp protocol's domain) as part of the Internet Zone.

Therefore the last thing we need to do is to add settings to the registry that would put all content served through the ALP protocol in the Trusted sites zone. you need to add a value under this key:

HKCU\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults

Add a DWORD value:

alp=2

If you want to change the setting for all the users make it to he HKLM (HKEY_LOCAL_MACHINE) instead of the HKCU (HKEY_CURRENT_USER). The number - 2 is the ID of the Trusted sites zone.

How to perform the change depends on when you would want to do it. Most often this is done during the setup, so you can use a section like this in the setup.cfg (if you use ALPInstall):

{ RMAKEALPTRUSTED: (ALPInstBase.InstallRegistry)
  { INSTALL:
    (string)InstallAction=CreateOnInstall
    { HKLM\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults:
      (int)alp=2
    } HKLM\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults;
    { HKCU\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults:
      (int)alp=2
    } HKCU\Software\microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults;
  } INSTALL;
} RMAKEALPTRUSTED;

The section above does the change in the both registry branches (just in case). In the setup.cfg of the IE ScriptBar with ALP demo downloadable here you will see a bit more extended version of it. There is no need to follow the paranoid manner used in that package, but still if you want to make sure about absolutely everything - this is a good way to do so. The extended settings make sure that the Trusted sites are allowed to run scripts and init ActiveX. Well, it is unlikely that anyone will forbid this for the trusted sites, but as we said the section in the demo show how to set up everything that may get in the way of your application.

Why is this all done this way? Why not simpler?

The answer of these questions concerns both ALP and IE ScriptBar. For ALP it is not a good idea to put factory settings that will put all the content served by it in the Trusted sites. While ALP is mostly used to run applications it can be also used to browse downloaded HTML content much like opening a local HTML file into the browser. So, the user can open a dangerous HTML page saved to the disk from some site through ALP the same way he/she can do this with file protocol (directly opening the page). Therefore the best policy is to keep the ALP putting the content into the Local Machine zone by default (which is the truth after all). Only the content that is especially configured otherwise (see the directory settings above) will be reported as belonging to the ALP domain. This is not a limitation because if one writes an application he/she will surely want to take at least a look at the application level settings and adjust them to fit the application needs. E.g. this policy just protects you from human mistakes done accidentally.

For better isolation it is also recommended to create ALP Application settings and Virtual ALP site in the same directory. While this has nothing to do with the issues discussed here it is recommended for any ALP application (see the ALP documentation and the ALP site for more information)

Download the IE ScriptBar with ALP demo (ZIP 1.2 MB). No documentation is included. The demo just packs them both and does nothing else. You can use it as base for writing combined IE ScriptBar/ALP solutions.