Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a real user-testing toolkit, but it needs review because it can collect and transmit detailed user behavior data without enough privacy and safety controls.
Review before installing or deploying. Use this only where participants have clear notice and consent, restrict it to test environments or controlled studies, configure a trusted HTTPS endpoint, redact URLs/referrers and filenames, avoid collecting free-text unless needed, and fix the unsafe innerHTML rendering before using tenant- or user-controlled survey configuration.
assets/survey.js:204Configurable Product and Survey Content Is Inserted into the DOM Without Escaping
'+w.subtitle+'
'; c+=''; c+='assets/tracker.js:67Complete Page URLs and Referrers Are Transmitted Without Sensitive-Value Redaction
The documentation encourages embedded survey triggers during real usage flows and automatic triggering while users are 'doing things,' but does not warn about informed consent, interruption risk, or possible manipulation of user experience. This is risky in context because the feature is intended to activate dynamically inside production-like interactions, which can affect user decisions and collect feedback under conditions users may not expect.
The tracker batches and transmits detailed user telemetry to a configurable remote endpoint, including URL, referrer, interaction timing, clicks, focus, errors, and session identifiers, without any visible consent, notice, minimization, or origin restrictions in this code. In the skill context, this is more dangerous because the script is explicitly designed to comprehensively reconstruct user behavior paths and can silently exfiltrate sensitive behavioral metadata to any configured endpoint.
The README promotes comprehensive tracking of user actions, hesitation, confusion, dwell time, hotspots, and survey responses, but it does not warn integrators about privacy obligations, consent requirements, or data minimization. In this context, the omission is security/privacy-relevant because it encourages deployment of invasive behavioral collection by default, increasing the risk of unauthorized monitoring, regulatory noncompliance, and leakage of sensitive behavioral telemetry.
The documentation encourages embedded survey triggers during real usage flows and automatic triggering while users are 'doing things,' but does not warn about informed consent, interruption risk, or possible manipulation of user experience. This is risky in context because the feature is intended to activate dynamically inside production-like interactions, which can affect user decisions and collect feedback under conditions users may not expect.
The file's primary descriptive and instructional language is Chinese, and it does not offer any user choice of language or explain a region-specific requirement. Per the policy category, forcing a specific language without opt-in is a natural-language policy concern.
This JavaScript file contains user-facing natural-language task text instructing the user to translate a video specifically into Chinese. Under the policy, locale constraints should not be forced unless the skill offers opt-in or clearly documents a justified region-specific purpose, which is not present here.
The welcome text presented to users specifies Chinese as the required translation target. Because the file does not provide a language choice or a documented justification for this fixed locale, this is a natural-language locale policy violation.
Natural-language strings throughout the file, beginning with the header and continuing in all user-facing UI text, are fixed in Chinese. This can violate language/locale policy when no user opt-in or locale selection is offered and the tool is not clearly limited to a Chinese-only context.
The script records detailed behavioral events and survey responses through UserTestTracker.record and then flushes them, while activation is controlled purely by URL parameters such as mode=test and uid. Although the welcome text mentions that short questionnaires will appear, this file does not provide a clear privacy notice, consent flow, or data-use disclosure before telemetry collection begins, which creates a real privacy/compliance risk and could expose sensitive user behavior or free-text feedback.
This JavaScript config file documents that tracker data will be POSTed as JSON to a configured endpoint, which is a network transmission of user or system interaction data. While the code comments explain the mechanics, they do not warn users about privacy impact, data collection scope, or that interaction data will be sent off-page.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
* 格式：完整的 URL，tracker 会 POST JSON body 到此地址
*
* 示例：'https://your-api.com/track'
* 'https://analytics.your-product.com/collect'
*/
window.TRACKER_CONFIG.endpoint = window.TRACKER_CONFIG.endpoint || '';
When a user selects a file, the code records the file name, MIME type, and size and queues that metadata for remote transmission. Even without file contents, filenames and types often contain sensitive business or personal information, so silently collecting them increases privacy and data-leakage risk in this tracking-oriented skill.
At L013, TRACKER_DISABLED is described as a reporting-disable switch that still preserves records. But the buffer/flush description at L140 says that when disabled, the queue is cleared, which discards records rather than retaining them. This is an active contradiction in the documentation about data retention behavior.
The spec describes detailed behavioral telemetry collection and transmission, including user identifiers, session IDs, interaction events, errors, and survey data, but provides no mention of notice, consent, minimization, or privacy controls. In a tracking skill, that omission is contextually important because it normalizes potentially excessive collection and reporting of user activity to a remote endpoint without user-facing transparency.
The primary descriptive tagline is written in Chinese and the document does not provide an alternative language option or indicate that the locale restriction is intentional and justified. This can constitute a language/locale policy issue when a skill effectively forces one language without user opt-in.
The file stores per-user survey progress and answered-checkpoint state in sessionStorage under a key derived from uid without any explicit disclosure. While sessionStorage is limited to the browser session, it still persists participant state and indirectly links behavior to a user identifier, which is a privacy weakness if users are not informed or if uid contains sensitive identifiers.
The file's natural-language documentation and inline guidance are entirely in Chinese, with no indication of alternative language support or user choice. If this skill is intended for a broader audience, that can constitute a locale/language policy concern because the implementation materials assume a fixed language without opt-in or justification.
The comment at L275 says this API gets the original milestone name before mapping, but getOriginalMilestone is assigned to mapMilestone, which applies TRACKER_CONFIG.getMilestone and may transform the name. This is a direct documentation-to-code contradiction in the public API surface.
This markdown file presents all user-facing instructions, labels, and survey text exclusively in Chinese. Under the policy, forcing a specific language without user opt-in or documenting a justified locale constraint is a natural-language policy concern.
The entire skill documentation is written in Chinese and does not offer any language or locale choice, nor does it explain that the skill is intentionally region-specific. Under the stated policy, forcing a specific language without opt-in or justification is a natural-language policy concern.
No suspicious patterns detected.