Advanced Guides

Safe Travels: Digital Security When Traveling on Assignment

Introduction

Every trip is unique and poses different security concerns owing to the diverse amount of specific threats which may arise based on factors such as the nature of the assignment, the destination, and the route you take. That being said, there are nonetheless baseline digital security considerations which generally apply to most travel.

It’s up to you to decide which digital security measures to implement while traveling. The main aim is to protect not just yourself or your newsroom, but also your sources who are oftentimes the ones rendered the most vulnerable when journalists don’t follow digital security recommendations.

Travel Devices and Accounts

Travel Devices

One of the main concerns we have when travelling on assignment is that someone could stop you and search your devices. As such, it’s important to minimise the amount of sensitive data you carry on you. The best way to do so is through using separate travel devices. It’s best to have a separate phone and laptop with you prior to travel and, if you’re using external cameras and voice recorders, to also buy new, empty memory cards.

If the travel device has already been used, make sure you first wipe or factory reset it. You can readily find instructions for how to do so for various models of hardware. Resetting the device helps ensure that there is no easily-recoverable past data on the device.

You can also buy privacy screens for the devices, which make it harder for someone next to you see the contents of your screen. Keep the privacy screens on your devices at all times, including when in seemingly private spaces such as hotel rooms, which may be subject to surveillance.

Though it may seem like overkill to go through the hassle of acquiring, setting up, and bringing travel devices on seemingly-routine trips to destinations you may consider as being relatively safe, keep in mind that any time you are traveling, you are potentially putting your sensitive sources at risk. Even seemingly simple trips may lead to your devices being confiscated and you being placed under arrest if you fail to provide the passwords for the devices. For instance, when an employee at a French publisher traveled from France to England, he was interrogated for six hours, and subsequently arrested for failing to provide the login credentials to his seized devices.

It might not be possible for everybody to get separate travel devices: they can be expensive or difficult to obtain. If you can’t get separate devices for travel, you should at least remove sensitive information (such as names of and chats with sources) before you travel. Even if the chances of being searched during most trips are low, you should still be ready for that possibility.

SIM Cards and mobile networks

You will almost certainly use your mobile phone while on a trip. Don’t forget that, due to the way mobile phones and cell towers work, phone networks can easily figure out the locations of every mobile which connected to them. If you do not want a mobile network to track you while you’re in a particular location, turn off your phone or put it into airplane mode. (But don’t forget that your location could still be tracked through other means, such as CCTV cameras.)

Some countries have compulsory SIM registration, and you will need to present your passport or other ID document when purchasing a SIM card. Take a moment to research whether it’s possible to buy an anonymous SIM card in the country you’re travelling to. If it is, consider doing so. While mobile networks will still be able to figure out your location (and could you eventually figure out that it’s you based on your movements, what hotels and cafes you stay at and so on), they will not be able to immediately trace that to your identity.

Travel Accounts

Just like you shouldn’t travel with your usual personal or work devices as well as with your usual SIM card, you also shouldn’t travel with your usual accounts. In other words, make sure your travel laptop and phone aren’t logged into your usual personal or work email, cloud storage, or any other account.

If you do need to check your work or personal accounts while on your trip, do so only once you have arrived at your staying location (such as your hotel) at your destination. Do not check your usual accounts while at or approaching a place where you could be searched, such as an airport or train station. Don’t forget that using a VPN might also attract additional scrutiny in some places; do some research on how widely accepted they are and if there aren’t any laws against using them.

Apps

Prior to your trip, you need to conduct research into which apps may not work at your destination. Some apps may be blocked via technical means (for example, if the country you are visiting interferes with the app being able to access the internet), while others may be blocked via legal means (for instance, if the app is outlawed in the country you are traveling to).

Do not have any potentially sensitive apps installed on your travel devices while going through security checkpoints or ports of entry; if these apps are essential to use during your trip, only install them once you have arrived at your destination, are past security checkpoints and have left your port of entry.

Contacts

