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

[Harlo Holmes]

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/d64c26a2/attachment.html>