Secure, test, and publish
Review permissions and data
Audit every requested capability, stored value, transmitted field, and website interaction before asking users to trust the extension.
8 minute lesson
Extensions can see sensitive browsing context. A permission that is easy to add may be difficult for a user to justify.
Remove unused permissions, prefer activeTab to broad host patterns, collect no data the feature does not need, and keep page notes local unless sync is an explicit feature. Document retention and deletion behavior plainly.
Separate API permissions from host access in the audit. storage enables an API; activeTab grants temporary access after a gesture; host_permissions grants ongoing access to matching origins. Optional permissions can delay broader authority until a user requests the feature, but the request must happen from a user gesture and refusal must leave a usable product.
Audit flows, not only declarations. The active URL becomes a storage key, note text moves from a trusted popup into an untrusted page DOM, and extension updates can change future behavior. For each transition, identify who can read it, how long it remains, and what happens when the user deletes the note or uninstalls the extension.
Local-only is a meaningful boundary only if the code has no analytics, crash reports, remote API, or embedded third-party resource carrying that data. Verify with the Network panel and source review. If data practices change later, store disclosures and consent must change before the release.
Create a permission-and-data table covering feature, gesture, context, fields, destination, retention, deletion, warning, and denial behavior. Remove one permission and prove the unrelated journeys still work. Capture Network evidence that Page Notes transmits no note or page URL.
Lesson completed