The contacts you store on your travel devices should be minimal, including only the contacts essential for your trip (don’t copy your entire address book or contacts database to your travel devices).

Your contacts should include a check-in contact at your newsroom (unless you have memorized their phone number) with whom you will need to perform check-ins at regular intervals to relay that you are OK. Talk to your newsroom and editors before the trip to figure out a check-in procedure that works well for everybody—and decide on what to do if you miss a check in. If you don’t perform a check-in after a set time (for instance, within four hours of letting your contact know you are approaching a checkpoint), your contact should initiate an agreed upon protocol which should typically include contacting your home country’s embassy (if your country has a presence at your destination) or getting in touch with a lawyer.

If you need to store the contact information for sensitive sources, this contact information should not be on your devices during your travel, and should only be opened when you have reached your temporary residence (for instance, your hotel) at your destination. Once at your temporary residence, if you need to store the contact details of sensitive sources locally on your device, be sure to use non-revealing pseudonyms, not their real names.

When communicating with sensitive sources, use an encrypted messaging app with disappearing messages enabled whenever possible.

Storing Information

DSo not store any sensitive information, especially that which could compromise sensitive sources, on your travel devices, especially not while you are actively traveling through checkpoints and points of entry. Instead, you can keep it on a cloud account that you only log in to at places such as hotels.

Many password managers have a ’travel mode’. That allows you to only keep essential passwords and passkeys you need for travel in your app, and hide others. If your password manager doesn’t offer a travel mode, you can just save essential passwords and passkeys in a different password manager and temporarily uninstall your primary one, which keeps all the sensitive logins (just make sure you have a good method of regaining access to your primary password manager once back from travels.)

If storing your devices unattended (for instance, if you are leaving them in your hotel room), place the devices into tamper bags, which are one-time-use bags you can generally order online which show immediately apparent signs of tampering if they have been opened. If upon returning to your devices you find evidence that the tamper bags have been tampered with, assume that the devices are no longer safe, and do not use them for sensitive communications.

Border Control Protocol

When crossing a border or otherwise interacting with a security checkpoint, you may experience a number of search and interrogation techniques, depending on both your destination region and your departure point.

Your devices may be taken from you at a checkpoint. If you lose sight of your devices or someone takes them away (even temporarily), then it’s possible that someone tried to install malware on them. Those devices will, if at all possible, need to be replaced. You can also contact a local threat lab or digital security community and ask them to analyse such devices.

It’s best to keep your devices switched off when crossing borders or in other sensitive places. That’s because authorities could sometimes use tools to forcibly unlock those devices, and such tools are far less likely to work when the device has been switched off. At other times, authorities can ask or force you to unlock your device and threaten you with arrest if you don’t do so. That’s one of the main reasons we ask journalists to use separate travel devices when going on high-risk trips.

Heading Back

All of the precautions we’ve outlined don’t just apply to your trip into the country but also to your trip back. Before heading back to the airport to fly back home, make sure that you once again have no sensitive information on your travel devices. If you have accessed sensitive information while on your trip, you can do a factory reset of your devices before you get to the airport or train station to make sure no record of the sensitive information remains on your devices.

If you have conducted sensitive audiovisual work such as source interviews and recorded audio or video or taken photos, upload these materials to a trusted cloud on at least a daily basis, and make sure they are deleted from your local device.

Checklist

Here is a summative checklist of baseline digital security controls to undertake prior to traveling on assignment.

• Leave personal/work devices at home and obtain travel devices, such as:
  • Laptop
    • Privacy screen
  • Phone
    • Privacy screen
  • Camera (or new memory card)
  • Voice recorder (or new memory card)
• Setup travel accounts for any services (such as for the app store) which may need to be accessed while traveling.
• Check if essential apps are operable in-region, and have back-up app options preselected.
• Make sure sensitive contacts are not stored on travel devices during travel.
• When communicating with sensitive sources, use an encrypted messaging app with disappearing messages enabled.
• Set up cloud storage to store all sensitive information.
  • Perform nightly uploads of any sensitive information generated in-region (e.g., source interviews) and delete from travel devices.
