Locara

22 — Content Policy

What apps are allowed in the Locara registry, and what aren’t. This is policy, not architecture — but it’s enforced through the same review pipeline as the technical checks.

The framework lets you build any app you want; the registry chooses what to surface. Sideload (.locapp files) is unaffected by this policy — users can install whatever they want from outside the registry.

Principles

  1. Open by default. Most apps are allowed. We start permissive and tighten only when specific harms emerge.
  2. Local doesn’t mean lawless. “Fully local” is a property of where data lives, not a license to ignore laws or harm users.
  3. Disclosure, not paternalism. Mature/edgy content is allowed if clearly disclosed; users get to decide for themselves.
  4. Capability transparency limits abuse. Apps that can’t access network, can’t run arbitrary code, and can’t access broader filesystem are by construction limited in the harm they can do.
  5. Predictable rules > arbitrary judgment. Reasons for rejection are mechanical and documented. Apple’s opacity is the cautionary tale.
  6. Apply equally. First-party (Locara-team-built) apps must meet the same bar.

What is allowed

The default answer is yes. Apps that:

  • Help users be productive, creative, learn, communicate.
  • Process documents, audio, images, video, code locally.
  • Provide chat / assistant / agent experiences.
  • Run inference on local data.
  • Use sensitive local data (medical notes, journals, finances) — especially these, since the local-only architecture is the value proposition.
  • Have mature themes, dark themes, edgy humor, political views, religious content — when properly disclosed.
  • Cover topics other stores find awkward (drugs harm-reduction info, sex education, conspiracy-debunking, etc.) when factual and disclosed.

The privacy thesis means Locara is the right place for apps that handle sensitive data. We should be more permissive, not less.

What is not allowed

The hard prohibitions. An app falls into one of these categories → rejected, no exceptions, no appeal beyond clarification.

1. Illegal content

  • CSAM (child sexual abuse material) — generation, viewing, processing. Zero tolerance. Reported to law enforcement where required.
  • Content depicting real, unconsented sexual content (revenge porn, deepfake of real individuals).
  • Materials that primarily exist to enable specific crimes (e.g., explicit doxxing tooling, swatting tooling).
  • Apps designed to facilitate harm to specific named individuals.

2. Malware / abuse

  • Apps that try to evade Locara’s capability declarations (the sandbox catches most of this; intent to evade is itself disqualifying).
  • Apps that mine cryptocurrency without explicit user disclosure + opt-in.
  • Apps that serve as malware delivery vehicles regardless of declared intent.
  • Apps that present false provenance or impersonate other publishers.

3. Deceptive or fraudulent

  • Apps that misrepresent what they do (manifest says X, app does Y).
  • Apps designed primarily to scam users.
  • Apps impersonating other apps, brands, or governments without authorization.

4. Hateful conduct

  • Apps that target individuals or groups based on protected characteristics (race, religion, nationality, sexual orientation, gender identity, disability) for harassment, dehumanization, or violence.
  • Distinction: an app that discusses hate speech (academically, journalistically, for moderation training) is allowed; an app generating hate speech as its product is not.

5. Real-time threat to safety

  • Apps designed to generate weapons of mass effect (CBRN — chemical, biological, radiological, nuclear) instructions.
  • Apps designed to generate explicit instructions for violence against specific persons.
  • Apps providing dangerous medical advice presented as authoritative without disclaimer (e.g., “AI doctor” with no caveats).

6. Sexually explicit content with consent / age issues

  • AI-generated nudity or sexual content depicting minors (real or synthetic).
  • AI-generated nudity / sexual content depicting real, identifiable individuals without consent.
  • Adult content is allowed when:
    • All depicted individuals are clearly adults and synthetic, or consenting adults if real.
    • The app is age-gated.
    • The app is clearly tagged “adult / NSFW.”
    • The app does not target users under 18 in any way.

Categories that require disclosure

Apps in these categories are allowed but must declare in their manifest’s content_warnings array, surfaced prominently on the app card:

  • Adult / NSFW. Sexually explicit content for consenting adults.
  • Mature themes. Violence, drug use, self-harm references, intense psychological themes.
  • AI-generated likenesses. Apps that can produce images / video / audio of real or synthetic individuals — deepfake risk.
  • Medical / health. Apps that process medical info or provide health-related output. Must include clear “not medical advice” disclaimers.
  • Legal. Apps providing legal-adjacent output. Must disclaim “not legal advice.”
  • Financial. Apps providing investment / tax / financial output. Must disclaim “not financial advice.”
  • Therapeutic / mental health. Apps providing emotional support / therapy-adjacent. Must include crisis-support resources + “not a substitute for therapy” disclaimer.

The capability badge system surfaces these so users see them before install.

Categories that require additional review

Some app categories need closer review (not auto-approve, regardless of capability profile):

  • Children’s apps (declared target audience under 13). Must comply with COPPA + best practices. Stricter capability defaults.
  • Apps using device.camera + device.microphone together with persistent storage (potential surveillance use case).
  • Apps with net: true declarations for any reason (since they break the fully-local pitch).
  • Apps using LLMs to generate identity-related output (e.g., resumes, personal statements). Risk of hallucinated detail.
  • Apps in regulated industries (medical, legal, financial — see 26-compliance.md when written).

