Groma Privacy Policy
Last updated: 24 October 2026
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 turn it on: you can sync a project with your own Google Drive (Sync with Google Drive in the project menu 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. Each time you press sync, 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 files only Drive holds are brought back. Untick run reports, run videos or issues in the project menu and those stay on your computer only. Groma asks for the narrowest Drive access Google offers: only files Groma itself put there, in a folder named Groma, never the rest of your Drive. 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. Groma also remembers, on this device, when each project was last synced, what each of its files looked like at that sync (its path, a checksum of its content and when it was written — how the next sync tells what changed or was deleted), which of those kinds of file you left out, and the email address of the Google account you signed in with — handed back to Google's sign-in page so it does not ask you which account each time, and sent nowhere else. Switch Google account… in the project menu replaces it. You can withdraw the access entirely in your Google account's third-party access settings.
Sharing by link, only when you press it: Share link on Home puts the test cases you ticked into one folder inside that backup and makes that folder alone readable by anyone holding the link — the rest of your backup stays private, and nobody else can write to any of it. Whoever opens the link in Groma reads those test cases from Google Drive with no sign-in; their run's report is saved in their own project on their device and is sent nowhere. Share link on a past run does the same for that one report — with its screenshots, console and network evidence and its video. Where your backup already holds the run, those two files are made readable by anyone holding the link, where they are; otherwise a copy goes into one folder of its own. Sharing the same thing again reuses that folder and gives the same link. Whoever opens the link reads them from Google Drive on Groma's run page, with no sign-in and no extension. Delete the folder or file in Drive, or stop sharing it there, to end a link.
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 saved, when you finish, as files in your project (below). Where no project can take them — a private window, or Safari's floating panel — they download as one zip to your downloads folder instead. Nothing is uploaded anywhere unless you use Share link (above).
- 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 kept with the run's report in your project (below) — or in the zip that downloads where no project can take the run — and exist nowhere else unless you sync or share them (above).
- 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,warnanderror, 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 — itsfetchandXMLHttpRequestcalls, 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 — anAuthorizationor cookie header, and a header, URL parameter or body field calledpassword,token,secret,api_keyand 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 kept in that run's report, beside the screenshot, is otherwise 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-issuessubfolder 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 — if that write is refused — as a Markdown file to your downloads folder; where no project can take the session at all, they go into the zip it downloads. Issues are never part of a test case and never travel in a shared link. - Your Projects (only if you connect one)
- Groma can save each test case as an ordinary
.groma.jsonfile 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 in any folder of yours 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 report, kept as JSON in a.groma-reportssubfolder (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, print, share or delete one. The issues you logged while authoring are filed there too, in a.groma-issuessubfolder — 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-suitessubfolder; 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.jsonand the files inside.groma-reports,.groma-issuesand.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;
- 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, and the name last given as "Resolved by" on a report — each stored only so you are asked for it once rather than every time, and never sent anywhere;
- if you use Google Drive, the email address of the Google account you signed in with, so Google's sign-in page is not asked to make you choose it again — sent only to Google, as part of that sign-in;
- 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.
- Groma archives
- Where Groma has no project it can write to, a finished run or authoring session is downloaded to your device as a zip of the same files a project would hold. It goes wherever your browser saves downloads and nowhere else; importing it on Home reads it from your device into a project.
- A "Run all" in progress
- Running a whole set of test cases in sequence saves each report into your Groma Project as that test case ends. Until you sign the sequence off, extension storage keeps only which project and which file each report went to — never the report — so your name can be written into them at the end. 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 — 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 a run.)
- 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/XHRcalls 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.
- Tab groups — only to draw a line under the tab a run or authoring session is on: Groma puts that tab in a group of its own, adds the tabs and windows you open from that group (and any you add yourself), and removes the group when the session ends. During a run the video shows the group's tab you're looking at, and never a tab outside it; closing the run closes the group's tabs. A tab already in one of your groups is left alone; no other tab is touched.
- 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 back up to Google Drive or share by link (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.