Groma Privacy Policy

Last updated: 3 October 2026

The short version: Groma has no backend, no accounts, no analytics, and no telemetry. Nothing you author, run, or capture leaves your browser unless you export a file or link and share it yourself.

1. Who this policy covers

This policy describes what the Groma browser extension ("Groma", "we") does with data on the device where it is installed. Groma is a local tool: it operates entirely inside your browser and communicates with no Groma server, because none exists.

2. What Groma collects

Nothing. Groma does not collect, transmit, or receive any personal data, usage data, analytics, crash reports, or telemetry. It makes no network requests to any Groma server. The only network traffic in a Groma tab is the tested app's own. This is still true if you connect a Groma Project (§3): that folder is on your own machine, and writing a file to it is not a network request.

Google Drive, only if you connect it: you can keep a project in your own Google Drive instead (+ Connect Google Drive on Home; Chrome, Edge and Firefox). You sign in on Google's own page — Groma never sees your password — and Google gives your browser a temporary access token, which Groma holds in extension storage only until the browser closes. From then on that project's files (test cases, run results with their screenshots, logs and videos, issues, test suite records) are sent from your browser straight to Google Drive and read back from it. Groma asks for the narrowest Drive access Google offers: only files Groma itself put there, in a folder named Groma or in one folder you pick yourself, never the rest of your Drive. Picking a folder opens Google's own folder chooser on a page of Groma's site (groma.pages.dev/drive-pick), because an extension may not load it; your temporary access token is handed to that page in the part of its address no server is sent, and the page uses it only to show you Google's chooser. Nothing passes through a Groma server, because none exists; what is in your Drive is held by Google under Google's terms and yours to share or delete there. Disconnecting the project on Home makes Groma forget it, and you can withdraw the access entirely in your Google account's third-party access settings.

One more exception, and only if you use it: the microphone button in the author panel's header dictates into whichever field your cursor is in, using your browser's own speech-recognition feature instead of typing. On Chrome, this sends the audio to Google's speech-recognition service to be transcribed — the only third-party network request Groma ever triggers, and only while you have dictation switched on. Nothing is recorded or sent unless you turn it on, your browser asks for microphone access the first time you do, and the button doesn't appear at all in a browser with no speech-recognition engine (Firefox, as of this writing).

3. What Groma stores on your device

Authored test cases

The steps you author (element locators, page URLs, your instructions and expected results) exist in memory while you work and are exported — at your request — as a Test suite to your downloads folder. Test cases are compressed directly into the test suite's run and edit links; they are not uploaded anywhere.

Screenshots and flow video

During a run, Groma captures a video of the app under test, and a screenshot of each step the tester fails, using the browser's tab-capture API — no screen-sharing prompt. The video runs for the length of the run without being switched on; a screenshot is taken only at the moment a step is failed. The app runs in an ordinary browser tab, with Groma's step panel docked beside it in the browser's side panel (a floating panel on Safari, which has no side-panel API). On Chrome and Edge the video is encoded in a hidden page of Groma's own (an offscreen document) rather than in that step panel, so that switching tabs — which the browser treats as a reason to close the panel — doesn't end the recording halfway through your run. It renders nothing, is never shown, touches no microphone or camera, and closes once no run needs it. These are embedded into the HTML report saved to your downloads folder and exist nowhere else.

Console and network logs

Alongside that screenshot, and on the same rule — only for a step the tester fails, and only covering the time since that step began — Groma attaches two things from the app under test: the console messages it printed (log, info, warn and error, with the objects or error stacks they carried), and the requests it made. For every request that is the method, URL, status and timing; for the ones the app makes in script — its fetch and XMLHttpRequest calls, the API calls behind a screen — it is also the headers sent and received, the data posted, and the response returned, so a developer reading the report can see what the server actually said rather than only that it said 500. A response body is read from the page's own JavaScript, which is where it already exists, so no body is captured for a page load, a script, an image or any other request the app did not make in script. Bodies are text only, capped at 8,000 characters each (a longer one is cut, and says so), and a body that is not text is not read at all. All of this is a mirror of what your own DevTools Console and Network tabs were already showing for that page. In the requests, Groma masks the values it can recognise as credentials by name — an Authorization or cookie header, and a header, URL parameter or body field called password, token, secret, api_key and the like. That is all it masks: an app is free to print anything it likes to its own console, which is attached as printed, and a token, session id or personal data under an ordinary name is something Groma cannot tell apart from ordinary content. Read a report before you forward it. All of it is embedded in the HTML report saved to your downloads folder, is held only for the length of the run, and — like the screenshot — never appears for a step that passed.

