100 lines
9.3 KiB
Markdown
100 lines
9.3 KiB
Markdown
---
|
|
name: store-declarations
|
|
description: Answer the store compliance forms for a mobile app or game - Google Play Data safety (API CSV), App content declarations (ads, app access, content rating IARC, target audience, advertising ID, government/financial/health/news), App Store App Privacy nutrition labels, age rating, export compliance. Use when the user fills in data safety, privacy labels, content rating, target audience, ads or advertising ID declarations, or gets Data safety CSV import errors.
|
|
---
|
|
|
|
# Store declarations
|
|
|
|
`storebound scan` proposes the Data safety and App Privacy answers from the detected SDKs and code (each item "detected (file:line)" or "ask owner") as a diff against `dataSafety` / `appPrivacy`; `--write` adds only the detected ones after the owner agrees.
|
|
|
|
Templates: `store/declarations.md` (Play App content + IARC answers), `store/app-privacy.md` (Apple labels), both
|
|
from `storebound init --profile app|game|subscription-app` (default `app`). They are honest starting points for a
|
|
typical app of that kind, not your answers: edit every line to match what your app really does. Data safety answers live in `dataSafety` of `storebound.config.ts`.
|
|
CLI: `storebound` (or `bunx storebound` in a project that has it, or `bun <toolchain>/cli/index.ts`).
|
|
|
|
## Order
|
|
1. **Inventory first.** List every SDK and server call: what leaves the device, who receives it, can the user turn
|
|
it off. The privacy policy (`privacy-policy` skill) must say the same; update it before the forms.
|
|
2. **Play Data safety (API).** Fill `dataSafety` (types not listed = not collected; `shared` = third party that is not
|
|
your service provider, e.g. ad networks; analytics vendors acting as processors are "collected" only).
|
|
`storebound play data-safety --dry --csv store/data-safety.csv` to review, then `storebound play data-safety`.
|
|
Play cannot read the form back: storebound keeps the hash of the last upload in `.storebound/data-safety.sha256`
|
|
and skips an unchanged CSV. After a hand edit in Play Console, `--force` sends the config's answers again.
|
|
Then check the summary in Play Console > Policy and programs > App content > Data safety.
|
|
3. **Play App content (UI).** Policy and programs > App content, each card with `store/declarations.md`:
|
|
privacy policy, app access, ads, content rating (IARC questionnaire), target audience and content, news, COVID-19,
|
|
data safety, government apps, financial features, health, advertising ID.
|
|
4. **Apple age rating (API).** `storebound apple appinfo` (all NONE except your overrides, e.g. `advertising: true`).
|
|
5. **Apple App Privacy (UI only).** App Store Connect > the app > App Privacy > Get Started / Edit, from
|
|
`store/app-privacy.md`; per data type: purposes > linked to identity > used for tracking. Then **Publish**.
|
|
- Purposes follow Apple's definitions (developer.apple.com/app-store/app-privacy-details/), one per Play purpose:
|
|
Play `advertising` (ads from an ad SDK) is **Third-Party Advertising only**, never also Developer's Advertising
|
|
or Marketing (that one is first-party ads or marketing to your own users: the owner's answer); `analytics` is
|
|
Analytics (not Product Personalization); `personalization` is Product Personalization; functionality, fraud,
|
|
account and `communications` are App Functionality (marketing messages: ask the owner).
|
|
- The owner's answers go into `appPrivacy.types`, keyed by Apple's type id (USER_ID, DEVICE_ID, GAMEPLAY_CONTENT,
|
|
ADVERTISING_DATA, CUSTOMER_SUPPORT, ENVIRONMENT_SCANNING, HANDS, HEAD ... all 35 in `cli/lib/app-privacy.ts`):
|
|
```ts
|
|
appPrivacy: { tracking: true, types: {
|
|
DEVICE_ID: { collected: true, linked: false, tracking: true, purposes: ['THIRD_PARTY_ADVERTISING', 'ANALYTICS'] },
|
|
ADVERTISING_DATA: { collected: true, linked: false, tracking: true, purposes: ['THIRD_PARTY_ADVERTISING'] },
|
|
GAMEPLAY_CONTENT: { collected: false },
|
|
} },
|
|
```
|
|
Purposes: THIRD_PARTY_ADVERTISING, DEVELOPERS_ADVERTISING, ANALYTICS, PRODUCT_PERSONALIZATION, APP_FUNCTIONALITY,
|
|
OTHER_PURPOSES. A set field wins over what storebound derives from `dataSafety`; types with no Play equivalent
|
|
(Advertising Data, Gameplay Content, Customer Support, Environment Scanning, Hands, Head) are answered only here.
|
|
`scan --write` proposes `collected` + `purposes` for detected types the block does not answer yet; `linked` and
|
|
`tracking` are never proposed (ask the owner). `storebound check` compares the block with the iOS project:
|
|
tracking true <-> `NSUserTrackingUsageDescription` and `NSPrivacyTracking` true; the app's
|
|
`NSPrivacyCollectedDataTypes` <-> the types marked collected (mismatches both ways).
|
|
6. **Export compliance.** `export-compliance` skill (`ITSAppUsesNonExemptEncryption` in Info.plist, `apple encryption`).
|
|
7. **Privacy manifest (iOS).** `privacy-manifest` skill; keep it consistent with App Privacy.
|
|
|
|
## Typical answers per profile (starting points, edit to match your app)
|
|
- **app** (utility / productivity, optional account, analytics, no ads): Data safety: email + user ids (account,
|
|
collected, functionality + account management), app interactions and diagnostics (analytics SDK as your processor:
|
|
collected, not shared), crash logs. Encrypted in transit: yes. Deletion: yes (in the app and on the web, see
|
|
`account-deletion`). Account creation: the methods you offer (e.g. `PSL_ACM_USER_ID_PASSWORD`, `PSL_ACM_OAUTH`).
|
|
Ads: No. Advertising ID: No (unless an SDK reads it). App access: sign-in needed, demo account given
|
|
(`review-access`). IARC category: not a game (utility, productivity, communication or social, reference ...).
|
|
Apple: Contact Info > Email Address and Identifiers > User ID are linked to the user (account), not used for tracking.
|
|
- **subscription-app**: as `app`, plus Purchases > Purchase History (linked, App Functionality) and Play
|
|
`PSL_PURCHASE_HISTORY` (collected, functionality). IARC: digital purchases Yes. App Review: subscriptions and their
|
|
disclosure (`store-subscriptions`).
|
|
- **game** (single-player free-to-play with ads + IAP, no accounts): approximate location (IP country; shared,
|
|
analytics + ads + fraud), app interactions (shared, analytics + ads), other app activity (save backup,
|
|
functionality), diagnostics (shared), device or other IDs (shared, ad id), purchase history (if your server checks
|
|
receipts). Encrypted in transit: yes. Deletion: yes, by email. Account creation: none. IARC (for games): everything
|
|
No except digital purchases Yes; target audience 13+; ads Yes; advertising ID yes (advertising, analytics, fraud
|
|
prevention); sign-in details: no login needed.
|
|
|
|
## Gotchas
|
|
- The Data safety CSV import **replaces** the whole form.
|
|
- `PSL_SUPPORTED_ACCOUNT_CREATION_METHODS` (e.g. `PSL_ACM_NONE`) is required even though Google's older sample CSV
|
|
omits it: without it the import fails with "Response missing". storebound always writes it.
|
|
- Conditional required rows: some questions become required by another answer, and Play refuses the import with
|
|
"Response missing for <id>" (400). Account creation not `PSL_ACM_NONE` -> `PSL_ACCOUNT_DELETION_URL` (from
|
|
`accounts.deletionUrl`) and `PSL_SUPPORT_DATA_DELETION_BY_USER` ("delete some or all data without deleting the
|
|
account?", `dataSafety.partialDeletion: true | false`, ask the owner); that answer true -> `PSL_DATA_DELETION_URL`
|
|
(`dataSafety.partialDeletionUrl`, default `accounts.deletionUrl`); `PSL_HAS_OUTSIDE_APP_ACCOUNTS` is refused next
|
|
to sign-up methods. A selected data type needs collected / shared, ephemeral, required / optional and a purpose
|
|
(a sharing purpose when shared). `storebound check` and `play data-safety --dry` name each missing row as
|
|
`missing: <id> (<when>; set <config field>)` and the real run stops before sending. Rules:
|
|
`DATA_SAFETY_RULES` / `typeRules` in `cli/lib/data-safety.ts`. A `dataSafety.extra` row with a generated
|
|
question id replaces that question (use it when your Play Console export shows other ids).
|
|
- "Optional" data is only allowed when the user can really choose for that data; otherwise required.
|
|
- Ads SDKs: read each network's own Play data safety guidance; adding a network can add data types.
|
|
- Target audience under 13 pulls the app into the Families policy (certified ad networks, no ad id): only if true.
|
|
- Apple: "linked to the user" is No when there are no accounts and nothing ties data to a name / email / phone;
|
|
with accounts, what you store under the account is linked.
|
|
- Accounts: Play asks for a delete-account URL in Data safety and Apple wants deletion inside the app
|
|
(`account-deletion` skill).
|
|
- Accounts are not email. A guest / username account (a name picked on the device, a server token, no password, no
|
|
email) is User ID only (Play `PSL_USER_ACCOUNT`, Apple Identifiers > User ID) and account creation "Username and other
|
|
authentication" (`PSL_ACM_USER_ID_OTHER_AUTH`): set `accounts.signUp: ['username']`. `storebound scan` marks Email
|
|
"detected" only for an email field, an `email` property in a request or schema, an email validation or endpoint, an
|
|
email sign-in call, an SDK that collects it (Google / Apple / Firebase sign-in) or `signUp: ['email-…']`; built
|
|
bundles (dist, build, the Capacitor webDir, minified files) only make it a question.
|
|
- App Privacy saved but not published = not submitted.
|
|
- Keep store answers, the privacy policy and the in-app privacy settings consistent; reviewers compare them.
|