Hi Andrew,<div><br></div><div>Thank you so much for this! </div><div><br></div><div>First off, I finished up the metadata spec, and have committed it here: </div><div><br></div><div><a href="https://github.com/guardianproject/SecureSmartCam/commit/861b26d01f57c7d60cb078d82747cb5a4979bee2">https://github.com/guardianproject/SecureSmartCam/commit/861b26d01f57c7d60cb078d82747cb5a4979bee2</a> </div>
<div><br></div><div>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.</div>
<div><br></div><div>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...)</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks!</div><div>Harlo</div><div><br></div><div><div class="gmail_quote"><font color="#999999">On Mon, Nov 28, 2011 at 11:38 PM, Andrew Senior <span dir="ltr"><<a href="mailto:andrew.senior@gmail.com">andrew.senior@gmail.com</a>></span> wrote:<br>
</font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#999999">I've been working on extending the JPEG redaction library to handle editing the metadata, and looking at storing proprietary metadata in the files. <br>
I think it might be best to store our proprietary data in an APPn data structure rather than makernote. <br>
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<br>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.<br>
If determined by the Manufacturer tag, then we'd have to change that too.)<br><br>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)<br>
<br>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.<br><br>On the other hand the EXIF standard <a href="http://www.exif.org/Exif2-2.PDF" target="_blank">http://www.exif.org/Exif2-2.PDF</a> talks about storing multiple APP2 segments, and skipping APPn segments if a reader can't parse them. <br>
Flashpix seems less important to preserve, and I suspect that we can coexist with other APP2 - we just define our own header string. <br>Alternatively we can pick our own 'n'. I think 13 (Adobe photoshop and IPTC) is the only one I've seen in use, and <a href="http://www.ozhiker.com/electronics/pjmt/jpeg_info/app_segments.html" target="_blank">this page</a> only lists a few. I think this would be my inclination.<br>
<br>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.<br>
APPn segments are supposed to be under 64KB, but you can have multiple segments to exceed that limit.<br><br>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?)<br>
<br>Candidate information to store: <br><br>Consent information: face locations, identities and consent status.<br>Signatures<br>Key identities. <br>Actual public keys? <br>Obscura version information. <br>Redaction information: regions' coordinates and encrypted contents.<br>
Non-standard (e.g. sensor) metadata<br>Audit trail (details of obscura-cam operations)<br>Anything else? <br><br>We need to work out what needs to be/can be signed and what encrypted.</font><span class="HOEnZb"><font color="#888888"><br>
<br>Andrew<br></font></span></blockquote><div><br></div><br clear="all">///////////////////////<div><font size="1">Harlo Holmes</font></div><div><a href="https://guardianproject.info/" target="_blank"><font size="1">guardianproject.info</font></a></div>
<div> </div></div><br></div>