Disclaimer
Security is an ongoing process; new vulnerabilities and attack vectors appear regularly. The threats and mitigations described below are representative but not exhaustive. Treat this document as guidance, not a guarantee of security.
Definitions
dcp-worker
A Node.js process that communicates with the DCP Scheduler over HTTPS to obtain Job data and report results. It also manages local communication with one or more sandboxed dcp-evaluator processes over TCP. Typically, there is one dcp-evaluator process per CPU core and GPU.
dcp-evaluator
A sandboxed process that embeds Google’s V8 JavaScript engine and Dawn (Google’s WebGPU implementation) to securely execute individual tasks on the CPU or GPU as part of a distributed computation.
Compute Group
A logical group that determines which dcp-worker nodes can execute specific DCP jobs. Workers join a Compute Group to become eligible for its jobs. Public groups are open (e.g., the DCP Global Network), while private groups require join credentials to restrict membership (e.g., Queen’s University).
Threat Categories
- DCP-Worker-specific threats: arise from DCP Worker architecture, protocols, and operational policies.
- Platform-agnostic threats: host, hypervisor, OS, supply-chain, or hardware attacks that can affect any software, including DCP.
DCP Worker-specific threats
- DCP Worker Application Manipulation A local administrator on a host running a DCP Worker has sufficient privileges to modify the Worker software or environment and access any job data it processes. This capability is inherent to administrative control on any system and is not unique to DCP. In private (enterprise or institutional) Compute Groups, this risk is managed by the organization’s access controls and trust in its system administrators. In public Compute Groups, operators generally have full control of their machines and can view all job data processed there. Sensitive job data should not be sent to public Compute Groups.
- Compute Group Credential Theft and Task Distributor Fraud If a malicious actor gains Compute Group join credentials through social engineering or by reading DCP Worker configuration (for example: the Windows Registry), they could run a DCP Worker from a machine they control with modified Worker code to log or leak job data. Mitigations include denying non-Administrators read access to Worker config and write access to Worker application code, configuring Compute Groups to use allow-lists of specified Worker IDs and/or IP address blocks, and using revocable Compute Group join credentials.
- On-Host DCP Worker Traffic Exposure The Worker sends job data to each dcp-evaluator over unencrypted TCP on localhost. A malicious actor who can capture loopback traffic could read and leak the job data. Mitigations include implementing proper user permissions and encrypting worker-evaluator traffic.
Platform-agnostic threats (affect DCP because DCP runs on hosts)
- RAM / Memory Dumps and Hypervisor Snapshots Host or hypervisor operators with sufficient privileges can capture physical memory or snapshot a VM and extract secrets from RAM images. Triggering and analyzing dumps is straightforward for privileged actors. Hypervisor control is equivalent to guest-ram access. Mitigation: avoid running sensitive workloads on hosts where hypervisor control is untrusted; encrypt swap and disable unencrypted crash dumps.
- Network Interception and TLS threats Network traffic between the DCP Scheduler and Workers is encrypted by default. Breaking cryptographic encryption is not yet a realistic threat. Mitigation: Distributive uses short-lived credentials and employs DNSSEC.
- Exploitable Runtime Bugs (Google V8) DCP Workers execute job code inside instances of Google V8, the same JavaScript engine used in Chrome. Vulnerabilities in V8 or its embedder can, in theory, allow sandbox escapes or arbitrary access to host resources, even if the Worker binary itself is untampered. In practice, exploitable V8 bugs are rare, and Google patches known security issues promptly. Mitigation: Distributive applies V8 patches to the DCP Worker as soon as they are available, Workers are run under least privilege, and sandbox isolation is used for untrusted code execution.
- Compromised Software Supply Chain A compromised library, package, or build infrastructure used by the Worker can introduce code that exfiltrates job data. This is a platform-agnostic supply-chain issue whose impact is DCP-specific when the compromised component runs inside the Worker. Mitigation: Distributive uses pinned dependency versions, reproducible builds, CI-based supply-chain monitoring and controls, and verified binary checksums.
- Unpatched Software Any vulnerabilities left unpatched on a host system could be exploited to log or leak job data. Administrators of hosts running DCP Workers must ensure software is regularly updated, security patches are applied promptly, and best practices are followed.