Every trip is unique and poses individual 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 origin or transfer ports involved in the trip. That being said, there are nonetheless baseline digital security considerations which generally apply to most travel.
Digital security precautions, by their very nature, are usually at odds with ease of use: the more secure a process is, the more laborious it can be to implement that process. A successful digital security protocol balances usability with security, with the underlying understanding being that the trade-offs made in sacrificing some usability are ultimately less detrimental than the consequences of not implementing the suggested security measures. For instance, it is more cumbersome to have to lock the door to your house–necessitating the purchase of a lock, taking the time to use the lock, not forgetting your keys, and so on–than to simply leave the door unlocked. Yet despite this, most people nonetheless lock their door, as the advantages of doing so outweigh the consequences of leaving the door unlocked. Think of the following digital security recommendations in a similar light.
It’s up to you to decide which digital security measures to implement while traveling, but keep in mind that the overarching 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.
When traveling on assignment, your personal or work devices should not be traveling with you, they should remain at your work, home, or other secure location. Instead, you should bring what are known as “burner” devices: cheap, disposable devices to be used for the duration of the trip and the loss or compromise of which will not pose a significant risk to you, your newsroom, or your sources.
Prior to your trip, obtain burner devices which you will need to use during the trip. Keep in mind that this extends to not just a phone and laptop, but to any other devices and related peripherals you may need such as a camera or voice recorder, if you’re planning to use separate equipment aside from your phone for doing audiovisual recordings. Though if your additional devices use removable storage media, it may be sufficient to simply bring new, empty flash memory cards for these devices, instead of an entirely new device
If you are reusing burner devices which have previously been used by you or someone else, make sure you “reformat” or “reset” the devices prior to use. You can readily find instructions for how to do so for various models of hardware. Reformatting or resetting the device helps ensure that there is no easily-recoverable past data on the device.
When acquiring burner travel devices, if possible also acquire privacy screens for the devices, which minimize the visibility of your device screens to on-lookers. 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 burner 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 innocuous 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.
Thus, every effort must be made to procure burner devices and leave your regular devices which may contain sensitive information at home. However, if you cannot immediately obtain burner devices, you should nonetheless at the least follow the rest of the suggestions in this guide (for instance, setting up burner accounts and logging out of your regular accounts).
Much like you should leave your personal and work phones behind, you should also leave your SIM card behind. When acquiring your burner phone, make sure that the phone will be compatible with the SIM card you’re acquiring. You should look for either an ‘unlocked’ phone, or purchase the phone and SIM card from the same vendor to assure compatibility.
You can purchase a SIM card either before embarking on your trip or after arriving at your destination. There are advantages and disadvantages to both workflows, depending on the particular circumstances of your trip. For instance, an advantage of acquiring your SIM card prior to your trip is that you can perform regular safety check-ins with your point of contact before and after going through security checkpoints. If you don’t plan on acquiring a SIM card until after arriving at your destination, you will not be able to perform these check-ins.
On the other hand, an advantage of acquiring your SIM card after arriving at your destination is that you will be able to verify that your SIM card works in the region. However, a potential disadvantage of acquiring the SIM card in-region is that the region may have specific laws about having to provide identification and needing to register your SIM card with the local authorities.
For these reasons, the general ideal workflow is to purchase a SIM card in advance of your trip, and to then plan to purchase an in-region SIM card if the previously purchased one is not working in-region.
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. Much like you need to acquire burner hardware devices, create burner accounts for services you will need to use on your devices while traveling. For instance, you will likely need to login to your phone’s app store to be able to download various apps. For this purpose, you should not log in with your standard accounts, but create accounts to use while you are traveling and log into those.
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, not while en-route. Do not check your usual accounts while at or approaching your port of entry such as at the airport or train station. Additionally, it may be best to use a trusted VPN when accessing sensitive accounts, whilst keeping in mind that VPN traffic may also draw unwanted attention to yourself.
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). Perform a web search prior to your trip to attempt to find any news or community discussions of the usability of apps you need to use at your destination, as well as ask any sources or region experts.
Make sure that you are using a trusted VPN app (which has gone through third-party security audits) during your trip, and that the app you are planning on using is not blocked in-region.
Additionally, be sure to have back-up apps pre-selected (especially for your chat and VPN apps) to switch to in case you find that your primary apps are not working in-region.
Do not have any potentially sensitive apps installed on your burner 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.
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. Check-ins should be done both prior to arriving at any security checkpoint to let your contact know that you are approaching a checkpoint, and after you have passed through the security checkpoint to let your contact know that you have done so successfully.
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) as well as contacting an attorney.
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 the real names of the sensitive sources.
When communicating with sensitive sources, use an encrypted messaging app with disappearing messages enabled.
Any sensitive information, especially that which could compromise sensitive sources, should not be stored on your travel devices, especially not while you are actively traveling through checkpoints and points of entry. Instead, sensitive information should be encrypted and then stored in a cloud account, and accessed once you have successfully passed through a checkpoint and have left your port of entry. The sensitive information may be encrypted using cloud encryption tools such as Cryptomator, which encrypt data prior to uploading it to a cloud storage account.
Passwords to your regular accounts which you will need to access during your trip should be stored in a ‘travel mode’ in your password manager. If your password manager doesn’t offer a travel mode, essential regular accounts should be moved to a separate password manager account. The purpose of keeping needed regular account passwords separate from all of your regular account passwords is that in the event of compromise, you will minimize the amount of passwords exposed. Passwords to your travel accounts should be stored in a separate password manager account altogether, with this being the main account you should use during travel.
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 compromised and proceed to obtain new devices. Store the potentially compromised old devices in your suitcase, in case the devices have been implanted with surveillance capabilities.
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 cannot maintain a line of sight with your devices, you should operate under the assumption that when and if your devices are handed back to you that they have been compromised. Once you have left your port of entry, obtain new in-region devices as soon as possible.
Authorities may ask or compel you to unlock your devices. Noncompliance with this request may result in your devices being seized, as well as you also being taken into custody, depending on the region you are traveling to. For these reasons, seeing as how you should be traveling with burner devices with no sensitive information present on them, it may be in your best interests to readily comply with a request to unlock your travel devices.
Keep in mind that all of the precautions outlined here apply not just to your inbound trip, but to your trip back to your origin point, as well. For instance, prior to 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, reformat or reset your travel devices prior to leaving for the port of exit (for instance, 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 using your encrypted cloud storage app on at least a daily basis, and make sure they are deleted from your local device.
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 “burner” travel devices, such as:
- Privacy screen
- SIM Card
- Privacy screen
- Camera (or new memory card)
- Voice recorder (or new memory card)
- Setup burner 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.
- Setup encrypted 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 and store the old devices in your suitcase.
- When crossing a border checkpoint:
- If line of sight is broken with devices, assume devices compromised when returned, and obtain new devices.
- If asked, provide passwords to burner devices and burner accounts (having made sure no sensitive information is viewable).
- Follow this protocol not just for your outbound trip, but also for the return trip.
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.
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
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
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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 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 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,.
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.