Issues

While you author, Groma keeps the observations you type and the uncaught errors the app throws — their message, script URL and line number, and the page they happened on. They are held with the draft above and, when you finish the session, saved for you: into a .groma-issues subfolder of the connected project (one file per session, kept as a history rather than overwritten, and read back under Project Issues Logged on the Home dashboard — one bucket for the whole project, where you can download or delete a session's set), or — with no project connected, or if that write is refused — as a Markdown file to your downloads folder. Issues are never part of a test case and never travel in a run link.

Your Projects (only if you connect one)

Groma can save each test case as an ordinary .groma.json file in a folder you pick yourself — a Groma Project — so your test cases stay in a place you own and control. You can connect more than one; one at a time is active. Nothing is chosen for you and nothing happens until you connect a project on the Home page; until then Groma reads and writes no files anywhere except your downloads folder. When a project is connected, Groma writes a test case file to it when you export a test suite (into whichever project was active for that session) or change one from Home — reordering, replacing text, or saving a smoke test row as a test case of its own — and reads the test case files of the active one back to list them on the Home dashboard, where you can also delete one — a delete you ask for, on a file you picked, after a confirmation. An unfinished authoring draft is never written there: it stays in extension storage on this device, so a project shared with other people carries no half-written work. When a test run ends with a project connected, Groma also files that run's results there straight away — the same report you download, kept as JSON in a .groma-reports subfolder (with the run's video beside it, when one was recorded), and updated with the tester's name and summary when they sign it off — so past runs of a test case are listed on the Home dashboard where you can reopen, download, print or delete one. The issues you logged while authoring are filed there too, in a .groma-issues subfolder — see Issues above. A test suite's own record — its title, and the brief you write for it (what a round of testing is about, and the setup a tester needs before its first test case) — is kept as a small JSON file in a .groma-test-suites subfolder; it is your own words, written only when you save a brief or create a test suite, and it travels to a tester only inside the links you choose to share. Groma touches only .groma.json and the files inside .groma-reports, .groma-issues and .groma-test-suites: it never reads, changes or deletes anything else in a project's folder, and it never deletes a test case file on its own. Each project is on your own machine: Groma has no account, no sign-in and no server, and does not know or care whether a project's folder happens to be synced by git, Google Drive, Dropbox or nothing at all. Your browser remembers which folders you connected (and may ask you to confirm access again after a restart); disconnecting one, from that same Home page, makes Groma forget it and leaves every file in it untouched. Connecting a folder is available only in browsers that offer extensions a folder picker — Chrome and Edge, as of this writing. Every install also starts with one project that needs no folder, This browser: the same files, kept in the private file storage your browser gives the extension, on this device only. It is not a folder you can open, it is never synced or transmitted, and it is deleted when you remove Groma or clear its data.

Extension storage

Groma keeps small operational values in the browser's extension storage, local to your browser profile and never synced. Some are transient and cleared when the browser closes: run and author state handed between Groma's own pages, including the in-progress run so closing the panel doesn't lose it, and the name you type when signing a report. Others persist until you remove them, because losing them is the problem they exist to solve:

the authoring draft you're working on, so a closed tab or a browser restart doesn't discard a captured flow — deleted when you finish or discard the session, and after 7 days otherwise. Kept here only when no Groma Project is active; see above;
a parked run you chose to finish later, with the statuses and notes given so far — or a parked "Run all", which also keeps the list of test cases still to run — deleted when you resume or discard it, and after 7 days otherwise;
your theme preference and the name you sign runs off with — the name stored only so you are asked for it once rather than every time, and never sent anywhere;
a one-time marker, written when Groma is first installed, saying it still owes you an introduction — so the Home page your first click on the toolbar icon opens explains itself rather than arriving unannounced. It is deleted the moment that happens; and
a reference to each Groma Project you connected, and which one is active — the handle your browser gives Groma to reach a project's folder, not a copy of anything in it; and
for each Groma Project, the addresses you've typed into "Run against" → "Other address…" on Home, so they're offered back the next time you open that picker instead of being retyped. Nothing else about where you run a test case is stored — only an address you typed yourself.

