Evaluating Web Browser Security Interfaces for a More Meaningful Design

Introduction

Problem Context

Web browser security and privacy messages are generated based on policies established by developers to protect user data These messages are triggered whenever users input information into form fields and submit it, warning them that they may be sending personal data unencrypted over the Internet When users send sensitive information through a secure method, they receive a different warning indicating that their data is being transmitted securely and cannot be intercepted Despite the similar appearance of these messages, they convey important distinctions regarding data security Additionally, users encounter security notifications when accessing and leaving secure websites, highlighting the transition between secure and unencrypted environments The repetitive nature of these alerts can lead to user annoyance and frustration, as they struggle to differentiate between the messages while navigating the web.

Pop-up messages typically share a uniform appearance, featuring a small colored box with buttons and text that outlines a general scenario related to the policy that triggered the warning This common format leads users to confuse one pop-up for another, resulting in a tendency to ignore them altogether Many users habitually click “Continue” or “Cancel” without reading the content, and often disable future warnings by unchecking options like “show next time.” This action leaves users unaware of which security policies are being disabled, potentially leading to a scenario where all security alerts are turned off, exposing them to risks during non-secure transactions An experiment indicated that over 70% of participants incorrectly clicked “Continue” on messages that warranted a “Cancel” response, highlighting the dangers of such automatic behavior in critical security situations.

Figure 1 - A standard security message from Netscape Navigator

Web browser security functionality presents significant challenges, as it relies on users to understand the available security features Default settings are often insufficient for comprehensive protection while browsing the internet Furthermore, users are typically not motivated to explore and adjust these security settings to enhance their safety In the case of Netscape's Navigator, modifying these settings is essential for improved security.

Web browsers like Netscape and Microsoft Internet Explorer feature complex security settings that users often overlook These settings require an understanding of terms such as "signed" controls, cookies, and scripting, along with choosing between various security levels Unfortunately, many users lack the knowledge of web security fundamentals and tend to ignore important security messages This ignorance poses significant risks during online transactions, as users may inadvertently disclose personal information to unauthorized entities, engage in insecure actions, or become victims of malware attacks.

Project Description and Impact

As web browsers advance, there is potential for more precise security and privacy policies; however, if users disregard these warnings, improvements will be futile To tackle this issue, I developed a project focused on enhancing user behavior through experimental designs that effectively combine meaningful descriptions of security risks with distinctive visual elements Each of the unique security messages I created conveyed the same warning but varied in appearance, ensuring users quickly grasp the web page's intent and recognize that clicking "Continue" is inadvisable The goal is to foster an awareness of the online environment, encouraging users to act safely and responsibly An example of this approach is illustrated in Figure 2, showcasing a security message with a clear warning and an altered design.

Figure 2 - An example of an unusual security warning

Despite my experiments indicating that users are more attentive to security messages that deviate from standard formats, altered messages still fail to effectively capture attention in critical situations For instance, a message warning about a web page component attempting to steal passwords should prompt automatic browser intervention However, when I presented this message in various formats, some users continued to click "Continue," possibly due to habit, skepticism about the message's authenticity, or other factors This highlights the need for further research to explore effective user notification methods or to consider new strategies for enhancing user awareness of security threats.

Report Overview

Chapter 2 of this technical report describes the problems in current web browser security design as well as previous research in the field of user interfaces in security applications

Chapter 3 begins an explanation of the experimentation done during this project and presents preliminary results that guided the completion of the project Chapter 4 provides details on an experiment done for this thesis project as well as a discussion of the results and their meaning Chapter 5 presents the significance of the data collected during experimentation and recommends future work in the area of security interfaces.

Background Information

The Problems

The World Wide Web hosts millions of diverse web pages, creating countless opportunities for compromising personal information To combat this, web browsers implement warning systems through pop-up messages to alert users of potential security or privacy breaches Unfortunately, these alerts can often be unclear and confusing, limiting their effectiveness in protecting users.

Web browser developers implement a set of security and privacy policies that flag web pages with forms as potentially hazardous, primarily due to the risk of consumers submitting sensitive information like credit card numbers However, this broad approach can frustrate users, as not all forms request personal data Over time, users tend to ignore or disable these warning messages, diminishing their effectiveness Despite extensive research in user interface design, challenges remain in applying established design principles to security applications.

