Assess app privacy

Skill rpuls/my-own-suite/skills/assess-app-privacy

Assess a MOS app version's telemetry, external services, account dependencies, data processing, Terms of Service, privacy policy, and technical evidence; assign an evidence-backed MOS Privacy Posture and write or refresh the package privacy assessment. Use for new apps, app updates, policy-change alerts, stale reviews, or privacy documentation claims.From its SKILL.md

Install

npx -y skills add rpuls/my-own-suite --skill assess-app-privacy

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.1 KB, as published. Nobody here has run it

Assess App Privacy

Produce a bounded assessment of one exact MOS app-package candidate. Bind it to the independent package version, package digest, immutable source revision, upstream component versions, and artifact digests. Do not describe it as a legal audit, certification, or guarantee.

Required sources

Read apps/README.md, the assessment contracts in suite-manager/backend/src/apps/package-contracts.cjs (the canonical document shape, dimension vocabulary, and posture derivation), the app manifest, Dockerfiles, runtime configuration, and existing privacy-review.json first. Browse current primary upstream sources: release notes, server documentation, telemetry configuration, Terms of Service, privacy policy, license, and source code when documentation is insufficient.

Prefer observed package/runtime evidence over upstream marketing. Label every conclusion observed, configured, documented, or inferred. Record uncertainty as unknown; never turn missing evidence into a favorable result.

Workflow

Identify every packaged upstream component and immutable image digest or version.
Separate server behavior from web, desktop, and mobile client behavior.
Review known optional and required outbound requests, update checks, crash reports, usage analytics, push services, maps, AI services, SMTP, object storage, and other integrations.
Verify which supported settings MOS uses to disable optional telemetry. Record exact package evidence. Do not claim network silence from a configuration setting alone.
Review upstream Terms, privacy policy, license, publishing legal entity, effective dates, and account requirements. Record direct primary-source URLs and retrieval dates.
Classify the dimensions defined in apps/README.md. Derive the overall posture mechanically; do not select it by intuition.
Record provenance. Use the runtime-reported provider/model identifier when available and unknown otherwise. Never guess a model version. Record human review separately.
Write the candidate package's apps/<app>/privacy-review.json, update its compact manifest privacy block, and document package-owned telemetry controls. This review travels with the package snapshot when installed.
Run npm run apps:privacy:check, npm run apps:catalog after changing a review, npm run apps:catalog:check, and relevant manifest tests.

Catalog signing

Regenerating the catalog after any review or manifest change invalidates the committed Ed25519 catalog signature, so the signature half of apps:catalog:check fails until the key holder runs npm run apps:catalog:sign (prompts to paste the key). If you do not hold the signing key, that specific failure is expected: report re-signing as a required step before merge. Never work around it by editing .sig files or leaving the regenerated catalog uncommitted.

Change monitoring

Treat a policy content or effective-date change, upstream ownership change, app update, telemetry-setting change, new outbound dependency, or expired review as a reassessment trigger. A changed page hash signals review; it does not prove improvement or regression.

The repository review describes the latest available package. An installed MOS instance must display the review preserved in its installed package snapshot, not silently substitute the latest repository review. Use a separate advisory when new evidence invalidates reviews attached to already-installed package versions.

Wording

Use: "MOS disables known optional telemetry where the packaged app provides a supported setting." Keep upstream behavior scoped to the assessed version and evidence. Never use "telemetry-free", "only you hold the keys", or equivalent absolutes unless separately proven for the exact stated boundary.