What Mesh will do about GDPR, CRA, OWASP and WCAG.

Permanent guardrails#

These are doctrine, not per-task decisions. They bind every session and every tool, so the posture cannot drift. They are written as what not to do, because on a WordPress plugin the common compliance reflexes are the dangerous ones.

Compliance status#

Mesh is a parked Phase 0 skeleton with no running code path. Every framework row is honestly not assessed, there is nothing executing to assess yet. "Not assessed" means no claim is made; it is never an implied pass. Statuses move only with a concrete cited mechanism from Phase 1+.

Data handling#

• No running data path. Mesh is a Phase 0 skeleton: no crawler, no storage, no admin screens. Nothing processes visitor or site-owner data yet.
• Designed (not built). Plan §16 specifies pasted-cookie encryption at rest (Core\HeaderCipher, AES-256-CBC, keyed off wp_salt('auth'), decrypt in-memory only, never logged), a WP Privacy API exporter + eraser, a default-90-day retention sweep, a first-use disclaimer hard gate, and an uninstall data-wipe. Each is scaffolded or specified; none is implemented.
• Crawl politeness (designed). robots.txt enforced with no opt-out and a 1 req/sec rate limit (plan §10); XML hardening (LIBXML_NONET) on the link parser (plan §11). The crawler and parser are not built.
• No phone-home. No activation telemetry and no anonymous usage statistics by design.
• Documentation site. This site self-hosts its webfont for GDPR; there is no third-party font CDN call.

Security measures#

Structurally true now at Phase 0 (these are absence properties, trivially true for a skeleton and binding as guardrails going forward):

• No .env. Secrets come from wp-config.php / WP options / WP salts; .gitignore ignores .env*; no .env in the repo; HeaderCipher keys off wp_salt. Status: met.
• No plugin-level password store. Mesh stores no passwords by design; nothing in src/ touches auth or shadows the WP password store. Status: met.
• No server-level header injection. Mesh injects no CSP/TLS/HSTS headers; the doctrine forbids it (CLAUDE.md §Compliance §1). Status: met.
• No Composer / npm runtime dependency. Plan §6.3; D3 v7 is vendored. The SBOM is near-empty by design. Status: met.
• Single grep-able hook registry (src/Plugin.php), convention scaffolded; bounded because there is almost no surface yet. Status: partial.
• Secrets: none hardcoded in the plugin codebase.

Reporting a vulnerability#

This is the shared Gillish Coordinated Vulnerability Disclosure (CVD) policy. It is studio-wide and governs every Gillish product with digital elements, Node, Cairnstone, Feed, Mesh, Core, free and Pro alike, not just Mesh. The canonical source is the Gillish Core CVD policy; this is its public rendering.

Safe harbour. Good-faith security research consistent with this policy is welcomed. The studio will not pursue or support legal action against a reporter who acts in good faith, stays in scope, avoids privacy violations / data destruction / service degradation, tests only against their own installation, and gives reasonable time to remediate before public disclosure.

What to expect. This is a one-person studio with no bug bounty and no monetary reward: stated plainly so expectations are correct. Best-effort target timelines:

• Acknowledge receipt: within 5 business days.
• Triage and initial assessment: within 10 business days.
• Fix or mitigation: prioritised by severity; no fixed guarantee, but actively-exploited / high-severity issues are worked first and shipped as soon as a safe fix exists.
• Free security updates for supported versions within the declared support period.

Coordinated disclosure. Fix first, disclose second. After a fix ships, a public security advisory is published (the product's readme.txt / changelog and this docs site), crediting the reporter unless they ask otherwise. Target window: 90 days from triage to public disclosure, shortened if a fix ships sooner or extended by mutual agreement if a fix is genuinely hard. Already-public or actively-exploited issues are disclosed as fast as a fix allows.

Out of scope. Your WordPress core, server, hosting, other plugins, and site configuration; third-party services you connect. This policy covers the Gillish plugin code only.

An actively-exploited vulnerability, or a report coinciding with a severe incident impacting product security, additionally triggers the studio's regulatory reporting workflow (CRA Article 14: notification to the coordinating CSIRT and ENISA on a fixed clock), run in parallel with remediation.

Accessibility#

Conformance target is WCAG 2.2 AA, inherited from the shared Gillish design rules. Status: not assessed, no UI exists yet (templates/ is empty), so there is no real surface to audit. Assessable only once admin screens are built (Phase 1+); there is no public frontend by design. When the UI is built the bar is uniform, semantic HTML, required ARIA on dynamic components, full keyboard navigation, and a visible focus indicator on every interactive element, with suppressing the focus outline without a replacement prohibited, and verification is by exercising the real surface in a browser, since a passing test does not prove a surface is usable.

Dependencies and SBOM#

• Minimal runtime surface. No Composer or npm runtime dependency; D3 v7 is vendored (plan §6.3). The third-party supply chain is therefore near-empty by design.
• License audit. Every shipped third-party asset must be GPLv2-or-later compatible; this is checked before anything is added.
• SBOM: not implemented. No CycloneDX or SPDX generation runs today. The CRA programme is Core-owned and phased and Mesh is pre-launch; stated honestly rather than fabricated. It will not be claimed as met until it ships.

Not yet assessed#

The honest gaps, listed so a reviewer can see exactly what is open. At Phase 0 this is, by design, almost everything:

• Every framework status (GDPR, CCPA/CPRA, CRA, EAA/WCAG 2.2 AA, OWASP Top 10), no running code path to assess.
• Every designed control, HeaderCipher encryption at rest, the WP Privacy API exporter/eraser, the retention sweep, the first-use disclaimer, the uninstall data-wipe, robots.txt politeness, and XML hardening, is designed-but-not-built.
• CRA process artefacts, SBOM generation, CVD policy, Annex VII technical documentation, EU DoC + CE, declared support period, and the Art. 14 reporting capability, not built.
• Per-entry-point sanitisation / nonce / capability checks, doctrine, but there are no entry points yet to exercise it.

From Phase 1+, statuses move off "not assessed" only with a concrete cited mechanism (a test, an audit, a code path), feeding the Core-owned CRA programme's per-tool gap audit. Input on any of this goes back to the maintainer directly.