System Requirements Document for sandbox-linux-disposable

1. Introduction

This document specifies a personal, disposable, isolated Linux sandbox that the requester (Bambang) uses to learn Linux commands. The product intent is narrow and exact: give one technically literate power user a real Bash shell inside a throwaway Linux environment that runs as a regular non-root user, starts in /workspace, can only touch its own sandbox filesystem, has no access to host credentials, sockets, or secrets, has a restricted network, and is reachable from a browser through an sshx session link — all running on the current machine ("jalankan disini"), not as a separately hosted service.

The audience is a single learner working alone. There is no team, no multi-tenant administration, no account system, and no hosted control plane. The sandbox exists to be used, learned in, and then disposed of.

2. System Overview

The system is a locally run, disposable Linux sandbox plus a browser-accessible terminal session delivered by sshx. The sandbox is created on the current machine, runs as a regular non-root user with Bash as the shell and /workspace as the working directory, confines filesystem access to the sandbox itself, exposes no host credentials, sockets, or secrets, and operates under a restricted network. The learner reaches the session from a browser via the sshx link, runs Linux commands to learn, and disposes of the sandbox when finished.

Actors:

• Linux Learner (Bambang) — the sole active human persona. Creates the sandbox, opens the sshx session link, runs commands, and disposes of the sandbox.
• sshx (external provider) — provides the browser-accessible terminal session and its session link. It is a provider-owned surface, not a persona.
• Local sandbox runtime (system process) — the disposable Linux environment on the current machine that enforces the non-root user, /workspace, Bash, filesystem confinement, credential/socket/secret isolation, and network restriction.

2a. Product Interpretation and Delivery Boundary

Delivery is local-first and headless in shape: the sandbox runs on the current machine, and the human-facing terminal interaction is owned by the sshx provider surface rather than by a custom-built terminal UI. The only first-party page is a Landing page that explains the personal disposable Linux sandbox and its browser-based sshx terminal before the learning session begins, and that carries the entry point to the sshx session link.

Access ownership: the Landing page is anonymously reachable and requires no identity. The sshx session is reachable via its link without an added token or password layer, for personal use. No application-owned account, login, or session-continuity mechanism is part of the current product.

Current boundary: creating the sandbox on the current machine, running it as a regular non-root user with Bash and /workspace, confining filesystem access to the sandbox, blocking host credentials/sockets/secrets, applying the required network restrictions, starting sshx and providing its session link, running Linux commands for learning, and disposing of the sandbox session when learning is complete.

Future boundary: nothing beyond the above is committed. No hosted service, no multi-user access, no persistent storage across sessions, and no additional account or permission layer is in scope.

2b. Source Content Inventory

Not applicable. No reference directive declares content_source; the sshx directive is a feature_reference only and supplies no factual content inventory.

2c. Page Content and Component Coverage

Landing

• Information / state
  • Product statement: a personal, disposable, isolated Linux sandbox for learning Linux commands.
  • Sandbox facts as label/value pairs: user: learner (non-root), shell: bash, cwd: /workspace, network: restricted, mounts: sandbox only.
  • Isolation facts: filesystem access limited to the sandbox; no host credentials, sockets, or secrets.
  • Session state: sshx session status (live / not yet started) and the session link when available.
  • Disposal fact: the sandbox is disposable and is discarded when the learning session ends.
• Primary actions
  • Open the sshx terminal session link.
• Supporting actions
  • Copy the sshx session link.
  • Read the sandbox fact rail (user, shell, cwd, network, mounts).
  • Read the isolation schematic explaining what the sandbox can and cannot reach.
• Domain entities
  • Sandbox (disposable Linux environment), sandbox user (regular, non-root), working directory (/workspace), shell (Bash), network policy (restricted), isolation boundary (sandbox filesystem only; no host credentials/sockets/secrets), sshx session (link, status).
