Browser permissions, explained

For the DynoMerge Chrome extension · Last reviewed August 13, 2026 · Published by Everything Virtually LLC.

If you are the person who has to approve this extension, this page is for you. A browser extension asks for permissions at install time, the install dialog summarizes them in alarming shorthand, and you are expected to decide from that. Below is the actual list — what each permission does, why DynoMerge needs it, what it does not allow, and how to check each claim yourself rather than take our word for it.

The authoritative source is the extension's manifest.json, which ships inside the package and can be read on your own machine. Everything on this page can be checked against it.

The complete list

DynoMerge requests six permissions and two host patterns. That is the entire list — there are no optional permissions requested later, and no permissions requested at runtime.

Permission	What DynoMerge uses it for	What it does not allow
`sidePanel`	Open the DynoMerge app in Chrome's side panel, docked beside your Salesforce tab.	No access to page content or data. It only lets the extension own a panel.
`tabs`	Read the URL of your active tab, so the panel knows which record or report you are looking at and can offer to merge it.	Does not read page content. Combined with the host patterns below, DynoMerge only acts on Salesforce URLs.
`cookies`	Reuse the Salesforce session you are already logged in with, so the extension can call the Salesforce API as you. Concretely: DynoMerge reads one cookie, named `sid`, on your Salesforce host.	Cannot read cookies for any other site — the host patterns below are enforced by Chrome, not by us. The session token is used in the API call and is never transmitted anywhere else, because there is nowhere else to transmit it.
`scripting`	Read the rows of a report table off the rendered page when you click "Grab this report" — the feature that lets DynoMerge work in orgs without API access.	Runs only on that click, only on a Salesforce tab, and only a function that ships inside the extension package. It is not a content script: nothing is injected on page load, and nothing runs in the background. See the note below.
`storage`	Keep your templates and settings on your device so they survive a browser restart.	Local to your machine. Not synced to us, not backed up by us. Removing the extension removes them.
`unlimitedStorage`	The same local storage, without Chrome's default size cap — a library of Word templates with images exceeds the default quota quickly.	Same scope as `storage`. It raises a local size limit; it does not widen access to anything.

Host access

DynoMerge requests exactly two host patterns:

https://*.salesforce.com/*
https://*.force.com/*

This is the boundary that matters most, so it is worth being precise about what it means. Chrome — not DynoMerge — enforces it. On any other site, the extension has no host access at all: it cannot read the page, cannot read cookies, and cannot make requests. It requests no wildcard host access and no access to your other tabs.

Both patterns are needed because a single Salesforce org spans both domains: Lightning and the API live on salesforce.com, while Experience Cloud sites, Visualforce pages, and sandbox and scratch org variants live on force.com.

About the report-grab feature

We want to address this one directly rather than let you find it. DynoMerge can read the rows of a Salesforce report straight off the rendered page. Described uncharitably, "reads data off the page you are viewing" is also a fair description of a malicious extension, and a security reviewer is right to look hard at it.

Here is the shape of it, and each part is checkable:

It runs on your click, not on page load. There is no content script in the manifest, so nothing is injected automatically. The extension has exactly one place where it injects into a page, and it is the handler behind the "Grab this report" button.
It injects a function that ships in the package. Chrome's Manifest V3 forbids executing remotely fetched code, and DynoMerge does not override the default content security policy. There is no mechanism by which new code could be fetched and run.
It reads a table, and the rows go into the side panel. They are merged locally into your template. They are not transmitted, because DynoMerge has no server to transmit them to.
It exists for a specific reason. Salesforce Professional Edition and similar orgs have no API access. Report-grab is how those teams generate documents at all. If your org has API access, you never need to use it.

What DynoMerge deliberately does not request

What an extension declines to ask for is often more informative than what it asks for. None of the following appear in the manifest:

Not requested	Which means
`<all_urls>` or broad host access	No access to any site other than Salesforce.
`webRequest` / `webRequestBlocking`	Cannot observe, intercept, or modify your network traffic.
`content_scripts`	Nothing runs automatically on any page you visit.
`nativeMessaging`	Cannot communicate with any program installed on your computer.
`management`	Cannot see or change your other extensions.
`history`, `bookmarks`, `downloads`, `identity`, `clipboardRead`	No browsing history, no bookmarks, no download management, no account linkage, no clipboard reading.
A custom `content_security_policy`	Manifest V3's remote-code prohibition applies unmodified.

How to verify all of this yourself

You do not have to trust this page. Each of these checks takes a minute and none require our cooperation:

Read the manifest. Go to chrome://extensions, enable Developer mode, and use "Inspect views" or the extension's directory on disk to open manifest.json. Compare it to the lists above. The permission and host entries are the ones Chrome enforces.
Watch the network. Open DevTools on the side panel, go to the Network panel, and generate a document. The only requests you will see are to your own Salesforce org. There is no DynoMerge domain in the list, because there is no DynoMerge server.
Read the code. The extension ships as unobfuscated JavaScript. The report-grab injection and the cookie read are each a single, greppable call site.
Check the store listing. The Chrome Web Store shows the permissions and data-usage disclosures for the published version independently of anything we say here.

If this ever changes

If a future feature ever changes the picture on this page, we will update this page and the privacy policy before that feature ships, and clearly label any mode in which data leaves your machine. The core promise will not change: the DynoMerge extension's document generation runs locally.

Questions

If you are evaluating DynoMerge for your org and something here does not answer your question, ask directly: [email protected]. Security questions get a real answer, not a brochure.