• If leaving devices unattended, store them in tamper bags. If tamper bags are broken, assume devices compromised when returned, and obtain new devices when it’s safe to do so.
• When crossing a border checkpoint:
  • If you lose sight of the devices, assume devices compromised when returned, and obtain new devices.
  • If asked, provide passwords to travel devices and travel accounts (having made sure no sensitive information is viewable).
• Follow this protocol not just for your outbound trip, but also for the return trip.

Identifying Digital Document Forgeries

Introduction

Throughout your journalistic career, you may come across some documents which you need to authenticate. For example, you wake up one morning to find that an anonymous source has sent you a highly classified document which details government wrongdoing. The document could lead to a big exposé–if it’s authentic.

You now, however, find yourself in a tricky situation as the usual techniques of verification and corroboration may put your source in danger. For instance, if you show or even just mention the document to the government agency it purports to be from in order to try and get them to comment on its authenticity, the agency may be able to readily identify your source based on checking access logs and determining who has accessed the particular document. Likewise, it would be unsafe to reach out to another potential source to try to corroborate the document as the other person may similarly, intentionally or not, compromise your source’s identity.

Luckily, there are nonetheless some passive technological authentication measures you can undertake to perform due diligence in establishing whether the document displays any telltale signs of potential forgery. It is, however, important to note that the various red flags outlined below are not in and of themselves definitive indicators of forgery; they are instead only pointers to the potential that something may be amiss, and there may be various plausible alternative explanations for the apparent discrepancies highlighted. In other words, it is prudent to avoid jumping to conclusions about a document’s authenticity.

Metadata Analysis

Digital files typically contain metadata, or data stored in the file which is information about the file itself. Standard metadata can include information such as when a file was created and modified, where a file was created (such as the particular timezone and other regional information like language settings), who created and modified the file, and how a particular file was created (in terms of which software and hardware was used to create the file).

There are any number of ways to view the metadata of a digital file, but by far the most comprehensive tool for the job is ExifTool. Other tools may not display as much metadata as ExifTool does, or may not support as many filetypes. Once a file is loaded, ExifTool will display its available metadata. Here’s a sample ExifTool metadata readout for a file:

ExifTool Version Number         : 12.62
File Name                       : secretdocument.pdf
Directory                       : .
File Size                       : 57 kB
File Modification Date/Time     : 2023:05:15 00:19:16-04:00
File Access Date/Time           : 2023:05:15 03:12:03-04:00
File Creation Date/Time         : 2021:05:15 02:55:22-04:00
File Permissions                : -rw-rw-rw-
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : No
App Version                     : 16.0000
Author                          : Lana M. Darin
Comments                        :
Company                         :
Create Date                     : 2014:10:26 23:36:36-04:00
Doc Security                    : 0
Hyperlinks Changed              : 0
Links Up To Date                : 0
Modify Date                     : 2014:10:25 23:37:09-04:00
Scale Crop                      : 0
Share Doc                       : 0
Source Modified                 : D:20151025033602
Subject                         :
Language                        : EN-US
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.6-c017 91.164374, 2020/03/05-20:41:30
Metadata Date                   : 2014:10:26 23:37:09-04:00
Creator Tool                    : Acrobat PDFMaker 20 for Word
Document ID                     : uuid:3b5c3c80-47e6-3b0a-c0ad-68821188654e
Instance ID                     : uuid:3b5c3c80-47e6-3b0a-c0ad-68821188654e
Format                          : application/pdf
Title                           :
Description                     :
Creator                         : Lana M. Darin
Producer                        : Mac OS X 10.15.6
Page Layout                     : OneColumn
Page Count                      : 1

Now that you have the file’s metadata output, you can begin your authentication efforts. What you’re looking for is any inconsistencies in the metadata which may serve as red flags that the file could potentially be a forgery.