• Component responsibilities
  • Hero block: display headline and the mono fact block (user, shell, cwd, root: no).
  • Terminal frame (decorative): rendered Bash prompt at /workspace with example commands and exit codes; bleeds off the right viewport edge as decoration only.
  • sshx status indicator: breathing status dot labelled with session state.
  • Primary CTA: compact tangerine rectangle labelled to open the terminal link.
  • Fact rail: persistent label/value readout of sandbox facts; collapses to a 72px icon rail at ≥1280px and a stacked definition list at 375px.
  • Isolation schematic: 1px-stroke diagram showing the sandbox boundary and the unreachable host credentials, sockets, and secrets.
  • Command ledger: command, purpose, and right-aligned exit code rows; copyable on click.
• States
  • Loading: session status resolving; fact rail and schematic render immediately with static facts.
  • Empty: no sshx session link yet — status shows "not yet started" and the CTA is presented as the way to start/reach the session.
  • Success: sshx session live — status dot active, session link available and copyable, CTA opens the terminal.
  • Error: session link unavailable or session not live — status shows the failure plainly and the CTA remains available to retry reaching the session.
  • Recovery: learner can re-open or re-copy the session link, or dispose of the sandbox and start a fresh disposable session.

3. Functional Requirements

FR-1 — Create a disposable isolated Linux sandbox on the current machine

• As the Linux Learner (Bambang), I should create a disposable, isolated Linux sandbox on the current machine, so that I have a throwaway environment to learn in.
• Provenance: explicit (plus required_inference for the on-machine creation mechanics).
• Lifecycle: initiator — Linux Learner; trigger — starting a learning session; observable result — a running disposable sandbox on the current machine; access state — anonymous, no identity required; failure/recovery — if creation fails, the sandbox is not started and the learner can retry creation; continuation — proceed to run commands in the sandbox.
• Acceptance: a disposable Linux sandbox is running on the current machine, not as a separately hosted service.

FR-2 — Run as a regular non-root user

• As the Linux Learner (Bambang), I should have the sandbox run as a regular user rather than root, so that my learning environment matches normal, non-privileged Linux usage.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — sandbox start; observable result — the session user is a regular non-root user; access state — anonymous; failure/recovery — if the session is not a regular non-root user, the sandbox does not meet the constraint and must be recreated; continuation — run commands as the regular user.
• Acceptance: the sandbox session user is a regular user, not root.

FR-3 — Use /workspace as the working directory

• As the Linux Learner (Bambang), I should start in /workspace as my working directory, so that my practice files live in a known, consistent location.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — session start; observable result — the shell's working directory is /workspace; access state — anonymous; failure/recovery — if the working directory is not /workspace, the learner changes to it or recreates the sandbox; continuation — run commands from /workspace.
• Acceptance: the session's working directory is /workspace.

FR-4 — Use Bash as the shell

• As the Linux Learner (Bambang), I should get a Bash shell, so that I can practice standard Linux commands in the shell I expect.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — session start; observable result — an interactive Bash shell; access state — anonymous; failure/recovery — if the shell is not Bash, the sandbox does not meet the constraint and must be recreated; continuation — run commands in Bash.
• Acceptance: the interactive shell is Bash.

FR-5 — Confine filesystem access to the sandbox only

• As the Linux Learner (Bambang), I should have filesystem access limited to the sandbox only, so that nothing I do can reach or damage the host filesystem.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — any filesystem operation in the session; observable result — reads and writes are confined to the sandbox filesystem; access state — anonymous; failure/recovery — if a path outside the sandbox is reachable, the isolation constraint is violated and the sandbox must be recreated; continuation — continue working inside the sandbox filesystem.
• Acceptance: filesystem access from the session is limited to the sandbox.

FR-6 — Block host credentials, sockets, and secrets

• As the Linux Learner (Bambang), I should have no access to host credentials, sockets, or secrets from the sandbox, so that my learning environment cannot leak or touch anything sensitive on the host.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — any attempt to reach host credentials, sockets, or secrets; observable result — those host resources are not present or not reachable inside the sandbox; access state — anonymous; failure/recovery — if any host credential, socket, or secret is reachable, the isolation constraint is violated and the sandbox must be recreated; continuation — continue working without host credential/socket/secret access.
• Acceptance: no host credential, socket, or secret is accessible from inside the sandbox.

FR-7 — Apply restricted network

