Deployment

Most of OKY's protection lands in the browser extension, so the question every IT team asks is the right one: what stops someone uninstalling it? The honest answer has two halves. On machines you manage, a managed install stops it outright — the browser itself refuses the removal. On machines you don't, nothing can stop it, so OKY does the next best thing: it tells you the moment someone stops being covered.

Why an extension can't just refuse

No browser gives an extension an API to block its own uninstall. Chrome, Edge and Firefox all withhold one deliberately: an extension that could pin itself into a browser is exactly what a malicious one would want. Any security product claiming to prevent its own removal is either describing the enterprise policy below, or describing something that doesn't work.

Force-install (the part that prevents removal)

Every platform below does the same thing: the browser installs OKY on startup, refuses to remove it, and labels it “Installed by your administrator”. Open Organization → Deployment in your dashboard — it prints the exact configuration for each platform with OKY's extension IDs already filled in, with a copy button, so nobody has to retype anything.

A force-installed extension also updates itself automatically and cannot be disabled from the browser's extension page, so coverage stops depending on anyone remembering anything.

Deployment targets — one rollout per group or OU

Nobody rolls out to “the organization”. IT rolls out to an Active Directory group, an OU, an Intune group or a Workspace OU — a pilot first, then a department, then everyone. The Deployment page keeps one row per such target. Each has its own enrollment token and its own generated package: for Active Directory, a PowerShell script that creates a GPO named after the target, writes the Chrome and Edge policies under the Computer or User configuration, links it to the domain or to your OU, and security-filters it to your group. Run it once on a machine with RSAT; it is idempotent and supports -WhatIf.

Because every target's token is different, each browser the package reaches reports back which target reached it. The page shows per target how many browsers enrolled, how many are live, and a device list — browser, version, last seen, who signed in. The members list shows which rollout each person's browser came from. Did the finance GPO reach the finance machines? is answered on the page, not by walking the floor.

New token on a target stops packages already pushed from enrolling new browsers (existing ones stay enrolled) — for a leaked script or a departed admin. Archive retires a target and keeps its history. OKY never connects to your directory: group and OU names are printed into the script and shown back to you, nothing is synced.

Ansible shops get the same thing as a playbook: one file per target, hosts: set to your inventory group, with tasks for Windows (registry policy for Chrome and Edge), Linux (managed policy JSON for Chrome, Chromium and Edge, plus Firefox's policies.json) and macOS (managed preferences for Chrome and Edge). Idempotent and --check clean; every host enrols with the target's token and names itself.

Managed identity — nobody walks desk to desk

Rolling the extension out is one thing; getting every employee to sign in is another. Under managed identity — a mode OKY enables per organization on request, never a setting you can flip yourself — a managed browser signs itself in. The GPO script writes, next to the enrollment token, what the domain already knows: the machine name and the signed-in user, as Group Policy Preferences the policy engine expands and writes as SYSTEM. The extension turns them into a pending member the moment it starts: protected, counted, visible to your admins as jdoe on FIN-LT-07 — before anyone has typed anything.

A pending member can only scan and report; the API refuses everything else until the person is verified. Verification is silent where your identity provider allows it — the extension asks your single sign-on with prompt=none, and ADFS with Windows authentication, Entra or a signed-in Workspace profile answer without a page (the script whitelists your IdP host for that). Otherwise the extension shows Protected as jdoe@corp · Verify my account: one click, address prefilled. Sign in with the claimed address and the pending row becomes you; sign in on that browser with a different address and the pending history merges into you — the device is the link, not the name. Admins see a Pending tab on Members, the claim and its status per browser on each target's device list, and can revoke automatic sign-in per device.

Enrollment — whose browser is it?

Installing OKY is half the job. The other half is that the person signs in with their work account, not a private one — otherwise the browser is protected but your organization cannot see it, and the member shows as uncovered. A browser becomes yours the first time a member signs in on it. The Enrollment blocks on Organization → Deployment make it yours from the moment it is installed, by pushing your organization's slug and an enrollment token as the extension's own policy (Chrome and Edge read it from the 3rdparty policy tree, Firefox from policies.json). The very first sign-in on such a browser already asks for the work account.

What a personal account on one of your devices means is set under Policies → Work account on your devices: ask for the work account (default) or refuse anything else. The enrollment token enrols devices and grants nothing — it is safe in a policy file, and you can see it any time on the Deployment page.

Machines you don't manage

Contractors, personal laptops, anyone outside your MDM. Force-install isn't available, so set If a member removes OKY under Policies:

Block needs Require browser extension to be on — blocking people for skipping something optional would make no sense, so turning the requirement off puts the setting back to Warn. Owners and admins are never blocked: an organization must not be able to lock itself out of the screen that turns the setting off. Neither is a member who never installed OKY in the first place — that's onboarding, not removal, and Require browser extension already nudges them.

Scanning, sign-in and preferences keep working for a blocked member throughout. Withholding protection from someone who currently has none would be backwards.

How OKY knows

Two independent signals, because either one on its own could be avoided:

• The browser tells us. Chrome and Firefox open a URL on the way out when an extension is removed. Immediate and precise — but silent if the machine was offline, or if the whole browser profile was wiped.
• The install goes quiet. Every OKY client checks in regularly. Three missed cycles — 72 hours — and it counts as gone. Slower, but it can't be suppressed by uninstalling while offline.

72 hours is chosen so a laptop shut for a long weekend never produces a false “reinstall OKY”. If the install comes back, coverage restores itself and the round trip stays visible in your audit log — someone who removes OKY every Friday shouldn't read the same as someone who never removed it.