Share Link Forensic Artifacts: What a Share Link Records, and What It Doesn't

When a file moves by cloud share link and someone later asks who opened it, there is usually a record. The record is not nothing. It is also not what most people picture when they hear the word “log.”

Box, to take the platform at issue in the case below, records shared-link activity as discrete events: a link being enabled, a link being emailed, a preview, a download. Those events are queryable through the enterprise events API [1 ]. So an examiner asking “was this folder accessed” has a real answer available.

The examiner asking “by whom” gets a different kind of answer. When the access came through an open shared link, Box’s documentation, as accessed on 9 August 2026, notes that the event feed may carry a user ID of 2, its internal identifier for anonymous users [1 ]. It is a vendor implementation detail and could change. That is the whole finding, rendered as an integer. Something happened. A number sits in the field where a person should be.

Share link forensic artifacts are worth understanding precisely, because the gap between “an access was recorded” and “a person was identified” is where a great deal of litigation actually lives.

The Fact Pattern That Made This Concrete

The plaintiff was Harleysville Insurance Company, seeking a declaration that it owed no coverage for a funeral home fire. In September 2015, a senior investigator for Nationwide Insurance, which owns Harleysville, uploaded a video about the fire to a Box folder and emailed the sharing link to a contact at the National Insurance Crime Bureau. Seven months later, in April 2016, he uploaded the entire claims file and the entire investigation file to that same folder, and sent the link to counsel. The folder was a “publically accessible, non-password-protected website” in the magistrate judge’s words [2 ], and no expiration had been set on the link, which is why it still resolved seven months later and why the district judge described the investigator’s contrary belief as erroneous [2 ].

In May 2016, the National Insurance Crime Bureau responded to a subpoena from the opposing party by producing the documents it had received, including the email carrying the link. Opposing counsel followed the link and downloaded everything in the folder, privileged material included.

The court’s disposition, which is background here rather than the subject: a magistrate judge found the privilege waived, and on review District Judge James P. Jones reversed as to the attorney-client privilege, vacated the monetary sanction that had been imposed on the receiving party’s counsel, and instead barred them from using the privileged material or anything derived from it to seek further discovery, by subpoena, or in any other manner [2 ]. The waiver question has been written about at length by people better placed to write it. What follows is the forensic question underneath it.

Two notes on scope before going further. This analysis is drawn entirely from the published opinion and from vendor documentation, all of it cited below; Lucid Truth Technologies had no involvement in the matter and no access to anything outside the public record. And this is forensic observation, not legal advice. Nothing here creates an attorney-client relationship or tells anyone how to conduct a case.

The Blind Interval

Nobody on the disclosing side knew anything from May 2016 until late October 2016. Not that the folder had been accessed. Not by whom. Not what had been taken.

The disclosure surfaced by accident. In August 2016, the receiving party produced discovery on a thumb drive. On October 27, 2016, while reviewing that production, counsel for the disclosing party found its own claims file sitting on the drive in a folder labeled “NICB Video,” among thousands of other documents [2 ]. Five days later, on November 1, they demanded destruction. The material had already been reviewed.

Two observations are worth stating plainly.

Detection came from downstream reuse of the material, not from any monitoring of the share itself. Nothing about the sharing mechanism produced a signal. The signal came from the other side’s own production, months later, and only because someone read it carefully.

The production layout became evidence in its own right. Judge Jones noted the subfolder was “misleadingly named,” observed that the email’s actual subject line was “video” rather than “NICB Video,” and concluded that the folder names had therefore not been auto-populated. From that he drew an inference: counsel chose the name “despite knowing that the folder included far more than a video,” and the inaccurate label “supports an inference that Insureds’ counsel wished to conceal its possession of the Claims File” [2 ]. Folder structure is discoverable evidence, and a court will draw inferences about intent from how a production is arranged. That is worth knowing on either side of a case.

Five months of silence is a telemetry failure.

What the Provider Actually Recorded

An examiner working this fact pattern would go looking in a specific order.

Provider side first. Box records shared-link events discretely, including link creation, an email being sent with a link, previews, and downloads, and multiple content-access events can be logged for a single user action [1 ]. Retrieval requires an enterprise admin or co-admin with reporting permission, which is a practical constraint worth planning around: the person who can run the query is often not the person who needs the answer.

Source IP may be present in the event record. It is the only pivot available toward attribution when the accessing identity is anonymous, and it carries every limitation covered in our discussion of IP address evidence in criminal investigations .

