Review policy

Who gets reviewed

Store apps do. Tenant-private apps do not.

That is a structural decision, not a courtesy. The central case this platform exists for is a company building a mini app of its own ERP for its own employees. If every change to that ERP joined a Sollar review queue, the platform would be unusable in a corporate setting — an internal release cycle cannot depend on a vendor’s service level.

Lark separates them the same way: self-built apps confined to one tenant with no Lark review, versus store apps with official review. DingTalk does the same for enterprise-internal applications, where an administrator creates the app under the corpid and grants its scopes without a platform gate.

Skipping review is not skipping cryptography. A tenant-private package is countersigned by the organisation’s CA, and Sollar’s client refuses any package lacking a countersignature from either the store or an organisation CA.

Entity verification

To publish in the public store, a developer must be a verified entity.

Type	May publish	Requires
Individual	Apps touching no sensitive data, no external auth	Verified identity
Organisation	Anything, subject to category	Business registration + a responsible contact
Tenant (private)	For itself only	Already a contracted customer

Sensitive categories — health, finance, education involving minors — require additional qualification. This is not decorative bureaucracy: it is what makes it possible to refuse a “payroll advance loan” mini app from an entity with no licence to offer one.

The model follows WeChat’s, which recognises six subject types, each enabling different service categories and each requiring its own documents.

The checklist

Every store submission is checked against all of this. Tenant-private packages are validated mechanically against the same schema, without the human review.

Manifest and permissions

1. The manifest validates against the published schema.
2. Every declared permission has a purpose that plausibly matches the app’s stated function.
3. No permission is declared that the code never uses. This catches more submissions than anything else — a scope declared “in case we need it later” reads as over-collection, because it is.
4. Prompts appear at the point of use, not in a wall at launch.
5. Refusal produces a working degraded path, not a dead end or a re-prompt loop.

Network and code

6. The network allowlist is justifiable. An unexplained host is a question to the developer, not an automatic rejection.
7. The CSP meets the floor: script-src 'self', no 'unsafe-eval', no remote script host.
8. No eval, no Function(), no dynamically constructed code.
9. An SBOM is present and contains no high-severity known vulnerability.
10. No obfuscation that prevents review from reading what the code does.

Actions

11. Every actions[] entry describes honestly what it does.
12. destructive is set where the effect is destructive. An action that releases an order to a vendor and is marked read_only is a rejection, and a serious one.
13. confirm is appropriate to the annotations. never with read_only: false is refused.
14. Descriptions do not attempt to steer an agent toward actions the user did not ask for.

Content and conduct

15. Reporting and blocking are reachable from inside the mini app (Guideline 4.7.1).
16. A content rating is declared (4.7.5).
17. A privacy policy exists and covers what the permissions actually collect.
18. A monitored vendor.contact.

Reasons for rejection

WeChat publishes a specific list, and several entries map directly onto abuse any mini app store has to police. Quoted, because the wording is precise:

• “诱导分享、诱导添加、诱导关注公众号、诱导下载等” — induced sharing, adding, following or downloading; requiring a user to share before they can use the app.
• “小程序的页面内容中不能存在虚假、欺诈类内容” — false or fraudulent content, including fake prizes and campaigns.
• “禁止视频、音乐、语音等多媒体的自动播放” — automatic playback of video, music or audio is prohibited.
• “不能做小程序导航，不能做小程序链接互推，小程序排行榜等” — no navigation between mini apps, no cross-promotion, no ranking lists.

The last one deserves emphasis. A store where mini apps promote each other stops being a tool directory and becomes an attention marketplace, and the tools lose.

Sollar adds three of its own:

• A misleading manifest — a permission whose purpose does not match the function.
• Actions that lie about destructiveness.
• Any attempt to collect a user credential inside the runtime’s WebView. This one is not a warning and not a request for changes; it is a rejection and a look at everything else the developer has published.

Approved is not published

Review approves; the developer decides when to publish. This is the Chrome Web Store’s separation and it is worth copying — it lets a release coordinate with a product launch, a campaign, or a maintenance window.

With an expiry: an unpublished approval lapses after 30 days. Without that, old approvals accumulate whose security context has since changed.

Reporting and moderation

Guideline 4.7.1 requires that offered software “include a method for filtering objectionable material, a mechanism to report content and timely responses to concerns, and the ability to block abusive users.”

Concretely:

• Report is reachable from inside any mini app, in the host’s chrome — it does not depend on the mini app implementing it, because a malicious mini app would not.
• A user can block a mini app; an administrator can block one for the whole organisation.
• A published response time for reports.
• vendor.contact is mandatory in the manifest.

Emergency revocation

Distinct from rollback. When a published version is dangerous:

1. A signed revocation list, consulted at launch, with a short TTL.
2. The client refuses to open the revoked version; if a safe version exists, it updates first.
3. If the whole app is revoked, it leaves the catalogue and installed copies stop opening.

The client has to work offline, so there is a window. A mini app with sensitive permissions can be required to verify online at launch — declared in the manifest.

What review cannot do

Stated plainly:

• Review cannot verify an annotation. Nothing proves an action marked read_only really is. What review adds is that the claim is attributable to a key and cannot be changed silently afterwards.
• Review reads a snapshot. A mini app’s backend can change its behaviour the day after approval. The manifest cannot — which is why capabilities live in the manifest and not in a server response.
• Review is not an audit. An approved mini app has passed a checklist, not a penetration test.

Nothing in this section has itself been through an independent audit; the platform is specified, not built.