[Ssc-dev] Storing Obscura metadata in JPEG files

[Harlo Holmes]

Hi Andrew,

Thank you so much for this!

First off, I finished up the metadata spec, and have committed it here:

https://github.com/guardianproject/SecureSmartCam/commit/861b26d01f57c7d60cb078d82747cb5a4979bee2


It's a .json file that you can reference for the required fields at this
time (values input are sample data that infer data types.)  I will also
include an XML representation of the same structure, I'm just more nimble
working in JSON.

I definitely want to insert our data in an APPn field; hopefully we can use
another APPn than those currently used to store EXIF/XMP (which should be
preserved for sharing the media across other
viewers/platforms/services/software.)  So, if we can safely preserve
Informa elsewhere than APP2, that would be great.  (If not, we can use #2,
we'll extend our spec to include EXIF data generated by the device...)

In regards to division of labor, I expect the app will handle all the
medatada generation, and encryption-- the JpegRedaction library should only
serve to input the generated payload into the correct APPn segment.  (I
hope I've understood the process properly-- please let me know if I'm
off-base here.)  I would want the app to send a complete data object (as a
JSON string) to the JpegRedaction class on save; that interaction being the
final step to generating the resulting image.

Thanks!
Harlo

On Mon, Nov 28, 2011 at 11:38 PM, Andrew Senior <andrew.senior at gmail.com>wrote:

> I've been working on extending the JPEG redaction library to handle
> editing the metadata, and looking at storing proprietary metadata in the
> files.
> I think it might be best to store our proprietary data in an APPn data
> structure rather than makernote.
> Then we can have the option to preserve makernotes, and not confuse other
> parsers with misleading makernote (I can't actually work out how image
> software is supposed to know
> what format the makernote is in- if it's determined by the manufacturer
> tag, or if everyone just tries to decode makernotes and sees if they match
> their own format.
> If determined by the Manufacturer tag, then we'd have to change that too.)
>
> APPn data on the other hand seems open for reuse. There are at least two
> standards using APP2 field. (Flashpix and ICC_PROFILE) and two for APP1
> (EXIF and XMP)
>
> XMP stands for extensible metadata, so we could use this standard, but I'm
> not sure it can coexist with EXIF, and I'm a wary of requiring XML and of
> fitting into this existing standard.
>
> On the other hand the EXIF standard http://www.exif.org/Exif2-2.PDF talks
> about storing multiple APP2 segments, and skipping APPn segments if a
> reader can't parse them.
> Flashpix seems less important to preserve, and I suspect that we can
> coexist with other APP2 - we just define our own header string.
> Alternatively we can pick our own 'n'. I think 13 (Adobe photoshop and
> IPTC) is the only one I've seen in use, and this page<http://www.ozhiker.com/electronics/pjmt/jpeg_info/app_segments.html>only lists a few. I think this would be my inclination.
>
> If the library is to construct this data segment, I would suggest that we
> store our metadata as a TIFF IFD, as that seems like a compact, flexible
> standard, for which some code already exists in the library. It's pretty
> basic with a flat structure.
> APPn segments are supposed to be under 64KB, but you can have multiple
> segments to exceed that limit.
>
> If the data segment were to be constructed inside the android app, then
> alternative (and richer) structures (XML or protobuffer?) might be more
> feasible or preferable. We have to think about the division of labour
> between the app and the JpegRedactionLibrary, and any other clients we may
> want in the future that might read/validate the data. The library has
> direct access to the raw data for signing/encryption, but the app has the
> metadata (and presumably the crypto libraries- I haven't looked at what we
> might use from the C++ code?)
>
> Candidate information to store:
>
> Consent information: face locations, identities and consent status.
> Signatures
> Key identities.
> Actual public keys?
> Obscura version information.
> Redaction information: regions' coordinates and encrypted contents.
> Non-standard (e.g. sensor) metadata
> Audit trail (details of obscura-cam operations)
> Anything else?
>
> We need to work out what needs to be/can be signed and what encrypted.
>
> Andrew
>


///////////////////////
Harlo Holmes
guardianproject.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20111201/72a51e96/attachment.htm>