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

Thu Apr 17 17:12:06 EDT 2014

My initial thought is that this will impact potential users of InformaCam
who have security concerns (e.g., Martus).

However, I think this is really about understanding the requirements,
overall.  For example, if we offered a "secure camera" (which never leaked
media or metadata to unencrypted storage) then the "need" to scrub EXIF
would be viewed differently.  Secondly, our work on verification is not
impacted by whatever data some camera app wants to store in the file -
we're not claiming to, use, understand, or verify THAT data, only the data
we ourselves "manage" (at least, as I understand it).

Still, there do seem to be legitimate concerns here, related to security.
 Perhaps this could a user-selectable feature (scrub EXIF)?

Question: do we rely on any specific EXIF data for our needs?

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 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
>>
>>
>
> _______________________________________________
> 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/david%40guardianproject.info
>
> You are subscribed as: david at guardianproject.info
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20140417/562d8f41/attachment.html>