Development data inventory
How Vibe Launch Master Handles Your Data.
Vibe Launch Master does not sell personal data or build advertising profiles. It processes only the data required for OAuth sign-in, service operation, safety, recovery, optional website analytics, and any directory application or support request a user submits. Local secrets and browser credentials follow the product security boundary described below.
What data is used for Google, Apple, or GitHub sign-in?
OAuth sign-in can process the provider identifier, verified email when supplied, display name or profile image when supplied, authentication timestamps, and the minimum token or session metadata needed to create and protect an account. The exact production scopes must be listed with the released sign-in flow.
What account and organization data is stored?
The service can store account identity, organization membership, role, project metadata, connection state, capability receipts, minimal campaign summaries, release metadata, support history, and security events required to operate or recover the service. It does not require an advertising profile.
What stays on the user’s device?
Local data can include product sources, working documents, Launch Master versions, raw browser artifacts, temporary asset variants, detailed campaign events, checkpoints, browser sessions, and operating-system credentials. The released desktop app remains authoritative for the final local-data inventory.
Where are directory passwords and AI keys stored?
Directory passwords remain in Chrome Password Manager inside the dedicated profile. AI provider keys remain in the operating system credential store. Vibe Launch Master does not create its own cloud password vault for directory credentials.
What website analytics are used?
No website analytics provider is enabled in the current development implementation. If analytics is added later, this page must identify the provider, events, identifiers, retention period, consent basis, opt-out method, and whether data leaves the user’s region before the script is deployed.
What data is processed for directory applications?
A production directory application can process directory name and URLs, operator identity, verified work email, accepted product types, free-path and fee disclosure, review process, example listings, audience evidence, ownership evidence, files, consent timestamp, status events, and reviewer decisions. The current development form is disabled and stores nothing.
Which third parties receive data during a launch?
A directory receives the product materials, account data, and listing fields needed for its submission flow. A connected email provider processes verification messages. A user-selected AI provider processes only the adaptation request sent to it. Chrome and the operating system process browser and credential data according to their own terms.
How long is each data category retained?
Final retention periods have not yet been approved for the production release. Before launch, the policy must specify separate periods for account data, security events, directory applications, evidence uploads, support requests, campaign summaries, receipts, website logs, and deleted-account backups.
This development page does not invent retention periods. Production collection must not begin until the applicable retention and deletion rules are documented and implemented.
How can a user access, correct, export, or delete data?
The production service must provide a verified request route for account access, product-fact correction, export, connection revocation, directory-application correction or withdrawal, and deletion subject to security, legal, fraud-prevention, and durable-receipt requirements. The general support endpoint is not connected in this preview.
How are policy changes recorded?
Material changes must update the effective date, change history, public data inventory, product and security facts, and any consent surface affected by the change. A deployment date alone is not treated as a privacy-policy update.