About Metadata

What is metadata?

Metadata means "data about data". For example the date and time that an email message was sent, who it was sent to, and who sent it, are metadata providing a context for, and information about, the text of the message.

Some metadata is readily apparent. The date and time that an email message was sent, who it was sent to, and who sent it, for example, will be shown whenever the email is displayed or printed. Some metadata, for example the last printed date of a Word document, is "hidden" in the sense that it is less well known, only displayed if you tap on certain options, and not so easy to print.

An example in more detail - EXIF metadata

JPGs in EXIF format (“Exchangeable Image File Format”) created by scanning a document also have hidden metadata known as  EXIF tags or "EXIF data". This includes the make and the model of the scanner. In addition XResolution and YResolution give the DPI value. As well as DateTime, there are two other EXIF date/time tags: DateTimeOriginal and DateTimeDigitized. For scanners, DateTimeOriginal was a field set aside to be filled in to record when the original paper document being scanned was created, and DateTimeDigitized is when the subsequent scan took place.

JPG photos in EXIF format also have EXIF tags giving the make and model of the camera or phone and have additional EXIF tags such as the exposure time, focal length, and  ISO number, as well as, of course, the date and time that the image was taken. As explained here DateTimeOriginal is the date/time that the camera's image sensor captured the image, DateTimeDigitized is the date/time that the file, containing a digital representation of that image in JPG format, was created on the phone's storage (or SDCard in the case of a digital camera), and DateTime is the date/time that that JPG file was last updated.  For modern cameras and phones the difference in time between DateTimeOriginal and DateTimeDigitized is infinitesimal and so they will always be the same down to the second and, providing the JPG has not been changed (e.g. by being rotated by a photo editor), DateTime will be the same. In fact, precisely because they are the same, some cameras only fill in one of the three date/time tags. Most cameras set all three but some cameras might just set DateTimeOriginal whilst other cameras might just set DateTime. Programs which display EXIF data sometimes refer to the date/time the image was captured as DateTaken. DateTaken is not actually the name of an EXIF tag but is just a shorthand for "the date/time in whichever of the three date/time EXIF tags has been filled in".   

In addition to DateTaken, if the device has a GPS sensor and geo-tagging is switched on, GPSDateStamp and GPSTimeStamp will contain the GMT date and time of the GPS satellite signal used for the last GPS fix before the photo was taken. In order to save battery life, if a phone detects that it is stationary (because two consecutive GPS fixes are the same) it will generally stop doing GPS fixes for a period unless and until it detects significant movement (the device can tell when it has started to move from the accelerometer). Consequently at the time a photo is taken the time of the last GPS fix may have been many seconds, or even minutes, ago but GPSDateStamp/GPSTimeStamp  can, nevertheless, provide useful confirmation that the device's internal clock, which is used when writing DateTaken is not wildly wrong.

A phone uses its internal clock when writing DateTaken. The internal clock of a phone can be set to synchronise automatically with the network signal from the nearest tower but it can alternatively be set manually. If the internal clock - of a phone or digital camera - has been set manually it could in theory have been set to the wrong time and/or wrong date. This is more likely to happen with a digital camera than with a phone because an incorrect date/time on a phone would affect everything - the home screen, emails, and the date shown for SMS messages, for example, and the user would be likely to soon notice and correct it. But unlike DateTaken the GPSDateStamp and GPSTimeStamp tags are not dependent on the device clock - they always show the GMT date/time independently provided by GPS satellites - so if GPSDateStamp/GPSTimeStamp show the same date and approximately the same time as DateTaken (making allowance for time zone) that provides additional confidence that  DateTaken is accurate, at least to within a few minutes.

There are other GPS tags present when geo-tagging is switched on. GPSLatitude (together with GPSLatitudeRef showing either North or South) and  GPSLongitude (together with GPSLongitudeRef showing either East or West) will show the approximate location of the camera at the time the photo was taken. The accuracy of the GPS position varies (buildings and terrain may interfere with GPS satellite signals) and there is actually an additional GPS tag which gives an estimate of the degree of horizontal inaccuracy (in metres) - GPSHPositioningError. 

GPSImgDirection is a tag which indicates the direction the camera was pointing when the photo was taken, relative to north (GPSImgDirectionRef identifies whether True or Magnetic north). For example if GPSImgDirection is 186660/2074 that is 90 degrees which is due east. Although the letters GPS appear in this tag it is usually set using data from the device's magnetometer (compass). A GPS signal only needs to be used in the calculation of GPSImgDirection if GPSImgDirectionRef is True (in which case the position of the camera or phone needs to be determined as part of calculating the magnetic declination).

When you take a photo with a digital camera or phone the rows and columns from the image sensor are stored in a JPG file - first row, written first. Image sensors have a rectangular array - not square - which receives a "landscape" image (where the width is greater than the height) when the phone is being held in its "natural" position for photography - i.e. horizontally. If you want to take a "portrait" photo (where the height is greater than the width) you hold the camera upright - i.e. rotated 90 degrees clockwise from its "natural" position. The phone has a built-in accelerometer which detects how it is being held and it would be possible for the phone software to be designed to transform the series of bits from the sensor so that the first column, rather than the first row, is written first in the JPG when the phone is held upright, so that the image is always written to the JPG file starting with the sky and ending with the ground no matter how it is being held, but that would use up power and slow down the process so, instead, the phone always writes the sensor data in the same way, first row written first, but sets an Orientation tag in the EXIF data within the JPG file it writes to indicate if, and by how much, the image needs to be rotated when being displayed - e.g. 90 degrees clockwise if the phone had been held upright.