Then the identity field, which is where this stops being a records question and becomes a forensics question. An access through an open shared link is recorded, and it is recorded without a person attached [1 ]. The platform can tell you a fetch occurred. It cannot tell you whose hands were on it.

That is precisely the property examined in our companion piece on cloud storage evidence attribution , where the same technical fact appears as an evidence problem: a link is not an identity. Here it appears as a detection problem instead. One fact about how cloud sharing works, two different ways it hurts.

Where the Rest of the Record Lives

When the provider side runs out, three other places hold artifacts.

The email path is the durable one, and in this case it was decisive. The link survived in a third party’s mailbox and was recovered by subpoena. The folder’s configuration was ephemeral; the email was not. Available from that path: headers, message identifiers, timestamps, the recipient list, the confidentiality footer, and any downstream forwarding. It follows, and it is worth stating as a rule of thumb, that a share link is only as controlled as every mailbox it has ever touched.

The recipient endpoint holds the next layer. Browser history and cache showing navigation to the link. Download provenance markers, where they survive: a Zone.Identifier alternate data stream on Windows generally carries a zone, and may or may not carry ReferrerUrl and HostUrl depending on the browser and its version, while com.apple.quarantine on macOS is not applied universally and is stripped by a number of transfer paths. The downloaded files themselves, whose file system timestamps may reflect the download rather than the original authoring, which is the same capture-time versus write-time distinction covered in file timestamp pitfalls . That one is worth checking rather than assuming: a bulk folder download arrives as an archive, and extraction commonly preserves the original modified times. Sync client databases, if the material was pulled into a synchronized folder.

Production media holds the last layer and the weakest one. A thumb drive carries file system metadata, folder structure, creation and copy timestamps, deleted-file remnants, and prior volume history. The media itself records no access at all. Attribution then depends entirely on endpoint artifacts, which may or may not exist: USB device registry entries, LNK and jumplist records, shellbags, prefetch, and any DLP or endpoint telemetry the organisation happened to be running. Where none of those survive, the question of who read it has no technical answer.

Then there is where reconstruction goes dark, and an honest examination says so out loud. Whether a specific human opened the folder. Whether the link was forwarded beyond the known recipients. Whether anyone else ever followed it. Absent server-side identity, those are not hard questions. They are unanswerable from the record.

Entropy Was Never the Vulnerability

The opinion contains a genuinely interesting piece of technical reasoning, and it is worth engaging on its own terms.

Judge Jones observed that although anyone knowing the URL could reach the folder without a password, “the URL itself functions as a password.” He then did the arithmetic: the link was a string of 32 characters drawn from an alphabet of 36, giving 6.3340287 x 10^49 possible sharing links. “The security of the Box Folder, then, is inherent in the nature of the URL.” He rejected the magistrate judge’s image of a briefcase left on a public park bench and offered his own instead: a briefcase “buried somewhere in a large park, technically publicly-accessible, but for all practical purposes, secured” [2 ].

The arithmetic is correct. The space is not searchable by brute force, and the court found nothing to suggest the folder was ever indexed or stumbled upon.

It is also beside the point, and the judge’s own metaphor shows why. A briefcase buried in a large park is perfectly secure against anyone searching the park. It offers nothing at all against someone handed the map. The threat model for a capability URL is disclosure of the URL, not discovery of it. The disclosure at issue did not occur by brute force, crawling, or cracking. It occurred because the link was subpoenaed out of a third party’s mailbox and handed over.

The general form: a capability URL is a bearer token. Whoever holds it is authorized, without question and without attribution. Every property that makes bearer tokens convenient for sharing makes them opaque afterward. Entropy defends against the search attack. The disclosure attack is the one that actually happens, and entropy has nothing to say about it.

Revocation Is Narrower Than It Sounds

It is tempting, and wrong, to conclude that share links cannot be revoked or logged. Both claims are false, and the record in this case contradicts the first directly. The court noted that a review of Box’s website showed such security precautions were available, and found that the investigator, in the opinion’s own words “inexperienced with the Box, Inc. service and who lacks a technical background,” believed he was implementing them [2 ].

The accurate constraints are narrower and more interesting than the myth.

Revocation was opt-in and off by default in the configuration this record describes. That is a product decision rather than a technical limit, and it is the kind of default that changes: any team relying on it should check what their own tenant does today rather than what a 2017 opinion describes.

