PublicTechnology.net in the UK ran a contributed article from Browsium today, pointing out the need for public sector organizations to end their dependence on IE6 so they can upgrade their browsers and operating systems to modern platforms.
But with so many public sector departments reliant upon applications written for the IE6 browser, any plans to migrate can be derailed if the availability of critical applications is threatened.
The solution detailed in the article is to take a Web Application Continuity approach, as delivered by UniBrows. Give it a read.
There’s an area of application compatibility that may affect your app that you probably haven’t even thought about: session isolation. The effect of this is simple: how much (or how little) user/logon information is shared between two tabs open in IE8 compared to how much or how little was shared between two windows in IE6?
While I worked at Microsoft, I remember corporations asking Microsoft for hotfixes in IE7 because IE7 shared logon information between tabs differently than when the app was hosted in IE6, resulting in severe changes in workflow that required unwanted user retraining. Although Microsoft has taken some steps to alleviate that pain (see more on that below), with the introduction of IE8, IE9 and IE10, those technical considerations are continuing to evolve (alongside other concerns, like security).
Think of it this way: originally in IE6, each web page was its own window. There were no tabs, so each window assumed it was the only web browser open to a particular page. As security concerns grew, the IE team worked to lock down how much information one web page could share with another (especially across domains). Of course these security changes impacted compatibility (don’t they always), so the IE team added options to allow IE6 (and IE7, and IE8, and IE9…) to opt into or out of different security/compatibility settings depending on their needs. Look up on MSDN; there’s a whole slew of feature control keys that you can toggle depending on the version of IE you’re running.
Session state sharing & isolation too has evolved; in IE6, each window rightfully assumed it had the only view of a given web page (even if you had more than one window open to the same site). In essence, IE6 had session isolation with other IE6 windows. With the introduction of tabs in IE7, sessions sharing became common; the thought was that tabs open in the same window are likely related. In IE7, tabs within one window can share some session state (to the same domain). Give this a test: open a window to Hotmail in a tab in IE7, IE8 or IE9 and log in to your account. Then open a new tab in the same window and go to Hotmail. What do you see? You’re already logged in to your Hotmail account in that second tab. That’s session state sharing.
Great for usability… but your web applications may break because of it
While this behavior makes sense for every day users of IE accessing web sites with a single logon, it can break certain web applications when corporations evaluate IE8. They open a window to their web app and view some customer data and then they open a second window to the same app to view a different customer. The problem is, the view in the first tab also updates to that second customer! Unlike in IE6, where you could view multiple customers in multiple windows, in IE7 (and later) you have a problem where when you update any one customer view, all the other tabs update as well. You can see this if you try to open two different Twitter or Gmail accounts in two IE8 tabs today; as soon as you log on to the second account in the second tab, the first tab changes too.
This behavior can fundamentally break the way your application works, and the way your users use that applications. Fortunately, UniBrows offers a solution.
UniBrows can help manage IE session isolation the way you want it
For each profile in UniBrows, you can choose how you want session state information to be managed: shared (the default for UniBrows, and the default behavior in IE7+) or unique (like IE6; isolated). This screenshot shows the option you can toggle to change the behavior:
If you set a profile’s session mode to ‘Unique,’ then any tab opened in IE8 using this profile will use its own unique session identifier with the application instead of sharing it with other tabs. See for yourself: add a rule using the UniBrows configuration manager like so:
Set the session state setting to ‘Unique’ for the Default IE8 Standards Mode Profile (as in the first screenshot above). Save the settings locally and open a tab to Hotmail.com and log in. Then open a second tab to Hotmail: notice that in that second window, instead of viewing the inbox of the user from the tab you’ve already opened, you are presented with the Hotmail logon screen: essentially allowing you to log on to a different Hotmail account from the 2nd tab. That’s session state isolation in action, and that may be just the thing to get your older web application running like it worked under IE6.
It’s also interesting to note that our example did not use any IE6 technology from UniBrows. Session isolation is an issue that impacts modern web applications, and can be solved by UniBrows using one of the modern Internet Explorer engines – in the case, the IE8 engine. The same is true of dependencies on multiple versions of Java, as discussed on this blog last week.
IE8’s “NoMerge” option
You may have heard of IE8’s “-nomerge” option, which in some ways attempts to accomplish the same thing. Here’s an article to read if you’re not up to speed on this feature of IE8. Why isn’t this feature enough? There are a few reasons:
Ultimately, the UniBrows solution is superior because users don’t have to do anything differently: they can just browse from site to site in any tab in any window and the ‘right thing’ will happen. There’s no need for user retraining.
Session state sharing within a tabbed browser is often great for end-users, but a headache for corporate web applications. UniBrows allows you to customize this behavior on a per-profile basis to make it easy to manage how your internal web applications function.
The session state mode setting is available in versions of UniBrows 1.1 and later.
Reading, Berkshire – 22nd September 2011: CDG, a leading provider of IT solutions for enterprise IT environments, today announced a partnership with Browsium, providing UK organisations with an enterprise browser management solution that enables IE6-dependent line-of-business applications to run natively on new OS and browser platforms—without changing a single line of code.
CDG is Browsium’s go-to-market partner in the UK for its UniBrows solution, which provides Web Application Continuity to organisations as they move to Windows 7 and provides centralised control over browsers and web applications. UniBrows is a lightweight browser add-on that is easy and inexpensive to deploy and requires no new infrastructure investment to support it. By simply installing UniBrows on PCs running Windows 7 or Windows XP, enterprises can continue to use all their IE6-dependent applications within an IE8 and IE9 tab, without the need for app redevelopment or use of complex and expensive virtualisation solutions.
“Browser compatibility is blocking Windows 7 migration plans for many private and public sector organisations. If application continuity can not be guaranteed projects become derailed,” commented Oren Taylor, director at CDG. “Browsium addresses the issue of IE6-dependency head-on providing a very simple way to keep web services available throughout IT transformation and beyond as well as giving customers the ability to centrally manage their web app environments.”
“We have seen demand from organisations around the world that are trapped on Windows XP and IE6 because of prior web application investments,” said Gary Schare, president of Browsium. “Through our Web Application Continuity approach, these organisations have the freedom to upgrade and reap the benefits of new platforms while extending the ROI of their business-critical applications.”
In addition to supporting IE6-dependencies, UniBrows provides control over all IE settings, freeing customers from the painful trade–off of security versus compatibility. With UniBrows, enterprise organisations can manage IE settings at the web application or even web page level.
Sold as a software subscription with pricing tiered by the number of PCs in the organization and available immediately, CDG is providing Browsium UniBrows in the UK as part of its portfolio of enterprise IT services and solutions. Organisations interested in further information or a free web demonstration can contact CDG UK on +44 (0) 118 963 7977 or email Browsium@cdguk.com.
Founded in 2010, Browsium Inc. creates enterprise-ready software solutions, enabling organisations to extend the life of existing line of business web applications as they deploy new operating systems and browser platforms to their client PCs. Browsium’s first product, UniBrows, promises to revolutionise browser compatibility be allowing legacy IE6-dependent web applications to run on Windows 7 and IE8 on Windows XP without modifying a single line of code.
CDG is focused on introducing and expanding innovative technologies into the UK and EMEA markets. As a business it works at the forefront of the technology industry, supported by a strong technological heritage spanning 20 years. CDG specialises in application delivery technologies, encompassing Cloud, Virtualisation (VDI and Application Virtualization), Desktops as a Service, Zero IT, Automation Tools, WAN Acceleration and Workspace Management.
Kellie Collier/Mark Kember
Tel: + 44 (0) 1491 873 323
Today we announced a new partnership with CDG UK to bring our UniBrows solution to the UK market to help customers there solve the IE6 dependency issues holding up Windows 7 migrations everywhere.
This problem is particularly acute in the UK where enterprises readily adopted what is now the legacy Windows XP and IE6 platform that Microsoft pushed so hard a decade ago. Demand from banks and the government is particularly strong, but the problem crosses every industry in the UK, as it does in the U.S. and around the world.
Read more in the press release.
Defining the problem
You may not know it, but you may have a Java problem in Internet Explorer. It starts simply and can be insidious. You have a web application (or two or more!), each of which requires a different version of Java. The solution is often simple enough: run the oldest version of Java necessary that works for the apps you have (also called the “lowest common denominator” approach).
But then things get complicated: your users might visit a gaming web site during their lunch hour and be coerced to download a newer update of Java than you anticipated. Oracle itself has released security updates for Java an average of every 2-3 months over the last three years and the Java auto-updater will try and download them all. And I didn’t even mention the full new version of Java (1.7) released in July of this year!
Suddenly your controlled application environment has started to fragment – and worse, your applications that relied on older versions of Java stop working. On top of all this, by staying on an older version of Java (to maintain compatibility), you’ve sacrificed security (by ignoring those 14 security updates released for Java since 2009 that were released for a reason). One account we’ve talked to knew that of the 25 Java security updates available for Java 1.6 at the time, 22 of them were running in their enterprise.
Sound familiar? That’s what I mean by the “Java Problem.”
The good news is that UniBrows can help solve this problem.
How UniBrows can help (aka “Web Application Continuity”)
The same way that UniBrows can help you run separate versions of Internet Explorer from one tab to another, UniBrows can help you run different versions of Java from one tab to another.
By using our profiles feature, you can designate certain versions of Java to run for certain sites independently of versions running on other sites at the same time with no user interaction required.
What this means is important: with UniBrows you can run the older versions of Java that you need for your older applications, but run the latest version of Java everywhere else. That means you maximize compatibility and security at the same time. You aren’t risking your corporate network’s health just for the sake of a few old web applications that you want to deprecate in a few years anyway. This also isolates your older apps from those Java security updates by preventing updates to the latest & greatest version of Java from impacting your older Java engines & applications.
Technical details about our solution
Java requires that you install the full version of Java you need on all client PCs. If you need to run 3 or 4 different versions of Java in your environment, you still need to install all of them on all your client PCs – that’s a Java requirement regardless of whether or not you’re running UniBrows. Java is designed to be installed side-by-side; just make sure all of your versions of Java are installed into discrete directories.
We also support the Microsoft Java VM in our solution – so if you’re one of those companies who rely on the MSJVM, we can manage that as well.
At a high level the UniBrows process, when called upon to load Java content, will check its profile settings to see if a custom version of Java has been specified. If one has been specified, UniBrows will instantiate the specific version of Java that you’ve designated to run for that page/site/application. If one has not been specified (which is the default), UniBrows allows Internet Explorer to load the default version of Java on the system, which should be the latest version of Java that’s installed (Java 1.6 Update 25 or Java 1.7 if they’re installed). Because UniBrows profiles all run in separate processes, you can have multiple versions of Java running simultaneously in different profiles all at the same time.
With UniBrows’ custom profile feature, you can maintain maximum web application compatibility for your old web apps while remaining secure while browsing the open Internet for users who use Java.
UniBrows has supported running custom versions of Java per profile since our 1.0.0 release.
One of the features that UniBrows has at its disposal to help maintain maximum compatibility with web sites is the idea of a settings sandbox.
When the browser session is closed, the sandbox is destroyed – returning all disk space & resources used by the UniBrows browsing session (like all the cached files) back to the operating system. It helps to guarantee isolation between changes made inside any UniBrows sessions from affecting anything in the native default Internet Explorer browser. There are other benefits including security, performance and privacy that are also gained by storing all settings in a sandbox.
This table shows what settings are written to and read from what locations depending on whether the UniBrows sandbox is enabled or disabled:
|Sandbox setting||Read (File System & Registry)||Write (File System & Registry)|
Essentially, with the sandbox enabled, UniBrows browsing sessions will read real settings (or from temporarily changed settings in memory) and will write temporary copies of settings (including local Internet cached files) to a temporary storage location that’s cleaned up (destroyed) after the UniBrows session ends.
The sandbox is ideal most of the time, but there can be instance where applications may not work as intended when the sandbox enabled.
One example is a web application that has to download a lot of information the first time a user connects to the site. With the sandbox enabled, every connection will act like the first connection, which would force the user to re-download the content every time they visit the site. For some applications, the download is sizable and the user delay is long enough that, for that profile, UniBrows administrators may want to disable the sandbox.
Another example is in cases where the IE6 browser interacts with a locally-installed program through file system objects (like image viewers). If the UniBrows sandbox is on, those files may be saved to a location that the 3rd party program does not know about, and as a result the application may appear to fail. In this case as well, we encourage the UniBrows administrator to consider disabling the UniBrows sandbox to restore maximum application compatibility.
The sandbox settings is a per-profile setting, so if you have several different applications managed by profiles but only one needs to disable the sandbox, you can do so without affecting the behavior of other UniBrows-rendered sites.
Where to find the setting
The checkbox to toggle this setting may be found in the Profile / Settings tab of the UniBrows Configuration Manager, as shown here:
By default, the sandbox feature is enabled for all profiles, but can be disabled for any profile at the discretion of the UniBrows administrator. The sandbox feature is available in UniBrows version 1.0.3 and later.
Welcome back to our ongoing series on the technical side of UniBrows features. Today we’re focused on custom Content Handlers.
Content Handlers are all about downloads. They give administrators the ability to mandate specific procedures that are taken when files are downloaded (i.e. open a certain type of file with a specific program or run a command on a downloaded file when the file has a specific extension). Additionally, due to limitations in Internet Explorer, Content Handlers are necessary in order to perform any form of file download when using the Internet Explorer 6 Engine. If users of a Profile that uses the Internet Explorer 6 Engine would like to perform any type of file downloading on sites rendered by that Profile, the file types that they would like to download must have specific entries in a Content Handler enabling their download. Otherwise, users will not be able to download the files. Downloads can be performed without any entries in a Content Handler on any other Profile that doesn’t use the Internet Explorer 6 Engine, assuming that the administrator has disabled sandboxing on that Profile. Please remember that these restrictions only apply to sites being handled by a UniBrows rule & profile – this does not apply to sites rendered with the native browser (IE8 or IE9).
Regardless of whether a Content Handler is necessary to enable file downloading on the Profile that you are concerned with, Content Handlers provide a great way for administrators to manage the types of files that users are able to download and what is done with those files as soon as they are downloaded (e.g. passing all files through a virus scanner).
Features / Interface
The following screenshot was taken off the Content Handlers tab:
The Content Handlers Tab consists of the following features:
Managing Content Handlers with the UniBrows editor
The Content Handler Editor window is where all configurations and settings are managed for individual Content Handlers.
This editor offers you the ability to configure the following properties of a Content Handler:
The following screenshot of a Handler Editor window illustrates the solution to a common scenario where users of a web application that requires rendering in the Internet Explorer 6 Engine also need to be able to download .jpg files from the site. Another extension could be substituted for .jpg (i.e. .pdf, .doc, .xlsx, .png, etc.) and that file extension would then be supported.
The following screenshot of a Handler Editor instance outlines an example scenario where files of MIME type “application/pdf” are downloaded to a temporary location and passed to an application via a command line. The downloaded file is passed to the command line via the “%1″ variable.
This powerful feature allows you to take explicit control of how Internet Explorer handles different file types when running under UniBrows, and is available in versions 1.2 and later of UniBrows.