Couldn't we just keep using JPEG without enabling any DRM features? Is there an actual practical issue with JPEG that theoretically supports DRM, or is this more of a stand on principles?

It's mostly a stand on principles. I don't have any reason to believe that there's anything wrong with JPEG in it's current form. I commend the EFF for representing the internet at large but I want to remind the hacker community that we can do something about it if we don't like the outcome.

> I commend the EFF for representing the internet at large but I want to remind the hacker community that we can do something about it if we don't like the outcome.

Some will call it undemocratic and thus bad, but I say it sometimes is the only way to restore sanity.

To quote one of my favourite lines of Nick Fury, "I recognize that the Council has made a decision, but given that it's a stupid ass decision, I have elected to ignore it."

[0] - http://youtube.com/watch?v=mOEr7kiysrE

We could maybe create a DRM blocker plugin for JPEG files with this property, just as the way people are using AdBlocker. But the difference with AdBlocker is that we accept format that conform to our standard.

How does switching formats affect the will of content providers to stuff DRM in your pictures?

But why? It seems to be a decent format. And what's the other option?

Sure it's a decent format and it's quite widespread. However, if the committee decides to make the format worse by incorporating DRM, we can easily decide to move away from that format. Easier said than done, but still an option.

Or ... just not implement the DRM feature? After all, everyone from the OS on up is gonna have to agree to respect this JPEG DRM feature.

In fact, for it to work at all, it'll have to be implemented in hardware or hardware-equivalent software (i.e. not in Firefox or anything where you can dump RAM or modify the software).

PNG and WebP

FLIF is very promising too: http://flif.info/

FLIF is not really a format so much as an experiment. There isn't a spec that I can find, nor is there any sort of formal description of the format. Right now, the only available spec is the source code and that leaves a lot of open-ended questions about what to do about inconsistencies in implementations. I hope it develops into something good, but for now it doesn't seem a viable option.

If we're going to use WebP anyway, we might as well drop PNG too in favor of the lossless mode. I don't know of any downsides to this. But mandatory chroma subsampling means WebP can't completely replace JPEG.

Sure it’s an option… but look how long it’s taking us to move to IPv6.

The trouble there is that so much hardware and infrastructure is built for IPv4.

With file formats however, it's only software. Add supports to mainstream browers and operating systems and you've got a fully functional new format. Look how quickly webm came into existence.

JPEG is an oldy, but support for a new format that does all JPEG does is certainly possible, and it would slowly win out. Much like how png killed gif (until social media brought it roaring back... egh).

One problem with JPEG's adoption is its prevalence in firmware actually - cameras. Some might not go away for decades. The IPV6 comparison is not entirely unwarranted.

That's a fair point. I was thinking cameras usually use a raw format, but that's not true of many devices.