Redact legal documents without uploading them to the cloud.

Client-side processing means the computation happens inside your web browser, on your machine, using your CPU and your RAM. The document is never transmitted over the internet. There is no API call to a remote server. There is no server at all. The Rust code that performs the redaction has been compiled to WebAssembly — a binary instruction format that modern browsers can execute at near-native speed — and it runs entirely within the browser’s sandboxed execution environment.

For attorney-client privilege, this architecture eliminates the transmission risk that cloud-based tools create. When you upload a document to a cloud redaction service, you are voluntarily disclosing the document’s contents to a third-party technology vendor. Whether this disclosure constitutes a waiver of privilege depends on your jurisdiction, the nature of the document, and whether the vendor qualifies as a “necessary agent” under the Kovel doctrine or its state-law equivalents. The analysis is fact-specific and the law is unsettled in many jurisdictions. With client-side processing, there is no disclosure to evaluate. The document never leaves your custody. The privilege analysis does not arise because the predicate act — transmitting the document to a third party — never occurs.

This is not a theoretical risk. In 2019, a federal court in In re Edelson PC found that transmitting privileged documents through a third-party cloud service could jeopardize privilege protections if the firm could not demonstrate adequate due diligence regarding the vendor’s security practices. The safest way to avoid this analysis entirely is to use tools that never transmit the document in the first place. Client-side architecture makes the privilege question moot by design.

Rust is a systems programming language developed by Mozilla and now maintained by the Rust Foundation. It was designed for two properties that matter enormously for security-sensitive applications: memory safety without garbage collection, and performance comparable to C and C++. Rust’s ownership model prevents entire categories of security vulnerabilities — buffer overflows, use-after-free bugs, dangling pointers, data races — at compile time. These are the vulnerability classes that account for roughly 70 percent of all security bugs in software written in C and C++, according to studies by Microsoft and Google’s Project Zero.

WebAssembly is a binary instruction format that allows code written in languages like Rust, C, and C++ to run inside web browsers at near-native speed. When Rust code is compiled to WebAssembly, it becomes a compact binary module that the browser can execute 10 to 50 times faster than equivalent JavaScript code, depending on the operation. For document processing — parsing PDF structures, scanning text for patterns, modifying document internals, stripping metadata — the performance difference between Rust/WASM and JavaScript is the difference between processing a 50-page PDF in two seconds versus thirty seconds.

The practical consequence for law firms is a tool that is simultaneously more secure than JavaScript-based alternatives (because Rust’s memory safety eliminates vulnerability classes that JavaScript cannot prevent), faster than JavaScript alternatives (because WASM executes at near-native speed), and more reliable than JavaScript alternatives (because Rust does not leak memory or crash on large documents the way JavaScript single-threaded processing does). The language choice is not an academic detail. It is the engineering foundation that makes client-side legal document processing practical at the file sizes and page counts that real legal work produces.

Visual redaction places a black box over text in the document’s visual layer. The underlying text remains in the document structure. It can be recovered by selecting and copying the text beneath the box, by opening the PDF in a text editor, by using PDF parsing tools that read the document’s text stream rather than its visual rendering, or by examining the document’s metadata for content that the visual redaction did not reach. This is not a hypothetical vulnerability. There is a long history of high-profile redaction failures caused by visual-only redaction, including the inadvertent disclosure of the names of intelligence officials in government filings, financial details in SEC documents, and personally identifiable information in court records.

Permanent redaction — the kind that court rules and discovery production requirements demand — removes the underlying text from the document structure entirely. The redacted content is not hidden behind a visual overlay. It is deleted from the PDF’s content streams, font subsets, and metadata. The black box is not covering the text. The black box is replacing the text, because the text no longer exists in the file. A properly permanently redacted PDF can be opened in a text editor, parsed with PDF analysis tools, or examined at the binary level, and the redacted content will not be present.

Secure Redaction performs permanent redaction. When you apply a redaction, the underlying text is stripped from the document’s content streams, the associated font data is removed, and the metadata is scrubbed. The output PDF contains no recoverable trace of the redacted content. This is the level of redaction permanence required by Federal Rule of Civil Procedure 5.2 for personal identifiers in court filings, by most state court e-filing rules, and by the Sedona Conference guidelines for discovery production. Visual-only redaction does not meet these standards, and any tool that merely overlays black boxes without modifying the underlying document structure is creating a compliance risk that a single opposing counsel with a PDF parser can exploit.

ABA Model Rule 1.6(c) requires lawyers to make “reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client.” ABA Formal Opinion 477R (2017) specifically addresses the use of technology and cloud services, stating that lawyers must take reasonable precautions when transmitting client information electronically, including understanding the technology being used and ensuring that the method of transmission affords reasonable security.

State bar ethics opinions vary in their specificity but converge on a common principle: before using a third-party technology vendor to process client documents, the lawyer must conduct reasonable due diligence on the vendor’s security practices, data handling policies, and access controls. This typically involves reviewing the vendor’s terms of service, understanding whether and where data is stored, determining who has access to the data during processing, and evaluating whether the vendor’s practices are consistent with the lawyer’s obligations under their state’s version of Rule 1.6.

For cloud-based redaction tools, this due diligence obligation is real and ongoing. The vendor’s security posture can change with any infrastructure update, personnel change, or business acquisition. A tool that was compliant yesterday may not be compliant after the vendor is acquired by a larger company with different data practices, or after an infrastructure change introduces logging that captures document content. With client-side processing, the due diligence obligation is dramatically simpler: there is no vendor infrastructure to evaluate because the document never touches vendor infrastructure. The ethical analysis reduces to evaluating the browser’s security model, which is standardized, independently audited, and maintained by the browser vendor (Google, Mozilla, Microsoft, Apple) regardless of the redaction tool. Client-side architecture does not eliminate your ethical obligations. It reduces them to a scope that can actually be satisfied with confidence.