Since the advent of the World Wide Web and the growth of ecommerce, social networking, and Web-based applications, greater connectedness and interaction have characterized the personal-computing user experience, both between users and between users and their far-flung applications and systems. It’s not a very daring prediction to say that the amount of connectedness and interaction will continue to increase, offering users many new varieties of user experiences.
In this column, I’ll explore the user experience of malicious software, or malware. My position is that, like many qualitative attributes, malware is in the eye of the beholder. And, I’ll suggest a method that product or service developers can use to assess the risk that their users, the media, or the market at large might perceive their offerings as malware.
What Is Malware?
The term malware refers to an application that causes either perceived or actual harm to a user’s data, software, or hardware or exposes a user’s data or personal information in ways that the user did not intend or is unaware of.
While this term originally applied to desktop applications, it can also apply to Web sites or Web-based applications. While there is typically less risk that Web sites or Web applications might muck up users’ computer systems, the risk that users’ personal information or data might be shared, exposed, or sold without their consent and understanding is probably higher. Often, the price of using a Web application is providing personal information or allowing data to reside in the cloud.
Why Do We Care About Malware?
Over the past decade, a number of commercial software and hardware manufacturers have suffered considerable negative press—and, in some cases, loss of sales—because the mass media picked up and heavily publicized reports of bad behavior by the manufacturers’ software. Some examples include the following:
Sony BMG, 2005—Sony BMG included copy-protection technology from First4Internet on CDs from selected artists. The copy-protection program used stealth techniques to hide from the operating system and attempted to contact Sony BMG servers via the Internet when users played the protected CDs on a PC. Users reported that attempts to remove the copy-protection software destabilized their PC’s operating system. Some users reported losing access to their computer’s CD-ROM drive after removing the software. Sony BMG recalled all copy-protected CDs and provided those affected by the malware with gift certificates for free—and presumably unprotected—CDs. However, Sony BMG continues to suffer negative press to this day.
Intuit, 2003—Intuit included Macrovision copy-protection software with TurboTax 2002 to prevent casual piracy in the form of pass-along installations. Users complained about having difficulty removing the copy-protection software, as well as excessive use of CPU cycles and operating system crashes resulting from the installation of the Macrovision software. TurboTax buyers also expressed concern about the spyware-like behavior of the Macrovision software. Intuit removed the Macrovision copy-protection software in the next release, after losing some market share to competitors and suffering negative press for months.
Intel, 1999—Intel announced Pentium III processors would include a unique identifier. Several privacy and consumer groups jointly filed a complaint against Intel with the Federal Trade Commission, saying the identifier would allow unscrupulous Web sites to track people’s Web surfing habits across the Internet. Intel dropped the unique identifier in later CPU versions.
Facebook, 2007—A recent Web-based example is the Beacon targeted advertising system from Facebook. Late in 2007, Facebook implemented Beacon, a system designed to combine users’ purchase histories from other Web sites with their Facebook profiles and present the information on Facebook. Almost immediately, the Facebook community erupted in outrage at the perceived invasion of their privacy, as well as at Facebook’s unfortunate decision to require users to opt out of Beacon. As a result of this policy, all Facebook users’ purchase histories were included by default, and users had to take action to exclude themselves from the program. Facebook later backtracked, making changes to Beacon and giving users more control over what information Facebook and third parties share.
Attributes of Malware
Users or the popular press might label a software application as malware for a variety of reasons. Some common reasons for labeling a product as malware include the following:
excessive personal data gathering and usage such as
gathering and transmitting information about a user or a user’s data within a company or to a third party
exposing more of a user’s personal information to his or her contacts or the application’s community than the user expected
damaging, degrading, or negatively affecting a user’s computing device or computing environment, including
modifying or damaging a user’s application or operating system settings
hiding an application’s own files or another application’s files or rendering them inaccessible
failing to restore modifications to other applications, application settings, or the operating system once the user has removed or uninstalled the application
resisting a user’s attempts to remove an application.
overusing resources such as a device’s CPU (Central Processing Unit), network bandwidth, memory, and so on
failing to adequately notify a user of third-party relationships in which the third party makes use of the user’s personal data
We should not automatically label an application as malware if it exhibits the behaviors I’ve described. Chance and other random forces always play a role in how market perceptions of a product develop over time. For example, technically skilled individuals might discover hidden or non-obvious capabilities of an application that the application designers never intended them to use—or possibly did not even know they had introduced. These latent capabilities could be quite powerful and subject to exploitation by third parties. Should the application then be considered malware? Again, it’s about perceptions. There is no hard-and-fast rule that we can decisively apply.
Finally, it’s important to point out that, according to my perception-centric definition of malware, there is no difference between an intentional, by-design capture of personal data and an accidental data exposure, or data spill. If users perceive the latter case as malware, well, then it is, despite the difference in intention. Malware is as malware does.
Whose Data Is It Anyway?
Who owns your personal data? Before tackling this issue, let’s first think about what we mean when we use the phrase your data. What are we even talking about?
Pretend you’re Pat Milford. You’re 34 years old, 5 foot 7, and weigh 136 pounds. You live in the house you bought about five years ago after finishing graduate school, on 58 Blue Jay Way, in the town of Springfield. You work for the state university system, in the IT department. You drive a 4-door 2003 Honda Accord. You’ve broken two bones in your life—your right wrist and left clavicle—and have four fillings in your mouth. You have no serious medical issues, although you were briefly hospitalized seven years ago after a minor car accident. You’re into 80s movies, 90s rock, and spend a lot of time on eBay looking for pop-culture collectibles, ranging from original Beanie Babies to lunch boxes emblazoned with cartoon characters from the 70s.
At first blush, much of this information would seem to constitute elemental and very personal information about you. Your instinct is to consider that information private. However, some of the information you consider private—your house purchase and your job information—is actually available from government records, which, increasingly, are available online.
Other items of personal data you may consider less important and worry less about whether others have access to it. But, as with any complex system—and the constellation of personal data every one of us generates is extremely complex—it’s not the piece parts that are so interesting, it’s the way the data points interact with each other and the behaviors they predict that are supremely interesting to marketers. To marketers, Pat Milford and the rest of us constitute an enormous data mine that is ripe for exploration.
So, back to the question of who owns your personal data. Unfortunately, there is no easy answer. Many reasonable people and organizations disagree on this question. For example, the European Union (EU) has taken the position that your information belongs to you and companies must, by default, ask your permission to use it. Contrast this with the United States, where the marketplace assumes personal information does not to belong to the person to whom it pertains.
People’s national cultures influence their opinions about the behavior of applications and Web sites. In countries such as the United States, there is probably more tolerance for certain aspects of malware-like behavior, simply because people see it as normal. In the EU, however, Germans or Belgians may be much more sensitive to perceived invasions of privacy and malicious behavior by an application and have negative perceptions of the company that produces it. These differences in attitudes toward privacy and data ownership across nations translate to differing levels of risk for application and Web site developers. But what are the risks?
Risks for Application and Web Site Developers
Of course, the biggest risks to product developers are financial and legal. Once the public tags an application or Web site as malware, the organization that produced it is at risk of revenue loss and litigation. To recover from major accusations of malware that garner media attention, organizations must expend considerable time and resources to adequately address customers’ concerns and attempt to repair their damaged reputations. Sometimes organizations never fully recover from such episodes.
And there are often significant amounts of collateral damage from an organization’s damaged reputation. It was Sony’s music and entertainment division that decided to include copy protection on music CDs. Sony’s consumer electronics division had nothing to do with this decision. Yet all of Sony was tarred with the same brush, not just Sony BMG. Is that unfair? Probably, yes. But it’s probably also unavoidable.
So, at this point, I hope I’ve established a few points:
Malware is in the eye of the beholder.
Once the public perceives an organization’s product offering as malware, it’s hard to change users’ perceptions.
Therefore, organizations should be highly motivated to assess any risk that people will regard their offerings as malware, so they can take steps to minimize or eliminate the risk.
One Way to Manage Risk: Assessment for Prevention
One good way to prevent the public from tagging your product as malware is to assess—ideally before going to market—the degree to which your product has the potential for people to perceive it as malware.
To facilitate this assessment, I suggest the UX community might provide a tool that organizations could use to assess the risk of the public’s slapping the malware tag on their products. While we cannot guarantee that we can accurately determine whether the public will perceive a product as malicious, learning about the public’s likely perceptions of your product by assessing it against a specific set of criteria at least lets an organization make informed product decisions.
To measure the probability of people perceiving a product as malware, I have created an assessment checklist, shown in Table 1, comprising a set of attributes that typically characterize malware. I have grouped these attributes into the following five categories, each containing two or more representative attributes:
personal information gathering and usage
modification of data or system configuration
stealth and resistance to removal or modification
transparency and disclosure of third-party relationships
Table 1—Checklist for assessing the risk of a product’s being perceived as malware
Statement of Malware Product Attribute
Personal Information Gathering and Usage
The product or Web site…
Gathers and transmits users’ personal data or information about users’ behavior to the organization providing the product
Gathers and transmits users’ personal data or information about users’ behavior to a third party.
Uses personal data and data the product developer obtained from third parties to assemble profiles of users that are more complete and comprehensive than users expect.
Exposes more of users’ personal information to their contacts or a community than users expected or wanted.
Does any of the above without user notification and consent.
Does any of the above and does not allow users to opt out.
Modification of Data or System Configuration
The product or Web site…
Overwrites, modifies, or destroys users’ data without their knowledge or consent.
Modifies other applications on users’ computers or their operating system settings or computing environment.
Fails to restore modifications to other applications, operating system settings, or the computing environment when the user uninstalls the product.
Damages or renders inoperative other software or hardware on users’ computing systems.
Stealth and Resistance to Removal or Modification
Hides or renders its files and resources inaccessible to the user through normal means—that is, using standard file managers and viewers.
Resists attempts at removal.
Modifies antivirus, antispyware, and other computing hygiene applications or application settings, to make itself appear harmless or less harmful than it actually is.
The product or Web site…
Overuses computing resources—CPU, GPU, memory, and so on—to a noticeable extent.
Utilizes computing resources for purposes not directly related to the tasks users typically perform with the software.
Transparency and Disclosure of Third-Party Relationships
The product or Web site…
Installs third-party applications that demonstrate any of the above behaviors.
Installs third-party applications without user notification and consent.
This checklist is not yet sufficiently well developed to allow the assignment of statistically valid or reliable scores to a product. For now, I advocate using an estimation approach. Simply put, when completing the checklist, if there are many Yes responses, it stands to reason that the product is at a higher risk of the public’s perceiving it as malware.
The promise of greater connectedness and opportunities for interaction with disparate applications and people on the Web also contains the threat of our encountering products that exhibit, if not malicious intent, behavior that appears not to be in the best interests of users. Whether users, in fact, perceive that a product is behaving maliciously depends on many factors. Some products that we could legitimately tag as malware often chug along in the market for years, without anyone noticing or calling attention to their malicious behavior. Other products—through some combination of salience, word of mouth, and the luck of the draw—get called out as malware almost as soon as they come to market.
Hopefully, in this article, I’ve established the importance of assessing the risk that your product or service could become the next malware poster child.
The assessment tool I’ve described, while still in the early stages of its development, could prove useful to product developers as they work to provide compelling, rich offerings that provide a convenient and personalized user experience, without their getting tagged as invaders of people’s privacy.
ShermanUX provides a range of services, including research, design, evaluation, UX strategy, training, and rapid contextual innovation. Paul has worked in the field of usability and user-centered design for the past 13 years. He was most recently Senior Director of User-Centered Design at Sage Software in Atlanta, Georgia, where he led efforts to redesign the user interface and improve the overall customer experience of Peachtree Accounting and several other business management applications. While at Sage, Paul designed and implemented a customer-centric contextual innovation program that sought to identify new product and service opportunities by observing small businesses in the wild. Paul also led his team’s effort to modernize and bring consistency to Sage North America product user interfaces on both the desktop and the Web. In the 1990s, Paul was a Member of Technical Staff at Lucent Technologies in New Jersey, where he led the development of cross-product user interface standards for telecommunications management applications. As a consultant, Paul has conducted usability testing and user interface design for banking, accounting, and tax preparation applications, Web applications for financial planning and portfolio management, and ecommerce Web sites. In 1997, Paul received his PhD from the University of Texas at Austin. His research focused on how pilots’ use of computers and automated systems on the flight deck affects their individual and team performance. Paul is Past President of the Usability Professionals’ Association, was the founding President of the UPA Dallas/Fort Worth chapter, and currently serves on the UPA Board of Directors and Executive Committee. Paul was Editor and contributed several chapters for the book Usability Success Stories: How Organizations Improve by Making Easier-to-Use Software and Web Sites, which Gower published in October 2006. He has presented at conferences in North America, Asia, Europe, and South America. Read More