7.9 KiB
Implementation plan and decision record
Product scope
Build a Windows privacy wizard with three browser choices: Tor Browser, Zen and Helium. Its job is to reduce collection and retention, expose tradeoffs, and verify specific settings. It must never present a percentage-anonymous score or claim that a host is untraceable.
The running Windows installation is the development host. Development and read-only inspection are authorized; this iteration creates the tool and planning artifacts without destructive OS changes or installation of applications on that host.
Profiles
| Profile | Default behavior | Availability |
|---|---|---|
| Standard | Minimum supported diagnostic policy, no advertising ID, Windows location/camera restrictions, covered app microphone default deny, no cloud speech/clipboard sync/Find My Device/cloud search, DO without peering; updates unchanged | Prototype implements policy configuration on reviewed Pro/Enterprise/Education build families |
| Strict | Standard plus no clipboard history and DO mode 99 | Prototype implements those added policies; advanced networking is not included yet |
| Isolated session | Separate Tails environment; explicit persistence and identity separation | Guidance; not an automated OS installer |
Users can select individual supported IDs with -Id. The future UI needs a clear restore action for each restriction so camera/microphone use is possible when wanted. Software permission controls and hardware disconnection must have distinct labels.
Work packages
| Area | Delivered now | Next implementation and acceptance gate |
|---|---|---|
| Policy engine | Audit, Plan, Apply, Restore, edition/build gates, readback, recovery journal and transaction tests | VM verification on each supported build/edition; confirm policy consumption after reboot |
| Browser/app selection | Exact package IDs, optional interactive installer, no default takeover, -WhatIf |
Verify freshness/publisher manifests in release pipeline; UI choices; detect updates without importing personal profiles |
| Home edition | Read-only report and explicit manual guide | Supported Settings integration; verify actual toggles rather than pretending Pro policies work |
| Diagnostics | Supported minimum Windows policy | Separate crash reporting, feedback and app-level controls with sources and side effects |
| Connected experiences | A small documented subset | Backup/account sync, Phone Link/CDP, Widgets, Start web search, consumer suggestions, application-specific policies; validate edition and deployment mechanism |
| Network controls | Research and validation specification only | Lab capture, destination attribution, narrow rules, timed recovery and VPN coexistence tests |
| AI removal | Research and deletion warning | Inventory Recall eligibility and installed Copilot apps; explicit data-deletion preview; dependency-aware uninstall |
| Debloat | Design only | Exact allowlist of removable apps; distinguish user/provisioned scope; OneDrive data-preservation preflight; Edge/WebView2 separation |
| Updates | Keep, Automatic, Notify, Manual registry choices on eligible editions | Reboot and actual update workflow tests; UI temporary pause uses supported Windows mechanisms; browser/AV updates independent |
| Sensors | Location/camera policy and limited app microphone policy | Optional hardware-device disablement with reliable recovery and device selection; never disable audio input blindly |
| Cleanup | Home guide | Storage Sense integration with explicit retention and exclusions; skip busy files; never clean the registry or clear security logs |
| Lock behavior | Design only | Session-lock trigger, vault integrations, clipboard handling, selected VeraCrypt volumes, busy-volume/error reporting; no generic process kill |
| Encryption | Guidance only | Read-only encryption status without recovery-key capture; key-custody guide; no automatic encryption/decryption migration |
| Security software | Preserve existing protections | Optional Bitdefender selection after conflict checks; no automatic Zillya recommendation pending sufficient evidence |
| Packaging | Local CLI scripts | Signed release, reproducible manifest, checksums, native GUI; optional AME wrapper after VM validation |
Network design requirements
The requested no-direct-Microsoft-contact option now has a separate collector and offline-maintenance design. Local inventory and bundle-integrity verification are implemented; isolation, signed-package authentication, offline scan and installation are not deployed. A connected profile with update exceptions necessarily retains some outbound Microsoft traffic. The fully isolated profile loses online cloud security capabilities and needs explicit maintenance for all security components.
- Normal mode retains security maintenance, licensing and requested connected functions. Fewer observed connections is a measurable result, not proof of anonymity.
- Strict egress must be opt-in and recoverable. Before applying rules, export the exact relevant state, maintain local console recovery, schedule a short rollback, and cancel it only after connectivity checks pass. The recovery service must not depend on the network being tested.
- Account for all firewall profiles, existing explicit allows, IPv4/IPv6, TCP/UDP/QUIC, DNS and application DoH, physical/VPN adapters, sleep/wake and boot-time behavior.
- Do not install a TLS interception root certificate to inspect traffic. Encrypted captures establish destination/timing observations; do not claim their payloads have been audited.
- Never claim VPN Lockdown prevents Microsoft collection inside the tunnel. If the requirement is absolutely no Microsoft-bound traffic, document the compatibility loss and use a separately enforced/offline environment rather than a hidden default.
- Network captures are opt-in, local and short-lived, with an explicit deletion/export choice. They can reveal private endpoints; they are not included in normal audit output.
Wizard flow
- Explain protected data and limits; choose Standard or Strict.
- Detect OS edition/build and managed-device constraints. Show unavailable controls as unavailable.
- Choose browsers and optional Mullvad/VeraCrypt; show installation separately from configuration.
- Review each setting, its source, expected result, compatibility impact and reversibility. Separate data-deleting actions.
- Prepare a local recovery journal, then apply selected actions in small independent groups.
- Report configured, pending reboot, behavior verified, unsupported, failed and conflict states separately.
- Offer rollback by group and show remaining manual checks. A successful registry write never earns a "verified anonymous" badge.
Reversibility rules
Configuration rollback restores original values and absence, not guessed Microsoft defaults. Package reinstalls do not restore application data automatically. Disabling Recall may remove snapshots. Closing an app may lose unsaved work. Unmounting a container does not erase the plaintext already copied by another process. These are different operations and must not share one "undo everything" claim.
Journals contain only allowlisted setting values, not entire registry branches, credentials, hardware IDs or browser history. Restoration derives targets from the local catalog rather than accepting registry paths in imported files. It refuses foreign profile markers and reports subsequent-edit conflicts. This is recovery metadata, not a cryptographic attestation against an administrator modifying both the tool and its state.
Release gates
The prototype is not approved for broad deployment until the validation protocol passes in clean VMs and representative hardware. AME packaging and a GUI must reuse the engine; neither should hide incomplete controls or add unverified registry tweaks. No combination of successful tests can prove universal absence of telemetry or endpoint compromise.