Effective user interface design prioritizes quick and efficient task completion, making pop-up messages counterproductive to these principles Users generally dislike interruptions, as they hinder focus and slow down progress Therefore, it is essential to minimize pop-up messages and other distractions However, interruptions are warranted when significant issues arise, particularly concerning web browser security and privacy, which necessitate immediate attention whenever a relevant concern is detected.

Determining when such an issue develops also impacts when a message appears.

Web Component Difficulties

Web browser developers implement security policies to assess the safety of web page content, particularly in relation to unauthorized access to user information However, the effectiveness of this detection is challenged by the diverse techniques used in web page creation and the various components included While elements like cookies, Java applets, JavaScript, and ActiveX Controls were designed to enhance web functionality, they also pose potential risks to user security and privacy.

Cookies are tools that track user activity on websites, enabling automated tasks like storing usernames and passwords on a user's device Frequently utilized by online advertising agencies, they monitor user navigation patterns However, since cookies are automatically transmitted through web browsers, they can infringe on user privacy by collecting personal and sensitive information without consent.

A Java applet is a small program written in the Java programming language, developed by Sun Microsystems, Inc When a user accesses a web page with a Java applet and has the Java Virtual Machine installed, the applet downloads and executes on their machine While web authors can program Java applets to perform various functions, Java's security model aims to limit applet access to the user's system Past exploits have shown that if security measures are bypassed, an applet could potentially access sensitive areas of a computer Notably, in 1996, researchers found that a Java applet could delete files on a user's hard drive without their knowledge In response to such vulnerabilities, Java's security protocols have since been enhanced to restrict applet operations, including reading and writing files and making network connections without user consent.

JavaScript is a client-side programming language that web browsers interpret without needing to download a full program It enables interactive responses to user actions, such as mouse clicks and form inputs However, like Java applets, JavaScript has been exploited to access users' information, with one notable incident involving a malicious script embedded in a Hotmail email link This exploit could redirect users to a counterfeit Hotmail login page, prompting them to enter their credentials and potentially stealing their passwords Typically, affected websites address these JavaScript vulnerabilities promptly rather than implementing a widespread update.

ActiveX controls, developed by Microsoft, are Windows programs that can be embedded in web pages and require a signed certificate from a trusted source to ensure safety While they are similar to Java applets, malicious users have circumvented these security measures Some ActiveX controls can execute low-level commands on Windows computers, leading to potential misuse, such as an instance where an ActiveX control was found to randomly reboot computers.

Protecting against all types of vulnerabilities is nearly impossible, as existing security policies often provide generic alerts about web components and their potential risks Not every form collects personal or private data, and not all Java applets or ActiveX components are harmful Consequently, while these policies aim to safeguard users, they can become overly intrusive and frustrating.

Stronger, more stringent security policies may help but are of no use if no one pays attention.

Making Users Pay Attention

Research on web browser warning message design is limited, but there is a growing interest in the design of security applications The Association of Computer Machinery’s Special Interest Group for Human-Computer Interactions (ACM/SIGCHI) focuses on enhancing interactions between users and computers, with a key objective of developing user interfaces that improve the ease of these interactions While user interface design for security products differs from that of other market segments, emerging research is beginning to address this critical area.

Developing user interfaces for security applications is challenging due to the necessity for developers to grasp essential security principles and the correct usage of the application; otherwise, users may fail to fully benefit from the software's protections Alma Whitten, a Ph.D student at Carnegie Mellon University, has compiled an online bibliography of research focused on human factors in security, similar to SIGCHI, aiming to enhance the usability of security applications Her assessment of a prominent security product revealed that even with a well-designed user interface, users struggled to effectively use the product without investing significant time in understanding the software.

To effectively understand user preferences for security software, practical methods such as user observation and feedback analysis are essential However, these approaches require users to grasp the functionality and reactions of the security software in various scenarios Unfortunately, most users lack a deep understanding of their web browser's security features and often only become aware of these issues when they experience security breaches themselves Consequently, there is an ongoing challenge in effectively alerting users to security vulnerabilities in a way that resonates with them.

Designing effective warning messages poses a significant challenge, as they must not only capture user attention but also maintain it Enhancing web browser security policies could alleviate this issue by ensuring messages appear only when there's a substantial risk, accompanied by clearer explanations of the situation However, given that users often overlook security and privacy warnings, it is crucial to develop strategies that effectively draw attention during critical moments to counteract initial design flaws in browsers Establishing an effective display method is essential before advancing to stronger security and privacy policies, which was the primary focus of my thesis project.

