Security and data handling

Bugpacker 1.1.2. Everything below is checkable against the extension package, and the last section says how to check it.

Written to be forwarded. If you are reviewing Bugpacker on behalf of an organisation, this page answers the questions in the order they usually get asked: what leaves the machine, what is stored, which permissions are held and why, and how to verify all of it yourself. Anything missing, ask: hello@bugpacker.com.

What it does

Bugpacker is a Chrome extension that records a bug while somebody reproduces it, then builds a ZIP file containing the screenshots, console output, network activity, page snapshot, form state and reproduction steps. The user saves that file and attaches it to their own issue tracker.

What leaves the machine

None of the captured data. The recording is held in the browser's session storage, the ZIP is assembled in the browser, and it is written to the user's own downloads folder. There is no Bugpacker server for it to go to. We do not operate one.

The extension makes network requests to exactly one host, and only these three endpoints:

Endpoint	When	What is sent
`api.lemonsqueezy.com/v1/licenses/activate`	Once, when a licence key is entered	The licence key and a device label such as "Bugpacker on mac"
`api.lemonsqueezy.com/v1/licenses/validate`	At most once a day, for licensed users	The licence key and the instance id returned at activation
`api.lemonsqueezy.com/v1/licenses/deactivate`	When a user releases a device	The licence key and the instance id

Lemon Squeezy is the payment provider and merchant of record. No page content, URL, browsing information or captured data is included in any of these requests. An unlicensed user makes no network requests at all.

There is no analytics, no telemetry, no error reporting service and no crash reporting. Not reduced or anonymised: absent.

What is stored, and where

Store	Contents	Lifetime
`chrome.storage.session`	The recording in progress and the package awaiting review	Cleared when the browser closes
`chrome.storage.local`	Settings and the licence key	Until the extension is removed

Both are local to the machine. Removing the extension deletes all of it.

Permissions, and why each is held

Permission	Why
`activeTab`	Access to the one tab the user invoked Bugpacker on, granted by their click. This is what allows the extension to work without requesting access to every site at install time.
`scripting`	Draws the region selector, records console and network activity from inside the page, and reads the page snapshot and form state when recording stops. Injected only into the tab being recorded.
`storage`	The two stores described above.
`downloads`	Writes the finished ZIP to the downloads folder. This is the extension's only means of delivering its output.
`sidePanel`	The capture interface.
`alarms`	Stops a forgotten recording after a configurable limit, and schedules the daily licence check. Service workers are terminated between events and cannot hold timers.
`webNavigation`	Re-attaches the recorder when the page navigates mid-recording, so a reproduction spanning more than one page is captured completely.
`webRequest`	Observes whether requests succeeded or failed, so failed requests appear in the report. Observation only: nothing is blocked, redirected or modified.
`api.lemonsqueezy.com`	The three licence endpoints above.
`<all_urls>`, optional	Never requested at install. Requested for a single origin, at the moment a recording starts, and only when a reproduction may cross origins, because Chrome's temporary `activeTab` grant ends at a cross-origin navigation. A user who declines it can still record within one origin.

Two things worth knowing about the install prompt

Chrome renders webNavigation as "Read your browsing history". That is Chrome's wording for the permission, not a description of what Bugpacker does with it: it is used to notice that the recorded tab navigated, so the recorder can re-attach. No history is read, stored or transmitted.

The prompt does not include "Read and change all your data on all websites", because the all-sites grant is optional and deferred to the moment it is needed.

What is deliberately never captured

The distinction that matters for a data review: some things are redacted after capture, and some are never captured at all. The second list is the stronger one.

Field values are never recorded. The page snapshot drops every value attribute, and the form state record keeps only the label, the validity and why the field was rejected. A password, a card number or a search term typed into a form does not enter any file, so there is nothing to redact.
Inline script bodies are removed from the page snapshot, since they routinely carry configuration and tokens.
Cookie and storage values are not read. Only their names appear, as environment context.

Separately, and on a best-effort basis, emails, phone numbers, card numbers, authorisation headers and tokens found in logs and network data are replaced with placeholders that keep the format and drop the content. Payment and password fields are masked in screenshots. None of this can be switched off. It is best effort and is described that way in the privacy policy: Bugpacker is a bug reporting tool, not a data-loss-prevention product, and the user reviews the whole package before it is saved.

Code and supply chain

No remote code. Everything the extension runs ships inside the package. Nothing is fetched or evaluated at runtime, and web_accessible_resources is empty.
Manifest V3, which forbids remote code by design.
Three runtime dependencies: React, React DOM, and fflate for building the ZIP. No analytics SDK, no error reporting SDK, no tag manager.
Source maps ship with the package, so the original TypeScript is readable by anyone who unpacks it. This is deliberate.
Distributed only through the Chrome Web Store, which reviewed and signed it.

If Chrome warned that the extension is "not trusted by Enhanced Safe Browsing"

That warning reflects the age of the publisher account, not an assessment of the code. Google's own position is that it takes a new developer at least a few months to become trusted, that it cannot be fixed by the developer, and that it resolves on its own for developers who follow their policies. Bugpacker was first published in September 2026. Users on Chrome's standard protection see no warning.

How to verify all of this

None of the above requires taking our word for it. A Chrome extension is a ZIP file of readable code.

Install it, then find it under Extensions/<id>/ in your Chrome profile directory. Or download the CRX with any of the usual tools.
manifest.json lists every permission and every host the extension may contact. Compare it against the table above.
Search the bundled JavaScript for http. Every outbound URL will be one of the three api.lemonsqueezy.com licence endpoints. The only other matches are links a user can click.
Watch it work: open the browser's network inspector on the recorded page and on the extension's own pages, and record a bug. An unlicensed install produces no outbound request at all.

What we cannot claim

Bugpacker holds no certifications. There is no SOC 2 report, no ISO 27001, no FedRAMP authorisation and no penetration test to share. It is a small independent product and pretending otherwise would waste your time.

What it offers instead is a smaller question to answer. There is no vendor processing your data, so there is no data processing agreement to negotiate, no sub-processor list to review, no breach notification path to agree and no vendor to re-assess next year. The captured bug data never leaves the machine it was captured on. For many organisations that turns a vendor review into a software review.

Questions

hello@bugpacker.com. If your review needs something specific in writing, ask, and if the honest answer is that we do not have it, that is the answer you will get.