Skip to content

Launcher Policy Overview

The Launcher Policy System controls which applications and file operations are available through the Turbo Launcher. Policies use a secure, JSON-based allowlist model to authorize launches and define file associations and operations. Use this page as the reference index for policy topics; for a narrative introduction and where policy fits into deployment, see the Policy System section of the Turbo Launcher Administrator Guide.

What You'll Learn

  • Security model and discovery scope
  • Security and reliability considerations
  • Error states when no policy is present
  • High-level policy evaluation flow
  • Configuration Templates
  • User Configurations
  • Networking
  • Links to all policy topics

Precedence Essentials

  • When a system-wide policy exists at %PROGRAMDATA%\\Turbo\\Launcher\\policy.json, the Launcher ignores any user policy at %LOCALAPPDATA%\\Turbo\\Launcher\\policy.json. Only one active policy is evaluated, and scope precedence (Global > App > Launch Profile) applies inside that file.
  • If no system-wide policy exists, the user policy governs.
  • For the full location-versus-scope breakdown, see Merging & Precedence.

Policy Topics

Security Model

The policy system uses an allowlist approach — only applications you explicitly allow will be available. This maximizes security by ensuring only approved applications can be launched.

The allowlist model includes identity/SSO integration, cryptography and host attestation posture, and classification-aware DLP.

Top-level structure

json
{
  "policySignature": "...",
  "signatureCertificateThumbprints": ["..."],
  "configuration": { /* Global settings, identity/SSO, security posture, classification */ },
  "configurationTemplates": [ /* Enterprise templates */ ],
  "apps": [ /* Application policies and modifications */ ],
  "fileTypes": [ /* File type definitions */ ],
  "fileAssociations": [ /* File routing UX */ ],
  "files": [ /* File operation policies */ ]
}

Authoring notes

Identifier Conventions (ID)

Use stable identifiers for any policy objects that can be referenced or require deterministic tie-break behavior.

  • Application policies (apps[]): id required
    • Purpose: referenced by fileAssociations[].verbs[].appRef; alphabetical tie-break after priority when multiple policies match
    • Format: kebab-case, unique within apps scope, stable over time
  • File association rules (fileAssociations[]): id recommended
    • Purpose: diagnostics, future references, and stable tie-break after rule priority (fallback to name when id is missing)
    • Format: kebab-case, unique within fileAssociations scope
  • File policies (list/import/export/open/delete): id recommended
    • Purpose: diagnostics and stable conflict resolution (priority, then id alphabetical; fallback to name when id is missing)
    • Format: kebab-case, unique within the file-policies scope
  • Launch profiles (apps[].profiles[]): id required
    • Purpose: launch profile–level merges and tie-breaks within the app; not globally unique across apps
    • Format: kebab-case, unique within the parent app
    • UI text: use displayName consistently; id is not user-facing

Conventions

  • Allowed characters: [a-z0-9-]; start with a letter
  • Stability: treat ids as contract keys; do not change once published
  • Keep user-facing labels in name/displayName; ids are not shown in the UI

Security and Reliability Considerations

The Launcher uses a secure allowlist model — only explicitly allowed applications can launch. For a quick hardening baseline:

  • Deny takes precedence over allow when both match the same executable.
  • Prefer strong identity matchers (publisherCertificate and/or fileHash), and constrain versions for sensitive apps.

For advanced security topics (revocation modes, RFC3161 timestamps, signed policy delivery, and printer/device considerations), see: Security Best Practices

No Policy File Error

If no policy file is found at any configured location, or if the policy contains errors, the Launcher shows: "Policy file is not configured." Both the Applications and Files tabs will show this error with a Retry button to reload the policy.

Policy Evaluation (High Level)

  1. Scan Windows shortcuts in the Start Menu and Desktop (see Discovery Scope)
  2. Evaluate application policies (allow) and visibility
  3. Display only allowed applications with visibility: "visible" and matching location constraints (if location profiles enabled)
  4. Apply modifications (runtime settings, arguments) and merge launch profiles
  5. Resolve file types and associations (preview/open/edit/print) via fileTypes + fileAssociations, gated by application allow policies

Matcher evaluation can include high-assurance checks such as publisherCertificate, fileHash, and version in addition to shortcut name/path/arguments.

Discovery Scope

The Launcher enumerates Windows shortcut files (.lnk) and does not crawl arbitrary file system paths.

Sources scanned:

  • Start Menu: All Users and Current User Start Menu locations (scanned recursively)
  • Desktop: Current user's Desktop, top-level shortcuts only (subfolders are not scanned)

Impact:

  • The Applications tab and application policies operate on the inventory of discovered shortcuts. If an executable is not represented by a shortcut in the scanned locations, it is not discoverable or launchable by the Launcher.
  • To manage such an application, create a Start Menu or Desktop shortcut and author a policy that matches it (for example, via targetPath).

Hidden Applications

Policies with visibility: "hidden" do not appear in the Applications tab but remain eligible as association targets for file operations via fileAssociations and can appear in Open With lists when referenced by association entries that set showInOpenWith: true.

Configuration Templates (Enterprise)

Configuration Templates let administrators define reusable, centrally managed constraints for environment variables, which users can then apply as user configurations across authorized applications. Define templates in the enterprise policy at %PROGRAMDATA%\\Turbo\\Launcher\\policy.json and link apps via apps[].configurationTemplates. See: Configuration Templates

User Configurations (Per-User)

Users can define per-user configurations that reference enterprise templates. These configurations provide validated environment variables and appear for apps that link the same template via apps[].configurationTemplates. Stored at %LOCALAPPDATA%\\Turbo\\Launcher\\user-profiles.json. See: User Configurations

Policy Quickstart (Minimal, Unified File Associations)

json
{
  "configuration": {
    "launch": {
      "runtime": {
        "isolation": { "remoteSandbox": true }
      }
    }
  },
  "fileTypes": [
    { "id": "pdf", "displayName": "PDF", "match": { "extensions": ["pdf"] }, "defaultPreviewProvider": "builtInPdf" }
  ],
  "apps": [
    {
      "id": "example-app",
      "displayName": "Example App",
      "enabled": true,
      "priority": 100,
      "visibility": "visible",
      "matchAll": [
        { "type": "targetPath", "pattern": "C:\\\\**\\\\example.exe", "patternType": "glob" }
      ],
      "action": "allow",
      "capabilities": [
        { "fileTypeRef": "pdf", "verbs": { "open": { "arguments": "\"%1\"" } } }
      ]
    }
  ],
  "fileAssociations": [
    {
      "id": "pdf-routing",
      "displayName": "PDF",
      "enabled": true,
      "priority": 250,
      "fileTypeRef": "pdf",
      "actions": [
        { "verb": "preview", "displayName": "Preview", "provider": "builtInPdf", "default": true },
        { "verb": "open", "displayName": "Open", "appRef": "example-app", "showInOpenWith": true }
      ]
    }
  ]
}