[Ssc-dev] InformaCam 0.1.42: more video fixes!

[Harlo Holmes]

But, more on this... it's really interesting.  That's the cool thing about
specifications (like jpeg in this case): different vendors have different
implementations, and that shows up as interesting metadata that can be used
to better verify.

For example, if a Galaxy device puts GPS exif data at position 115 in the
exif header and a Nexus puts the same data in position 137, you have a
pretty cool new data point to work with.  I remember telling Nathan that we
might use this to our advantage.

Using Andrew Senior's jpeg redaction library, i was able to write a little
proof-of-concept around how we might cluster different sources around this
data:
https://github.com/harlo/UnveillanceInspector/blob/master/Utils/csv_utility.py(but
this is not ready at all for primetime, just wanted to illustrate what
I mean!)


On Thu, Apr 17, 2014 at 9:34 AM, Harlo Holmes <harlo.holmes at gmail.com>wrote:

> Actually, we decided not to strip exif in informacam photos afterall.  We
> made this decision a few months ago.  I can search my email history for the
> exact thread sometime later.  And yes, that does present a classic McAfee
> conundrum!
>
>
> On Wed, Apr 16, 2014 at 12:49 PM, bryan <bryan.nunez at gmail.com> wrote:
>
>> When I pull images off the global leaks server, those files still contain
>> exif data, including GPS. Is that info put back into the file when you
>> download from the server?
>>
>>
>> On Wed, Apr 16, 2014 at 9:59 AM, Nathan of Guardian <
>> nathan at guardianproject.info> wrote:
>>
>>>
>>>
>>> On April 16, 2014 9:49:42 AM EDT, David Oliver <
>>> david at guardianproject.info> wrote:
>>> >ok, thank you for this clarification, but I need one more.
>>> >
>>> >It is my understanding that various and sundry cameras insert plenty of
>>> >their own information into the file header.  This might include
>>> >location
>>> >info and all manner of other info taken from elsewhere on the device.
>>> >This, in addition to, the basic information that is required for
>>> >display.
>>>
>>> Yup.
>>>
>>> >
>>> >Does InformaCam scrub this non-essential camera-provided data from the
>>> >file
>>> >header, or does InformaCam only "augment" what is there with its own
>>> >data?
>>> > I'm thinking about "the John McAfee problem" here.
>>>
>>> We extract and scrub.
>>>
>>> InformaCam extracts the existing metadata from the EXIF headers that you
>>> are referring to, stores it in the J3M metadata we capture/secure, and then
>>> scrubs the original headers.
>>>
>>> There is a case to be made for keeping the original headers when the
>>> goal of InformaCam is only verification, and not privacy. We can support
>>> that, but our default is a privacy focused solution.
>>>
>>> +n
>>>
>>>
>>>
>>>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >David M. Oliver | david at g <david at olivercoady.com>uardianproject.info |
>>> >http://g <http://olivercoady.com>uardianproject.info | @davidmoliver |
>>> >+1
>>> >970 368 2366
>>> >
>>> >
>>> >On Wed, Apr 16, 2014 at 9:43 AM, Nathan of Guardian <
>>> >nathan at guardianproject.info> wrote:
>>> >
>>> >>
>>> >>
>>> >> On April 16, 2014 9:37:49 AM EDT, David Oliver
>>> ><david at guardianproject.info>
>>> >> wrote:
>>> >> >This would seem to be important news for our Benetech cooperation.
>>> >>
>>> >> I think I expressed issues related to media encryption usability in
>>> >our
>>> >> last report, and happy to share this with them. (Also Barbra is still
>>> >on
>>> >> this list).
>>> >>
>>> >> >
>>> >> >Correct me if I'm wrong on this, but I think you are implying that
>>> >> >while
>>> >> >there is an encrypted metadata blob within the media file header,
>>> >there
>>> >> >is
>>> >> >no unencrypted metadata in the file (except the minimal necessary to
>>> >> >play/view the contents in a standard player/viewer), right?
>>> >>
>>> >> If you export the file for sharing to someone you have a public key
>>> >for,
>>> >> then the metadata will be encrypted to that key, and signed with your
>>> >key.
>>> >> If you export for general sharing, then it will just be signed with
>>> >your
>>> >> key.
>>> >>
>>> >> Either way, until you choose to share, all of the captured metadata
>>> >is
>>> >> stored encrypted.
>>> >>
>>>
>>> _______________________________________________
>>> Ssc-dev mailing list
>>>
>>> Post: Ssc-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>>
>>> To Unsubscribe
>>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>>         Or visit:
>>> https://lists.mayfirst.org/mailman/options/ssc-dev/bryan.nunez%40gmail.com
>>>
>>> You are subscribed as: bryan.nunez at gmail.com
>>>
>>
>>
>> _______________________________________________
>> Ssc-dev mailing list
>>
>> Post: Ssc-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>
>> To Unsubscribe
>>         Send email to:  Ssc-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com
>>
>> You are subscribed as: harlo.holmes at gmail.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20140417/ddb6d63c/attachment-0001.html>