SmrtHub Privacy & Security Policy (Draft v0.1)¶

Authoritative privacy + security posture for evaluating SmrtHub in enterprise environments. Applies to all SmrtHub runtimes (C# and Python), packaging artifacts, and operational tooling.

1. Status & Stewardship¶

Owner: Platform Engineering / Security Guild
Document State: Draft v0.1 (2025-11-18)
Applies To: All SmrtHub desktop/runtime components, support tooling, and documentation.
Interfaces: Reads from SmrtHub-Operational-Data-Policy, SmrtHub.Logging, Smrt.Config, Smrt.Security, and SmrtHub-Asset-Policy for canonical behaviors.

2. Purpose & Scope¶

Establish guardrails for how SmrtHub collects, stores, processes, and retains data (privacy) and how the platform is protected against unauthorized access or tampering (security).
Covers desktop supervisor, runtime apps/services, Python workers, shared libraries, build outputs, and support bundle workflows.
Excludes customer-authored automation scripts and third-party extensions; those must conform to this policy before distribution.

3. Governance Model¶

Role	Responsibilities
Platform Engineering	Owns policy, enforces config/log/layout standards, reviews PRs touching privileged code paths.
Security Guild	Performs threat modeling, approves crypto/secret-handling changes, drives penetration testing.
Documentation Team	Ensures MKDocs/README parity and publishes customer-facing excerpts.
Release Management	Verifies policy regression checklist prior to GA builds.

Change Control: Modifications require Platform + Security approval. Each release note must include a link to this policy section summarizing change impact.

4. Data Classification & Handling¶

Data Class	Examples	Handling Rules
Critical Secrets	API keys, OAuth tokens, service passwords	Never persisted in config/state/logs. Store via `Smrt.Security.WindowsCredentialHelper` (Windows Credential Manager / DPAPI).
Operational Config	`<slug>-config.json`, `<slug>-state.json` under `%AppData%/SmrtHub/Config`	Atomic writes via `Smrt.Config`; `.bak` backups permitted; redact secrets prior to persistence.
Telemetry & Logs	`<slug>-log.txt` / `<slug>-log.json`	PII scrubbing enabled by default (C# + Python). No raw extraction text or documents recorded. 14-day retention unless policy overrides.
Support Bundles	Bundled logs/config snapshots for diagnostics	Generated via `Smrt.SupportBundle`; bundles encrypted/transferred per customer agreement.

Data primarily resides under %AppData% / %LocalAppData% roots per the Operational Data Policy to inherit Windows profile ACLs. Machine-wide artifacts that must be shared across identities (Storage Guard secret/snapshots/signatures/logs plus SmrtSpace metadata) live under %ProgramData%/SmrtHub/Config or %ProgramData%/SmrtHub/Logs via SharedDataPathResolver and StorageGuardPaths. These helpers migrate any legacy %AppData% copies on first write and fall back only when ProgramData is unavailable. The Privacy/Security checklist (Tools/Privacy-Security/Invoke-PrivacySecurityChecklist.ps1) explicitly verifies those ProgramData directories and warns if a component attempts to write to a stray location. No registry persistence.

5. Privacy Principles¶

Data Minimization: Components store only the config/state strictly required to resume operations. No raw image/PDF payloads retained.
Transparency: User-facing docs (MKDocs > Getting Started) describe what is stored locally, how logs are structured, and how to purge them via Clean scripts.
User Control: Support for manual log/config purge via Tools/Clean-Build scripts and UI entry points (Supervisor tray). Future work: expose self-service “Delete My Data” flow.
Consent & Notices: Enterprise admins must disclose SmrtHub deployment to employees; tray UI includes “Privacy & Logging” link to this policy.
PII Safeguards: Logging stack recursively scrubs emails, tokens, auth headers, and credential-like strings before disk writes. Structured logs never contain full extraction text, clipboard payloads, or credential bodies.

Privacy TODOs¶

Provide template customer notice + DPIA worksheet referencing this policy. (Owner: Documentation)
Define explicit processes for responding to data subject requests (export/delete) once cloud integrations expand beyond existing providers. (Owner: Security Guild)

6. Security Architecture¶

Process Supervision: SmrtHubSupervisor enforces lifecycle, restart limits, and controlled shutdown to prevent orphaned workers.
Path Discipline: Smrt.Config.ConfigPathResolver guarantees canonical directories; arbitrary write locations are forbidden, mitigating path traversal risk.
Logging Hardening: SmrtHub.Logging writes dual sinks with optional Windows Event Log emission (Production + admin only). HTML export sanitized and offline.
Secret Storage: Smrt.Security.WindowsCredentialHelper backs sensitive strings with Windows Credential Manager; helpers expose Win32 error codes for logging without secrets.
Packaging & Build: Single RID target (win-x64) reduces attack surface; shared log/config defaults distributed via embedded resources.
Transport Security: In-proc + supervisor channels use named pipes/loopback HTTP. External connectors must terminate TLS 1.2+ with modern cipher suites before releasing payloads to SmrtHub. Document exceptions in release notes.
Least Privilege: All runtime processes execute as the signed-in user; elevation only needed for optional Event Log sink or installer tasks.
Traceability: W3C trace context propagation ensures cross-component correlation for incident response.

Security TODOs¶

Document encryption strategy for Support Bundles at rest and in transit (inherits host filesystem). (Owner: Platform)
Define threat model for future arm64 port before enabling additional architectures. (Owner: Security Guild)
Publish third-party dependency SBOM + vulnerability monitoring cadence. (Owner: Release Mgmt)

6.2 External Connector TLS & Network Requirements¶

Default behavior: Extraction pipelines run locally. No outbound network traffic occurs unless an administrator enables a cloud connector.
When cloud connectors are enabled:
TLS version: Require TLS 1.2 or higher for all outbound HTTPS calls to configured providers.
Cipher suites: Enforce strong cipher suites (e.g., AES-GCM). Document the allowed cipher list in deployment notes.
Certificate validation: Rely on Windows certificate validation. Do not disable revocation checks or install permissive roots.
Proxy inspection: If HTTPS inspection is in use, ensure the proxy certificate is trusted and protect inspection logs.
Data minimization: Administrators should review each provider’s privacy terms separately.
Documentation: Record which provider(s) are enabled and endpoint URLs in the DPIA worksheet.

6.1 Dependency SBOM & Vulnerability Monitoring¶

SBOM generation (per release):
Run dotnet list SmrtApps/SmrtHub.sln package --include-transitive --format json > Compliance/SBOM/<version>/dotnet-packages.json after restoring packages.
Activate SmrtApps/PythonApp/.venv and run python -m pip list --format=json > Compliance/SBOM/<version>/python-packages.json.
Check in both files with a short README.md noting the release tag and generation timestamp under Compliance/SBOM/<version>/.
Vulnerability cadence:
Weekly, run dotnet list SmrtApps/SmrtHub.sln package --vulnerable and archive the output beside the latest SBOM folder.
In the Python venv, run pip-audit (or python -m pip_audit) weekly; log findings alongside the SBOM artifacts.
High/critical findings open backlog issues for package upgrades; release management confirms fixes before the next GA build.
Current state: These steps rely only on the existing .NET SDK and Python tooling already required for the repo, so they can be executed immediately without new automation.

6.3 Storage Guard Telemetry & Evidence¶

Runtime guard: SmrtHubSupervisor now captures a storage guard snapshot at boot, validating the active SmrtSpace root’s drive (BitLocker status, free-space %, readiness) and the presence of the associated sync client.
Persistence: The latest snapshot, signature, and logs live under %ProgramData%/SmrtHub/Logs/system-info/, ensuring LocalSystem services and user-scoped tooling share a single evidence folder. Legacy %LocalAppData% directories are migrated automatically on first run, and the helper falls back to %LocalAppData% only when ProgramData is unavailable.
Shared secret: %ProgramData%/SmrtHub/Config/storage-guard/storage-guard-secret.json stores the HMAC credential so the LocalSystem service, Supervisor, and Support Bundle harness all read the same material regardless of account context. Reinstalling the service rotates this file automatically.
SmrtSpace metadata: %AppData%/SmrtHub/Config/smrt-space/active_smrtspace.json declares the active SmrtSpace name/root for the current Windows user.
Support bundle artifact: Every support bundle contains system-info/storage-guard.json, giving support and auditors immutable proof of the checks collected at export time.

7. Access Control & Authentication¶

Relies on Windows user profile isolation; each user receives dedicated %AppData%/SmrtHub roots.
Supervisor/service binaries never grant additional privileges or impersonate other users.
Secrets retrieved via Smrt.Security must be scoped per user; shared-machine scenarios require IT-managed service accounts.
Optional OTEL/HTTP integrations must propagate trace context without embedding tokens.

8. Logging, Monitoring, and Incident Response¶

Dual log modalities with correlation IDs enable rapid diagnostics.
Support Bundle exporter captures recent logs/configs with manifest hashing; bundles intended for secure transfer to SmrtHub support.
HTML log export yields sanitized viewer for local triage.
Incident workflow:
Collect component + supervisor logs via Support Bundle.
Validate integrity using manifest hashes.
Apply containment steps (stop supervisor, revoke credentials via Windows Credential Manager) if compromise suspected.
Escalate to Security Guild; file report referencing this policy.

8.1 Support Bundle Encryption & Transfer¶

Phase	Guidance
At Rest (Local)	Bundles default to `%UserProfile%\\Desktop\\SmrtHub-Bundles` and inherit workstation disk encryption (BitLocker). IT must ensure SmrtHub devices enforce disk encryption.
Optional Local Encryption	Before sharing, compress the bundle with AES-256 encryption (Zip/7z) using a support-issued passphrase. Store passphrases in Windows Credential Manager or corporate vaults—never plaintext files.
In Transit	Transfer via approved secure channels (SFTP, managed FTPS portal, encrypted email attachment). SnapRun Labs does not host automatic upload endpoints; customers remain in control.
Retention	Delete local bundles after transfer unless an incident remains open. SnapRun Labs support deletes received bundles once the case closes per contract.

Operational Procedure 1. Generate bundle via Supervisor tray or Smrt.SupportBundle CLI. 2. Inspect contents; remove unrelated corporate artifacts. 3. Encrypt the archive (Zip/7z) with a strong passphrase. 4. Send through the approved secure channel and share the passphrase via a separate medium. 5. Delete the local copy after confirming receipt.

9. Data Retention & Destruction¶

Artifact	Default Retention	Destruction Method
Logs	14 rolled files (~14 days). Configurable via `Smrt.Logging` options.	Automatic deletion by Serilog; manual purge via Clean scripts.
Config/State	Persist until uninstall or schema migration requires rewrite.	Manual removal (`Tools/Clean-Build/CleanApps.ps1` with `-TargetScope`), or uninstall script.
Support Bundles	30 days in default export location unless case remains open.	Manual deletion by admin; bundles stored outside repo.

Admins must enforce local disk encryption policies (BitLocker) for laptops/workstations running SmrtHub to cover data at rest.

10. Compliance Alignment¶

Framework	Mapping
SOC 2	Logging, access control, and change management sections provide coverage; formal control IDs tracked externally.
GDPR	Privacy principles + TODOs satisfy data minimization & transparency; subject rights workflow pending (see TODO).
HIPAA	Not officially supported; deployments processing PHI must implement additional safeguards (network segmentation, audit review).

11. Shared Responsibility & Onboarding Acknowledgement¶

Control Area	SnapRun Labs (SmrtHub)	Customer / Enterprise	Evidence Produced
Data at Rest	Enforces canonical `%AppData%`/`%LocalAppData%` paths, blocks arbitrary writes, provides disk-encryption guidance in policy docs.	Enable BitLocker (or equivalent) on all SmrtHub endpoints, monitor compliance via device management.	Encryption compliance report or MDM export referenced in DPIA.
Secrets & Credentials	Provides `Smrt.Security.WindowsCredentialHelper`; scrubbed logs ensure secrets never hit disk.	Provision credentials per-user, rotate per corporate schedule, revoke access when staff exit.	Credential vault change tickets + revocation logs.
Retention & Destruction	Ships defaults (14-day logs, explicit clean scripts), Storage Guard verification, and Support Bundle retention exports.	Use Supervisor CLI to apply/verify retention policies, confirm Storage Guard snapshot signature + `retention-health.json`, and archive Support Bundles showing retention evidence.	Supervisor `--retention-status` export, signed Storage Guard snapshot, Support Bundle ZIP with `system-info/retention/*`.
Disaster Recovery / Business Continuity	Certifies installer/build artifacts and documents how to redeploy from clean media.	Back up `%AppData%/SmrtHub` folders using corporate backup tooling; validate restore procedures.	Backup job reports + annual restore test record.
Incident Response	Supplies Support Bundle tooling, manifest hashing, and escalation contacts.	Trigger internal IR playbook, review bundles before sharing, control distribution of decrypted archives.	IR ticket IDs + signed support-bundle transfer log.
Cloud Connectors	Publishes TLS/cipher requirements, never proxies payloads through SnapRun.	Maintain contracts with cloud providers, audit outbound firewall/proxy rules, review provider DPAs.	DPIA appendix + firewall change tickets.
Monitoring & Telemetry	Provides structured logs, HTML export, and schema docs.	Integrate logs into SIEM, watch for anomalous behavior, store alerts per corporate policy.	SIEM dashboard screenshot or alert export.

11.1 Onboarding Acknowledgement Workflow¶

Distribute the matrix: During SmrtHub deployment planning, security/compliance leads share this section plus the DPIA worksheet with stakeholders.
Capture acknowledgement: The designated SmrtHub administrator must sign the Shared Responsibility Acknowledgement template (see §14.3) or submit the equivalent text through the Supervisor onboarding wizard (planned UI toggle). Store the signed copy under Compliance/Shared-Responsibility/<customer>/<YYYY-MM-DD>.pdf or the customer’s GRC system.
Record evidence: Attach BitLocker/mdm compliance exports, backup job summaries, and retention overrides to the acknowledgement packet so future audits can cross-reference a single artifact.
Renew annually or when scope changes: Regenerate the acknowledgement whenever new cloud providers, retention overrides, or architecture changes occur; archive both the previous and superseding copies.

Why this matters: Enterprises expect written proof that both parties understand their duties. The acknowledgement packet becomes the baseline evidence bundle for procurement, security reviews, and incident retrospectives.

11.2 Retention Verification Checklist¶

Run Supervisor CLI: SmrtHubSupervisor.exe --retention-status to capture the current policies, legal holds, and verification timestamp. Attach the JSON output or screenshot to the audit ticket. When updates are needed, use --retention-apply and re-run --retention-status to prove success.
Export canonical artifacts: SmrtHubSupervisor.exe --retention-export --output <secured share> copies retention-policy.json, legal-holds.json, retention-verification.json, .sig, and retention-health.json. Preserve the export folder with operator/timestamp notes.
Validate Storage Guard evidence: Inspect %ProgramData%/SmrtHub/Logs/system-info/storage-guard.json and .sig to ensure the snapshot includes the Retention block. Review storage-guard-verification.json (created by Support Bundle) or the Storage Guard HTTPS endpoint to confirm signature verification succeeded.
Capture Support Bundle: Generate a Support Bundle (tray UI or CLI) with ExportCategories.SystemInfo enabled. Verify system-info/retention/ exists inside the ZIP, then attach the bundle (or extracted retention folder) to the compliance record. Delete local copies per policy once evidence is archived.
File evidence: Store the CLI output, export directory, Storage Guard verification, and Support Bundle references with the Shared Responsibility acknowledgement so future audits can trace enforcement.

12. Customer Responsibilities¶

Provide acceptable use policies to end users.
Configure OS-level backups/encryption per corporate standard.
Review support bundles before sharing to avoid including unrelated corporate data.
Integrate SmrtHub logs into SIEM only after validating scrubbing suffices for your policies.

13. Appendix – References¶

README.Files/SmrtHub-Operational-Data-Policy-v1.0.README.md
README.Files/SmrtHub.Logging.README.md
README.Files/SmrtHub-Asset-Policy.README.md
SmrtApps/src/Smrt.Config/README.md
SmrtApps/src/Smrt.Security/README.md

14. Templates & Customer Artifacts¶

14.1 Privacy Notice Template¶

Purpose: Provide administrators with evergreen text describing SmrtHub's local processing posture. Replace bracketed fields prior to publication.

[Organization Name] deploys SmrtHub to help teammates ...

What SmrtHub keeps locally:
- Configuration + state files under %AppData%/SmrtHub/Config per component (window layouts, recent files, feature toggles)
- Diagnostic logs under %LocalAppData%/SmrtHub/Logs with strict PII scrubbing (no raw document text, images, or credentials)
- Optional Support Bundles generated manually by you when working with support; bundles stay on your device until you share them

How to clear your data:
- Use the Supervisor tray "Export Logs / Clean" entries or run Tools/Clean-Build scripts to remove config, state, and logs
- Delete Support Bundles from their export folder after sharing

Questions or concerns? Contact [Privacy Contact] at [email] or review the full SmrtHub Privacy & Security Policy.

14.2 DPIA Worksheet (SmrtHub Deployment)¶

Section	Description	Customer Input
Processing Summary	Describe SmrtHub use cases (clipboard capture, text extraction, logging).
Data Categories	Confirm only local config/state/logs + optional extraction payloads are processed; note any sensitive data expected.
Legal Basis	Document the lawful basis (legitimate interest, contract) for running SmrtHub on managed devices.
Data Flows	List any enabled cloud providers; include endpoints and contracts. Otherwise state "on-device only".
Storage & Retention	Reference Operational Data Policy (14-day logs, persistent config). Note corporate overrides if applied.
Access Controls	Confirm devices use Windows accounts + BitLocker; identify administrators with access to Support Bundles.
Risk Assessment	Summarize residual risks (e.g., user screenshots sent to cloud providers). Rate impact/likelihood.
Mitigations	List controls (PII scrubbing, Supervisor clean commands, credential storage via Windows Credential Manager).
Review Cadence	Set revalidation frequency (e.g., annually or before enabling new cloud providers).

Reminder: Attach completed worksheets to customer compliance records and update when enabling new integrations or changing retention policies.

14.3 Shared Responsibility Acknowledgement Template¶

Purpose: Provide a lightweight, signable artifact that documents acceptance of duties outlined in §11.

Shared Responsibility Acknowledgement — SmrtHub Deployment

Organization: [Customer Name]
Deployment Owner: [Name, Title]
Date: [YYYY-MM-DD]

I acknowledge that SnapRun Labs and [Customer Name] share operational responsibility for SmrtHub deployments as described in §11 of the SmrtHub Privacy & Security Policy. Specifically, our organization will:
- Maintain full-disk encryption and endpoint compliance controls on every SmrtHub workstation.
- Manage data retention, backup/recovery, and legal hold workflows for all SmrtHub artifacts stored in our tenant.
- Review and redact Support Bundles prior to sharing, transmit them over approved secure channels, and delete local copies per policy.
- Operate cloud provider connectors only with providers under active contract, enforcing TLS inspection and firewall rules documented in our DPIA.
- Revalidate this acknowledgement whenever SmrtHub scope changes (new workflows, connectors, or retention overrides).

Signature: _______________________________

Instructions: Save the signed copy to `Compliance/Shared-Responsibility/[customer]/[date].pdf` (or your internal GRC system) and attach supporting evidence (BitLocker compliance report, backup job proof, firewall approvals). Share the acknowledgement ID with SnapRun Labs support when requesting enterprise assistance.

This policy is a living document. TODOs must be resolved before the SmrtHub 1.0 GA security review.