TabsPack
Security
An extension that can read every tab you have open deserves to be held to a high standard. Here is how to tell us about a problem, and what the product does to have fewer of them.
Reporting a vulnerability. Please do not open a public issue.
Write to security@palworks.ai with what you found, how to reproduce it, and what an attacker could do with it. We will acknowledge within three working days and tell you what we intend to do. Give us a reasonable chance to fix it before publishing, and we will credit you in the release notes unless you would rather we did not.
In scope
- The extension: anything that lets a web page, another extension, or a crafted import file read or change something it should not.
- The import path, which is the most exposed surface: a hostile
.tabspack.jsonor foreign export that causes script execution, a navigation to a dangerous scheme, or a crash that loses data. - Anything that causes a secret to end up in an exported file. This should be impossible by construction; if it is not, it is the most serious class of bug this project can have.
- The support relay at
tabspack-support.palworks.ai: anything that lets somebody send mail as us, read another person's message, or use it to reach a third party. - This website, if it can be made to serve something it should not.
Out of scope
- Findings that require the attacker to already have your unlocked machine, or to have installed a malicious extension with its own permissions.
- Volumetric denial of service against the support relay. It is rate limited on purpose and past its cap the extension simply uses your mail client instead; we know it can be flooded, and the cost of that is a slower support channel.
- Missing headers on a static site that serves no user content and sets no cookies, unless you can show an actual exploit.
- Reports produced by a scanner with no demonstrated impact.
What the design already does about it
Most of the security of an extension is decided before any code is written, by what it asks the browser for. TabsPack asks for as little as it can:
| Decision | What it removes |
|---|---|
| No host permissions at install | The extension cannot reach any address. The only one it can ever be granted is the support relay, and you grant it at the moment you press Send |
| No content scripts, ever | Nothing of ours runs inside a web page, so a hostile page has nothing of ours to attack and we have no way to read a page |
| No remote code, and a strict content security policy | Scripts are pinned to the package. Nothing can be loaded and run from anywhere else, which is also a hard store policy requirement |
No innerHTML, anywhere | The build fails on it. Every piece of text from a file becomes a text node, so a title containing markup is a title, not markup |
| Dangerous schemes are refused on import | javascript:, data: and their relatives are never turned into a link or opened, and the report says a tab was skipped rather than dropping it silently |
| No secrets in an export, by specification | Cookies, tokens, headers and form data are excluded by the format definition. A pack cannot sign in as you |
| One file may make a request | The build fails on any transport anywhere else in the source, so the network surface is eighty lines that a reviewer can read in full |
| No key ships in the package | The mail key lives on the relay. A key inside a published extension is a public key, and this project will not ship one |
Checking it yourself
You do not have to take any of that on trust. The source is at
github.com/PalWorks/tabspack under the MIT
licence, the checks that enforce the claims above are in scripts/lint.mjs, and the
reasoning behind every non-obvious decision is written down as a numbered record in
docs/DECISIONS.md.
You can also unzip the published package and compare it: the build is deterministic from the source tree, and the source archive is submitted to addons.mozilla.org alongside the extension.
If something does go wrong
A fix ships as soon as it is ready, and store review time is outside our control. The release notes say what happened in plain language rather than "various security improvements", the privacy policy changes in the same release if anything about data handling changed, and a decision record explains how it was allowed to happen.