• As the Linux Learner (Bambang), I should have the sandbox network restricted, so that the environment stays contained while I learn.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — sandbox start; observable result — the sandbox operates under a restricted network policy; access state — anonymous; failure/recovery — if the network is unrestricted, the constraint is violated and the sandbox must be recreated; continuation — continue running commands under the restricted network.
• Acceptance: the sandbox network is restricted.

FR-8 — Run Linux commands for learning

• As the Linux Learner (Bambang), I should be allowed to run Linux commands in the sandbox for learning, so that I can practice and build understanding.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — typing a command at the Bash prompt; observable result — command output and exit status are shown in the session; access state — anonymous; failure/recovery — a failing command returns a non-zero exit status and the learner can correct and re-run it; continuation — keep practicing commands.
• Acceptance: the learner can run Linux commands in the sandbox and see their output and exit status.

FR-9 — Install/use sshx to provide the terminal session

• As the Linux Learner (Bambang), I should have sshx installed and used to provide the terminal session, so that I can reach my sandbox shell from a browser.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — sandbox start; observable result — an sshx session is running and provides the terminal session; access state — anonymous; failure/recovery — if sshx does not start, the session is unavailable and the learner can retry starting it; continuation — open the session link.
• Acceptance: sshx is installed and running to provide the terminal session.

FR-10 — Reach the sshx session via its link without an added token/password layer

• As the Linux Learner (Bambang), I should reach the sshx session through its link without an added token or password layer, so that my personal session is quick to open.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — opening the sshx session link; observable result — the terminal session opens for personal use without an added token/password layer; access state — link-based, personal use; failure/recovery — if the link does not open the session, the learner can re-copy the link or restart the sshx session; continuation — run commands in the opened session.
• Acceptance: the sshx session is reachable via its link without an added token/password layer, for personal use.

FR-11 — Run the sandbox here, on the current machine

• As the Linux Learner (Bambang), I should run the sandbox here on the current machine, so that it is my own local environment rather than a separately hosted service.
• Provenance: explicit.
• Lifecycle: initiator — Linux Learner; trigger — starting the sandbox; observable result — the sandbox runs on the current machine; access state — anonymous; failure/recovery — if the sandbox is not running on the current machine, the constraint is violated and it must be started locally; continuation — use the local sandbox.
• Acceptance: the sandbox runs on the current machine, not as a separately hosted service.

FR-12 — Dispose of the sandbox session when learning is complete

• As the Linux Learner (Bambang), I should dispose of the sandbox session when I am done learning, so that the environment does not persist.
• Provenance: required_inference.
• Lifecycle: initiator — Linux Learner; trigger — finishing a learning session; observable result — the sandbox session is disposed of and no longer running; access state — anonymous; failure/recovery — if disposal fails, the learner can retry disposal; continuation — start a fresh disposable sandbox for the next session.
• Acceptance: the sandbox session is disposed of when learning is complete.

4. User Personas

Linux Learner (Bambang)

• Product context: Bambang is a solo, technically literate power user who wants a personal, disposable Linux sandbox to learn Linux commands. He works alone, from a browser, and cares about exactness — flags, exit codes, paths, and permissions. He wants the machine to feel honest, legible, and entirely his own.
• Primary goal: practice Linux commands safely inside a throwaway sandbox without touching the host.
• Distinct accepted responsibilities: create the disposable sandbox on the current machine; ensure it runs as a regular non-root user with Bash and /workspace; rely on filesystem access being limited to the sandbox and on host credentials, sockets, and secrets being unreachable; operate under a restricted network; run Linux commands for learning; reach the terminal session from a browser via the sshx link without an added token/password layer; dispose of the sandbox session when learning is complete.
• Relevant inputs or decisions: which commands to run and what to learn; when to open the sshx session link; when the learning session is complete and the sandbox should be disposed of.
• Interactions with other accepted participants: Bambang is the only active human participant. He interacts with the sshx provider surface (which supplies the browser-accessible terminal session and its link) and with the local sandbox runtime (which enforces the non-root user, /workspace, Bash, filesystem confinement, credential/socket/secret isolation, and network restriction).
• Observable success: commands run in a Bash shell as a regular non-root user with /workspace as the working directory; output and exit codes are visible; nothing outside the sandbox is reachable; the session is reachable from the browser via the sshx link; the sandbox is disposed of when he is done.

