Tor as Infrastructure — internet tool, Ubuntu toolbox, and relay-as-learning¶
Validation status: Tor facts + relay requirements sourced (2026). The curriculum/toolbox proposals and MPowerUP integration ideas are [HYPOTHESIS] — design directions, not committed scope.
This note responds to a direct steer from the team: treat Tor as an internet tool, fold it into our custom Ubuntu toolbox and learnings, consider Briar (for Android), and weigh running a Tor relay (relay requirements) as a contribution. It connects the comms-architecture survey to the Second Boot refurb + digital-literacy program.
Mission alignment. The Tor Project's mission — "to advance human rights and freedoms by creating and deploying free and open source anonymity and privacy technologies, supporting their unrestricted availability and use, and furthering their scientific and popular understanding" — is a near-exact match for BNI's agentic-AI-access and privacy-for-vulnerable-users posture. "Furthering popular understanding" is itself a digital-literacy curriculum goal, which is why Tor belongs in Second Boot, not only in MPowerUP.
1. Tor as an internet tool (three distinct roles)¶
Tor is not one thing — separate the roles so the toolbox and curriculum stay honest about what each does:
| Role | Tool | What it gives the user | Honest cost |
|---|---|---|---|
| Anonymous browsing | Tor Browser (desktop/Ubuntu) | Hides IP from sites; resists tracking/fingerprinting; reaches blocked content | Slower; some sites block Tor; not a magic cloak (see threat model) |
| Route any app over Tor | Orbot (Android) / torsocks (Ubuntu) |
Per-app or system IP protection | Battery cost on mobile; latency |
| Censorship circumvention | Snowflake / bridges / pluggable transports | Reaches Tor where it's blocked | Reach layer, not extra anonymity |
| Host without revealing location | Onion services (v3) | Self-authenticating .onion; no IP exposed; no DNS/CA |
Hosting from Arti not yet as hardened as C-Tor |
What Tor protects (and doesn't), stated plainly — this is the literacy point, per the Epistemic Honesty directive: - ✅ Hides your IP from the destination and the destination from the network; circumvents local/ISP surveillance and censorship. - ❌ Not a defense against a global passive adversary watching both ends (Tor is low-latency, not a mixnet). ❌ Doesn't encrypt content past a clearnet exit (use HTTPS/onion). ❌ Doesn't make a logged-in account anonymous.
→ Add Tor to the BNI Tool Integrations register under Communication & Privacy (done — see that file).
2. The custom Ubuntu toolbox (Second Boot)¶
Second Boot rebuilds donated laptops on Ubuntu 24.04 LTS with a curated open-source stack (UBUNTU INSTALLATION covers the dual-boot install). Proposed privacy-tools tier of the toolbox [HYPOTHESIS]:
| Tool | Install (Ubuntu 24.04) | Role | Notes |
|---|---|---|---|
| Tor Browser | Official .tar.xz from torproject.org (preferred over the torbrowser-launcher apt package, which lags) + verify signature |
Anonymous browsing | Teaches signature verification — a literacy win in itself |
tor daemon |
apt install tor |
Local SOCKS proxy; relay capability | Basis for torsocks and for running a relay (§3) |
torsocks |
apt install torsocks |
Route CLI apps over Tor | torsocks curl … |
| OnionShare | Flatpak / apt | Anonymous file + secret drop | The "ad-hoc secure handoff" primitive from the survey |
| Briar Desktop | .deb / Flatpak |
Offline-resilient secure messaging companion to Briar Android | Pairs with the Android recommendation in §4 |
Why this belongs in the curriculum, not just the image: "furthering popular understanding" is the Tor mission and a Second Boot learning objective. Candidate module content [HYPOTHESIS]: threat-model literacy (what anonymity does/doesn't do), signature verification, the three-axis privacy model from zones-model, and the difference between content privacy and metadata privacy.
Cross-program note: the canonical home for the Ubuntu toolbox + curriculum is the Second Boot program (
big-nerd-idea/docs/programs/second-boot/), not this vault. This note is the research/rationale; the toolbox spec and a curriculum module should be added there. Flagged as a follow-up — see the handoff at the bottom.
3. Running a Tor relay — contribution and learning artifact¶
Running a relay is where the Tor mission, the sustainability directive, and the digital-literacy curriculum intersect: a refurb laptop or a Pi-class node on a stable connection can give bandwidth back to the network that protects the same vulnerable users BNI serves. It is also a concrete, hands-on networking lesson.
Requirements (from the official relay requirements, 2026):
| Role | Min bandwidth (up & down) | RAM | Monthly traffic | Notes |
|---|---|---|---|---|
| Bridge | ≥ 1 Mbit/s | 512 MB (<40 Mbps non-exit) | ≥ 100 GB out + 100 GB in | Best first step — lowest bar, helps censored users, low abuse exposure |
| Guard / Middle relay | ≥ 10 Mbit/s (16 recommended) | 512 MB (<40 Mbps); 1 GB (>40 Mbps) | ≥ 100 GB each way (2+ TB ideal) | No exit-traffic liability; handles ≥ 7,000 concurrent connections |
| Exit relay | ≥ 10 Mbit/s (≥100 for fast) | 1.5 GB per tor instance | Higher; fast exits ~100,000 connections | ⚠️ Abuse complaints land on the operator — do NOT run from home or on refurb without legal/ISP clarity |
Other constraints: public IPv4 (dynamic OK if stable ≥ 3 hours; static preferred); ≤ 8 relays per IPv4; modern CPU with AES-NI; < 200 MB disk for Tor data; uptime ≥ 2 hrs/day (24/7 ideal); must stay on a supported Tor version.
BNI-specific guidance [HYPOTHESIS]:
- ✅ Start with a bridge or a non-exit middle/guard relay. 100 GB/month each way and 512 MB–1 GB RAM is well within a refurb laptop or Pi-class node on an unmetered home/makerspace line.
- ❌ Do not run an exit relay from a residence, a refurb-program device, or without explicit ISP + legal sign-off — exit operators receive the abuse/legal complaints. This is an organizational/EXPERT-REVIEW decision, not a casual toolbox default.
- ♻️ Sustainability fit: a low-power non-exit relay on a refurbished device, ideally on a solar/low-power line, is a textbook expression of the sustainability directive — reuse + grid-resilient + public-good bandwidth. Carbon framing stays [HYPOTHESIS] until measured.
- 🎓 Curriculum artifact: "stand up a bridge/middle relay" is an excellent capstone networking lab for an advanced Second Boot module (firewall/port-forward, bandwidth config in torrc, monitoring via Nyx/Relay Search, operational ethics of exit-vs-non-exit).
4. Briar for Android — the team's specific pick¶
Briar is profiled in full in candidates-tor-native; summarizing why it belongs in the toolbox + curriculum specifically (the team asked to consider it for Android):
- ✅ Android-native and mature (1.5.17, March 2026) — matches Second Boot's likely awarded-device profile and MPowerUP's budget-Android target.
- ✅ The only surveyed app that works with no internet — Bluetooth/Wi-Fi mesh + sneakernet + Briar Mailbox (async delivery via a spare/refurb device). This is the standout property for users in connectivity-fragile situations.
- ✅ No phone number, no account, audited (Cure53), Tor for internet transport — strong on all three privacy axes.
- ⚠️ Honest caveats for users: in-person key exchange raises the onboarding floor; persistent service draws battery; groups are feed/forum-style. Teach these, don't gloss them.
- ♻️ Second Boot synergy: Briar Mailbox running on a spare refurbished Android device is a natural program artifact — it gives a Circle asynchronous delivery without any server, using exactly the kind of hardware the refurb pipeline produces.
Recommendation [HYPOTHESIS]: include Briar (Android) + Briar Desktop in the Second Boot toolbox as the recommended offline-resilient secure messenger, taught alongside the Tor literacy module. It is also an honest interim referral for MPowerUP's target users until/unless MPowerUP ships its own Z0 offline tier.
5. How this feeds the MPowerUP reconsideration¶
- Tor/Arti is the way MPowerUP could add the network-identity (IP-protection) axis to its own app without adopting a whole Tor app — client-side Arti is production-ready (hosting is not yet). See protocols-and-primitives (Arti) and the verdict.
- Briar is the architectural reference for the Z0 offline-mesh tier MPowerUP lacks, and the honest interim referral today.
- Running relays is a BNI contribution to the commons and a curriculum artifact — not part of the MPowerUP app, but squarely on-mission.
Follow-up / handoff¶
The toolbox spec and curriculum module should be authored in the Second Boot program docs (big-nerd-idea/docs/programs/second-boot/), with this vault note as the cited rationale. Suggested additions there [HYPOTHESIS]:
1. A "Privacy & Anonymity Tools" page in the Ubuntu toolbox (Tor Browser, tor daemon, torsocks, OnionShare, Briar Desktop).
2. A curriculum module: Understanding Anonymity & Metadata (threat-model literacy + the three-axis privacy model).
3. An advanced lab: Run a Tor bridge/middle relay (with the exit-relay caution as an explicit org policy).