Revocation is all-or-nothing. With no recipient identity attached to a capability URL, one holder cannot be cut off individually. Killing the link cuts off everyone. Per-user permissions revoke a person; a capability URL can only revoke the capability.

Revocation presupposes knowing you need to revoke. This is where the case actually turned. The investigator believed the link he had sent seven months earlier had already expired, reasoning by analogy to his company’s encrypted emails, which expire within five to ten days after being sent [2 ]. He mapped the expiry behavior of one mechanism onto an entirely different one. That transference is the human failure worth naming, and it is a failure no amount of cryptography addresses.

Revocation is prospective only. It does not reach copies already downloaded, and it does not reach the link sitting in a mailbox that is subpoenaed a year later, which is the exact path the disclosure took here.

What Each Sharing Method Leaves Behind

The useful way to compare distribution methods is not by how each one fails, but by what each one leaves behind for reconstruction afterward.

Taking the bottom rung and the top rung in turn: physical media is self-explanatory, and the disclosure-portal row is worth sourcing precisely. Axon Justice records an audit trail per item covering upload, update, share, and delete [3 ], and its published disclosure-portal documentation, as accessed on 9 August 2026, states that “[e]vidence remains accessible in the disclosure portal is 90 days from the last shared date,” that “[t]his date is recalculated if additional evidence is received during the 90-day period,” and that “[i]f 90 days elapse and no additional evidence is received, the case and evidence are deleted” [4 ]. Vendor documentation changes; that is the wording on the date given.

The ladder is the argument. Each rung up trades some convenience for a record, and the record is what makes reconstruction possible later. Note also that the bottom of the ladder and the top differ on defaults as much as on capability: the disclosure portal expires access unless someone acts, while the unauthenticated link persists unless someone acts.

Nothing Expired. Nobody Asked.

There is an obvious lesson here about retention windows, and it is the wrong lesson on these facts.

Provider retention is real and it is finite. Google Workspace holds Drive log events, the row that matters for file sharing, for six months, the same figure it gives for admin and login events, and keeping any of it longer means exporting it [5 ]. Microsoft’s Audit (Standard) retains records for 180 days, with one year for certain workloads under Audit (Premium) and appropriate licensing, and up to ten years for organisations holding the separate ten-year audit-log retention add-on. That last option is worth knowing about and worth not over-reading: it is not retroactive, so it reaches only what was logged after the policy was created [6 ]. Those clocks run from the event, not from the day someone thinks to ask.

But Box is more generous than either. Box’s developer documentation, as accessed on 9 August 2026, states that one year of enterprise events is available through the API and seven years through exported reports in the administration console [1 ]. On this fact pattern, nothing expired. The provider-side record of who fetched what, and when, almost certainly outlived the entire dispute.

That is a more uncomfortable conclusion than a missed deadline. The evidence was there the whole time. Five months passed before anyone knew there was a question, and the question only arose because a document turned up in the other side’s production. A retention window cannot help you when the problem is that nobody knew to look.

The practical consequence survives intact, and sharpens. Shared-link access events are a distinct record type from file contents, held under their own retention rules, and a preservation demand framed only around contents may never reach them. Whether and how that distinction is drawn in a given instrument is counsel’s call; the forensic point is only that the two are not the same record. For the legal process side of obtaining provider records, see our guide on how to subpoena cloud provider data .

Questions Counsel Should Ask

Put these to the examiner, whichever side you are on.

• Were shared-link access events specifically preserved and requested, as distinct from file contents?
• Does the provider’s event record name an actor for the accesses at issue, or does it record an anonymous user?
• What source IP addresses appear in the access events, and what do they narrow?
• Was the link ever password-protected, expiration-limited, or restricted to named collaborators, and when did each setting change?
• How many recipients ever held the link, counting every mailbox it was forwarded to?
• Was other content added to the shared folder after the link went out, and when?
• What endpoint artifacts exist on the receiving side: browser history, download provenance markers, sync databases?
• If material arrived on physical media, what does the folder structure itself show?

If the answers rest only on the presence of the files, the reconstruction is thinner than it sounds.

What This Analysis Changed About Our Own Practice

Candor is owed here, because it would be easy to write this section as though we had always known better.

We have sent unauthenticated share links to known recipients. Not carelessly, and not to anyone who should not have had the material, but as the ordinary way of moving a large file to a lawyer who is expecting it. In every such case the link was revoked shortly after the recipient confirmed receipt, and every production was hashed and manifested, so the window in which the link was live was short and the contents were fixed. Working through this case changed our assessment of it anyway, because a short window is still a window, and a revocation still tells you nothing about who walked through it first. What follows is our practice from here, and we are stating the change rather than presenting it as settled habit.

One of these was already how we worked: hash and manifest every production, because a manifest is the access log that physical media does not otherwise have.

Three are changes.

One folder per recipient per purpose, and never add content to a folder whose link has already gone out. This is the discipline whose absence caused the disclosure in this case, and the court said so directly: had the video and the claims file been stored in two separate folders, “the disclosure would never have occurred” [2 ]. The failure mode is not the link. It is the folder outliving the purpose the link was created for.

Expiration and password on by default, and named-collaborator sharing in preference to link sharing whenever the recipient list is known. The reason is not that links are insecure. It is that a named-collaborator share produces an identity in the access record, and an unauthenticated link produces an integer.

Verify expiry against the platform rather than inferring it from another tool’s behaviour. The investigator here was wrong about a setting, not careless with a file, and nothing in his workflow could have told him so.

That last point generalises past our own practice, and it is worth saying to anyone who handles links in a matter. A link’s apparent state is not evidence of its actual state, and a link’s provenance is not evidence of its safety. This is the same reflex that good phishing hygiene asks for: the fact that a link arrived from someone you know, in a thread you recognise, tells you nothing about where it now goes or who else can follow it. Check the platform, not the assumption.

The same hygiene covers the receiving end, and it is worth stating as advice rather than as anyone’s policy. Do not follow a link you were not given a reason to have. If you follow one and land somewhere you should not be, stop reading, record what happened, and tell counsel in writing, promptly. The instinct to keep scrolling is the expensive one, and in this matter it is what turned an inadvertent disclosure into a sanctions fight.

There is exposure running the other direction that experts should sit with, and it is an extrapolation rather than a holding. No expert opinion was excluded in this matter; the restriction ran against counsel, and it was evidentiary, barring use of the material and anything derived from it, with a certification requirement that future work rest on independently obtained information [2 ].

Conclusion

The cryptography was sound. The controls existed and were available on the platform. The disclosure happened anyway, because the entire arrangement depended on one person’s mental model of the tool being correct, and nothing in the system was positioned to tell him it was not. No signal that the link was still live. No signal that a second audience still held it. No signal that anyone had opened the folder.

Good security and observable security are not the same property, and only one of them survives contact with a discovery dispute. The forensic question is never whether the link was strong. It is what the link wrote down, how long that record lasts, and whether anyone will think to ask for it while it is still there.

Several products are named above. Box, Google, Microsoft and Axon are discussed because they are what the record and the documentation describe, and the disclosure-portal row sits at the top of the ladder on the strength of its published behaviour rather than any view of the vendor. Lucid Truth Technologies has no commercial relationship with, and receives no compensation from, any company named in this post.

Lucid Truth Technologies reconstructs how digital material actually moved, tests the artifacts that are claimed to prove it, and says plainly where the record runs out. If a matter in your office turns on who received something and when, contact us to discuss it.

References

[1] Box, Inc., “Get Enterprise Events,” Box Developer Documentation. [Online]. Available: https://developer.box.com/guides/events/enterprise-events/for-enterprise/

[2] United States District Court for the Western District of Virginia, Harleysville Insurance Company v. Holding Funeral Home, Inc., No. 1:15-cv-00057, Opinion and Order of District Judge James P. Jones, Oct. 2, 2017 (W.D. Va. 2017). [Online]. Available from the court: https://www.vawd.uscourts.gov/OPINIONS/JONES/1-15cv00057 privilege-sanctions.pdf . Also available as Document 108 via Justia .

[3] Axon Enterprise, Inc., “Evidence audit trail,” Axon Justice Product Guide. [Online]. Available: https://www.axon.com/help/justice/software/justice/evidence/manage-evidence/evidence-audit-trail.htm

[4] Axon Enterprise, Inc., “Disclosure portal,” Axon Justice Product Guide. [Online]. Available: https://www.axon.com/help/justice/software/justice/evidence/manage-evidence/disclosure-portal.htm

[5] Google LLC, “Data retention and lag times,” Google Workspace Admin Help. [Online]. Available: https://knowledge.workspace.google.com/admin/reports/data-retention-and-lag-times

[6] Microsoft Corporation, “Manage audit log retention policies,” Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies