In re Uber Techs., Inc. Passenger Sexual Assault Litig.
In re Uber Techs., Inc. Passenger Sexual Assault Litig.
2025 WL 678543 (N.D. Cal. 2024)
March 3, 2025

Cisneros, Lisa J.,  United States Magistrate Judge

Failure to Produce
Hyperlinked Files
Email Threading
ESI Protocol
Cloud Computing
Metadata
Download PDF
To Cite List
Summary
The Court addressed and resolved disputes between the parties regarding the production of hyperlinks in Uber's document production, including issues related to metadata, non-Google Drive documents, and email threading. The Court emphasized the importance of considering technological feasibility in producing ESI and ordered the parties to meet and confer on protocols for future requests and productions.
Additional Decisions
IN RE: UBER TECHNOLOGIES, INC., PASSENGER SEXUAL ASSAULT LITIGATION
This Document Relates to: ALL CASES
Case No. 23-md-03084-CRB (LJC)
United States District Court, N.D. California
Filed March 03, 2025
Cisneros, Lisa J., United States Magistrate Judge

ORDER REGARDING DISCOVERY LETTER BRIEF REGARDING HYPERLINKS Re: Dkt. No. 2194

The parties filed a Joint Letter (Dkt. No. 2194) raising several issues related to hyperlinks in Uber’s document production. The Court heard argument at a Discovery Status Conference on February 27, 2025. The Court now addresses and resolves the issues raised in the Joint Letter as follows.

As an overarching question, many of the parties’ disputes here implicate the ESI Protocol filed on May 3, 2024 as Dkt. No. 524. Before the Court approved the ESI Protocol, the parties disputed whether a hyperlinked document, such as a cloud-based document in Google Drive, constitutes an attachment. The Court determined that a hyperlinked document is an attachment, for purposes of the ESI protocol in this litigation, because it is akin to a traditional email attachment, where the email message and hyperlinked document reflect a single communication at a specific point in time. See Dkt. No. 511 at 3, 10-11. Accordingly, the ESI Protocol treats hyperlinks as “attachments,” but does not require Uber to provide contemporaneous versions of all hyperlinks:

h) “Attachment(s)” shall be interpreted broadly and includes, e.g., traditional email attachments and documents embedded in other documents (e.g., Excel files embedded in PowerPoint files) as well as modern attachments, pointers, internal or non-public documents linked, hyperlinked, stubbed or otherwise pointed to within or as part of other ESI (including but not limited to email, messages, comments or posts, or other documents). This definition does not obligate Uber to produce the contemporaneous version of Google Drive documents referenced by URL or hyperlinks if no existing technology makes it feasible to do so.  

Dkt. No. 524 at 3.

In this litigation it has been established that it is technologically feasible for Uber to produce contemporaneous versions of Google Drive files (Google Docs, Sheets, etc.) stored in the normal Google Drive cloud storage system when linked in an email, but it is not technologically feasible for Uber to automate the production of contemporaneous versions when Gmail messages and hyperlinked Google Drive files have transitioned to the Google Vault storage system. At least for Google Drive hyperlinked email attachments, the ESI Protocol requires Uber to provide metadata linking the hyperlinked document to the email where it is referenced. E.g., Dkt. No. 524 at 32 (requiring production of a “LINKBEGBATES” metadata field listing “the beginning Bates value for any Google Drive linked documents referenced within a given Gmail document”). The lesson from the Court’s prior order, which bears on the current dispute, is that while attachments are broadly defined to include hyperlinks, the production of all hyperlinked documents is not required in light of the pervasive technical challenges.

A. Issue 1: Hyperlinks to Non-Google Drive Documents

Plaintiffs seek at least metadata, and perhaps also production of the underlying documents, for hyperlinks that reference resources other than Google Drive documents. Uber contends that this is not required by the ESI Protocol (which instead focuses on Google Drive hyperlinked attachments), while Plaintiffs argue that it falls within Uber’s obligation to provide sufficient metadata to establish parent-child relationships between documents and their attachments. Uber also presents evidence that currently the production of hyperlinked non-Google Drive documents is not technologically feasible at scale. Dkt. No. 2194-9 (Anderson Decl.) ¶¶ 10, 14–20; Dkt. No. 2194-10 (Brown Supp’l Decl.) ¶¶ 17–22. Plaintiffs do not dispute the evidence or argue otherwise.[1] See Dkt. Nos. 2194 at 3; 2194-8 (Forrest Decl.)

