VOTE NO: eXIf 2017-0119

NO
eXIf 2017-0119
ftp://ftp.simplesystems.org/pub/png-group/documents
png-proposed-eXIf-chunk-2017-0119.txt
"Adam M. Costello" <png.amc+0-NbS3tD7h7f85yCWXc2AjrAjBWlxwwXjJRgbkGAX3vvA@public.gmane.org>

I would vote yes (on either this or the compressed version, I haven't
decided yet) if the proposal were modified in two ways:

First, because the chunk is safe-to-copy, the spec should clearly state
that it describes some past version of the image, not the current
image.  If the spec says anything about what that implies for decoders,
it should say that decoders should assume that none of the EXIF data
applies to the current image, unless the decoder is given external
knowledge that some of it does apply.  (The current proposal says that
decoders should ignore EXIF data that conflicts with other chunks, but
that's not strong enough; decoders should ignore all EXIF data unless
the user instructs otherwise.)

Second, I don't see why there is a security-considerations section.
I don't see how that text is related to security.  The question of
whether the EXIF data pertains to the current image or a past version
is central to the chunk specification and should not be hidden in a
security-considerations section in a separate chapter.

AMC

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot