[FFmpeg-devel] modification time in libavformat (.MOV files)

[Michael Niedermayer]

On Fri, Feb 21, 2014 at 12:45:51AM +0100, Ayke van Laethem wrote:
> 2014-02-15 21:02 GMT+01:00 Michael Niedermayer <michaelni at gmx.at>:
> > On Fri, Feb 14, 2014 at 07:39:18PM -0800, Alex Sukhanov wrote:
> >> On Fri, Feb 14, 2014 at 4:47 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> >>
> >> > On Fri, Feb 14, 2014 at 07:18:13PM +0100, Ayke van Laethem wrote:
> >> > > Hi,
> >> > >
> >> > > I have been working on a patch to fix a bug I discovered in the saving
> >> > > of .MOV files. In short, the creation time of individual streams isn't
> >> > > copied as it says they will be (it is copied from the output .MOV file
> >> > > instead, which is null if -map_metadata isn't used), and modification
> >> > > time is set to the creation time.
> >> > >
> >> > > This SuperUser post is in part about this issue:
> >> > >
> >> > http://superuser.com/questions/510578/when-spliting-mp4s-with-ffmpeg-how-do-i-include-metadata
> >> > > I can add a way to reproduce the issue if needed. I will certainly do
> >> > > that before (or while) submitting the patch.
> >> > >
> >> > > The patch I wrote seems to work correctly, but fate fails. I assume
> >> > > this is because the metadata is changed so the output file has a
> >> > > different hash than what fate expects. Updating the hash so it
> >> > > includes the correct creation_time should be easy, but the
> >> > > modification time will be different each time.
> >> > > So here is the question. Should the modification time be set at all? I
> >> > > think it would be the more 'correct' way to go, but it makes testing
> >> > > harder. If modification time will be set, how should testing be done?
> >> >
> >> > storing the current time in files without the users knowledge poses
> >> > a risk to privacy and security.
> >> >
> >> >
> >> > [...]
> >> > --
> >> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >> >
> >> > it is not once nor twice but times without number that the same ideas make
> >> > their appearance in the world. -- Aristotle
> >> >
> >> > _______________________________________________
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel at ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >
> >> >
> >> Sorry for dumb question, but what is a risk to privacy and security?
> >
> > time and location allow indentfying a person in some/many cases
> > so storing time without the person knowing gives half the information
> > needed to identify the person. Now the location can possibly be
> > identified from the video content.
> >
> > security wise, storing the time in files leaks information about
> > the system clock. which could be helpfull to any attack that needs
> > to be timed pricessely or could be feedback for an attack involving
> > NTP. Iam no expert in this stuff iam sure there are others who could
> > provide better examples
> >
> 
> Okay, that makes sense. But I think in most cases, it is expected
> ffmpeg will save the modification according to the specification (I
> would expect that, at least).
> 
> What about making it a command line option whether to save
> modification times as metadata?
> Are there any other containers that save modification time, besides
> the MOV/MP4 family? I tried to grep 'time', but I only found something
> that seemed to be related to MPEG transport streams.

See the "-timestamp" option to ffmpeg

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140221/4083a590/attachment.asc>