To support their demand that Uber preserve and produce metadata for all links, regardless of whether they link to Good Drive documents, Plaintiffs rely on an ESI Protocol provision that states, “Defendants shall use methods of collection and processing that preserve . . . the association between attachments and parent documents.” Dkt. No. 525, App’x 1, ¶ 4. The ESI Protocol also provides that Uber’s document production must preserve the URLs of hyperlinks:

. . . Documents containing hidden URLs, e.g., an email containing a link where the text of the link is not the URL (for example, a link with the displayed text “Please review this article” where the URL of the link, e.g., https://somesite.com/somearticle.html/” is not itself the display text of the link) should be processed such that all hidden URLs are included in the extracted text.

Dkt. No. 524 at 23. Uber represented at the February 27, 2025 Discovery Status Conference that it has complied with that requirement, and Plaintiffs did not dispute that assertion.

Even if the ESI Protocol could be read as requiring metadata, beyond the URL for hyperlinks to non–Google Drive documents, there is no obligation where it is technologically infeasible for Uber to do so at scale. Uber cannot use a method of collection and processing that preserves a certain metadata relationship, if the method does not exist. Furthermore, it is not clear what metadata fields Plaintiffs seek, and which metadata fields Uber must provide under the ESI Protocol for hyperlinked non-Google Drive files that can be collected and produced by Uber in an automated fashion, if any.[2] 

Instead, where Plaintiffs believe a particular hyperlink is potentially relevant and further information besides the URL is necessary, Plaintiffs may ask Uber to produce the hyperlinked document, or to identify its Bates number if already produced. If the linked document has already been produced, Uber must identify it by Bates number. If the linked document has not already been produced, Uber must produce it if it is relevant to the case or to a reader’s ability to understand the document that links to it (and is not privileged or otherwise protected from disclosure). Uber need not produce documents for hyperlinks to public websites.

The parties are ORDERED to meet and confer as to a protocol for such requests, and to file either a stipulation or joint letter no later than one week from the date of this Order. Such a protocol may include a limit on the number of requests Plaintiffs may make if the parties believe that is appropriate. If there is a dispute as to the number of requests to allow, the Court is inclined to allow a large number.

Separately, the parties are also encouraged—but not required—to consider whether it is technologically feasible to include further useful information regarding hyperlinked non–Google Drive documents in future document productions, and whether doing so would be more efficient than providing such information through case-by-case requests.

B. Issue 2: Hyperlinks Within Non–Google Email Documents

Plaintiffs contend that Uber has not been producing documents or metadata (other than URLs) for hyperlinks that appear in documents other than emails sent through the Google Gmail platform, which the Court understands to be Uber’s internal email system.

As Uber acknowledges, the ESI Protocol requires Uber to produce hyperlinked documents that appear in communications. See Dkt. No. 524 at 16–17 (¶ 17(a)–(b)). Even if the ESI Protocol required more, namely the production of documents hyperlinked in documents other than communications, Uber has presented undisputed evidence that this is not feasible using Google Vault or a third-party tool. See Dkt Nos. 2194-9 (Anderson Decl.) ¶ 24, 2194-10 (Brown Supp’l Decl.) ¶¶ 17–18. The Court’s prior discussion of Google Parser (a tool developed by Uber’s ediscovery vendor) described this tool as capable of extracting specific links to Google Drive documents from Google email messages and chats, and certain metadata, Dkt. No. 511 at 2. Plaintiffs have not since presented any evidence that it is technologically feasible to automate the production of hyperlinks within non-Google emails or chats, though one of Uber’s declarants noted that Microsoft Purview facilitates the collection of linked documents as part of a message collection. Dkt. 2194-10 (Brown Supp’l Decl.) ¶ 18. Here, Plaintiffs do not appear to seek collection of Microsoft emails or other Microsoft messages. If it has not already done so, Uber shall produce documents[3] hyperlinked in Google chat messages, and related metadata to the extent feasible. The parties shall meet and confer and stipulate to a deadline for the production. As to hyperlinks contained in documents other than Google emails and chat documents, the same outcome as described for Issue 1 is appropriate, and the parties are ORDERED to comply with the process set forth in the preceding section with respect to hyperlinks appearing in documents other than Gmail and chat messages.

C. Issue 3: Missing Information Regarding Typical “Modern Attachment” Links

According to Plaintiffs, Uber has not consistently provided the metadata information required by the ESI Protocol for links to Google Drive documents from Gmail messages. The parties indicated at the Discovery Status Conference that the scope of this dispute has narrowed, and the Court ordered them to meet and confer further to resolve it, and to file a status report no later than March 7, 2025. See Dkt. No. 2407 (Minutes).

D. Issue 4: Email Threading

The ESI Protocol calls for treating each email as a distinct document, rather than allowing for production of consolidated email threads:

13. NO EMAIL THREADING No email may be withheld from production because it is included in whole or in part in a more inclusive email, although Parties may use email threading for their own internal review and other internal processes.

Dkt. No. 524 at 16.
Plaintiffs argue that “although Uber agrees it is required to produce all emails within a thread (Dkt. 524 at 16, ¶ 13), Uber has repeatedly not produced the earliest in time emails (or the hyperlinked documents and hyperlink metadata), even though they are clearly relevant and discoverable. (See, e.g., Ex.’s E, F).” Dkt. No. 2194 at 5. Uber, however, does not agree that it is required to produce all emails in a thread if they are not all independently relevant or found in the files of a designated custodian, id. at 7–8, and Uber is correct that the ESI Protocol does not require it to do so.

Plaintiffs contend that some of the earlier emails Uber has withheld are relevant and should have been produced in their own right. That is a fact– and context-specific inquiry that experienced counsel should be able to work out as to particular documents in dispute. If the parties require the Court’s intervention as to specific relevancy disputes, they may raise that by a separate joint letter.[4] 

Even where Uber does not produce an earlier email separately, the later email that has been produced often quotes the content of the earlier emails in a thread below the new message. Uber apparently has not been producing documents or metadata (other than URLs) for hyperlinks appearing in that quoted text. Uber contends that it is treating such links in the same manner as traditional attachments, which often would not be included in a reply to the original message where the document was attached. Dkt. No. 2194 at 8. That is often (but not always) true for threads created by email replies, although it is similarly often (but not always) false for threads created by forwarding earlier emails.

Can a hyperlink within an earlier email be considered the equivalent of an attachment to a later email that quotes the earlier email? Under some circumstances, perhaps—but the question does not have a clear, universal answer, and the ESI Protocol does not speak to this issue directly. Once again, the Court concludes that, at this stage of the case, a process of handling such issues by request is appropriate under the same framework discussed above.

E. Conclusion

The parties are ORDERED to meet and confer as to a protocol for Plaintiffs requesting and Uber providing either documents or metadata for: (1) hyperlinks to sources other than Google Drive documents; (2) hyperlinks within documents other than Gmail messages; (3) earlier-in-time emails that are quoted in produced emails but have not been produced separately; and (4) hyperlinks within such earlier-in-time emails. Uber need not produce documents that are irrelevant, privileged, or protected from disclosure. For hyperlinks to public websites, Uber need produce documents or information other than URLs, except that Plaintiffs may request contemporaneous versions of Uber’s own public webpages where relevant.

The parties shall file either a stipulation or joint letter no later than one week from the date of this Order. The parties are further encouraged to consider whether any of the information at issue in this Order can be incorporated efficiently into future document productions.

IT IS SO ORDERED.

Footnotes
The record evidence that Uber presents appears strong, and Plaintiffs do not dispute it at all, which raises the question as to why Plaintiffs are demanding this in the joint discovery letter. The Court expects that discussions regarding what discovery is technologically feasible to occur during the meet and confer process so requests for ESI discovery that appears to be impossible are not routinely presented to the Court
In contrast, Plaintiffs are specific about the metadata fields that they seek for Google Drive documents that have been linked in Gmail messages. See ECF No. 2194 at 4.
Consistent with the Court’s ruling on Issue 1, this production order only applies to Google Drive files.
If an earlier email is undisputedly relevant but does not involve an agreed custodian, Uber may be correct that it was not required to produce the email in the first instance, but it should produce the email upon request. Plaintiffs should only make such requests where they have some reasonable need for the earlier email as a separate document, rather than simply using the later email that quotes it.