Dates

The metadata output for our sample file produced a variety of dates. The first three date fields– File Modification Date/Time, File Access Date/Time, File Creation Date/Time –are the dates when your copy of the file was modified, accessed, and created, respectively. If you downloaded the copy of the file yourself (for instance, from an email attachment), then the dates will be specific to the particular copy of the file you downloaded. For example, if you download the file once today and then again the next day, these three dates will now be different for the new copy of the file you downloaded, reflecting the data and time that you downloaded this new copy. As such, these three date fields are of limited utility when attempting to authenticate a document. These fields are only useful if you are analyzing a copy of the document that you did not yourself download or copy over–for instance, if you are viewing the metadata of files the source gave you on a USB stick.

The other four date fields in the metadata– Create Date, Modify Date, Source Modified, Metadata Date –are static metadata fields that will not change when you download a new copy of the same document, unlike the previous three data fields, as the dates in these fields are created by the PDF software used to create or edit the document. Even if you were to download a new copy of the same file, these metadata fields will stay the same. Being static, these four fields are usually more useful for performing a document analysis.

The key discrepancy to be on the lookout for when looking at the metadata dates of a given document is illogical inconsistencies. For instance, the date and time a document is modified should not be earlier than the date and time that the document was created. A document could not have been modified before it was created, as you first need to create a document before you can modify it.

In the sample document, you can see that while the Create Date field is 2014:10:26 23:36:36-04:00, indicating that the document was created on October 26 2014 at 23:36:36 in the GMT-4 time zone; on the other hand, the Modify Date field is 2014:10:25 23:37:09-04:00, which would mean that the document was modified almost a full day before it was first created. This is illogical, and therefore could indicate that someone attempted to modify the date the document was either created or modified, but forgot to make sure both date fields matched. However, an alternate explanation could be that someone’s system clock settings were malfunctioning. It is therefore crucial to keep in mind that such discrepancies may have alternate possible explanations, and don’t necessarily indicate a forgery or document manipulation.

Software

After comparing the dates themselves for inconsistencies, the next step in metadata analysis is to compare the software versions to the listed dates. For instance, in the sample document the XMP Toolkit field states that the software used to create the PDF metadata was Adobe XMP Core 5.6-c017 91.164374, 2020/03/05-20:41:30. In this case, the date this particular software was created is conveniently listed in the metadata. This is not always the case, and thus you may have to do a web search for all listed software in the metadata to find out when that particular version of the software was first released.

While the XMP Toolkit field states that the version of the software used to create this document’s metadata was made in 2020, recall that both the Create Date and Modify Date fields state that the file was created in 2014. It is highly suspicious that the version of the software used to create the file is six years older than when the file was ostensibly created–in other words, this version of the software didn’t exist until 2020, and could not have been used to create a file in 2014. While an alternative explanation could perhaps be that someone had very early access to a test version of the software, though even this explanation would be hard pressed to fully explain away a six-year discrepancy in the dates.

Hardware

Much like versions of software used to create a document can be cross-referenced with the dates in the document’s metadata, so too can the hardware. While the sample file doesn’t have any hardware listed, photographs or scanned documents will frequently have the model number of the camera or scanner used to create the document. As with identifying the software version’s date of release, perform a web search to see when a particular device or its particular model was first publicly released, and compare it to the document’s other date metadata. For instance, if you find that the document was created using a model of document scanner that was not released until a year after the document’s metadata dates list the file as first having been created, then this is a red flag that the document may be a forgery.

Operating System

Aside from the specific hardware and software used to create the document, the metadata may also indicate the particular operating system version used. Just like the hardware and software, the operating system may also be compared to the file’s metadata dates. In the sample document, the Producer field indicates that the document was created using Mac OS X 10.15.6. Performing a web search for this operating system version indicates that it was released on July 15 2020–years after when the file was ostensibly created in 2014.

