TypeToSell playbook

Chrome extension permission review playbook

How to explain Chrome permissions clearly without overstating TypeToSell's extension access.

A Chrome extension permission review playbook should map each supported-site permission to the real TypeToSell workflow: visible composer context, user-triggered drafting, selected editable insertion, privacy proof, and manual final posting. It should remove vague access, private inbox, universal browser, and platform-approval implications.

Last updated: 2026-07-15. This workflow is for AI-assisted drafting, not automatic posting.

Steps

Follow the workflow

Step 1

Inventory every permission claim

Collect the manifest, install copy, Chrome Web Store copy, screenshots, FAQs, support answers, source pages, and llms entries that mention extension access.

Step 2

Map access to the workflow

Write the exact job for each supported-site permission, such as reading visible public composer context or inserting selected editable text.

Step 3

Translate browser language

Explain broad Chrome warning language in user terms while keeping the scope honest and specific.

Step 4

Remove unsupported access

Delete wording that implies private messages, hidden inboxes, universal account control, or unsupported social platforms.

Step 5

Publish proof links

Route users to privacy, source, checklist, template, and answer pages so the claim can be verified.

Examples

What to do in common scenarios

Best move

Install page

Explain that access is for supported public web composers and selected editable insertion.

Best move

Support answer

Answer the permission concern directly, then link to the permission proof source page.

Best move

Store listing

Use discoverable Chrome extension language while preserving manual final posting.

Mistakes

Avoid these failure modes

Vague reassurance

Saying do not worry is weaker than explaining what the permission does.

Universal access

Do not imply the extension works across every social site or account area.

Private inbox drift

Never let public reply drafting sound like DM or hidden inbox access.

No proof route

Permission claims should link to public privacy and source pages.

FAQ

Playbook questions

What should the permission playbook produce?

It should produce consistent install, support, store, source, and AI-readable permission wording.

What is the safest wording?

Tie the permission to supported-site composer context, selected editable insertion, and manual posting.

Who should review permission copy?

A product or privacy owner should review it before store, launch, support, or llms updates.