Last updated: 2026-11-08.
Vehra is a browser extension that helps a QA person report a bug with its proof. Vehra runs no server that receives your evidence, and the extension sends nothing to us. There are no analytics, no usage counts, no tracking and no advertising.
What Vehra reads
Only on web addresses you allow, and nowhere else:
- the network requests the page makes: address, method, status, timing, and request and response headers and bodies. Passwords, tokens, cookies, authorization headers and card numbers are taken out first;
- the messages in the browser console;
- the element you point at, the page's address (secret-looking values in the address are removed), and the steps you take. Steps are clicks, not what you type;
- where it was seen: the browser and system names, the window and screen size, the language, the time zone and the page's title;
- a screenshot of the page, with typed fields covered;
- only if you ask: a video clip with typed fields covered, a whole-page accessibility and SEO check, or a design check against a Figma layer.
The steps and the screenshot never include what you type. The steps carry no values, and typed fields are covered in the picture. A request body can hold what a page sent to its own server. Passwords, tokens, cookies, authorization headers and card numbers are taken out of it, but other form data in a body stays. You can leave bodies out of a ticket when you save it.
Where it goes
- Nowhere, by default. A ticket is saved on your computer, in the extension's own storage, and stays there until you delete it.
- To Notion, only if you connect your own workspace and then save a ticket. It goes from your browser to Notion, into your own database, and holds what the ticket holds: your note, the screenshot, and the request and response bodies unless you left them out.
- To GitHub, Linear or Jira, only if you connect one with your own key and then save a ticket. It goes from your browser straight to that service, as an issue in the one repository, team or project you chose. It holds what the ticket holds, as text: your note, the evidence (request and response bodies too, unless you left them out) and the receipt. Jira also gets the screenshot as an attachment. GitHub and Linear do not get the screenshot, and the issue says so. The key is kept in this browser, never in a ticket or a backup. Tickets go to one of these at a time, the one you chose.
- To Figma, only if you save a Figma token and paste a link. Vehra asks Figma for that one layer's numbers.
- To Slack, only if you paste a Slack webhook address and tick the box on a ticket. Vehra posts one message from your browser to that one channel. It holds your note, the page address, the element's selector, one line saying what the receipt says, and the counts of requests, failures and console errors. It never posts screenshots, video, request or response bodies, or headers, and secrets are blanked first. You can read the exact message before it is sent. The box is off for every ticket. If Slack does not answer, Vehra says it can't tell whether the message posted, and does not post again by itself. The address is kept in this browser, never in a ticket or a backup.
- To a file, only when you export one. An export or a backup is a copy that Vehra no longer controls, and it is not encrypted. It holds what the tickets hold.
How the data is used
Vehra uses what it reads only to make the ticket you asked for and the features you switch on, like a clip, a check or a test. It is not sold, not shared, and not used for ads or for anything else. Vehra does not receive it, so nobody at Vehra can read it.
How long
Vehra keeps the last 30 seconds of network and console for an allowed page in the browser's session storage, not the long-term store. It throws that away when the tab moves to an address you have not allowed, or is closed. Tickets, and any tests you save (up to 20), stay on your computer until you delete them. Uninstalling the extension removes its local data.
Why each permission
| Permission | What Vehra uses it for |
|---|---|
debugger | To read a page's network requests and console on addresses you allowed. Chrome shows a bar saying Vehra started debugging this browser while this runs. See "Why Vehra needs the debugger permission" below. |
tabs | To know which address a tab is on, so Vehra can tell whether you allowed it and show whether it is recording. |
webNavigation | To notice when an allowed page finishes loading, so the recorder bar can appear on it. |
webRequest | To keep an observe-only list of request addresses and timings on allowed pages. Vehra never blocks or changes a request. |
scripting | To put the recorder bar on allowed pages and, only when you ask for a page check, the accessibility checker. |
storage | To keep your settings and your tickets on your computer. |
alarms | To check once a minute for a ticket waiting to be filed to Notion, and try again. |
| Optional access to sites | Asked for the one address (or the one domain, if you choose) you allow, at the moment you allow it. No site access is asked for at install. |
| Optional access to Notion, Figma, Slack, GitHub, Linear and Jira | Asked when you connect one: api.notion.com, api.figma.com, hooks.slack.com, api.github.com, api.linear.app, or the address of your own Jira site. Given back when you disconnect. |
Why Vehra needs the debugger permission
This is the permission Chrome warns about most, so here is exactly what it does.
- What it attaches to. Only a tab on an address you allowed. It attaches when that page loads, or when you click the Vehra icon on it.
- What it reads. The page's network requests and responses, the browser console, and a picture of the screen (a screenshot, and frames for a clip if you ask for one).
- What it does not use. Vehra uses five parts of the debugger: Network, Page, Runtime, Log and Target. It does not use any part that clicks or types for you, blocks or changes a request, changes the page, or pretends to be another device.
- What it blanks. Chrome hands Vehra each request inside your browser, on your computer. Vehra blanks passwords, tokens, cookies, authorization headers and card numbers right then, before anything is written to disk or sent anywhere. Vehra never saves the originals. Other data in a request body is kept, and leaving bodies out of a ticket removes it.
- When it stops. The moment you press Cancel on Chrome's "debugging this browser" bar. Vehra then stays off until you turn it back on.
What the install prompt says
In Chrome, the install prompt describes the debugger permission as "Access the page debugger backend" and "Read and change all your data on all websites", and the tabs and webNavigation permissions as "Read your browsing history". Those are Chrome's own words for what the permissions could do. What Vehra does with them is on this page: it attaches the debugger only to addresses you have allowed, and it sends nothing to us.
Early access list
If you ask for early access, you fill in a form hosted by Tally. It collects your name and the email address you enter. That information is used only to write to you about access to Vehra. It is kept until you have been invited, then deleted within 30 days, or sooner if you ask at [email protected]. Tally handles the form under its own terms.
Your choices
You choose which addresses Vehra may read, whether to connect Notion, Figma, Slack, GitHub, Linear or Jira, and when to export. You can delete any ticket, remove any address (which gives back the browser's access), and disconnect any of them (which removes the key or address, and the access). The Notion, Figma, GitHub, Linear and Jira keys and the Slack address are kept in the extension's storage in your browser, not encrypted, and are never put in a ticket.
What Vehra does not do
Notes are typed, and no audio is recorded.