All of it stays on this device.

Reports from an interrupted "Run all"

Running a whole set of test cases in sequence normally ends with one archive download. If it ends some other way instead — a closed tab, a crash, a declined download — the reports already produced (with their screenshots and video) stay in extension storage rather than being lost, and the toolbar icon badges to say so. Clicking it opens Home, which leads with a card for them; from there you can download them, preview one test case's report in a tab, or discard the set; nothing here leaves your device, and anything left unclaimed is deleted after 7 days. A sequence started from Home saves each report into your Groma Project instead of an archive; for those, extension storage keeps only which project and which file each report went to — never the report — so your name can be written into them when you sign off. That note is deleted at the sign-off, or after 7 days.

4. What captured content can include

Screenshots, videos, test cases, issues, and reports show whatever was on screen in the app under test — which may include personal or confidential information. Error messages the app throws can carry the same. Those files are created locally and shared only by you; treat them with the same care as the data they display.

5. Why Groma asks for broad permissions

Groma requests powerful browser permissions because it must author and run tests on whatever app you point it at. None of them are used to gather data:

Access to all sites — authoring and running must work on any app you test. Apart from a small script that recognises Groma links — loaded only on Groma's own site and on files you open from your own disk — Groma's content scripts are loaded only while you have an authoring session, a run or a locator check open, and stay dormant in every tab but that one. (On Safari, which has no side panel, they are always loaded but stay dormant until you start an authoring session or open a run link.)
Storage, active tab, scripting — the extension's own state, and launching the author panel or floating step panel on the current tab. Scripting is also how the console and request detail in section 3 are read: while a run is on, Groma runs a small piece of code in that one tab that notes what the app logs and what its fetch/XHR calls send and receive. It runs in no other tab, and what it notes goes only into that run's own report. Reports and Test suites are saved through the browser's normal file-download mechanism, not a dedicated permission.
Web request observation — this is the one your browser may describe most alarmingly, so it is worth being exact. Groma watches requests only for a tab a run is actively driving, and only to note their method, URL, status and timing for the network log attached to a failed step (see section 3). It is the read-only form of the permission: nothing here blocks, redirects or modifies any request, on any site, and this permission reads no bodies — the request and response detail in section 3 comes from the page's own JavaScript, not from here. Watching starts when a run starts and stops when the run ends or its tab closes; no other tab is ever observed, and nothing observed leaves your machine.
Microphone — not an extension permission at all, and not part of the install prompt. The first time you switch on dictation while authoring, Groma opens a small window of its own and your browser asks for the microphone there — a side panel has nowhere to show that prompt, which is the only reason the window exists. It happens once, and never otherwise. Decline it and everything except dictation works exactly as before.

A step an author wrote for a particular screen size resizes your browser window as you reach it, through the ordinary window API every extension has — no permission is requested for it, and nothing about the tested app is altered beyond the width it lays out at.

6. Third parties

Groma sends data to no third party, embeds no third-party analytics or ad code, and does not sell, rent, or share any data — there is no data to sell. The two exceptions are both yours to switch on: a project you choose to keep in Google Drive (section 2), whose files go to Google and nowhere else, and the optional microphone dictation described in section 2, which is off unless you click it and uses your browser's own speech-recognition provider, not one Groma runs or controls. The apps you test with Groma are governed by their own privacy policies.

7. Data retention and deletion

Uninstalling the extension removes everything Groma keeps in extension storage, including the built-in This browser project and every test case and run in it. A folder you connected as a project, and files you exported (test cases, reports), remain wherever they are and are yours to delete.

8. Children

Groma is a professional testing tool and is not directed at children.

9. Changes to this policy

If Groma's behavior ever changes in a way that affects privacy, this policy will be updated and the "Last updated" date revised before the change ships.

10. Contact

Questions about this policy: selahsolution@gmail.com.