Want more advice for
locking down your network? Stay on top of the latest security issues and
industry trends by automatically
signing up for our free Internet Security Focus newsletter, delivered each
Monday.

How often have you browsed to a Web site, only to encounter
a blank page in your browser? This happens to me all the time. Other times, the
Web page is missing entire sections—typically navigational elements—and I can’t
browse around at all. And sometimes, though not always, the Web page notifies
me that I need to install or enable a plug-in or change my browser’s settings in
order to view and navigate the Web page properly.

Now, I’ll be the first to admit that I’m not a typical user,
but by no means am I the only person who experiences these problems
either—particularly since users are much more aware of Web browsing security
concerns than they used to be. Depending on my mood and the Web site in
question, I may spend some time attempting to adjust my Web browser settings.

But more often, when I encounter an improperly displaying Web
site—especially those that require JavaScript, ActiveX controls, Java, or
Macromedia Flash in order to work at all—I question whether it’s worth my time.
And if a Web site “locks” me in, due to JavaScript code redirects,
pop-up windows, or some other method to keep me from going back, I won’t even
bother trying to make it work.

Don’t get me wrong: Interactive features on Web sites can
offer great benefits to users. However, these features are only truly
beneficial when the Web site has properly addressed browser security concerns.

It’s important to remember that any technology that has the
potential for abuse can and will eventually be the target of abuse, something
that Web site designers seem to ignore. This should not be news to anyone;
attackers have already used the interactive browsing features of Macromedia
Flash and browser-side programming languages such as Java and JavaScript to
circumvent security precautions and exploit Web browsers.

In response, many users have taken steps to prevent such
exploits by customizing Internet security settings on their Web browsers and
configuring higher security settings. But this beefed-up security means that
many Web sites using interactive features via Java, JavaScript, ActiveX,
cookies, and other browser-resident interactive features simply won’t work without
user intervention.

Of course, it’s never a bad idea to heighten the security of
your Web browser, but keep in mind that these security settings have no bearing
on browser plug-ins or Browser Helper Objects (BHOs). While users can now
adjust controls for browser plug-ins, this process is even more confusing than
setting up specific Web site security zones. Consequently, most users don’t even
bother.

In the case of a particular browser plug-in, such as
Macromedia Flash, the security settings of the Web browser itself have no
effect on the security settings for the Flash plug-in. In fact, Internet
marketing companies have recently exploited this very “feature” to
force pop-up advertisements to display—even if the user has disabled other
interactive browsing features.

In addition, Flash can keep persistent information about
users outside of the security controls for the Web browser. While Macromedia,
now part of Adobe Systems, has responded
to this security concern, I still choose to disable Flash entirely in my Web
browser.

Incidentally, there have been numerous other exploits for
Macromedia Flash. Therefore, knowing that Flash bypasses browser security
settings should be a wake-up call to Web site designers who are forcing Flash
on people who don’t want it.

But I can’t entirely blame Macromedia or Web site designers for
using Flash for interactive Web sites. Even though the World Wide Web
Consortium (W3C) established standards years ago, the only Web browser that
strictly adheres to these guidelines is Opera. (And how many people do you know
who use Opera?)

Internet Explorer, Mozilla Firefox, AOL, Safari, and other Web
browsers all behave differently when using Java, JavaScript, or ActiveX to
process and render HTML. For Web site designers looking to establish a common
denominator for interactive features, Flash proved to be almost universally
compatible because Macromedia itself produced the browser plug-in.

Many Web sites offer visitors the option of using
interactive features that depend on changes to security settings or plug-ins. I
have no issue with these Web sites—because they give me a choice. But I’m never
very impressed with a Web site that requires
me to use a different Web browser, change my security settings, or enable a
browser plug-in.

It’s important to remember that many Web site visitors don’t
have the required plug-ins or have enabled high-security settings, which means
they often end up viewing a blank Web page. In many cases, rather than
attempting to resolve the problem, they simply don’t bother. And I can’t blame
them—I would rather skip viewing a Web site than change my security settings.

I hate to break the news to Web site designers, but fancy
features that require changes to browser security settings are proving to be
quite unpopular with users. In my opinion, Web site designers need to focus on
functionality instead of “flash” and keep design as simple as
possible.

Judging from the number of support calls I’ve received regarding
improperly displaying Web sites, I think it’s safe to say that Web browser
security is currently trumping interactive Web site features. As users become
more aware of security concerns, they’re boosting their security settings and
disabling many of those interactive features in Web browsers in the process.

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