5. Core User Flows

Flow 1 — Start a disposable sandbox and open the terminal session

1. Bambang decides to start a learning session and creates the disposable Linux sandbox on the current machine (FR-1, FR-11).
2. The sandbox starts as a regular non-root user with Bash as the shell and /workspace as the working directory (FR-2, FR-3, FR-4).
3. The sandbox applies its isolation: filesystem access limited to the sandbox, no host credentials/sockets/secrets, and a restricted network (FR-5, FR-6, FR-7).
4. sshx is installed and started to provide the terminal session, and its session link becomes available (FR-9).
5. Bambang opens the Landing page, which explains the personal disposable Linux sandbox and its browser-based sshx terminal, and shows the sandbox facts (user, shell, cwd, network, mounts) and the session status.
6. Bambang opens the sshx session link from the Landing page and reaches the terminal session without an added token/password layer (FR-10).
7. Failure/recovery: if the session link is unavailable or the session is not live, the Landing page shows the failure plainly and Bambang can re-copy or re-open the link, or restart the sshx session.
8. Continuation: with the session open, Bambang proceeds to run commands (Flow 2).

Flow 2 — Learn by running Linux commands in the sandbox

1. Bambang is in the sshx terminal session, at a Bash prompt in /workspace, as a regular non-root user (FR-2, FR-3, FR-4).
2. He types a Linux command to learn (FR-8).
3. The command runs inside the sandbox; its output and exit status are shown in the session (FR-8).
4. Failure/recovery: if the command fails, it returns a non-zero exit status; Bambang reads the error, corrects the command, and re-runs it (FR-8).
5. Continuation: he keeps practicing commands, with filesystem access confined to the sandbox and no host credentials, sockets, or secrets reachable, under the restricted network (FR-5, FR-6, FR-7).

Flow 3 — Dispose of the sandbox when learning is complete

1. Bambang finishes his learning session (FR-12).
2. He disposes of the sandbox session, so the environment no longer runs (FR-12).
3. Failure/recovery: if disposal fails, he retries disposal (FR-12).
4. Continuation: for a later session he starts a fresh disposable sandbox (Flow 1).

6. Visuals Colors and Theme

Authoritative creative direction: Rasmus Andersson — systematic product craft with an opinion: warm graphite, monospace numerals, one hot tangerine signal. Headline: "A Linux sandbox that forgets you when you leave."

Colour tokens (dark mode)

Approximate area distribution: 70% graphite, 18% surface, 8% text, 3% tangerine, 1% acid.

Typography

• Headings: Space Grotesk 500/600, tight tracking (−0.03em), sentence case for product statements; ALL-CAPS only for 11px micro-labels with 0.14em tracking. Numerals in headings are tabular and set slightly larger, as ornament.
• Body: Inter Tight.
• Mono data: JetBrains Mono 14px/1.55.
• Scale (1.25 modular on a 4/8-pt grid): display clamp(40px, 7.6vw, 96px); h2 clamp(28px, 3.4vw, 44px); h3 24px; body 17px/1.65 desktop, 16px/1.7 mobile; micro-label 11px/0.14em tracking.
• Line lengths: 68ch for prose, 92ch for code.

Shape language

• Rectilinear and honest: 8px radii on controls, 12px on panels, 0px on rules and data rows.
• No blobs, no squircle, no soft shadow bloom — separation via 1px #2A2D33 hairlines and a 1px inner top highlight on raised surfaces.
• Terminal frame is a hard-edged rectangle with a 3px tangerine top rule.
• Buttons are compact 36px/44px rectangles, never pills.
• Focus rings are a 2px tangerine offset outline, always visible.

Layout

• 12-column grid with a persistent left rail (72px collapsed / 232px expanded at ≥1280px) holding sandbox facts as label/value pairs: user, shell, cwd, network, mounts.
• Main column is asymmetric: at 1280px the hero copy occupies columns 1–6 and the live terminal frame occupies columns 7–12, bleeding to the right viewport edge as decoration only.
• At 768px the rail becomes a horizontal fact strip and the terminal drops below the copy.
• At 375px everything is single column, the terminal frame is full-width with a horizontally scrollable output region, and the fact list becomes a stacked definition list with hairlines between rows.
• Vertical rhythm: 8/16/24/40/64; section boundaries are full-width hairlines with a small mono index number at the left rail.