Although slight discrepancies between the file’s metadata dates and the dates of the releases of the particular software, hardware, or operating system versions may be explained by the creator of the document perhaps having early access new versions of software, hardware models, or operating systems, large discrepancies spanning years are a big red flag that the document may have been tampered with.

Font Analysis

Now that you’ve analyzed some of the inconsistencies in the document’s metadata, you can move on to an analysis of the document itself. The particular fonts used in the document may aid in the dating of a given document.

The first step to date a document via font analysis is to identify all of the fonts used in the digital document. To do so, you can first open the document in its native program (for instance, Adobe Acrobat if the document is a PDF file, or Microsoft Word if the document is a DOC or DOCX file). In Word, you can then select various characters and see which font name is displayed. In Acrobat, you can go to the Fonts tab in Document Properties.

There may be times, however, when font information is not readily displayed in the file’s native application. For instance, if the digital document is a collection of page images from a scanner or camera, the fonts may not be readily identifiable. In such cases, a screenshot may be taken of a word or phrase in the document, and then run through a font identifier website, such as WhatTheFont or Font Squirrel’s Font Identifier.

For instance, let’s say that our sample document contains the word ‘INVOICE’:

Taking a screenshot of the word and uploading it to Font Squirrel’s Font Identifier results in the website stating that the font which matches that in the image is Spectral SC Regular.

Now that the name of a potential font is known, the next step is to identify when this font was created. Consulting a font information website, Fonts In Use, reveals that the Spectral font was released in 2017–three years after the file’s Create and Modify dates. This is therefore another red flag, as if the document is not a forgery it would mean that someone had access to a particular font three whole years before it was released.

A note of caution with font analysis, however, is that the various font recognition websites may misidentify the font, and may instead provide the name of another, similar font. It’s therefore important to consider all potential red flags together, instead of relying on a single one when determining a document’s authenticity.

Checklist

Here is a summative checklist of baseline digital document authenticity checks to undertake when attempting to determine whether a given digital document is a potential forgery. The more checks, the more red flags that the document may potentially be a forgery.

• Is the document’s creation date more recent than its modification date?
• Is the software used to create or edit the document more recent than the most recent date in the document’s metadata?
• Is the hardware used to create or edit the document more recent than the most recent date in the document’s metadata?
• Is the operating system used to create or edit the document more recent than the most recent date in the document’s metadata?
• Are any of the fonts used in the document more recent than the most recent date in the document’s metadata?

Working With Audio-Visual Leaks: Protecting Sources

Introduction

With the rise of remote video conferencing, more and more meetings and presentations are happening over digital platforms. It then stands to reason that you may be receiving more and more materials of surreptitiously recorded audio and or video of various events which may expose corporate or government malfeasance or other wrongdoings. Sources who send you these materials may do so at the risk of losing their jobs or facing legal risks. It is therefore paramount that the utmost caution be exercised when working with audio-visual leak materials so as to avoid inadvertently compromising a source.

This guide will go through some audio and visual clues to be on the lookout for which may reveal a source’s identity and which will need to be removed if you’re thinking of publishing the leaked materials, whether in whole or in part. There may be times, however, when it is ultimately safest to not publish the audio-visual content at all, but to instead only write about the recorded event; perhaps, only printing text transcripts or creating voice recreations if an audio-visual element is desirable for the story.

Audio Clues

There are a number of potential clues in the audio stream of a recording which may allow someone to identify the source who recorded the content in question. Carefully listen through the recorded material several times, being especially attentive to any stray background sounds in the recording.

Are there any notification chimes at any point in the recording? For instance if the person doing the surreptitious recording received text messages, emails, Slack messages, or any other notifications which trigger a sound while conducting the recording, it may be possible that these sounds may lead to identifying the recorder. For instance, let’s say that ten minutes into the recording of a meeting, there is an audible chime in the audio. You think nothing of it, and publish the recording as part of your story. When the company whose meeting was recorded is subsequently investigating the leak, their investigators will likely readily be able to identify that this particular chime means that a new email message had arrived in the inbox of the person doing the recording. Given that it’s known what time the meeting started, the investigators will subsequently be able to ascertain the approximate time the email message arrived. Investigators can then ask the IT team to look-up mail server records to see which staff member got an email at around that time, thus identifying who likely conducted the recording.

