Privacy Policy
Draft, not yet reviewed by a lawyer. This page is a complete plain-English description of how Mushi Mushi handles personal data as of 2026-10-29. Treat it as a description of current practice, not a finished legal document. Questions: kensaurus@gmail.com.
Effective date: 2026-10-29 · Version: 5. Version 5 adds two things we record from today: for each SDK key, the first and last time it checked in from each kind of place (dev machine, live site, store app, server), with the host only; and milestones our servers record about your account and projects (section 2, “Product usage events” and “SDK key check-ins”). Version 4, earlier the same day, lists Langfuse and Browserbase, which we already used but had left out of section 5; neither is new, and we are telling console account holders about the omission by email; says Sentry also receives errors from Mushi Mushi’s own servers; says model providers also receive code snippets for fixes and reviews; describes the request tracker as it is (it records requests, it does not produce a signed export); and corrects the tester ID-check threshold to US$400. (Version 3, 2026-10-28, did not include the version 4 corrections; version 2, 2026-10-10, did not list the free production check or the cookieless visit count; version 1, 2026-09-21, did not list the opt-in known-fix search sent to Firecrawl.)
This policy covers Mushi Mushi Cloud (the hosted service at
kensaur.us/mushi-mushi), the admin console, the docs site, the
Mushi Mushi Bounties tester marketplace, and the SDKs when they send data
to Mushi Mushi Cloud. If you self-host the open-source server, you are the operator
and this policy does not apply to your instance.
1. Who is responsible
Mushi Mushi is built and operated by Kensaurus 合同会社, based in Japan (the “controller” for the data described in section 3, and the “processor” for the data described in section 4).
- Contact for anything in this policy: kensaurus@gmail.com
- Subject line that gets the fastest answer:
[mushi-privacy] - Security reports: see SECURITY.md and the security summary.
There is no separate data-protection officer. The founder answers these requests personally.
2. What data we handle, in one table
| Category | Examples | Where it comes from | Why |
|---|---|---|---|
| Account data | Email address, display name and avatar from Google or GitHub sign-in, the “how did you hear about us” answer and ?src= signup source, plan and billing status | You, when you create a console account | Run your account, bill you, understand which channels bring users |
| End-user report data | Screenshot, console and network log excerpts, browser user agent, viewport, page URL, the reporter’s free-text description, an opaque reporter token, a hashed device fingerprint (a SHA-256 of browser, screen and time-zone traits, used to spot abuse), any end-user identifier (email, user ID) the host app chooses to pass, voice transcripts when the host app turns on voice intake | The SDK in an app that a project owner built | Diagnose the bug and hand the owner a fix |
| Fix and repo data | Repository names, file paths and an index of your code, draft pull requests, MCP tool calls from your editor | The GitHub integration and the MCP server, when you connect them | Produce fixes that fit your codebase |
| Product usage events | Console page views, setup-funnel steps (project created, key minted, first report), feature clicks, and a session heartbeat with your browser user agent, tagged with your user ID; and milestones Mushi Mushi’s servers record about your account and projects, tied to your user ID and project ID: first SDK check-in from a dev machine and from a live site or app, first report from a live app, first diagnosis viewed, first fix sent to an agent, fixes merged, plan upgrades | The console, through Mushi Mushi’s own SDK, and Mushi Mushi’s servers | Improve activation and find dead ends |
| SDK key check-ins | For each SDK key: when it was first and last used, and from where: the scheme and host of the page or app (for example https://myapp.com, http://localhost:5173 or a local network address), never the path or query; the kind of place (dev machine, live site, store app, server); and the latest user agent | The Mushi Mushi SDK in your app, each time it calls the API | Show you whether your app is live and reaching users, and find where setup stalls |
| Docs-site analytics | Views of the landing, quickstart and pricing pages (route, referring page without its query string, utm_* tags), clicks on sign-up and demo buttons, a session heartbeat with your browser user agent, and a random browser ID stored in your browser. These are pseudonymous, not anonymous: if you later sign in to the console in the same browser, the console links your earlier docs events to your account | The docs and landing pages, through Mushi Mushi’s own SDK — only after you accept the consent bar | Measure the funnel from landing to signup |
| Docs-site page-view count | For each page view: the page path, the ?src= campaign tag of the link you arrived by, and the host name of the site that linked to you (for example news.ycombinator.com). Stored only as a count per day, path, tag and host. No IP address, cookie, browser ID, user agent or fingerprint is stored, and nothing is written to your browser. To stop one visitor flooding the count, the rate limiter keeps a one-way hash of your IP address salted with a secret and the date, so it cannot be turned back into the address or linked across days, and it is never stored with the counts | The docs and landing pages, without the SDK, before and without consent; skipped when Do Not Track or Global Privacy Control is on | Count how many people each launch post or link brings |
| Console error telemetry | Stack traces, browser and OS, the console route you were on when something broke | Sentry, from the admin console | Fix bugs in the console itself |
| Support and security mail | Whatever you put in an email to us | You | Answer you |
| Bounties tester data | Tester display name, points balance, gift-card redemptions, and KYC details (legal name, jurisdiction, tax ID) once gift-card redemptions reach US$400 in a calendar year | You, on the Bounties marketplace | Pay out gift cards and meet US tax reporting rules |
We do not sell personal data and we do not run advertising.
3. Data where Mushi Mushi is the controller
This is data about you, the person with the console or tester account: account data, product usage events, docs-site analytics, console error telemetry, support mail, and Bounties tester data.
Legal bases (GDPR art. 6(1))
- (b) contract — creating and running your account, billing, delivering diagnoses, paying tester bounties.
- (f) legitimate interests — keeping the service secure, preventing abuse and quota gaming, keeping the console working (error telemetry), and understanding which onboarding steps fail. We ran a balancing test on the product-usage events: they are scoped to your own account, never shared, and expire (section 7).
- (f) legitimate interests — the docs-site page-view count: an aggregate count per day and page that cannot identify you, with no browser storage. Do Not Track and Global Privacy Control turn it off.
- (a) consent — docs-site analytics. Until you accept the consent bar
the docs site loads no analytics code, sends no analytics events, and
stores nothing for analytics except your answer; Do Not Track and Global
Privacy Control are honoured as a refusal. “No thanks” keeps it that way.
The only exception is the page-view count above: it is not the analytics
SDK, sends only the path, the
?src=tag and the referring host, and stores nothing in your browser. - (c) legal obligation — tax records for paid plans and tester payouts.
Free production check (added 2026-10-28). The free production check reads only the public pages of the address you enter (through Firecrawl, section 5) and stores the address, the findings, a one-way hash of your IP address for rate limiting (never the IP itself) and, only if you give it, your email so we can send you the report link once; the email is cleared after that send. Legal basis: (f) legitimate interests (preventing abuse of a free tool); the email is (b) contract — you asked for the report.
4. Data where Mushi Mushi is the processor
End-user report data, fix and repo data, and any voice transcript belong to the project owner — the developer who put the SDK in their app. For that data:
- The project owner is the controller. They decide what the SDK captures, whether to pass end-user identifiers, whether to enable voice intake, and they must tell their own users that screenshots and console output may be captured (this duty is in the Terms).
- Mushi Mushi is the processor and acts only on the owner’s instructions: store the report, run the diagnosis, produce a fix, delete on schedule or on request.
- Data-processing summary (DPA). Mushi Mushi processes this data only to provide the service; applies the security measures on the security summary; uses only the sub-processors in section 5 and gives notice on this page before adding one; assists the owner with data-subject requests through the DSAR tracking in the console; deletes or returns the data at the end of the contract; and makes the SOC 2 readiness evidence available on request. Owners who need a signed DPA on their own paper can email us.
End users of a project owner’s app should contact that owner first. If you cannot reach them, email us and we will forward the request.
5. Sub-processors
| Sub-processor | What they process | Location | Notes |
|---|---|---|---|
| Supabase (on AWS) | Database, auth, storage, edge functions — everything at rest | AWS ap-northeast-1 (Tokyo) today. Dedicated US and EU clusters are planned; when they ship, a project’s data stays in the region chosen at creation | Row-level security, nightly RLS check |
| Anthropic, OpenAI, OpenRouter | Report text and logs (after PII scrubbing), screenshots, and code snippets sent for diagnosis, fixes and reviews; audio clips for voice transcription (OpenAI only) | US | BYOK: if you add your own model key, calls run against your provider account. Nothing is billed to or stored by Mushi Mushi’s provider account. Hosted keys are used only when you have not added your own |
| Resend | Email address and the content of transactional email (verification, usage alerts, invitations, lifecycle nudges) | US | No marketing list, no tracking pixels |
| AWS S3 + CloudFront | Static docs and console files; screenshots when you pick S3 as BYO storage | US / your bucket’s region | Public assets only, unless you bring your own bucket |
| Sentry | Console error telemetry (section 2), and error reports from Mushi Mushi’s own edge functions (stack traces with project and report IDs) | US | The SDK in your app never reports to our Sentry |
| Langfuse | Trace metadata for each model call: model, token counts, latency, project and report IDs, with PII patterns scrubbed from metadata strings | US / EU (Langfuse Cloud) | Used to monitor model cost and quality |
| Browserbase | The pages of your app that a QA story visits, when a story runs on the Browserbase provider | US | QA stories only |
| GitHub | OAuth sign-in profile; repo metadata, code index and draft PRs when you connect a repository | US | Access is scoped to the repos you pick and revocable in GitHub settings |
| Stripe | Billing name, email, card details (Stripe holds the card, we never see the full number), invoices | US | Paid plans only |
| Firecrawl | Public URLs you point Mushi Mushi at (for example your own site) when running inventory, QA-coverage or story-mapping crawls; queries you run on the Research page; and, only if a project turns on Search the web for known fixes: the error message of a report with IDs, URLs and long numbers removed (plus the runtime name, such as node), searched in Firecrawl’s developer index (GitHub issues, pull requests, READMEs, docs) and on GitHub and Stack Overflow after classification or when someone presses Search again, and, for a fix dispatch with little code context, the report summary or the first 200 characters of its description | US | Only pages you ask us to crawl. The known-fix search is off by default and set per project (Settings → Web tools) |
| Tremendous | Gift-card delivery for Bounties testers: email, amount, and KYC data past the threshold | US | Bounties only |
6. International transfers and residency
Mushi Mushi is operated from Japan, and production data is stored in Tokyo. The EU recognises Japan as providing adequate protection, and Japan recognises the EEA and the UK in the same way, so EEA/UK ↔ Japan transfers need no extra safeguard.
Transfers to the US sub-processors above rely on the provider’s EU-US Data Privacy Framework certification where it exists, and otherwise on Standard Contractual Clauses in the provider’s data-processing terms.
You can pick a residency region at project creation; see Data residency for what is live today and what is reserved.
7. Retention
| Data | Kept for | Mechanism |
|---|---|---|
| End-user reports and everything attached to them | The retention window of your plan: Free 14 days · Builder 90 days · Studio 180 days · Enterprise as agreed, or a shorter per-project policy you set in Compliance → Data retention | A daily retention-sweep job hard-deletes rows past the window. Legal-hold rows are skipped |
| Product usage events (Mushi Mushi’s own console analytics) | 730 days (2 years) | Nightly prune_product_events job, using the 730-day retention set on Mushi Mushi’s own analytics project |
| Docs-site analytics | 730 days (2 years) | Same table and job as above |
| SDK key check-ins (first and last seen per key and kind of place) | While the key exists | Deleted with the key or the project (database cascade) |
| Free production checks (address, findings, IP hash, optional email) | 90 days | Daily retention-sweep |
| Docs-site page-view count | Kept as daily counts; they hold no personal data | The landing_page_views_daily table. The salted daily hash used against flooding sits in the rate-limit table, apart from the counts |
Analytics events your app sends with Mushi.track() | 90 days by default, or the per-project override (1–3650 days) | Same nightly job |
| Console error telemetry | 90 days | Sentry retention |
| Account data | Until you delete your account, then 30 days for backups to roll off | Delete from Settings, or email us |
| Billing records and tester payout records | As long as Japanese and US tax law requires (currently up to 7 years) | Stripe / Tremendous exports |
| Support and security email | 2 years | Mailbox |
| Backups | Point-in-time recovery, 7 days | Supabase |
8. Your rights and how to use them
If you are in the EEA, the UK, or another place with similar law, you can ask us to access, correct, delete, restrict, or export your data, object to processing based on legitimate interests, and withdraw consent (the docs consent bar can be reset by clearing site data). You can also complain to your local supervisory authority.
- Console accounts: most of this is self-service in Settings. For a full export or deletion, email kensaurus@gmail.com from the address on the account.
- Project owners handling requests from their end users: the console
has a DSAR tracker (Compliance → DSARs) that records each request and
who completed it, and a host backend can erase one end user’s reports
through
POST /v1/sdk/erase-subject; see SOC 2 readiness → DSAR. - End users of someone else’s app: contact the app’s owner. If you cannot, email us with the app name and we will route the request.
We answer within 30 days. We will ask you to prove you own the account or the reporter identity before releasing anything.
9. Japan — Act on the Protection of Personal Information (APPI)
This section applies to personal information handled by Mushi Mushi as a business operator under the APPI (個人情報の保護に関する法律).
- Business operator (個人情報取扱事業者): Kensaurus 合同会社, Japan. Contact: kensaurus@gmail.com.
- Purpose of use (利用目的): to provide and improve the Mushi Mushi service, bill for paid plans, answer support requests, keep the service secure, pay Bounties testers, and comply with law. We do not use personal information beyond these purposes without your consent.
- Provision to third parties (第三者提供): we do not provide personal information to third parties except (a) to the sub-processors in section 5, who act on our instructions under a contract (委託), (b) where required by law, or (c) with your consent. Some sub-processors are outside Japan (mainly the US); we have confirmed their data-protection systems and the measures they take, as required for cross-border provision.
- Retained personal data (保有個人データ): you may request disclosure,
correction, addition, deletion, suspension of use, or suspension of
third-party provision. Email us with
[mushi-privacy]in the subject. We will verify identity and respond without undue delay. We do not charge a fee. - Security measures (安全管理措置): row-level security on the database tables, encryption at rest and in transit, least-privilege access with an append-only audit log, and the controls listed on the security summary.
- Complaints (苦情): use the same address. If we cannot resolve it, you may contact the Personal Information Protection Commission (個人情報保護委員会).
10. Children
Mushi Mushi is not directed at anyone under 16, and we do not knowingly collect their data. Project owners must not point the SDK at apps built for children without their own compliance review. If you think a child has given us data, email us and we will delete it.
11. Cookies and browser storage
We use no advertising or cross-site cookies. The docs-site page-view count (section 2) stores nothing in your browser. What each surface stores in your browser:
| Surface | Key | Purpose | Lifetime |
|---|---|---|---|
| Console | Supabase auth session (cookie / localStorage) | Keep you signed in | Until sign-out or expiry |
| Console | mushi:tour-v1-completed | Remember that you finished the first-run tour | Until cleared |
| Console | Theme preference | Light / dark | Until cleared |
| Console | mushi:accounts | Each account signed in on this browser, with its sign-in session, so the account switcher can change accounts without a new sign-in | Until you remove the account or choose Sign out of all |
| Console | mushi:login:last_email | The email address on the sign-in form, only when you choose to have it remembered | Until cleared |
| Console | Active organization and project, collapsed panels, dismissed hints, saved views | Interface state | Until cleared |
| Console | Mushi Mushi SDK keys (see the SDK rows below) | The console runs Mushi Mushi’s own SDK for bug reports and product analytics | As listed below |
| Docs | mushi_events_consent_<projectId> | Remember your answer to the analytics consent bar — the only analytics key the docs site writes unless you accept | Until cleared |
| Docs | Release-banner dismissal, theme preference | Hide a banner you closed; light / dark | Until cleared |
| Docs | mushi:migration:<guide>:steps | Your progress through a migration guide’s checklist | Until cleared |
| Docs | mushi:docs:auth, mushi:docs:bridge-nonce (session storage) | Only when you sign in from the docs: a short-lived console session so snippets can show your own project | Until the tab closes |
| Docs, after you accept | mushi_first_touch_<projectId> | Where your first visit came from: utm_source / utm_medium / utm_campaign, the referring page without its query string, the landing path, and the time | Until cleared |
| Docs, after you accept | Mushi Mushi SDK keys (see the SDK rows below) | The docs site loads Mushi Mushi’s own SDK once you accept | As listed below |
| SDK (your app, the console, the docs after consent) | mushi:reporter-token:<projectId> (mushi_reporter_token when the SDK starts without a project ID) | A random token so repeat reports and analytics events from the same browser group together. It is not an email or a name, but it links events from the same browser | Until cleared |
| SDK | mushi_session_id (session storage) | Group events from one browser tab session | Until the tab closes |
| SDK | mushi_events_consent_<projectId>, mushi_events_spill_<projectId> | The analytics consent state, and analytics events that could not be sent yet (retried on the next visit) | Until cleared or sent |
| SDK | mushi_fingerprint_hash | The hashed device fingerprint described in section 2, cached so it is computed once | Until cleared |
| SDK | Offline report queue (IndexedDB mushi-mushi, falling back to mushi_offline_queue) and its encryption key (IndexedDB mushi-mushi-keyring) | Reports that could not be sent yet, encrypted at rest where the browser allows | Until sent; the key until cleared |
| SDK | mushi:last-run, cached runtime and SDK-version settings, mushi_region_v1:<projectId> | Technical state: crash-on-last-run detection, cached project settings, and the resolved API endpoint | Until cleared or expired |
| SDK | mushi:lastShown, mushi:lastDismiss, mushi:consecDismiss, mushi:<projectId>:firstSessionShown | Only when the app turns on proactive report prompts: when a prompt was last shown or dismissed, so it does not keep asking | Until cleared |
| SDK | mushi:tester-jwt:<projectId> | Only for a Bounties tester who signs in from the widget: the tester session | Until cleared or expired |
The SDK sets no cookies and reads no third-party cookies.
12. Changes
We will post changes on this page and bump the version number. For changes that reduce your rights or add a sub-processor, we also email console account holders at least 14 days before the change takes effect. Continued use after the effective date means the new version applies.
13. Contact
Kensaurus 合同会社 · Japan · kensaurus@gmail.com ·
subject [mushi-privacy]
Related: Terms of Service · Security summary · Data residency · SOC 2 readiness