Scope & Ecosystem Architecture
This Privacy Policy outlines how the Reed Programming Language Project ("Reed", "we", "us", or "our") handles data across all tools, services, and digital properties within the Reed ecosystem. This includes:
- The Reed Compiler & Runtime (
reed/reed.exe): The native compiler, bytecode virtual machine, garbage collection runtime, and standard libraries. - The ReUI GUI Framework: The native cross-platform desktop UI framework built directly into the standard toolchain.
- The Reed Package Manager (
rpk/rpk.exe): The official package orchestrator, dependency resolver, and build tool. - The Reed Toolchain Updater (
ReedUpdater/ReedUpdater.exe): The self-contained transactional binary updater. - The Official Web Platform & Package Hub (
reed-lang.org/registry.reed-lang.dev): The public website, documentation hub, playground, and REST package registry. - Development Tooling & Extensions: The official Visual Studio Code language extension (
reedpl-vscode).
Our core philosophy is simple: developers own their code. Programming language tools should be transparent, secure, and private by default.
The Reed Compiler & Runtime (Zero Telemetry)
The Reed Compiler (reed) is designed to operate completely offline. We believe that developer workstations and proprietary source code should never be subject to hidden diagnostic tracking.
Data Handling During Compilation & Execution
| Data Category | Processed Locally? | Transmitted Remotely? | Notes & Safeguards |
|---|---|---|---|
| Source Code & AST | Yes (in memory during build) | NEVER | Parsing, semantic analysis, and type checking are strictly local. |
| Compiler Diagnostics & Errors | Yes (printed to stdout/stderr) | NEVER | Error spans and syntax messages stay on your terminal. |
| Hardware / Machine IDs | No | NEVER | Reed does not inspect MAC addresses, CPU serials, or device GUIDs. |
| Network Calls in User Code | Only if invoked by developer | Only to endpoints you specify | Standard libraries (net, http) only initiate network connections when your own code commands them to. |
Reed Package Manager (RPK) & Local Machine Storage
The Reed Package Manager (rpk) handles local project orchestration and remote dependency resolution. Below is how data is stored and exchanged when using RPK:
1. Local Storage on Your Workstation
- Package Cache (
~/.reed/cache/packages/): Stores uncompressed package archives and dependency versions locally. This avoids redundant downloads and enables fast, offline builds for already-resolved dependencies. - Cryptographic Lockfiles (
reed.lock): Stored within your project root. Contains exact package versions and FIPS 180-4 SHA-256 hashes to guarantee reproducible builds across your team. - Local Credentials File (
~/.reed/credentials.json): When you authenticate viarpk login, your active API token, username, email, and registry URL are saved locally to authenticate subsequent publishing operations. You can clear this file at any time withrpk logout.
2. Remote Registry Network Exchanges
- Installing Dependencies (
rpk add,rpk install): When querying dependencies, RPK sends standard HTTPS GET requests containing the requested package name, requested SemVer range, and a standard User-Agent header (e.g.rpk/1.0.0 (windows-x64)). No private source code, environment variables, or file paths are ever transmitted. - Publishing Packages (
rpk publish): When you explicitly publish a package, your.reedpkg/.rpkarchive containing your package source,reed.tomlmanifest, README, and LICENSE is transmitted to the registry over TLS 1.3 using your authenticated Bearer token. By publishing, you acknowledge that package source files and metadata become public.
Toolchain Self-Updater (ReedUpdater)
ReedUpdater is an optional, self-contained binary updater for Reed and RPK. Its operations are transparent and user-directed:
- Update Checks (
ReedUpdater check): Queries the official release manifest (latest.json) over HTTPS. It sends only standard HTTP headers and does not transmit machine fingerprints, telemetry IDs, or usage metrics. - Cryptographic Verification: Before installing any binary archive,
ReedUpdatercomputes its SHA-256 digest and verifies it against the manifest to prevent corrupted or tampered downloads. - Local Backup Directory (
/backup): When updating, the previous compiler and package manager binaries are automatically moved into a localbackupdirectory within your installation path. This enables instantaneous rollback (ReedUpdater rollback) without re-downloading.
Package Registry & Web Platform (reed-lang.org)
The official Reed website and package registry (reed-lang.org / registry.reed-lang.dev) provide package search, release distribution, and documentation.
1. Server Access Logs & Operational Metrics
When you access the website or download packages, edge infrastructure automatically logs transient technical data strictly for reliability, DDoS defense, and rate-limiting:
- Internet Protocol (IP) address
- HTTP request method and requested URL path
- Timestamp of request
- HTTP status code and payload byte size
- Browser or CLI User-Agent string
These logs are retained for a rolling period of 30 to 90 days for network security and are never sold or combined with external tracking datasets.
2. Public Nature of Package Registries
Package registries are public repositories designed for distributed open-source software collaboration. When you publish a package to RPK:
- The package archive, documentation, version history, and dependencies become publicly downloadable.
- Your publisher username and any author email specified in
reed.tomlare published as part of the package metadata. - Aggregated download counters are maintained to reflect package popularity across the ecosystem.
3. Malware Reporting & Abuse Prevention
If a developer submits a malware report against a malicious package (/api/v1/packages/:name/report), we collect the reported package name, alleged threat category, submitted evidence details, and optional reporter contact email. This data is reviewed exclusively by project administrators to protect ecosystem safety.
Publisher Accounts & API Tokens
To maintain ecosystem security and eliminate anonymous malware uploads, all publishers must authenticate before publishing packages.
Account Data We Store
- Username: Public identifier associated with your packages.
- Email Address: Used for account recovery, security notices, and official publisher communication. Not displayed publicly unless included in your package manifest.
- Password Hash: We use industry-standard
bcryptcryptographic hashing with secure salt rounds. Plaintext passwords are NEVER stored, logged, or accessible to anyone.
Scoped CLI API Tokens
Publishers can generate scoped API tokens (POST /api/v1/auth/tokens) to authorize CLI publishing from developer laptops or CI/CD pipelines:
- Tokens are stored securely in MongoDB using cryptographic SHA-256 hashes.
- Only the token prefix (e.g.
reed_a1b2...) and your user-provided label are displayed in your web dashboard. - You can revoke any token instantly via the dashboard, immediately terminating access for that token.
Cookies, Local Storage & Analytics Policy
We maintain a strict, privacy-first web policy. We do NOT use advertising cookies, third-party analytics trackers, or cross-site tracking scripts.
Client-Side Storage Keys
| Storage Key | Storage Type | Purpose & Description | Retention |
|---|---|---|---|
reed_auth_token |
localStorage |
Stores your authenticated session JSON Web Token (JWT) when you sign in, enabling you to manage packages and generate CLI tokens. | Until manual sign out or token expiry |
theme |
localStorage |
Stores your UI display preference (light mode vs. dark mode). | Persistent on local browser |
Both items are strictly functional and stored entirely on your local browser. No third party has access to them.
Legal Bases for Processing (GDPR, UK GDPR, CCPA/CPRA)
For users located in the European Economic Area (EEA), United Kingdom, Switzerland, and jurisdictions with equivalent data protection frameworks, we process personal information under the following lawful legal bases:
- Contractual Performance (GDPR Art. 6(1)(b)): Processing necessary to deliver our services to you, such as creating your publisher account, issuing authentication tokens, and hosting your published packages.
- Legitimate Interests (GDPR Art. 6(1)(f)): Processing necessary to safeguard infrastructure security, mitigate DDoS attacks, detect supply-chain vulnerabilities, prevent software fraud, and ensure reproducible software builds for the public developer community.
- Compliance with Legal Obligations (GDPR Art. 6(1)(c)): Processing necessary to comply with applicable statutory requirements and lawful law enforcement requests.
- Consent (GDPR Art. 6(1)(a)): For optional communications or voluntarily submitted follow-up contact details in security vulnerability reports.
California Privacy Notice: Under the California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA), we do not sell, rent, or share personal information with third parties for commercial monetary consideration or targeted cross-context advertising.
Data Retention & Package Immutability Rules
Open-source software package managers require unique stability guarantees to ensure that software built today can be reliably reproduced tomorrow:
- Account Records: Your publisher account details are retained for as long as your account remains active. You may request account deletion at any time.
- Strict Version Immutability: Once a specific version of a package (e.g.,
v1.0.0) is published to the RPK registry, it is permanent and immutable. Releases cannot be quietly overwritten or modified. This prevents catastrophic software supply chain breakage and ensures that cryptographic checksums inreed.lockfiles remain perpetually valid. - Account Deletion & Package Ownership: If you delete your publisher account, packages you authored will remain in the public registry to prevent breaking downstream applications, but your personal identifying information (email address) will be unlinked or marked orphaned/archived in accordance with open-source registry industry standards.
Security Architecture & Infrastructure
We employ comprehensive technical, administrative, and physical safeguards designed to protect ecosystem data:
- Transport Layer Security (TLS 1.3): All website, CLI, and registry API communications are encrypted in transit using modern TLS ciphers.
- Archive Traversal Protection (Anti-Zip-Slip): RPK and the registry server validate every entry in
.reedpkg/.rpkZIP containers, strictly rejecting entries with path traversal components (.., absolute paths) to protect user filesystems. - FIPS 180-4 SHA-256 Hashing: Every published package version is assigned an immutable SHA-256 digest recorded in the database and validated on download.
- Infrastructure Isolation: Web services run on serverless edge architecture (Vercel) with isolated read/write object storage (Vercel Blob) and encrypted database clusters (MongoDB Atlas).
- Administrative Audit Trails: Administrative operations (package removals, security dismissals) are logged in tamper-evident audit logs including admin username, timestamp, and action summary.
Developer Rights & Data Portability
Subject to local data protection laws, you possess the following rights regarding your personal information:
- Right of Access & Portability: You can inspect your account details and list of published packages anytime via
GET /api/v1/auth/meor your web profile. - Right to Rectification: You can update your profile information or contact the team to correct inaccuracies.
- Right to Revoke Tokens: You can immediately revoke any CLI token at any time through the publisher dashboard.
- Right to Erasure ("Right to Be Forgotten"): You may submit a request to delete your publisher account. Personal contact details will be expunged from active operational databases.
- Right to Lodge a Complaint: You have the right to lodge a complaint with your local data protection supervisory authority.
Contact Information, Disclosures & Updates
This Privacy Policy may be updated periodically to reflect new tooling features, runtime capabilities, or statutory requirements. When changes are made, the "Effective Date" at the top of this policy will be revised, and notable revisions will be announced in the official Changelog.
Direct Points of Contact
- Privacy & Data Rights Inquiries:
privacy@reed-lang.dev - Security & Vulnerability Reports:
security@reed-lang.dev - Open Source Project Repository: GitHub • Reed Language Project
security@reed-lang.dev before public disclosure to allow coordinated remediation.