Making The Case Against Adding DRM To JPEG Images
from the don't-go-down-that-road dept
Earlier this year, we wrote about a plan to add DRM to the JPEG standard, meaning that all sorts of images might start to get locked down. For an internet where a large percentage of images are JPEGs, that presents a potentially serious problem. We did note that the JPEG Committee at least seemed somewhat aware of how this could be problematic -- and actually tried to position the addition of DRM as a way to protect against government surveillance. However, there are much better approaches if that's the real purpose.The JPEG Committee recently met in Brussels to discuss this, and thankfully Jeremy Malcolm from the EFF was able to give a presentation explaining why this was such a bad idea and to suggest alternative approaches for protecting privacy without having to go down the path of DRM.
Hopefully the JPEG Committee listens.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 to 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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: drm, jpeg, privacy, surveillance
Companies: eff
Reader Comments
Subscribe: RSS
View by: Time | Thread
Here we go again...
An expensive, complicated and ineffective step that will only inconvenience the 'honest' users and will be cracked in no time...
No really sure why anyone would think it will work on images when it has failed on all other media it was applied to: games, music, books, movies...
[ link to this | view in chronology ]
Call me cynical to believe those who wish to utilize the "encryption" of the image will be giving the keys to unlock the image freely.
This means websites wishing to use the image much first obtain the key.
The very reason HTTPS works is because the digital key necessary to view the site has no restrictions on obtaining the key.
Not seeing how this same system will be applied to JPEGs (already covered by HTTPS if used) while pretending it's not DRM.
[ link to this | view in chronology ]
Re:
With an encrypted, non DRM'd file, you do not have that kind of issues.
[ link to this | view in chronology ]
Re:
Yes and no. If you read carefully, the encryption suggestion is talking about the metadata and not the file as a whole. So, you should be able to access the image part of the data, but require a key to decrypt the metadata. Since, as mentioned, many uses of jpegs strip out the metadata anyway, and it should be less problematic than you think.
There may be some unforeseen issues introduced depending on how this is implemented, but the files should in theory be usable even in the encrypted form.
[ link to this | view in chronology ]
Re: Re:
I'm not sure how much I can make myself care about a form of DRM that means I can't interpret the metadata of images that I download from the internet... but that can't be what they mean, otherwise stripping the metadata involves taking the unencrypted image data, and saving it into a new image with neither DRM nor metadata.
[ link to this | view in chronology ]
JPEG Will Never Suceed Without DRM
So let these smart-aleck photographic "experts" (makes air quotes) WAKE UP AND SMELL TEH COFFEE!! Otherwise THERE CLEVER FORMAT PORPOSAL WILL BE LEFT IN TEH DUST BY TEH MARKET!
[ link to this | view in chronology ]
Re: JPEG Will Never Suceed Without DRM
[ link to this | view in chronology ]
It will be cracked in days & requires 'always on' connectivity
[ link to this | view in chronology ]
Yet another reason to standardize on PNG
[ link to this | view in chronology ]
Re: Yet another reason to standardize on PNG
[ link to this | view in chronology ]
Re: Yet another reason to standardize on PNG
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
Oh yes, standardise .png, by all means. Result: prettier, clearer, sharper graphics.
If Twitter can do it FB has no excuse.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Never gonna work
Serial - Fail
Serial with online verification - Fail
Online only - Fail
Sandboxes - Fail
Sever side data required - Fail
Encrypted Virtualization - Fail
Just because DRM technology is improving doesn't mean hackers are not. Hackers will always be ahead of the game because there are more of them. Some have malicious intent, and others see DRM as a challenge; meaning the harder the better.
What cannot be cracked will be replaced with custom code. IE private video game servers are almost always coded from scratch. Then a custom patch will set the game to use different server IP addresses.
With and video the best that we'll ever do is advanced recognition software. Then the problem will be getting everyone to use it on their servers.
Most will not, I know I wouldn't. It's not my problem or job to babysit.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
I thought this was a joke.
This would be the easiest thing to bypass ever.
A script embedded somewhere like imgur, which relies on how easy jpegs and pngs are to share, could render it completely worthless.
Hey guys, remember when they tried drm in pdf? That was the most secure thing ever, right guys? No one ever got past that.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
DRM bad, but digitally signed metadata is good
Anyone viewing the image would then be able to verify, with the same level of trustworthiness as SSL certificates have, that the metadata within the image is really from who it claims to be from.
An example: When a US Senator posts pictures of his microsoft and digitally signs the bragging rights, we could all be pretty sure it was actually him doing the bragging.
Now imagine that Certificate Authorities could issue digital signing certificates to individual cameras and the cameras do the signing. Have some cryptographically secure way to distribute the certificate into the camera without any human ever seeing or having access to it. The key would be kept in a smart chip running Java like the sim card on your phone. The processor, memory and signing key are in a secure chip that is tamper resistant.
The result of this is that you could be sure that a SPECIFIC CAMERA took the picture. That way, a journalist could have each of his 500 cameras have a different uniquely identifiable certificate so that each picture can be identified with the camera that took the image and signed it.
The potential security issues are:
* someone steals the camera and takes photos -- but the journalist can also record when the camera was stolen or missing. Certs can be revoked.
* for a dedicated attacker it might be possible to recover the secret key material from the sim card so that it now is available to humans in a form that can be used to sign anything
[ link to this | view in chronology ]
Re: DRM bad, but digitally signed metadata is good
On the other hand, if it is possible to strip out metadata, then wouldn't it be possible to add bogus metadata easily?
I am having a hard time discerning what might be accomplished with any of this, except as someone mentioned above, showing that there IS a JPEG committee, and that they are doing...something...trying to stay relevant.
[ link to this | view in chronology ]
Re: Re: DRM bad, but digitally signed metadata is good
This problem has been solved for years. Relying on text in a separate node of the container file is silly.
[ link to this | view in chronology ]
Just another barrier to entry
The markets include, but aren't really limited to: image viewers, document production, photo manipulation, CGI, and web browsers. The only four ways that such DRM can actually perform its task are:
1. Code kept secret in any program that decodes the image.
2. An effectively secret "standard" that costs lots of money to use, and requires strict NDAs.
3. DRM in the operating system itself, which must then be the code that's kept secret.
4. DRM in the hardware, which must then be the code that's kept secret.
All four of these means to the end will limit the number of entries into any of the markets I mentioned above. We will all suffer from this DRM. It looks to me like 3 of the 4 methods would require quite a bit more in terms of legal support, stricter "intellectual property" laws, stricter laws against reverse engineering or reverse engineering tools, or some combination of the above.
Unfortuntely, all of this can come to pass. Parts of the US government clearly have some perverted fetish about listening to and saving all electronic communication. Having the "IP" and other laws in place make it much easier to mandate pseudo-encryption with backdoors, because everything must be checked to see if the DRM on an image is being violated or not. If those perverted agencies can see this, they would probably throw their weight behind such a proposal. Other agencies might see the DRM on images as a way to assign blame for leaks, or keep classified material from journalists, even if they're not directly involved in the fetishistic surveillance of the entire population.
[ link to this | view in chronology ]
lol
SHIT, this image has DRM and I can't view it on my computer.
Me:
What metadata? I used screen shot
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
.jpg, .jpeg, .jpe
[ link to this | view in chronology ]
Re:
The fact that the OS I am thinking of even required extensions in order to identify what was in a file was another example of how far behind the times it was. Even back then.
[ link to this | view in chronology ]
Re: Re:
No wait, unix required you to just know what program to use to open a particular file.
[ link to this | view in chronology ]
Every once in a while, a company will ask really nicely for an original or a set, usually of their product, and I almost always give it to them.
So, I'm not sure what DRM would give me as a photographer. I want people to see my work. I want my photos to be spread far and wide. My only fear is that someone else takes credit for my work, but the watermarks fix that.
As far as control, from a technological standpoint, the only control I have is whether to put my photos are in the wild or not. Once they go into the wild, my only control is artificial: threats, lawsuits, whatever reactive bullshit people do.
As far as my work going into the wild without my consent, I do the best I can. It's probably a hundred thousand photos and they are all stored on an encrypted drive. If someone swipes the drive, they'll just get a brick. If hackers or a three letter agency swipe my drive, then oh well, I did my best to secure it if they crack it.
The watermark tool I built (and also sell) will also set the metadata on formats like JPEG, but I've never looked to see if anyone is stripping it off my photos in the wild. I think (?) Google even uses this metadata to help decide your search ranking.
Any way I look at it, as a photographer, the only end result of DRM would be everyone seeing me as a douche-bag and staying away from my work, which is the polar opposite of what I want.
[ link to this | view in chronology ]
Is nothing sacred?!
[ link to this | view in chronology ]