Getting around browser security

When developers build an interactive Web site, one of their tasks is ensuring the site works on a variety of browsers and operating systems. An even more taxing challenge is addressing differences in browser security settings.

When developers build an interactive Web site, one of their tasks is ensuring the site works on a variety of browsers and operating systems. An even more taxing challenge is addressing differences in browser security settings.

Why the dev team thinks I'm a killjoy
I'm often guilty of bringing up the topic of browser settings after one of our development team completes a Web site. Even though part of my job is to see if I can make the new site fail, the development team considers me kind of a party pooper.

All I usually do is disable scripting and cookies and see if major areas of a Web site (or even the entire site) stops working properly. If I find this to be the case, I ask the developers to explore the problem further.

The proliferation of pop-up ads
These days, you can almost guarantee that you'll see a pop-up ad online. Savvy users avoid pop-up ads simply by disabling scripting. The problem is that this also disables other uses for scripting that don't involve pop-up windows, which limits the functionality of many sites. There's a workaround for this issue: Modern browsers can put lists of sites in different security categories.

Visitors won't spend much time on your site if you make the home page so script-dependent that they can't access menus or navigate pages if they disable scripting. If the site does require scripting, ensure users can still see some content even if they disable scripting. For example, I've seen a number of Web sites with missing parts or content and even blank home pages. When I view the source, I usually find that JavaScript is required to generate content or a Flash object is the only item on the page.

Trail of crumbling cookies
Web site problems that concern browser cookies can get confusing. First, the basics: There are session cookies and persistent cookies. Session cookies go away when the user closes the browser, and persistent cookies remain when the browser is closed.

Like most developers, I disable persistent cookies by default; some people disable cookies completely, which I don't suggest. An interactive Web site that requires cookies without checking or noting that cookies are enabled may fail miserably, or worse, display disorganized or incorrect information.

I've seen Web sites fail with strange diagnostic errors in areas that require cookies--even when the user doesn't enable cookies. Again, browsers can adjust security settings to correct this, but you should inform users if a Web site requires cookies.

Sometimes developers have no other option than to use cookies in order to make an area of a Web site interactive. If this is the case, see if the user has enabled cookies, and then note that this specific area of the Web site requires cookies. Always test and verify proper operation with the major Web browser software, making sure that browser security settings don't interfere with most of the Web site.

If you have a very interactive Web site that requires JavaScript or VBScript--or requires cookies in order to operate at all--you're likely to have problems. Due to the recent rash of worms and viruses, a lot of people are simply setting their browsers to the most secure setting; this can disable script- or cookie-dependent Web sites.

Choose security over showiness
When in doubt, opt for a less flashy approach, and always test to make sure that some content appears even if a user disables scripting or cookies. Web sites can't control browser security settings--that's why developers need to take action behind the scenes.

Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.