February 21, 2018

Misleading Term of the Week: "Rights"

A “right” is a legal entitlement – something that the law says you are allowed to do. But the term is often misused to refer to something else.

Consider, for example, the use of “digital rights management” (often abbreviated as DRM) to describe technologies that restrict the use of creative works. In practice, the “rights” being managed are really just rules that the copyright owner wants to impose; and those rules may bear little relation to the parties’ legal rights. Cloaking these restrictions in the language of “rights” makes them sound more neutral and unchangeable than they really are.

DRM advocates often put forth arguments that go roughly like this:

(1) we have built technology that doesn’t let you do X;

(2) therefore you cannot do X;

(3) therefore you do not have the right to do X;

(4) therefore you should be required to use technology that doesn’t let you do X.

The trickiest part of this argument is getting from (2) to (3). Using the term “digital rights management” in (1) and (2) makes the leap from (2) to (3) seem smaller than it really is.

There is at least one more common misuse of “rights” in the copyright/technology debate. This is in the use of the term “rights holder” to refer to copyright owners (but not to users). When someone says, “Content is shipped from the rights holder to the consumer,” the implication is that the rights of the copyright owner are more important than those of the user. There is no need for this term “rights holder.” “Copyright owner” will do just fine, and it will help us remember that both parties in the transaction have rights that need to be protected.

Misleading Term of the Week: "Standard"

A “standard” is a technical specification that allows systems to work together to make themselves more useful. Most people say, for good reasons, that they are in favor of technical standards. But increasingly, we are seeing the term “standard” misapplied to things that are really regulations in disguise.

True standards strive to make systems more useful, by providing a voluntary set of rules that allow systems to understand each other. For example, a standard called RFC822 describes a standardized way to format email messages. If my email-sending software creates RFC822-compliant messages, and your email-receiving software understands RFC822-compliant messages, then you can read the email messages that I send you. Compliance with such a standard makes our software more functional.

Crucially, standards like RFC822 are voluntary and nonexclusive. Nobody forces any email-software vendor to comply with RFC822, and there is nothing to stop a vendor’s product from complying simultaneously with both RFC822 and other standards.

Lately we have seen the word “standard” misapplied. For example, the Broadcast Protection Discussion Group (BPDG) calls its proposal a “standard,” though it is anything but. Unlike a real standard, BPDG is not voluntary. Unlike a real standard, it contains prohibitions rather than opportunities. Put the BPDG “standard” in front of experienced engineers, and they’ll tell you that it looks like a regulation, not like a standards document. BPDG is trying to make its restrictive regulations more palatable by wrapping them in the mantle of “standards.”

A more subtle misuse of “standard” arises in claims that we need to standardize on DRM technology. As I wrote previously:

In an attempt to sweep [the technical infeasibility of DRM] under the rug, the content industry has framed the issue cleverly as one of standardization. This presupposes that there is a menu of workable technologies, and the only issue is which of them to choose. They want us to ask which technology is best. But we should ask another question: Are any of these technologies workable in the first place? If not, then a standard for copy protection is as premature as a standard for teleportation.

Misleading Term of the Week: "Trusted System"

The term “trusted system” is often used in discussing Digital Rights/Restrictions Management (DRM). Somehow the “trusted” part is supposed to make us feel better about the technology. Yet often the things that make the system “trusted” are precisely the things we should worry about.

The meaning of “trusted” has morphed at least twice over the years.

“Trusted system” was originally used by the U.S. Department of Defense (DoD). To DoD, a “trusted system” was any system whose security you were obliged to rely upon. “Trusted” didn’t say anything about how secure the system was; all it said was that you needed to worry about the system’s level of security. “Trusted” meant that you had placed your trust in the system, whether or not that trust was ill-advised.

Since trusted systems had more need for security, DoD established security criteria that any system would (theoretically) have to meet before being used as a trusted system. Vendors began to label their systems as “trusted” if those systems met the DoD criteria (and sometimes if the vendor hoped they would). So the meaning of “trusted” morphed, from “something you have to rely upon” to “something you are safe to rely upon.”

In the 1990s, “trusted” morphed again. Somebody (perhaps Mark Stefik) realized that they could make DRM sound more palatable by calling it “trusted.” Where “trusted” had previously meant that the system’s owner could rely on the system’s behavior, it now came to mean that somebody else could rely on its behavior. Often it meant that somebody else could force the system to behave contrary to its owner’s wishes.

Today “trusted” seems to mean that somebody has some kind of control over the system. The key questions to ask are who has control, and what kind of control they have. Depending on the answers to those questions, a “trusted” system might be either good or bad.