The difference between embedded metadata and file-system metadata

The metadata example discussed above is an example of embedded metadata - embedded within the data in the file. There are different types of embedded metadata depending on file type - EXIF data in JPG photos, MIME data in emails, and XML data in a Word document. But in addition to metadata embedded within the data in a file, the file-system (e.g. Windows NTFS or Android Ext4) stores its own metadata for each file in the file-system's directory. Depending of the system, this file-system metadata might technically be in another structure linked from the directory rather than in the directory itself but the point is that the file-system metadata for each file is maintained by the file-system outside each file itself, and is used for general file management purposes. For example the date/time of last modification for each file - one of the items of file-system metadata maintained for each file - is used when an incremental backup is run. An incremental backup is a backup of only those files which have changed since the last backup. The file-system metadata maintained for each file will also include a "filename" - a series of characters used (together with a "folder" name) to uniquely identify the file on the storage device, often ending with an abbreviation indicating file type, e.g. StandardtermsV2.2.pdf as well as other items such as file size.

File system metadata

Most file systems allow files to be grouped together in "folders" with the possibility of sub-folders, so that there is a "pathname" recorded within the file-system directory consisting of folder and sub-folder names and ending in the filename. What other file-system metadata there is depends on the particular file system.

In most file-system directories a "date/time last modified" metadata item is maintained for each file. There may also be a "date/time created" recording the original date/time the file was created. In general, as long as the computer clock is correctly set, these date/time items should be correctly set by the file-system in the device, but it is not so simple if files are transferred from one device to another device. Files may be transferred from one device to another for a variety of reasons, for example when one computer is replaced by another or when files are moved to cloud storage to save space. Files on mobile devices such as phones may be copied to a computer as a precaution and subsequently the mobile phone might be lost or destroyed. When files are transferred, the original file-system date/time might be retained or, alternatively, it may be reset to the date/time of transfer: it depends on the file-system and on how the transfer is accomplished.  

Some file systems also maintain a "date/time last accessed" as part of their metadata. As the name suggests, events which will cause the file-system "date/time last accessed" to be updated include many events in which the data is simply read. But in order to be of value a file system has to be somewhat selective about what is to count as an "access". For example if simply displaying the "date/time last accessed" was itself considered to be an "access" then the "date/time last accessed" when displayed would always just show the current date and time! Exactly what counts as an access may vary,  to a degree, between different file systems which maintain this item of metadata.  

Preserving backup copies of documents with metadata if there are (or may be) legal proceedings  

Preserving embedded metadata in backup copies is straightforward as it is part of the data within each file.

The situation with preserving file-system metadata in backup copies is more complex. Although it can depend on the particular tribunal and on any case-specific directions given, the general approach in civil litigation is that there is no expectation that the copies routinely used during the litigation process - e.g. for the disclosure of documents stage - should have original file-system metadata but, in the event of a query about any specific document, it should be possible for the original document with its original filename to be made available for inspection. For example the original filename of a spreadsheet may give a clue as to what it is a spreadsheet of, if that is not otherwise obvious. To allow the original file to be inspected (even if the actual original device has become unavailable) if that should become necessary at any point, a backup copy can be taken at the outset designed to preserve, so far as possible, key file-system metadata. Depending on the programs used to create the archive and subsequently extract files from it, the file system under which the extract program in particular is running, and the history of a file, the "date/time last modified" of a file extracted from the archive might or might not be the original date/time but the filename of the file as extracted should be the filename as it originally was at the time the archive was created. Any "date/time created" and "date/time last accessed" of the extracted file will probably not be the original.     

Different civil courts and other civil tribunals may have slightly different rules about the disclosure of documents including metadata, and, to a degree, a particular tribunal might give different directions depending on the type of case and the potential significance of particular data. In extreme cases the High Court might make an urgent "imaging order" at an early stage even before the formal court claim has actually commenced. An "imaging order" is a compulsory order requiring a party to actual or impending litigation to allow solicitors for another party, accompanied by a neutral "supervising solicitor" and neutral computer expert, to enter premises where computers and other electronic devices belonging to that party are located and take a complete image of each storage medium, the image to be held securely by the computer expert subject to future directions of the High Court. But normally, when backup copies are being taken by litigants at an early stage, the approach is to make archive copies in which at least the original file contents (including embedded metadata), and at least the filename from file-system metadata, are preserved for each document, but accepting that some other file-system metadata - in particular "date/time last accessed" - may not be preserved.  

Disclaimer

The information above is necessarily of a general nature and will not be applicable to every case: it is intended to be used in conjunction with more specific advice to the individual client about the individual case. Contact me for advice about your case.

The information on this page about specific computer techniques is provided for information purposes only. Every reasonable effort has been made to ensure that the information is accurate and up to date at the time it was written but no responsibility for its accuracy, or for any consequences of relying on it, is assumed by me. You should satisfy yourself, before using any of the techniques, software or services described, that the techniques are appropriate for your purposes and that the software or service is reliable. The features and behaviour of different apps may vary with different versions. Take technical advice as appropriate.