01
Hard boundary
An extension must not become an unauthorized connector
Browser proximity does not grant permission to copy page data, read authentication cookies, intercept private requests, automate controls, or bypass provider restrictions. DewEngine's LinkedIn path remains decision-gated and unimplemented. A safe extension concept should focus on customer-owned CRM context, explicit user input, and links while provider data and actions stay unavailable unless a separately approved contract exists.
- Prohibit cookie, token, and session extraction
- Do not use DOM selectors as an unofficial API
02
Narrow permissions
Request only the browser access the feature needs
Prefer an extension popup or side panel that talks to the customer's backend using short-lived application authorization. Broad host permissions, background page inspection, clipboard capture, and all-tab access increase risk. Explain each permission in plain language and keep functionality useful with the provider page closed. Enterprise administrators should be able to restrict or disable the extension centrally.
- Use least-privilege host and storage permissions
- Keep secrets out of extension local storage
03
User-initiated context
Let the user supply a reference deliberately
A user might paste a profile URL into a CRM lookup, select an existing contact, or open a customer-owned task. Treat the URL as an unverified locator and require review before linking. Do not silently read the page or collect every profile visited. The extension should show what will be saved, the destination workspace, and how to undo it.
- Require an explicit capture action
- Avoid passive browsing histories and behavioral tracking
04
Action handoff
Prepare work in the SaaS, not the provider page
The companion can open a CRM record, create an internal note, or prepare a draft in the SaaS. Provider-visible messages or invitations remain separate commands requiring approved connector capability, sender authority, final review, account health, and budgets. Do not simulate clicks, inject send buttons into the provider interface, or randomize browser activity to imitate a person.
- Keep all approved actions in an auditable backend state machine
- Make capability absence visible instead of hiding a failed automation
05
Security
Assume page content and browser messages are untrusted
Validate origins, extension messages, deep links, and customer identifiers. Sanitize displayed page-derived text even when entered by a user, and never execute instructions found in content. Use signed updates, content-security policy, dependency review, and short-lived backend sessions. Support diagnostics should not include visited URLs or page text unless the user deliberately submits them for a bounded case.
- Test malicious pages and cross-origin message spoofing
- Separate extension identity from provider account identity
06
Release criteria
Review the extension and connector as separate products
The extension needs browser-permission, security, privacy, update, enterprise-policy, telemetry, and deletion review. Any LinkedIn data or action needs the additional legal, provider, account-entitlement, conformance, restriction, pacing, audit, and kill-switch gates. Passing a browser-store review would not approve provider automation. The minimal safe release can remain a CRM companion with no LinkedIn extraction.
- Document exactly which page information is never collected
- Prove uninstall and workspace deletion remove extension-held data