The extension is the product. That is the whole appeal of this category: you press record in the browser, click through the process once, and a guide comes out the other end. It is also the reason your IT and security team stops the purchase. A tool that can turn any screen into a document is, by construction, a tool that can read any screen.
That conversation goes badly when it happens at the end of a procurement. It goes fine when the buyer walks in with the answers. Below is the review we would want a European IT team to run on us, in roughly the order the questions come up.
Full disclosure: we build Loopyback, an EU-hosted documentation tool with a Chrome extension. We are not neutral here. Everything below is written so you can point it at us as easily as at anyone else.
Read the permission string before the pitch deck
Chrome shows a plain-language warning at install time, and it is deliberately alarming. "Read and change all your data on all websites" is what a broad host permission looks like from the outside. It tells you nothing about what the extension does with that access, which is the whole problem.
Ask the vendor for the `manifest.json` permissions block. It is a public file inside every published extension. A vendor who hesitates has answered a different question.
| Permission | What it grants | Why a documentation tool might need it | What to ask |
|---|---|---|---|
| `<all_urls>` host permission | Read and modify page content on every site | The user can document any internal app, so the domain is unknown in advance | Can it be scoped to a domain allowlist by policy? |
| `activeTab` | Access to the current tab, only after the user invokes the extension | Recording only starts on a deliberate click | Is this used instead of a standing host permission? |
| `scripting` | Inject code into pages | Highlighting the clicked element, drawing step overlays | Does injection happen always, or only while recording? |
| `tabs` | Read tab URLs and titles across the window | Naming steps, detecting navigation | Are URLs stored, or used only in-session? |
| `desktopCapture` / `tabCapture` | Screen or tab capture | Screenshots and recordings | Can capture run outside an explicit recording session? |
| `cookies` | Read cookie values | Rarely justified for capture | Ask for the specific use case, in writing |
| `storage` | Local extension storage | Holding a draft guide before upload | Is anything sensitive cached, and for how long? |
Manifest V3 removed the blocking `webRequest` API, which narrows what an extension can do to your traffic. It does not narrow what it can read on a page. "We are MV3" is not an answer to a data question.
Four questions the permission list cannot answer
Permissions describe what is possible, not what happens. These four decide the actual risk.
When does capture start and stop? There is a large difference between an extension that captures only between an explicit start and stop, and one that keeps a rolling buffer so recording "feels instant". Get the answer in writing.
Where does the screenshot go, and when is it redacted? If the image leaves the browser and is redacted server-side, the unredacted original travelled and was written somewhere, however briefly. Redaction that happens in the browser before upload keeps it out of the pipeline entirely. That is not a marketing distinction, it is the difference between one processing operation and two.
What is excluded by default? Most vendors in this category state that they do not capture password fields. Tango, for example, states publicly that it never captures keystrokes or text in password fields, and also notes that it cannot control what a user chooses to capture. The second half is the honest part, and it is true of every tool in this category including ours. Password masking is the floor, not the control.
Who is controller and who is processor? You are the controller for whatever your staff record. The vendor is a processor, which means an Article 28 agreement, a current sub-processor list, and a straight answer on where storage sits.
The European layer
Three regimes turn this from a preference into a procurement gate.
GDPR Article 28. No data processing agreement, no deal. Check that the sub-processor list is published and versioned rather than "available on request", and that you get advance notice of changes with a right to object.
GDPR Article 35. A DPIA is required where processing is likely to result in a high risk. A tool that captures employee screens inside internal systems lands on most national supervisory authorities' DPIA lists, usually under systematic monitoring of employees. Budget for it. The works council approval step usually runs in parallel and takes longer than the DPIA does.
NIS2 Article 21(2)(d). Security in supplier relationships. A documentation vendor holds guides describing your access-control and incident procedures. If you are an essential or important entity, that vendor sits inside your supply-chain measures whether or not anyone labelled it that way. We went through this in NIS2 and process documentation.
On transfers: if the tool is hosted in the United States, that is not a dead end, it is a Chapter V question with a defined answer. Ask which transfer mechanism is relied on, whether the entity is certified under the EU-US Data Privacy Framework, and what the transfer impact assessment concluded. An EU-hosted tool removes the question rather than answering it. That is a practical argument about paperwork and control, not a political one.
Controls you can apply without the vendor's cooperation
Chrome Enterprise lets you constrain an approved extension rather than trusting it wholesale. The relevant policy is `ExtensionSettings`.
| Setting | Effect | Use for a documentation extension |
|---|---|---|
| `installation_mode` | `allowed`, `blocked`, `removed`, `force_installed`, `normal_installed` | Force-install the approved build so nobody sideloads a lookalike |
| `blocked_permissions` | The extension will not load if it requires a listed permission | Block `cookies` if the vendor cannot justify it |
| `runtime_blocked_hosts` | The extension cannot read or modify pages on listed hosts (maximum 100 entries) | Block payroll, HR and banking domains outright |
| `runtime_allowed_hosts` | Overrides the block for named hosts | Permit only the systems you actually intend to document |
`runtime_blocked_hosts` is the underused one. It converts "we trust the vendor" into "the extension is technically unable to see the HR system", which is a much easier sentence to put in front of a works council or a DPO.
Worth knowing too: Chrome Web Store policy updates taking effect on 1 August 2026 require extensions to collect only data strictly necessary to the extension's disclosed single purpose, and to proactively disclose changes to data handling after installation. That gives you a public commitment to hold a vendor to.
Where Loopyback sits, honestly
We host in the EU, in Belgium, and detected personal data is redacted in the browser before the screenshot is uploaded. Pricing is in euros: a free plan, €16 per month personal, €24 per seat for teams.
What we do not do: we are not an enterprise browser or an extension-governance platform, we do not offer on-premise deployment, and our automatic redaction is pattern-based. It handles structured identifiers well and free-text names inside a support ticket less reliably. Manual redaction exists for exactly that reason, and any process that records screens still needs a human check before publishing.
Common mistakes
Approving the extension once and never re-reviewing it. Extensions auto-update. The build you assessed is not the build running next quarter. Put a review date in the register.
Treating the Chrome install warning as the risk assessment. It describes capability, not behaviour, and it reads identically for a careful tool and a careless one.
Skipping the DPIA because "the employee starts the recording". Employee consent is rarely a valid legal basis, and voluntariness does not change whether the processing is systematic.
Letting each department install its own. Three documentation extensions across three teams means three processors, three DPAs, and nobody owning the review.
Assuming SOC 2 answers the GDPR question. It is a controls audit. It is not a statement about lawfulness, data location or sub-processors. Both are useful; neither substitutes for the other.
FAQ
Does an employee starting the recording mean this is not monitoring?
Not by itself. In several Member States the legal test is whether the technology is objectively suitable for observing behaviour or performance, regardless of the employer's intention. A finger on the record button does not change the capability.
Can we avoid the browser extension entirely?
Some tools offer a desktop application or manual upload instead. That trades one risk for another, because a desktop capture agent sees more, not less. What you gain is that it is not sitting inside the browser session alongside your SaaS credentials.
The vendor says data is encrypted in transit and at rest. Is that enough?
Necessary, not sufficient. Encryption addresses confidentiality against third parties. It says nothing about where data sits, who at the vendor can access it, or which sub-processors are involved.
What belongs in the DPIA that is specific to this kind of tool?
The capture trigger, the redaction point (browser or server), the retention period for unredacted originals if any exist, the sharing model for published guides, and the list of systems the extension is permitted to run on. That last item is where `runtime_blocked_hosts` earns its place.
Founder of Loopyback
Daan is the founder of Loopyback, a Belgium based tool that turns workflows into step by step guides. He writes about documentation, SOPs and getting knowledge out of people's heads.