Imagery

• The interface is the imagery: a real rendered terminal frame with a Bash prompt at /workspace, tabular command output with exit codes, a permissions matrix (rwx columns) as a diagram, a mount/namespace schematic drawn in 1px strokes with tangerine for the sandbox boundary and muted grey for everything the sandbox cannot reach, and JetBrains Mono code blocks with syntax tinting limited to text, muted, and tangerine.
• No stock photography, no illustration, no 3D renders, no gradient blobs, no device mockups.

7. Signature Design Concept

The public entry (Landing) is a dark graphite full-viewport hero split asymmetrically 6/6, not centred.

• Left (columns 1–6): a 3-line display headline in Space Grotesk at clamp(40px, 7.6vw, 96px) — "A Linux sandbox that forgets you when you leave." — set flush left, with "forgets you" in tangerine #FF5A1F and the rest in #F2EFE9, over a 4-row mono fact block (user: learner · shell: bash · cwd: /workspace · root: no) separated by hairlines. The only CTA is a compact tangerine rectangle cut into the fact block's bottom rule, labelled "Open the terminal link".
• Right (columns 7–12): a live terminal frame bleeding off the right viewport edge as decoration, with a tangerine 3px top rule, a real prompt learner@disposable:/workspace$, and three typed commands resolving to output with exit code 0 in acid green #C6F24E. A breathing tangerine dot labelled sshx · session live sits above it.
• Signature moves carried through the page: the persistent left fact rail reading like a system readout (user, shell, cwd, network, mounts) on hairlines with tabular mono numerals; the permissions/mount schematic drawn entirely in 1px strokes with the sandbox boundary in tangerine and host credentials, sockets, and secrets as muted grey shapes outside it with strikethrough labels; command examples rendered as a tabular ledger (command in JetBrains Mono, purpose in Inter Tight, exit code right-aligned in acid green with tabular numerals, copyable on click with a 120ms tangerine border flash instead of a toast); and section transitions marked by full-width hairlines carrying a small mono index (01 / 02 / 03) at the left rail with the section title in Space Grotesk flush left at the same baseline as the rule.
• No gradient, no centred stack, no blue button. Readable text and needed content stay whole at 375px, 768px, and 1280px; only decoration bleeds off the edge.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the live terminal frame at the right of the hero — a real Bash prompt at /workspace with typed commands resolving to output and exit code 0 — plus the breathing sshx status dot above it.
• Input → transformation → outcome thesis: the learner's intent to start a session (input) is expressed through the hero's fact block and the single tangerine CTA; the terminal frame shows the transformation — commands typed at learner@disposable:/workspace$ resolving to output with exit code 0 in acid green; the outcome is the sshx · session live state and the open terminal link.
• Motion vocabulary: restrained and functional, 120–200ms, cubic-bezier(0.2, 0, 0, 1). One purposeful loop only — the sshx status dot breathing at 2.4s and the terminal caret blinking at 1.06s. Hover states are instant colour swaps on hairline borders and 1px underline reveals, never lifts or scales. The command list reveals with a 40ms stagger on scroll-into-view, once, no re-trigger.
• Composed first frame: graphite ground #141517; left — the 3-line Space Grotesk headline with "forgets you" in tangerine over the 4-row mono fact block on hairlines, with the tangerine CTA cut into the bottom rule; right — the terminal frame with its 3px tangerine top rule, the prompt, three command lines with acid-green exit codes, and the breathing sshx · session live dot above it.
• Reduced-motion state: under prefers-reduced-motion the status dot and caret become static and all reveals render at final state.

9. Non-Functional Requirements