Though it may be possible to remove audio clues such as stray chimes, it should be kept in mind that investigators may nonetheless be able to identify the times in the audio when the sound has been muted, which may in turn lead them down the same investigatory path as above, such as seeing if any meeting participant received an email at the times corresponding to the timestamps in the recording when the audio drops out. It may therefore not be sufficient to simply mute stray sounds in the recording.

Similarly, any other background sounds may be used to narrow in on the potential identity of the leaker; such as, If there is recurring ambient noise that others at the company may be able to readily link to a particular staff member (for instance, if someone lives near the water and routinely has foghorns sounding in the background in other meetings).

If the recording is of an in-person meeting, how loud and quiet various people sound may allow investigators to form a pretty good idea of where the recording device was situated in a room, and therefore where the leaker was likely sitting, which may subsequently be further corroborated by consulting surveillance footage.

Visual Clues

Much like audio notifications may identify a leaker, so too can visual notifications. After going through the recording to identify and potential audio clues, you should repeat the process–this time focusing exclusively on any visual details. Be sure to focus exclusively on the video while performing the visual analysis, and watch the video at least twice with fresh eyes so as not to miss any fleeting visual indicators which may compromise a source. For instance, an email notification pop-up box appearing only for a split-second may be enough for investigators to be able to identify the person recording the event in much the same way as the audio analysis, by identifying who received a company email at that precise time.

If the recording is of a video conference with a number of panelists and attendees appearing in an array on the screen, the order of the participants may identify the recorder of the session. For instance, the popular video conferencing platform Zoom by default displays each participant as appearing at the top of the overall participant grid when they themselves view it. In other words, while you may see yourself at the top of a Zoom meeting, another attendee will instead see themselves at the top. This in turn means that if the entire attendee grid is visible in a recording, it may be possible to deduce which participant conducted the recording, as they will by default be situated at the top of the arrangement. For this reason, prior to recording a video conference, the attendee layout order should be randomized. Similarly, care should be taken to remove any portion of the video which may otherwise reveal who the recording party is, for instance by disabling Self View; one American politician failed to do so, leading to him being identified as a leaker of a private meeting

Even seemingly innocuous visual clues may lead to investigators being able to identify the source of a recording. For instance, indicators about which operating system the person recording the video conference was using may be used to deanonymize the source. For this reason, operating system indicators such as file menus should be cropped from the screen recording. Additionally, any other telltale signs of which operation system may be in use should likewise be excised from the video. These signs could be something as a fleeting mouse pointer visible on the screen, which can lead to operating system identification as, for instance, while the default mouse pointer on Windows operating systems is a white mouse with a black outline, on Mac systems it is the opposite–a black mouse with a white outline. If the majority of staff are known to use the Mac operating system, but a white mouse is visible in the recording, it may be possible for investigators to narrow in on who conducted the recording, as only a few staff are known to use Windows.

Just like the recording should be repeatedly analyzed for any potentially-deanonymizing audio clues, it should likewise be watched several times to lessen the chance that any visual clues remain in the recording.

Watermarks

Aside from inadvertent audio-visual clues in recorded material potentially being mobilized by investigators to identify the source of a leak, the material may also have intentional identifiers placed into it, in the form of watermarks. For instance, Zoom has the capability to insert both image watermarks which add the participant’s email address over the meeting video, as well as ultrasonic acoustic watermarks into their meeting audio streams. Though the visual watermarks are overt and readily visible, the acoustic watermarks are imperceptible to the naked ear, but when run through an identification algorithm may readily reveal which meeting attendee conducted the recording.