Handling AI-specific concerns

LLMs generate content that the app author didn’t write. Some risks are unique to AI apps:

  • Hallucinated facts. Apps must not present LLM output as authoritative facts in safety-critical domains. Apps in medical/legal/financial categories must include disclaimers (see disclosure section).
  • Prompt injection vulnerability. Apps should be robust to malicious user input (or content) attempting to break system prompts. Locara provides recommended patterns; we don’t enforce.
  • Bias amplification. LLMs reflect biases in their training data. We don’t ban biased models per se, but apps targeting hiring / lending / law enforcement / etc. need explicit disclosure of model limitations.
  • Generated likenesses. Apps producing convincing audio, video, or image of identifiable people require explicit user attestation that they have consent / rights.
  • Persuasion / manipulation tools. Apps explicitly designed to manipulate users (think: dating profile generators, “make me sound charming”) are allowed but require the “AI-generated content” disclosure. Apps designed to manipulate third parties on user’s behalf (e.g., scam-letter generator) are not.

Process

How an app gets reviewed

  1. Submission via locara publish triggers automated checks (capability validation, signing, static analysis).
  2. The submission’s manifest is classified for risk:
    • Low-risk capabilities + no content_warnings → auto-approve.
    • Capability or content flags → human review.
  3. Human reviewer (initially the project lead) reads the app metadata, may install + spot-check the app’s behavior, makes a determination.
  4. Outcome:
    • Approved — app goes live.
    • Approved with conditions — e.g., add specific disclaimers, retag content warnings.
    • Rejected — clear reason cited; appeal possible.

How a reviewer decides

Reviewers ask:

  • Does the manifest match the app’s actual behavior?
  • Are content warnings accurate and complete?
  • Does the capability surface match the stated purpose?
  • Are required disclaimers present (medical/legal/financial/etc.)?
  • Does the app fall into any prohibited category?

Reasons for rejection are written clearly and tied to specific policy points. Vague “we don’t like this” rejections are not allowed.

Appeals

A rejected publisher can appeal with:

  • Clarification of intent (what the app is actually doing).
  • Manifest / metadata changes.
  • Specific content rewording.

Appeals go to a different reviewer where possible (in v1: project lead reviews own appeals, but second opinion sought for borderline cases).

Takedowns

An app already in the registry can be revoked if:

  • Post-publication evidence emerges of policy violation.
  • An update changes behavior in a non-policy-compliant way.
  • A user reports an issue that turns out to be valid.

Takedown process: same as the kill-switch in 14-trust-safety.md. Revocation is public, signed, logged. Affected users are notified. Postmortem published for any non-trivial case.

Special considerations for “fully local” apps

The architectural property “the app cannot phone home” limits some classes of harm but enables others. Specifically:

Reduced harm surfaces:

  • Data theft via the app is structurally impossible for fully-local apps (they can’t reach the network).
  • Coordinated harassment campaigns can’t be orchestrated from a fully-local app.
  • Real-time monitoring / spying is bounded by the user’s own device.

Possibly increased harm surfaces:

  • Generated illegal content (CSAM etc.) doesn’t leave the device, but is still illegal to possess + create.
  • Apps that ingest / process illegal content the user already has (rare but possible).
  • Apps facilitating self-harm without external alarm (no mandatory reporting via cloud).

The registry’s policy applies to the app’s design and intent, not whether the harm could “leak.” A fully-local CSAM-generation app is rejected even though no data leaves the device.

What the policy doesn’t cover

  • Quality. A boring, useless, but not harmful app is allowed. The market decides. (We may surface “low-engagement” apps less prominently in discovery.)
  • Aesthetic preferences. Ugly UI doesn’t get rejected.
  • Political views. Apps with various political stances are allowed if they don’t violate other policies.
  • Religious content. Same.
  • Adult content (with proper disclosure + age-gating) is allowed; we don’t moralize.

v1 enforcement reality

In v1 (small catalog, hand-curated):

  • Reviewer = project lead.
  • Volume is low; every app gets human review regardless of risk class.
  • Policy refinements happen as edge cases emerge.

In v2-v3 (larger catalog):

  • Trusted-reviewer program.
  • Auto-approve for low-risk well-known publishers.
  • Policy firms up based on real cases.
  • Public appeals process.

Open questions

  • (open) How do we handle apps that produce factually-correct but socially-controversial output (e.g., dietary advice contradicting mainstream guidance)? Probably: allow with disclosure.
  • (open) Cryptocurrency-adjacent apps (wallet UIs, mining pool UIs) — allow with disclosure or block? Leaning allow with disclosure; block if the primary purpose is scam-adjacent.
  • (open) Apps that explicitly bypass content filters of upstream models (jailbreak frameworks). Probably allow if the use is research / education / red-teaming; block if marketed as “uncensored” without context.
  • (open) Bug bounties — do they apply to content policy violations, or only security issues? Probably yes, both.

Cross-references