boboko / privacy & compliance · competitive survey

What privacy & compliance elsewhere can do that boboko can't yet

A feature-by-feature pass across GDPR/CCPA compliance tooling used by Shopify, WooCommerce, and dedicated consent-management platforms — sourced, not recalled from memory — checked against master and the substantial, unmerged Privacy branch ("Feature: Creating Privacy Basics") already built in this repo. For deciding what to finish and merge next, not a build order.

● have ◐ partial ○ missing
Most "partial" rows below are fully coded on the unmerged Privacy branch (53 files, +3127/‑24 across two commits: 9f540cb, 59303cf) but not on master — treated as partial, not have, until it merges. boboko:anonymize is the one privacy-adjacent command that already lives on master today.
01

Right of access & erasure

GDPR Art. 15 (access) and Art. 17 (erasure) — the two rights every DSAR tool is built around.

Data export request (right of access)
partial
On Privacy branch only: PrivacyService::requestExportForCustomer()/requestExportForUser() queue ExportDataSubjectJob, which gathers every registered provider's data and writes a CSV-per-provider zip via WriteExportToCsvListener. Not on master.
Data erasure request (right to be forgotten)
partial
On Privacy branch only: PrivacyService::requestErasureForCustomer()/requestErasureForUser(), extensible via config('core.privacy.providers') — the same config-array-registration pattern as NotificationRegistry, keyed off Modules\Core\Privacy\Contracts\PersonalDataProvider.
Cancellable grace period before erasure
partial
On Privacy branch only: 30-day default (core.privacy.grace_period_days), reverted automatically on login via CancelErasureOnLoginListener — same pattern Shopify's own account-deletion flow uses. No native platform documents this as a first-party primitive; it's usually left to a third-party app.
Immediate erasure for regulator/legal requests
partial
On Privacy branch only: requestImmediateErasureForCustomer()/ForUser(), typed to accept only Staff $requestedBy so a self-service path cannot reach it even by accident.
Multi-tenant erasure scoping (business account vs. individual login)
partial
On Privacy branch only, and a genuinely uncommon feature: PrivacyService splits every operation into Customer-scope vs. User-scope, plus a sole-owner cascade (CascadeCustomerErasureListener) when erasing the last linked User orphans a Customer. No researched competitor product handles B2B multi-seat erasure this explicitly.
Right to rectification (self-service data correction)
missing
No dedicated flow found on either branch — Art. 16 is generally satisfied today only incidentally, by a customer editing their own profile/address through existing account forms, not a tracked rectification request.
Dummy data anonymization for local dev
have
On master: src/Command/AnonymizeCommand.php (boboko:anonymize) — scrubs users/lunar_customers, environment-guarded to local only. Distinct from GDPR erasure; the Privacy branch README diff explicitly flags this is not the compliance tool.
02

Anonymization, pseudonymization & retention

Deletion isn't the only lawful outcome — these are three different operations, often confused with each other.

Legal-retention pseudonymization (orders/invoices)
partial
On Privacy branch only: OrderDataProvider::eraseForCustomer() clears PII fields but keeps order rows/totals/tax data intact, citing GDPR Art. 17(3)(b)'s legal-obligation exception — reports ErasureOutcome::Pseudonymized, not Erased, distinctly.
Per-provider retention policy, owned by the data's own module
partial
On Privacy branch only: PersonalDataProvider deliberately has no central taxonomy — each provider (CustomerDataProvider, AddressDataProvider, OrderDataProvider, CartDataProvider, ReviewDataProvider) decides erase vs. pseudonymize vs. skip for its own table. docs/privacy.md flags ReviewDataProvider's scope choice as needing review before relying on it.
Automatic data retention / auto-deletion after N days
missing
Neither branch has a scheduled sweep that erases stale data on its own — every erasure on the Privacy branch is triggered by an explicit request, not a retention-policy timer (e.g. "delete guest carts after 2 years," "purge OTP logs after 90 days").
Audit trail of what was erased/exported and why
partial
On Privacy branch only: DataErasureRequest.report stores the full per-provider outcome as a snapshot (not a live lookup), specifically so the audit record stays readable after the underlying data is gone.
03