Measuring User Behavior

User Responses to Standard Messages

To investigate user behavior in response to security warnings, I conducted an experiment that monitored actions taken by participants when faced with a standard style security alert Collaborating with my technical advisor, David Evans, and professors Jane Prey and Peter Miller from the Computer Science Department, I assembled a test group of students enrolled in the introductory computer course, CS 110, which Prey and Miller taught during the semester of the experiment The study was designed to appear as a homework assignment to the participants.

The students received a “Web Treasure Hunt” assignment that required using information retrieved via search engines like Google (http://www.google.com) or AltaVista

The hunt list included approximately 30 items, each requiring students to utilize the Web to find specific answers One example of an item was to search for particular information online.

To locate the homepage of your U.S Congressman, visit official government websites An example of a personal inquiry included in the assignment was about the city where 'danakate' stayed during the summer of 2000, linked to my website (http://www.danakate.com) Since the task was unrelated to security topics, students were not anticipating any security messages.

The main web page featured a link titled "danakate's summer 2000," along with a JavaScript-generated security message designed to appear standard When students accessed the page, a pop-up message prompted them to either click "Continue" or not Choosing "Continue" redirected them to "pictures.html," while opting out sent them to "piictures.html," with the slight variation in page names allowing for effective analysis of their choices Figure 3 illustrates the security message displayed on the web page.

A contains a source code listing of the HTML and JavaScript used in this experiment

Figure 3 - Standard security warning message used in experiment one.

Results and Conclusions

The student's selection was documented in the access logs of the Apache 1.3.9 web server, which operates on the FreeBSD 4.1-RELEASE Unix system System administrator Yossarian Holmberg configured the logging system to save all web server activities into a text file located in my root directory, allowing for convenient data analysis at any time.

By analyzing the log files, using a search and extraction script I created using the Perl programming language, I determined that users usually ignore security warnings

Before discussing the results, it is important to clarify the analysis process Students completed the web hunt independently, making it challenging to identify their access points Log file analysis revealed repeated access from University network addresses, likely from a public lab used by different students Additionally, some participants lived off-campus and utilized non-University Internet connections While it was difficult to ascertain which accesses were from students engaged in the hunt, I opted to include addresses from recognized local service providers in the analysis.

In a study involving 81 students, 75 chose to click "Continue" on a misleading security dialog box, while 6 opted for "Cancel" during their initial encounter Notably, some students revisited the page multiple times, displaying inconsistent responses with each interaction.

“Other Behavior” represents students who clicked “Continue” first and then “Continue” or

“Cancel” in a seemingly random order Table 1 shows the types of behavior and number of students that exhibited that behavior Appendix A contains the script I used to analyze the entries

Table 1 - Types of Behavior and Number of Students Showing each Behavior

The findings indicate significant insights into user behavior, particularly among students who frequently clicked "Continue" in response to security messages, suggesting they likely ignored the warnings More concerning is the behavior of those who initially clicked "Cancel" but later switched to "Continue" or displayed "Other Behavior," raising doubts about their understanding of secure actions This inconsistency implies a general lack of attention to pop-up messages and the implications of their choices, highlighting a broader issue of user awareness regarding security prompts.

“Cancel” after they originally clicked on “Continue,” those results show people may notice the messages after repeated exposure and realize they should click “Cancel.”

The primary objective is to capture users' attention when they first encounter a potential security threat Initial experiments validated the assumption that users often overlook security messages, while also offering a framework for further investigation The subsequent phase involves redesigning security messages to assess their impact on users' web browsing behavior.

Evaluating New Designs

More Use of Unusual Messages

To conduct a global experiment, I required a high-traffic website, and the Oracle of Bacon pages were ideal, attracting over 10,000 daily visits worldwide To manage the volume of data and minimize potential security complaints, Evans, the director of the CS web team, recommended using a less popular page linked from the Oracle of Bacon, which received only a few hundred hits.

For a 24-hour period, we implemented an unusual security message on the “Star Links” page of the Oracle of Bacon, changing it daily for four consecutive days A network connection issue at the University caused an eight-hour disruption on the third day, prompting an extension of that day's message evaluation period After completing the experiment, I analyzed the access logs with a Perl script I developed.

First Three Messages and Results

In developing security messages, I initially adopted a design closely resembling standard messages, gradually diverging from this format throughout the experiment To isolate the effects of the design, I retained the original text used in previous experiments, ensuring that any user reactions were solely based on the message's format The first three messages maintained similar functionality and are detailed in this article For those interested, all JavaScript, HTML, and analytical files related to these messages can be found in Appendix C.

On the first day, I implemented a deceptive security message featuring an animated element, where the lock, key, and exclamation point images blinked every half-second to capture user attention Figure 4 illustrates the design of the security message, highlighting the animated component.

Figure 4 - Security message for day one of experiment three animated

On the second day of experimentation, a message was displayed in all red text, contrasting with the standard black text typically used for security alerts This choice aimed to enhance visibility and encourage users to read the message in its entirety A screenshot illustrating this red text message can be found in Figure 5.

Figure 5 - Security message for day two of experiment three

On the third day, the pop-up window featured a striking red background, setting it apart from standard security messages in browsers like Netscape and Internet Explorer While this bold design aimed to capture attention, it risked surprising or annoying users, potentially leading them to dismiss the message without reading it Figure 6 illustrates this third pop-up message from the experiment.

Figure 6 - Security message for day three of experiment three

Access logs captured user choices, and after filtering out irrelevant entries and enhancing a Perl script for analysis, I categorized users based on their behavior The user statistics for the initial three days of the experiment are detailed in Table 2.

Table 2 - Statistics for first three days of experiment three

In the first three days, visitor numbers to the Star Links page fluctuated, yet the percentages across categories remained consistent This indicates that most users opted for "Cancel" as their default response, suggesting that they either read security messages or tend to habitually dismiss pop-up alerts.

Users who consistently select "Continue" may overlook pop-up messages, indicating a lack of engagement with the content My initial assumption that a significantly different pop-up message on day three would capture more user attention proved to be inaccurate.

Final Message and Results

The final security message introduced a new element: a text box, alongside the standard security warning Users could dismiss the message in four ways, three of which were trackable The first option was the "Cancel" button, which typically restricts access to the page, but this feature was not applied in my messages The second and third options involved typing "yes" or "no" into the text box and clicking "Done"; any other input would keep the message open The fourth method, closing the message by clicking the "x" in the top right corner, is a standard practice but not trackable Figure 7 illustrates the last security message implemented.

Figure 7 - Security message for day four of experiment three

The final day’s statistics revealed more about user behavior Table 3 shows the statistics of user behavior to the last message

Chose “Yes” then “No” or “Cancel” 0.7%

Chose “No” or “Cancel” then “Yes” 1.3%

Table 3 - Statistics for the last day of experiment three

Note: "No" and "Cancel" were considered the same action

A significant number of users opted for "No" or "Cancel," but this does not necessarily indicate they read the security warning Many users may have been trying to dismiss the message quickly However, further analysis shows that 25.5% of visitors actually typed "no." The format of the security warning likely captured users' attention, prompting them to read it Unfortunately, some users selected "yes," but given the low occurrence of this choice, it may have been a random decision Without the ability to reach those who chose "yes," this assumption remains unverified.

My findings suggest that while it's possible to capture user attention, encouraging active engagement in online activities remains a challenge The security message presented was serious yet somewhat unrealistic, leading to minimal concern among participants; out of over 700, only two reached out to the administrator regarding the perceived vulnerability This lack of response may indicate that most visitors found the messages unconvincing Ultimately, it appears that user awareness is influenced by factors beyond just the content and format of the messages.

Conclusions

Summary

An experiment revealed that typical user behavior often leads individuals to select "Continue" when faced with standard security messages, allowing non-secure content to display This trend persists even among security-conscious users, who frequently click "Continue" without fully reading the messages During my project, Scott Ruffner, a system administrator for the Computer Science Department, participated in testing and consistently chose "Continue" despite being instructed to select "Cancel" in response to a false message.

Further experimentation showed that adjusting the warning format to highlight the severity of security issues led to more users preventing non-secure actions However, my initial hypothesis that significantly deviating from standard security messages would yield greater impact was incorrect In the first three messages, each format strayed further from the norm, yet about one-third of participants still chose "Continue" for all warnings The final message did improve the number of users who blocked non-secure actions, but this was due to making it harder to proceed with the action.

Interpretation

The analysis of experimental data indicates that merely altering the format of security messages is insufficient to effectively alert users to security issues The findings suggest that capturing user interest in critical situations requires security messages in web browsers to adopt a format that may border on being overly intrusive.

In user interface design, minimizing user interruptions is essential, ensuring that any disruptions are brief and non-intrusive However, security warnings are an exception, as they must be more prominent and intrusive due to their critical nature.

The second experiment indicates that users tend to focus on unusual messages, but this attention may not stem from actually reading them Instead, users might be clicking buttons out of habit to quickly dismiss the messages Additionally, some users may have recognized the false nature of the messages and opted to proceed with actions just to see the outcome This behavior poses significant risks if such methods are adopted by web browsers, as many users might inadvertently engage in high-risk actions, believing the security alerts to be false While the experiments effectively captured user behavior, they did not clarify the underlying reasons for that behavior.

Recommendations

This evaluation project reveals that improving user behavior is achievable, but it requires significant research and effort To enhance effectiveness, it is essential to integrate stronger web browser security policies and increased education on security issues with new message designs Conducting interviews with users after they encounter unusual security messages can provide valuable insights into their behavior, offering developers ideas for improved design However, the challenge lies in creating an appropriate experiment that ensures users are unaware that their security-related behaviors are being monitored.

The World Wide Web serves as a highly accessible part of the Internet, highlighting the need for ongoing research and testing in online security to protect user information during transactions Enhancing users' understanding of security issues is crucial, as it not only helps prevent victimization but also encourages users to engage more actively in the online space Informed users contribute to a safer Internet by recognizing the importance of security, raising awareness, and reporting security concerns to the appropriate authorities.

1 Festa, Paul Hotmail Flaw Exposes Passwords 19 Mar 2001

2 Holmstrửm, Ursula User-centered Design of Security Software Human Factors in

Telecommunications Copenhage, Denmark May 1999 18 Oct 2000

3 Oppliger, Rolf Security Technologies for the World Wide Web Boston: Artech House 2000.

4 Raskin, Jef The Humane Interface: New Directions for Designing Interactive Systems Reading: Addison Wesley Longman, Inc 2000.

5 Tiwana, Amrit Web Security Boston: Digital Press 1999.

6 Whitten, Alma, J.D Tygar Usability of Security: A Case Study Technical Report CMU- CS-98-115 Carnegie Mellon University, School of Computer Science December 1998 18 Oct 2000

7 Whitten, Alma, and J D Tygar "Why Johnny Can't Encrypt: A Usability Evaluation of PGP5.0." Proceedings of the 8th USENIX Security Symposium, August 1999 12 Sept 2000 < http://www.cs.cmu.edu/~alma/johnny.pdf>

Association of Computer Machinery ACM/SIGCHI 22 Mar 2001

Electronic Privacy Information Center The EPIC Cookies Page 19 Mar 2001

Festa, Paul Hotmail Flaw Exposes Passwords 19 Mar 2001

This appendix contains key materials related to the experiment detailed in Chapter 3, including the JavaScript for generating pop-up messages and the HTML for the false messages It also includes Perl scripts utilized for log file analysis All relevant files and log files can be accessed online at http://www.danakate.com/thesis.

JavaScript for Pop-up Message

The JavaScript used in the first experiment was designed to display a false security warning positioned in the center of the viewer’s monitor screen This is a listing of the

JavaScript code used to generate the message.

// Store the height and width of the user’s monitor. var maxwidth = screen.width; var maxheight = screen.height;

// Define the height and width of the pop-up message. var p0pupwidth = 300.0; var p0pupheight = 200.0;

To position a pop-up message at the center of the monitor, calculate the new left and top coordinates using the formula: `newleft = (maxwidth / 2.0) - (p0pupwidth / 2.0)` and `newtop = (maxheight / 2.0) - (p0pupheight / 2.0)` Additionally, set the window's screen coordinates with `window.screenX = (screen.width / 2.0) - (window.outerWidth / 2.0)` and `window.screenY = (screen.height / 2.0) - (window.outerHeight / 2.0)`.

// Display the pop-up with “alert.html” as the source. remote = window.open('alert.html','alert','toolbar=no,location=no,directories=no,status

=no,menubar=no,scrollbars=no,resizable=no,width='+p0pupwidth+',height='+p0puph eight+',top='+newtop+',left='+newleft+'')

HTML for Standard Pop-up Message

The HTML for the deceptive pop-up message resembled a typical security alert, differing only in its redirection of users to an alternate webpage based on their selection of "Continue" or "Cancel." Additionally, the message did not provide users with the option to disable the security warning.

This page contains both secure and non-secure items Do you wish to download the non-secure items?

Perl Scripts for Analysis

After the first experiment finished, I had to collect the log files and separate the extraneous information from the relevant information I created two Perl scripts to facilitate my information gathering.

The initial script analyzed all log files produced during the experiment, compiling a master file that documented every user who accessed the web page displaying the erroneous message The Perl code for this script is provided below.

# Open the output file, exit with an error if a problem exists. open(INDEX, ">$filename") || die("$filename: $!");

# Select the output file for writing. select(INDEX);

# Create an array of all text files in the directory.

# Go through each file in the array. foreach $file (@filenames) { if (!open(READFILE, "$filename") || die("$filename: $!");

# Select the output file for writing. select(INDEX);

# Define an input file and open it for reading.

$infile = "full-output.txt"; open(READFILE, "$outfile") || die("$outfile: $!");

# Select the output file as the default file handler. select(WRITEFILE); while ((($host, $action) = get_line()) != 1) { if (!exists($client_states{$host})) {

$client_state = $client_states{$host};

# Change the user’s state accordingly. if ($action eq "continue") {

$new_state = $state_transitions{$client_state}->[0];

$client_states{$host} = $new_state;

# Print the hash table by hostname, then final state. map { print "$_ => $client_states{$_}\n" } keys %client_states;

$client_count = scalar keys %client_states; print "\n\ntotal number of clients: $client_count\n\n";

# Determine the number and percentage of users in each state. foreach $state (values %client_states) { if (!exists($state_count{$state})) {

} foreach $state (keys %state_count) { print "$state_count{$state} clients in $state state - (",

($state_count{$state} / $client_count) * 100, " %)\n";

The data collected on the final day of testing differed significantly from previous days, necessitating a new analysis script Key changes included an increase in the number of states to monitor and additional testing options Despite these modifications, the script operated similarly to those used in the initial three days of testing Below is the script utilized for analyzing the last day of experimentation.

# Create a state transition table using a hash table that determines

# what category a user moves to if they choose “yes,” “no,” or “Cancel.”

# The key for the hash table is the user’s current state The value, in

# list format, is the state to which the user changes The first value

# is the state change when the user chooses “yes.” The second value

# is the state change when the user chooses “no.” The third value is

# the state change when the user chooses “Cancel.”

%state_transitions = ( initial => ["yes", "no", "cancel"], cancel => ["cancel_then_yes", "cancel_then_no",

"always_cancel"], always_cancel => ["always_cancel_then_yes", "always_cancel_then_no",

"always_cancel"], yes => ["always_yes", "yes_then_no", "yes_then_cancel"], no => ["no_then_yes", "always_no", "no_then_cancel"], always_yes => ["always_yes", "always_yes_then_no",

"always_yes_then_cancel"], always_no => ["always_no_then_yes", "always_no",

The article outlines various conditional responses, categorized as follows: "always_no_then_cancel," "yes_then_no," "no_then_yes," "always_cancel_then_no," "always_cancel_then_yes," "always_yes_then_no," "always_no_then_yes," "always_yes_then_cancel," "always_no_then_cancel," "cancel_then_yes," "cancel_then_no," "yes_then_cancel," and "no_then_cancel." Each category represents a unique response pattern, with "other" serving as a fallback option for unspecified cases These classifications help in understanding decision-making processes and response sequences.

# Define a sub-function called “get_line,” which takes no parameters.

# This function reads one line of text from the specified file handler

# and, if it exists, determines if the action was “yes,” “no,” or

# “Cancel.” Then, it returns the hostname and the action.

# Note: “Cancel” takes precedence over “yes” or “no” actions. sub get_line {

$one_line = ; if (!$one_line) { return 1;

($hostname) = split(" ", $one_line); if ($one_line =~ m/alert4\=no\&alert4can\cel/i) {

} elsif ($one_line =~ m/alert4\=yes\&alert4can\cel/i) {

# Get the file to open from the command line and open it for reading.

$filename = $ARGV[0]; open(READFILE, "$outfile") || die("$outfile: $!");