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

Thu Apr 17 21:05:08 EDT 2014

I believe the decision was made because the pixel-by-pixel JpegMediaHasher
was not functioning properly if we scrubbed the exif data.  Nathan, please
let me know if that's accurate.  If not: then I have a plan that would
actually mitigate the whole issue (by extending the jpeg redaction library
a little bit.)

On Thu, Apr 17, 2014 at 5:12 PM, David Oliver <david at guardianproject.info>wrote:

> 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/860d5cfb/attachment-0001.html>