Consent & cookies

What a visitor is asked before tracking starts, and whether that choice is recorded anywhere.

Cookie consent banner (categorized: essential/analytics/marketing)
missing
No code on either branch. Shopify ships a first-party Customer Privacy API recognizing four consent signals (analytics, marketing, preferences, sale-of-data); WooCommerce relies entirely on third-party plugins for this.
Granular marketing-consent tracking (email/SMS opt-in, per channel)
missing
Not modeled anywhere in Modules\Core — no consent flag found on the Customer/User models on either branch.
Timestamped, versioned consent log (audit trail per visitor)
missing
Standard feature of dedicated CMPs (OneTrust, Enzuzo, Consentmo) — a logged record of which policy version a visitor consented to and when. Nothing comparable exists in this codebase; the Privacy branch's audit trail covers erasure/export requests only, not consent events.
Google Consent Mode v2 / IAB TCF v2.3 integration
missing
Storefront/analytics-layer concern, not present in boboko-core at all — would live in the 3dealer storefront, not this package.
04

Policy & agreement management

Terms of service and privacy policy as tracked, versioned documents — not just static pages.

Terms-of-service / privacy-policy versioning
missing
No version-tracked policy document model on either branch — best practice researched: store version hashes or dated text alongside each acceptance record, review at least annually.
Per-user acceptance tracking (clickwrap audit trail)
missing
No record of "which policy version did this customer accept, and when" anywhere in Modules\Core. Researched as a standard requirement for surviving a legal dispute or regulatory inquiry.
Re-acceptance prompt on material policy change
missing
Depends on the versioning row above existing first — nothing to gate a re-prompt on today.
05

Payment data & PCI-DSS scope

Whether cardholder data ever actually reaches boboko's own infrastructure.

Card data never touches application servers (tokenization)
have
Verified from source: docs/lunar.md "Stripe integration" — payment flows through Lunar's Stripe driver (Lunar\Stripe\Facades\Stripe, fetchOrCreateIntent()/PaymentIntents), so PAN never lands in a boboko/Lunar database. Researched: this pattern alone can cut PCI-DSS scope by roughly 90% per industry sources.
Self-attested SAQ-A eligibility documentation
missing
The technical precondition (no card data touching the server) is met, but nothing in docs/ documents or asserts SAQ-A eligibility for a consuming app's own compliance paperwork.
06

Regional & regulatory coverage

Beyond GDPR — the other regimes a storefront selling outside the EU may need.

CCPA "Do Not Sell/Share My Info" opt-out
missing
No opt-out flag or page found on either branch. Shopify's Customer Privacy API models this as a distinct fourth consent signal ("sale of data") alongside analytics/marketing/preferences — boboko has no equivalent signal at all yet.
Geo-targeted regulatory detection (GDPR vs. CCPA vs. LGPD banner)
missing
Third-party CMPs (Consentmo, UniConsent) auto-detect visitor region to show the applicable banner/rights. No geo-based privacy-regime logic anywhere in this codebase.
Age verification / minor-data restrictions (COPPA-adjacent)
missing
No age gate or minor-specific data handling found on either branch.
07

Incident & vendor accountability

What happens when something goes wrong, or when a third party is handling data on the shop's behalf.

Data breach notification workflow
missing
No incident-tracking model or notification path found on either branch — GDPR Art. 33/34's 72-hour authority-notification and affected-subject-notification duties have no tooling here today.
Subprocessor / third-party vendor disclosure list
missing
No subprocessor registry in code — Stripe is the one third-party data processor identifiable from docs/lunar.md, but nothing formally tracks or discloses it as a subprocessor.
Data processing agreement (DPA) tracking per vendor
missing
Not applicable to application code directly, but no config or doc references a DPA registry either — purely a legal/ops artifact today, not represented in boboko-core at all.