other
- Location
setup.md:8- Finding
Persistent User and Project Profiling Without Explicit Opt-In
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:22;setup.md:8-30;memory-template.md:3-24
Vulnerability Type: Persistent user profiling without explicit consent
Risk Level: LowEvidence
SKILL.md:22:markdown User preferences and memory live in `~/Clawic/data/swift/` (see `setup.md` on first use, `memory-template.md` for the file format). If you have data at an old location (`~/swift/` or `~/clawic/swift/`), move it to `~/Clawic/data/swift/`.setup.md:8-30:markdown ## How To Load Preferences 1. Read `~/Clawic/data/swift/config.yaml` if it exists. Apply its values. 2. For anything absent, use the defaults in the Configuration table of `SKILL.md` — do not ask. - `swift_language_mode: 6`, `build_tool: swiftpm`, `test_framework: swift-testing`, `target_platforms: apple`, `deployment_floor: none`, `force_unwrap_policy: tests-only`. 3. Read `~/Clawic/data/swift/memory.md` for prior context (their stack, recurring pain points). Absence is fine; proceed without comment. Infer what the project already tells you before falling back to a default: `Package.swift` names the tools version, platforms, and language mode; the test target names the framework. What the repository states beats the table. ## Recording Preferences (only when the user declares one) Write to config or memory **only** when the user states a preference in the course of the work — never as a preflight questionnaire. - User names a language mode, build tool, test framework, target platform, OS floor, or unwrap policy → update the matching key in `~/Clawic/data/swift/config.yaml`. - User expresses a habit or stance (formatter and rule set, access-control conventions, dependency appetite, diff vs full files, test-first) → record it under the relevant preference area in `~/Clawic/data/swift/memory.md`. - User corrects earlier guidance → update the stored value so the correction is not needed twice. If the user has ...[truncated 3656 chars]- Remediation
View remediation
Remediation Suggestions
- Default to stateless operation and require explicit opt-in before the first persistent read or write.
- Clearly disclose what information will be stored, its filesystem location, retention period, and how it will affect later sessions.
- Request separate confirmation before persisting information merely disclosed during an ordinary task.
- Notify the user after each write and summarize the exact fields that changed.
- Provide commands or documented controls to inspect, edit, clear, and permanently disable memory.
- Store only enumerated configuration values in a schema-validated format; reject unknown keys and instruction-like content.
- Treat free-form Markdown memory as untrusted data when reloading it. It must not override system, developer, safety, or current-session instructions.
- Restrict file permissions to the invoking user and use atomic writes to reduce unauthorized disclosure and corruption risks.
- Define retention and expiration rules for project context and recurring pain points.
- Avoid automatically migrating data from legacy locations unless the user explicitly confirms the source and destination.
