Category Archives: commentary

PDF 2.0

The ISO specification for PDF 2.0 is now out. It’s known as ISO 32000-2. As usual for ISO, it costs an insane 198 Swiss francs, which is roughly the same amount in dollars. In the past, Adobe has made PDF specifications available for free on its own site, but I can’t find it on Its PDF reference page still covers only PDF 1.7.

ISO has to pay its bills somehow, but it’s not good if the standard is priced so high that only specialists can afford it. I don’t intend to spend $200 to be able to update JHOVE without pay. With some digging, I’ve found it in an incomplete, eyes-only format. All I can view is the table of contents. There are links to all sections, but they don’t work. I’m not sure whether it’s broken on my browser or by intention. In any case, it’s a big step backward as an open standard. I hope Adobe will eventually put the spec on its website.
Continue reading

A world of emoji misinformation

July 17 was World Emoji Day. Anyone can declare a World Anything Day, but my local library thought it was important enough to give it part of a sign, along with Cell Phone Courtesy Month.
Library sign giving inaccurate information about Emoji They didn’t think it was important enough to give accurate information, though. It does tell us something about how non-tech people think of emoji. Here’s the content of the sign, with commentary.
Continue reading

MOBI and other obsessions

The MobileRead Wiki is a great place to jump into if you’re looking for information on ebook formats. It isn’t uniformly up to date; for instance, it says there is “a new version of [EPUB] called ePub 3 but it is not in wide use.” But it covers lots of formats and has some excellent analysis, especially a look in depth at the Amazon MOBI format. points at that wiki page as its reference on the format, so it seems as close to an “official description” as anyone has offered.

Amazon is the one company that uses MOBI and its bastard children, while everyone else is using EPUB, but obviously Amazon can’t be ignored. It distributes Kindle software so widely that you can read MOBI files on any device.
Continue reading


In a post in May, I wrote: “The patents which gave [Fraunhofer] revenue have barely expired on the format, and they’ve suddenly decided that MP3 is dead.” It appears that I fell for fake news, and I apologize. On rechecking, … Continue reading

The strange history of the GIF format

CompuServe introduced it in 1987. It’s limited to 256 different colors (possibly more with some color table trickery). When it was locked down by a patent, people rebelled and invented better formats. Yet 30 years later, the GIF format is strangely popular. Wired’s article, “The GIF Turns 30,” covers its history and the bizarre resurgence in its popularity.

The reason for its survival is a feature that seemed unimportant at first: it lets people create simple animations. That wasn’t a very practical feature on the home computers of the eighties; the creators probably thought of it more as a way to put a slide show into one file, with the image changing every few seconds.
Continue reading

MP3 is dead. Long live … what?

Update: My statement that Fraunhofer declared MP3 dead was completely wrong. Please read this retraction.

Girl Genius: The old Storm King is killed, and a new one promptly crowns himselfThere’s the blatantly obvious. Then there’s the blatantly cynical, who-cares-if-you-see-right-through me obvious. I’m not talking about Donald Trump but Fraunhofer. The patents which gave them revenue have barely expired on the format, and they’ve suddenly decided that MP3 is dead. They’ve even crowned its successor: not any open format, of course, but AAC, which can provide patent revenues for years.
Continue reading

Why MP3 freedom matters

Yesterday I mentioned MP3 Freedom Day to a friend, and he asked why it mattered. That’s something I should have explained. The MP3 patent holders, principally Fraunhofer and Technicolor, demand payment for any use of MP3 technology.

They even go after distributors of open source code. The Register reports:
Continue reading

Malware in a PNG file (for real)

Not every report of malware in an image file is spurious. A report of malware smuggled through a PNG file looks plausible to me. It claims that for two years, criminals got malware undetected onto respectable sites with this technique. Ironically, the ads included ones for a so-called “Browser Defence.”

Unlike Check Point’s “Imagegate,” this report doesn’t claim the image alone can do anything, and it describes the technique in considerable detail. Check Point said it would give specifics about “Imagegate,” like what format is affected, “only after the remediation of the vulnerability in the major affected websites.” It’s still waiting, apparently.

The PNG exploit is impressively sneaky. A script which doesn’t trigger alarms checks the host browser’s defenses. If it finds a vulnerable target, it loads a PNG file whose alpha channel encodes the malware script, then decodes the script and runs it. The actual malware takes advantage of — wouldn’t you know it? — Flash vulnerabilities. The user doesn’t have to do anything except view the page to be victimized.

This doesn’t mean any PNG file is dangerous in itself. An external script has to extract the JavaScript from the alpha channel and run it. So this counts as an exploit of a file format, but not as a vulnerability in it. Malicious code can be embedded in any format that has room for some noise in its data.

Attacks like this are why ad blockers have become so popular.

More on SVG risks

SVG is a risky format in more ways than I’d realized. I’d previously mentioned the risk of cross-site scripting with embedded JavaScript, but I’ve found it gets worse.

The article “Crouching Tiger – Hidden Payload: Security Risks of Scalable Vector Graphics” covers the hazards in detail. There are two problems: (1) HTML5 requires SVG support in multiple contexts, and (2) SVG can have embedded JavaScript and CSS.

SVG is XML, and embedding it in HTML means switching between two different parsing modes. The author, Thorsten Holz at Ruhr-University Bochum, states that “SVG files must be considered fully functional, one-file web applications potentially containing HTML, JavaScript, Flash, and other interactive code structures.” I still haven’t digested all the content, but it describes lots of ways SVG could be exploited.

Websites that allow third-party posting should disallow or filter SVG content. WordPress disallows SVG uploads by default.

SVG is a designed-in danger in HTML5.

The “Imagegate” rumor mill goes wild

Search for “imagegate,” and you’ll find lots of articles claiming there’s a malware risk in JPEG files. Look more closely, and you’ll notice they don’t provide any support for the claim. They all take an article from Check Point as their source, but there are two little problems with that: (1) The article doesn’t blame JPEG files, and (2) as I noted in my last post, it’s inept reporting.

Looking very closely at the video which accompanies the Check Point article, I see that it shows a file called “payload.jpg” being uploaded. This must be what all these sites are going by. You have to look really close to see the blurry file name coming up, and I give these sites credit for examining it more closely than I did.

If this was Check Point’s way of tipping people off that the weakness is in JPEG, it’s a strange way to do it. Did they think that ordinary users would catch it, but malware authors would be tricked by the article’s reference to non-image formats like JS and HTA as “images”?

None of the articles I’ve seen question why Check Point tipped them off in this way or note the inconsistencies in the article and the video. None of them ask why Check Point refuses to give any information until “the major affected websites” fix the problem, when a format vulnerability impacts any software that reads the files.

Doesn’t anyone know how to do journalism any more?

Update: Facebook says that “Imagegate” is bull.