Re: DRAFT: eXIf 2017-03-09

On 11 March 2017 at 07:45, Phil Harvey wrote:
> Too bad I can't vote yet. :(

I still encourage you to vote, even if your vote won't be counted at
the end (if you happen to still not be eligible by that time).

You obviously are a metadata expert. I have been an exiftool user for
almost 10 years, and I've learned a lot from it (as well as its
extensive accompanying documentation). If you will eventually become a
permanent contributor to our group (provided that, of course, you will
have the time and willingness for it), that will be awesome.

> I'm for the minimalist approach.  As a metadata developer who understands Exif, less is better.  See the eXif chunk description in the FLIF specification for example, which is perfectly sufficient.

[Before I proceed any further, I want to state clearly that I agree
both *with* and *without* including a statement on security, so my
vote will not be influenced by this particular issue. The rest of this
email is my personal opinion, and nothing more than that.]

I hope you don't mind if I respectfully disagree here. I wrote a
barebones TIFF decoder from scratch in OptiPNG, more than 10 years
ago, and I am enhancing it right now. Hoping that eXIf does become a
reality, I plan the next OptiPNG release to have full support for it.
You said the following a few days ago:

> Any developer who adds eXIf support for PNG has probably already implemented a TIFF reader, so they already know this.

So, yes, I did implement a TIFF reader, but no, I did not see this coming.

Anybody remember Heartbleed, the OpenSSL bug and the web security
nightmare from 2014? Think about the TLS protocol, i.e. the Transport
Layer Seurity protocol, designed by security experts, and implemented
by security experts also. What could possibly go wrong?

This: https://xkcd.com/1354/

It is important to clarify the difference between the
OpenSSL/Heartbleed scenario and our eXIf scenario: they bear almost no
resemblance. (And it wasn't really uninitialized data that needed to
be patches, it was rather a buffer size issue.) It is, however, also
important to clarify two important takeaways: (1) that even security
experts can get this wrong, and one brief sentence of warning
"caution: you may already know, but here lies uninitialized data, and
also GPS coordinates, and user passwords, and also dragons" is *not*
one-too-many. And (2) that uninitialized data is not a security issue
in itself, but it may become an issue if the implementation fails to
take it into proper consideration. OpenSSL has been patched as a
security issue in its implementation, but the TLS protocol itself is
still considered secure.

For this reason, one short sentence "Any gap preceding an IFD is
filled with bytes of unspecified content" does not hurt readability in
any way (because it is so brief) but it may help (because it is so
clear).

Finally, I understand that the TIFF specification does not mention any
security issue. But again, there is a difference between having (or
not having) issues vs. mentioning (or not mentioning) existing issues.

Just my 2 cents worth of opinion.

I would be happy enough to see that the eXIf proposal gets advanced
into the formal discussion stage, either with or without this (or any
other) security clarification.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford