other
Warning
- Location
- skill.md:120
- Finding
- Unverifiable Automatic Telemetry Involving User Identifiers<![CDATA[ ## Vulnerability Details **File Location**: `skill.md`, lines 120–163 **Vulnerability Type**: `other: Undisclosed telemetry and privacy risk` **Risk Level**: Medium The Skill declares automatic analytics collection at invocation, processing, completion, and error stages. The documented event data includes a user identifier, invocation source, input type, question type, output metadata, timing information, and error metadata. ```javascript // When the Skill starts trackEvent("skill_start", { skill_id: "teaching-research-analyzer", user_id: userId, source: "workbuddy", input_type: "text" }); // When the Skill completes trackEvent("skill_complete", { skill_id: "teaching-research-analyzer", user_id: userId, output_format: "markdown", output_size: 3500, total_duration_ms: 4200, word_count: 450, question_type: "cloze" }); ``` The same section states that analytics failures are silently suppressed by an `analytics-sdk` wrapper using exception handling and a three-second timeout. ### Technical Analysis Telemetry is not required to perform the Skill's stated educational analysis. Associating analytics events with `user_id` may allow activity to be linked to an identifiable or pseudonymous user. The package does not contain the referenced analytics SDK, an endpoint configuration, a complete event schema, a privacy policy, a consent mechanism, or an opt-out mechanism. Consequently, the audit cannot verify: - Where telemetry is transmitted. - Which organization controls the collected data. - Whether additional fields are added by the absent SDK. - Whether error events include user prompts, generated answers, or other contextual data. - How long data is retained or with whom it is shared. - Whether identifiers are anonymized or pseudonymized. Silent failure handling also reduces observability by preventing users and operators from readily detecting unsuccessful or misconfigured transmissions. No executable telemetry implementation o ...[truncated 1696 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove telemetry unless it is necessary for the Skill's stated educational function. 2. Make analytics disabled by default and require explicit, informed opt-in consent before transmitting any event. 3. Provide a clearly documented opt-out that does not reduce core Skill functionality. 4. Publish the analytics endpoint, data controller, processor list, retention period, deletion procedure, and complete event schema. 5. Replace direct user identifiers with short-lived, randomly generated identifiers where correlation is genuinely necessary. 6. Do not transmit prompts, answers, educational records, IP addresses, device identifiers, or raw exception messages. 7. Apply strict field allowlisting in the analytics client so undocumented metadata cannot be attached automatically. 8. Include the actual analytics implementation and dependency declarations in the package so its behavior can be independently reviewed. 9. Use authenticated HTTPS transport and validate the destination against an explicit allowlist. 10. Record telemetry status in an operator-visible audit log rather than silently suppressing all failures. 11. Add automated tests confirming that telemetry remains inactive without consent and that error events cannot contain user content. ]]>