EFF has posted a strong critique of the proposed addition of a DRM option to the JPEG format, but it mostly misses the point.
The article addresses the JPEG Privacy & Security Abstract and Executive Summary of September 10, 2015. 
JPEG stands for both the Joint Photographic Experts Group and the eponymous image file format. To minimize confusion, I’ll refer to the group as J.P.E.G. and the format as JPEG, even though the periods are non-standard.
J.P.E.G.’s proposal for JPEG (got that?) would allow for encrypted extensions. An image might be available in a “degraded” base form for public viewing, with an encrypted differential signal that would let only authorized parties view the full-resolution image. A similar technique could be used to encrypt some metadata, to help ensure privacy. The proposals are currently under discussion at the 70th J.P.E.G. meeting in Brussels, Belgium.
EFF’s characterization confuses the issue:
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.
Their presentation to J.P.E.G. does the same. It quotes Bruce Schneier’s statement that “digital files cannot be made uncopyable,” but nothing in the J.P.E.G. proposal suggests any attempt to prevent copying files.
What isn’t clear is how the encryption feature would work in a browser, or whether it’s even intended to. The J.P.E.G. article suggests that you’d view the full image in a separate application that had the authorization key:
As the extension layer is encapsulated in the marker’s carrying boxes, along with all other metadata, the JPEG privacy extension would only need to specify a method to encrypt selected markers or subsets of markers with a suitable cypher, and at the very same time additional metadata of the images could be encrypted all along with the image data. This could be used to secure Exif or IPCT metadata necessary for professional image applications while allowing some private use of the image content.
There are some scenarios to worry about. A website might let only approved browsers display its images properly, and fully open-source browsers would be left in the dust. Other objections are silly: “If your pacemaker’s app uses JPEG icons, it could potentially criminalize vulnerability reporting.” The whole application including its icons might be encrypted to dodge vulnerability reporting, which publishers can do right now (I’ve pointed out a similar issue with embedded car software), but why would they add an encrypted layer to their low-res icons? That’s work with no purpose. The biggest problems with DRM aren’t with the technology but with the law; the DMCA makes it legally dangerous to reverse-engineer encryption and discover security flaws. That’s not an argument for or against encryption.
EFF says, “For encryption of plain text metadata only, this can be done without locking the whole image,” but the J.P.E.G. proposal allows for exactly that. Look at the quote above again: “the JPEG privacy extension would only need to specify a method to encrypt selected markers or subsets of markers with a suitable cypher, and at the very same time additional metadata of the images could be encrypted all along with the image data.” This is the antithesis of all-or-nothing encryption.
Anything that would make parts of JPEG files available just to some software and potentially break compatibility requires scrutiny, and existing DRM laws are a disaster, but EFF has basically misread the proposal.
Like this:
Like Loading...
Related
Mad File Format Science 
Adding DRM to JPEG?
EFF has posted a strong critique of the proposed addition of a DRM option to the JPEG format, but it mostly misses the point.
The article addresses the JPEG Privacy & Security Abstract and Executive Summary of September 10, 2015.
JPEG stands for both the Joint Photographic Experts Group and the eponymous image file format. To minimize confusion, I’ll refer to the group as J.P.E.G. and the format as JPEG, even though the periods are non-standard.
J.P.E.G.’s proposal for JPEG (got that?) would allow for encrypted extensions. An image might be available in a “degraded” base form for public viewing, with an encrypted differential signal that would let only authorized parties view the full-resolution image. A similar technique could be used to encrypt some metadata, to help ensure privacy. The proposals are currently under discussion at the 70th J.P.E.G. meeting in Brussels, Belgium.
EFF’s characterization confuses the issue:
Their presentation to J.P.E.G. does the same. It quotes Bruce Schneier’s statement that “digital files cannot be made uncopyable,” but nothing in the J.P.E.G. proposal suggests any attempt to prevent copying files.
What isn’t clear is how the encryption feature would work in a browser, or whether it’s even intended to. The J.P.E.G. article suggests that you’d view the full image in a separate application that had the authorization key:
There are some scenarios to worry about. A website might let only approved browsers display its images properly, and fully open-source browsers would be left in the dust. Other objections are silly: “If your pacemaker’s app uses JPEG icons, it could potentially criminalize vulnerability reporting.” The whole application including its icons might be encrypted to dodge vulnerability reporting, which publishers can do right now (I’ve pointed out a similar issue with embedded car software), but why would they add an encrypted layer to their low-res icons? That’s work with no purpose. The biggest problems with DRM aren’t with the technology but with the law; the DMCA makes it legally dangerous to reverse-engineer encryption and discover security flaws. That’s not an argument for or against encryption.
EFF says, “For encryption of plain text metadata only, this can be done without locking the whole image,” but the J.P.E.G. proposal allows for exactly that. Look at the quote above again: “the JPEG privacy extension would only need to specify a method to encrypt selected markers or subsets of markers with a suitable cypher, and at the very same time additional metadata of the images could be encrypted all along with the image data.” This is the antithesis of all-or-nothing encryption.
Anything that would make parts of JPEG files available just to some software and potentially break compatibility requires scrutiny, and existing DRM laws are a disaster, but EFF has basically misread the proposal.
Share this:
Like this:
Related