Malware: Whether on the Desktop or the Web, It’s a Perception Thing

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
• resource utilization
• 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	Response
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	____Yes	____No
Gathers and transmits users’ personal data or information about users’ behavior to a third party.	____Yes	____No
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.	____Yes	____No
Exposes more of users’ personal information to their contacts or a community than users expected or wanted.	____Yes	____No
Does any of the above without user notification and consent.	____Yes	____No
Does any of the above and does not allow users to opt out.	____Yes	____No
Modification of Data or System Configuration
The product or Web site…
Overwrites, modifies, or destroys users’ data without their knowledge or consent.	____Yes	____No
Modifies other applications on users’ computers or their operating system settings or computing environment.	____Yes	____No
Fails to restore modifications to other applications, operating system settings, or the computing environment when the user uninstalls the product.	____Yes	____No
Damages or renders inoperative other software or hardware on users’ computing systems.	____Yes	____No
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.	____Yes	____No
Resists attempts at removal.	____Yes	____No
Modifies antivirus, antispyware, and other computing hygiene applications or application settings, to make itself appear harmless or less harmful than it actually is.	____Yes	____No
Resource Utilization
The product or Web site…
Overuses computing resources—CPU, GPU, memory, and so on—to a noticeable extent.	____Yes	____No
Utilizes computing resources for purposes not directly related to the tasks users typically perform with the software.	____Yes	____No
Transparency and Disclosure of Third-Party Relationships
The product or Web site…
Installs third-party applications that demonstrate any of the above behaviors.	____Yes	____No
Installs third-party applications without user notification and consent.	____Yes	____No

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.

Conclusion

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.