While Zoom does nonetheless present an overt indicator that a meeting has acoustic watermarks enabled–in the form of a green audio icon with a padlock () which appears on the top-left of the meeting screen next to the encryption shield icon, and displays the text ‘Audio signature enabled’ if hovered over,–it may be possible that future versions of Zoom remove this visual indicator, and that other video conferencing platforms don’t display one at all. Nonetheless, a source video should always be analyzed for the presence of this watermark indicator, and if it is not visible owing to cropping or the source only supplying an audio recording of the meeting, the source should be asked about whether they recall seeing this indicator during the meeting.

Zoom is by no means the only video conferencing platform that allows for the embedding of identifying watermarks in a meeting; for example, Webex also offers meeting hosts the option to add “unique inaudible identifiers” to meetings, which Webex claims are “nearly insensitive to added noise, audio compression, filtering, and noise suppression processing techniques.”

Source Device Identification

Source camera identification is the forensic practice of identifying the camera used to take a particular image or video. Investigators may be able to identify the source device based on either subtle clues like a smudge or a stray dust particle or dead pixel, or through more technical analyses of digital signal imperfections in the image which are not visible to the naked eye. Investigators may then be able to match these singularities to other videos taken with the same device, potentially identifying the leaker. For instance, investigators may look through the social media accounts of suspected leakers–broadening the search to the accounts of all staff, if necessary–to potentially identify if any other videos or photos posted by a given account match the unique imperfections found in the leaked video.

Audio source identification is the similar practice of identifying the device used to record audio.

Metadata

Metadata is information contained in a file about the file itself. For audio-visual files, metadata may include information such as the date, time, and timezone the recording was created, which hardware equipment and/or software was used to create the recording, as well as other potentially-identifying information such as the name, username, or email address of the person doing the recording. Two effective programs for viewing audio and video metadata are ExifTool and MediaInfo.

Metadata may be introduced into the audio or video file both by the source at the time the recording was made, as well by your newsroom’s editing team when working on editing the materials. It is therefore imperative to always run any media files through both ExifTool and MediaInfo prior to uploading them online (even in draft form), so as to make sure that there is no information in the file’s metadata which could deanonymize a source or otherwise leak non-public information. Not performing a thorough metadata inspection on audio-visual materials prior to publication may lead to inadvertent exposure of personally-identifiable information which may place people in danger. For instance, the New York Times failed to remove metadata from phone recordings, and ended up exposing the phone numbers of various people.

It’s important to keep in mind that much like a PDF document composed of page images may have its own metadata as well as the metadata of all of its component images, so too can the individual files inside a video file contain their own metadata. For instance, a video file which contains an audio file may have metadata both for the video file itself and for the individual audio file. It is therefore important to ensure that all metadata is thoroughly removed.

If the ExifTool or MediaInfo analysis indicates potentially-identifying metadata as being present in the audio track, video editing tools such as FFmpeg or Avidemux may be used to extract the audio file, and an audio editing tool such as Audacity may then be used to create a new audio track devoid of potentially-identifying metadata, before utilizing avidemux or FFMpeg once more to add the new audio track back into the video,.

Recreation Instead of Publication

Owing to the fact that the above list of potential red flags to watch out for is both not exhaustive and is constantly evolving, as well as the fact that all it takes is one potential mistake in the handling of sensitive audiovisual materials to inadvertently allow for the deanonymization of a source, the safest approach when dealing with audiovisual recordings is to avoid publishing the original recording.

Instead of publishing the original recording, simply write about the information in the meeting, using select text quotations, if need be. If it is desirable for an audio-visual component to nonetheless accompany the story, consider recreating the audio by having someone else read a transcript of the meeting, and recreating any visual elements such as slides.

However, keep in mind that if the meeting in question had a sufficiently small attendance, even writing about the meeting may lead to the source being identified. Furthermore, the more meetings a source provides, it may be more likely for investigators to identify them, as the investigators can then compare attendance lists for all of the leaked meetings to identify common attendees across all of the leaked meetings, potentially narrowing the suspect pool.