Skip to main content

There's No DRM in JPEG—Let's Keep It That Way

If you have ever tried scanning or photocopying a banknote, you may have found that your software—such as Adobe Photoshop, or the embedded software in the photocopier—refused to let you do so. That's because your software is secretly looking for security features such as EURion dots in the documents that you scan, and is hard-coded to refuse to let you make a copy if it finds them, even if your copy would have been for a lawful purpose.

Now imagine if you had the same problem with any image that you found online—that your computer wouldn't let you make a copy of Gene Wilder when making a image macro, or would stop you from reposting photos from an online catalog to your Pinterest account, or would prevent an artist from using a digital photograph as the basis for a new artwork. That's essentially what the JPEG Committee is discussing today in Brussels, when considering a proposal to add DRM to the JPEG image format.

The professional version of the JPEG format, JPEG 2000, already has a DRM extension called JPSEC. But usage of JPEG 2000 is limited to highly specialized applications such as medical imaging, broadcast and cinema image workflows, and archival, therefore the availability of DRM in JPEG 2000 hasn't affected the use of images online, where the legacy JPEG format remains dominant. Now, the JPEG Privacy and Security group is considering essentially backporting DRM to legacy JPEG images, which would have a much broader impact on the open Web.

EFF attended the group's meeting in Brussels today to tell JPEG committee members why that would be a bad idea. Our presentation explains why cryptographers don't believe that DRM works, points out how DRM can infringe on the user's legal rights over a copyright work (such as fair use and quotation), and warns how it places security researchers at legal risk as well as making standardization more difficult. It doesn't even help to preserve the value of copyright works, since DRM-protected works and devices are less valued by users.

This doesn't mean that there is no place for cryptography in JPEG images. There are cases where it could be useful to have a system that allows the optional signing and encryption of JPEG metadata. For example, consider the use case of an image which contains personal information about the individual pictured—it might be useful to have that individual digitally sign the identifying metadata, and/or to encrypt it against access by unauthorized users. Applications could also act on this metadata, in the same way that already happens today; for example Facebook limits access to your Friends-only photos to those who you have marked as your friends.

Currently some social media sites, including Facebook and Twitter, automatically strip off image metadata in an attempt to preserve user privacy. However in doing so they also strip off information about authorship and licensing. Indeed, this is one of the factors that has created pressure for a DRM system that could prevent image metadata from being removed. A better solution, not requiring any changes to the JPEG image format, would be if platforms were to give users more control over how much of their metadata is revealed when they upload an image, rather than always stripping it all out.

We encourage the JPEG committee to continue work on an open standards based Public Key Infrastructure (PKI) architecture for JPEG images that could meet some of the legitimate use cases for improved privacy and security, in an open, backwards-compatible way. However, we warn against any attempt to use the file format itself to enforce the privacy or security restrictions that its metadata describes, by locking up the image or limiting the operations that can be performed on it.

Related Issues

JavaScript license information