Security posture
Defensive parsing reduces risk; it does not make a browser project a secure vault.
Input boundaries
Cue files, checkpoints, and audio headers use byte, row, field, chunk, identifier, and schema limits. Dangerous JSON keys, malformed quoting, traversal-like filenames, and unsupported control characters are rejected.
Application boundaries
Production preparation emits a restrictive content security policy, no remote connections, no microphone permission, no framing, and noindex for the private studio.
No vault claim
The project does not encrypt browser storage, securely erase data, scan malware, authenticate users, or create tamper-proof evidence. Use appropriate device and organizational controls.
Worked example
Feed the intake station a file whose header row contains a column called constructor and it is refused as an unsafe header rather than mapped. Feed it two columns whose names differ only in case and it is refused for duplicate headers. Feed it a cell that starts with an equals sign and the export path neutralizes it so a spreadsheet cannot execute it later. Feed the checkpoint importer a file whose bytes were edited and the schema and digest checks refuse it instead of loading a partial project.
Open the same project in two tabs and the second reports that another tab holds the writer lease, rather than both saving over each other. Each of these is a place where the correct outcome is a visible refusal.
Method
Cue files, checkpoints and audio headers all pass byte, row, field, chunk, identifier and schema limits before anything is written. Dangerous JSON keys, malformed quoting, content after a closing quote, traversal-like filenames and unsupported control characters are rejected. Imports commit atomically, so a rejected row never leaves half a project behind.
Production preparation emits a restrictive content security policy with no remote connections, no microphone permission and no framing, and marks the private studio noindex.
What this does not do
- Browser storage is not encrypted and cannot be securely erased by the application.
- There is no user authentication, no malware scanning and no tamper-proof evidence.
- A digest proves bytes are unchanged; it proves nothing about who wrote them or when.
Do this in the app
Exercise a refusal on purpose so you recognize one under pressure.
- Open station 03 Intake and preview a deliberately malformed file.
- Read the rejection message and note the row number it names.
- Fix the source file and preview again before committing.
Open the local workspace at station 03 Intake