• NFR-1 — Disposability: the sandbox must be disposable; it is discarded when the learning session ends and does not persist. Provenance: explicit. Rationale: the user asked for a disposable sandbox.
• NFR-2 — Non-root execution: the sandbox user must be a regular user, not root. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-3 — Working directory: the working directory must be /workspace. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-4 — Shell: the shell must be Bash. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-5 — Filesystem isolation: filesystem access must be limited to the sandbox only. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-6 — Credential/socket/secret isolation: no host credential, socket, or secret may be accessible from the sandbox. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-7 — Network restriction: the sandbox network must be restricted. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-8 — Session access: the sshx session is reachable via its link without an added token/password layer, for personal use only. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-9 — Local execution: the sandbox runs on the current machine ("here"), not as a separately hosted service. Provenance: explicit. Rationale: explicit hard constraint.
• NFR-10 — Accessibility: readable text and needed content stay whole at 375px, 768px, and 1280px; focus rings are a 2px tangerine offset outline, always visible; reduced-motion preferences are honored. Provenance: explicit (creative direction). Rationale: direction's readability and accessibility rules.

10. Tech Stack

• Sandbox runtime: a disposable Linux sandbox running on the current machine, as a regular non-root user, with Bash as the shell and /workspace as the working directory, filesystem access confined to the sandbox, no host credentials/sockets/secrets, and a restricted network. Provenance: explicit.
• Terminal session provider: sshx, installed and used to provide the browser-accessible terminal session and its link. Provenance: explicit (reference directive: sshx, feature_reference, authoritative).
• Frontend: React for the Landing page. [Default — not specified by user]
• Styling: CSS with the tokens in Section 6 (Space Grotesk, Inter Tight, JetBrains Mono). [Default — not specified by user]
• Containerization: Docker / docker-compose for the disposable sandbox. [Default — not specified by user]
• Orchestration: Kubernetes is not required; the sandbox runs on the current machine. [Default — not specified by user]

11. Assumptions and Constraints

• A-1: The sandbox runs on the current machine ("jalankan disini") and is not a separately hosted service. Provenance: explicit.
• A-2: The sshx session link is used for personal use only, without an added token/password layer. Provenance: explicit.
• A-3: The Landing page is anonymously reachable and requires no identity; no application-owned account or login is part of the current product. Provenance: required_inference (access reconciliation).
• A-4: Disposal of the sandbox session when learning is complete is an indispensable mechanic of the disposable-sandbox lifecycle. Provenance: required_inference.
• A-5: The Landing page is the only first-party page; the terminal interaction is owned by the sshx provider surface. Provenance: required_inference (delivery shape: custom_ui: false, provider_managed_surfaces: true).
• C-1: The sandbox must be disposable. Provenance: explicit.
• C-2: The sandbox user must be a regular user, not root. Provenance: explicit.
• C-3: The working directory must be /workspace. Provenance: explicit.
• C-4: The shell must be Bash. Provenance: explicit.
• C-5: Filesystem access must be limited to the sandbox only. Provenance: explicit.
• C-6: No host credential, socket, or secret access. Provenance: explicit.
• C-7: The network must be restricted. Provenance: explicit.
• C-8: The sshx session access is link-based without an added token/password layer, for personal use only. Provenance: explicit.
• C-9: Run on the current machine ("here"), not as a separately hosted service. Provenance: explicit.

12. Glossary

• Sandbox: the disposable, isolated Linux environment created on the current machine for learning Linux commands.
• Disposable: the sandbox does not persist; it is discarded when the learning session ends.
• Regular user (non-root): the unprivileged user account the sandbox session runs as, rather than root.
• /workspace: the working directory the sandbox session starts in.
• Bash: the shell provided in the sandbox session.
• Filesystem confinement: the property that filesystem access from the session is limited to the sandbox only.
• Host credentials/sockets/secrets: sensitive host resources that must not be accessible from inside the sandbox.
• Restricted network: the constrained network policy applied to the sandbox.
• sshx: the external provider that supplies the browser-accessible terminal session and its session link.
• Session link: the sshx link used to reach the terminal session without an added token/password layer, for personal use.
• Landing: the anonymous first-party page that explains the personal disposable Linux sandbox and its browser-based sshx terminal, and carries the entry point to the session link.
• Linux Learner (Bambang): the sole active human persona who creates, uses, and disposes of the sandbox.