Business
Why interactive Web site features often conflict with security best practices
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.
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.
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.