Published revision 1.0 (2026-10-18). This page is generated from the canonical policy text; both carry the same revision.

TameFlash data and privacy policy

Revision 1.0 — 2026-10-18. This file is the canonical, owner-approved text (issue #109). The published copy at https://tameflash.com/privacy (Cloudflare Pages) is generated from this file by scripts/build-site.mjs and carries the same revision. The extension bundles the revision its Privacy link points at and shows a one-time notice in the popup and on the Options page when that revision changes (a fresh install records the current revision at install time, so only a change is announced).

Data controller: Jan Bednář, an individual developer in the European Union. Privacy requests, deletion requests and support: [email protected]. GDPR applies to users in the EU and is the baseline applied to everyone.

1. Summary

• TameFlash analyses video on your device. Nothing about what you watch leaves the browser unless you deliberately submit a report.
• The only requests TameFlash sends to its own service today are the manual incident report (you press "Report a problem", review the exact payload, and press Submit; each report is a separate decision) and the deletion of such a report (you press Delete next to it; the request carries that report's deletion code). (Your browser may additionally synchronise the extension's settings between your own profiles through its vendor's sync service; TameFlash never receives that data, see section 4.1.)
• A report never contains the page URL, the video title, your account, your IP address as a stored field, or any identifier of your installation. It contains the public video identifier of the supported provider when one exists, the playback time, the protection state at that moment, the detector's recent hazard summary, and an optional note you typed.
• Reports are stored by Cloudflare (Workers, D1) in a database created with Cloudflare's EU jurisdiction constraint. A report becomes eligible for deletion 180 days after receipt (reports received before 2026-10-19 keep the 90-day schedule they were submitted under), a note after 30 days; an hourly cleanup job removes eligible rows, so actual removal follows that schedule and a backlog or outage can delay it. You can delete a report earlier with the one-time deletion code kept on your device: that removes it from the active database at once; Cloudflare's point-in-time backup history can still contain it for up to 30 days before it expires.
• The optional note is free text. You are told not to type health details, names or contact information, but the service cannot prevent it, so a note may contain personal data you chose to type; it is read by the maintainer only and deleted on sight when it does.
• No data is sold, shared with third parties, or used for advertising.
• The service is not anonymous: omitting accounts and install identifiers does not stop Cloudflare from handling the ordinary network metadata (IP address, request time) that any HTTPS request carries. Section 4 says what happens to it.
• Every planned feature that would send more (exact video lookups, automatic evidence sharing, creator uploads) is off, unbuilt, and marked PROPOSED below. Each needs a separate owner approval on its issue before it ships.

2. Locked constraints (from issue #109, verbatim in substance)

• Manual submission is per-report consent; any optional diagnostics bundle requires a separate unchecked opt-in.
• Exact catalog lookups and automatic detector-evidence sharing are independent, default-off controls.
• No stable installation identifier is introduced merely to rate-limit or establish crowd quorum.
• No production endpoint, automatic lookup, evidence upload, creator upload, or catalog publication ships until this policy is accepted (for the shipped class, it is; for the planned classes, their PROPOSED rows must be approved first).
• Automated downloading or retrieval from YouTube is out of scope unless a later authorization review explicitly permits it. The first scanner accepts authorized uploaded files only.
• The policy must never describe the service as anonymous merely because it omits an account or installation ID.

3. Decisions (owner, 2026-10-18) and PROPOSED values

4. Data inventory

Columns: what is collected; purpose; lawful basis; where; who can access; retention; deletion path; backups and logs; incident handling. "Device" means the user's browser profile. Most Device rows never leave it; the exceptions are stated in the row itself: a report draft's serialized payload, note and idempotency key are transmitted when the user submits or retries that report, and a stored deletion code is transmitted when the user deletes that report. Nothing in a Device row is transmitted without one of those explicit actions.

4.1 Shipped today

4.2 Planned, not built, PROPOSED

5. Processor boundaries

Cloudflare (Workers, D1, Workers Logs; R2 once uploads exist) is the only processor today. The Worker runs on Cloudflare's global edge network at the location nearest the user, so the request itself (IP address, timing, TLS metadata, Origin) is handled wherever that location is; no Regional Services or Customer Metadata Boundary product is configured, and this policy does not claim an EU boundary for request handling. The production database tameflash-reports-eu was created on 2026-10-18 with wrangler d1 create --jurisdiction=eu, the only way D1 location can be constrained, so EU residency is a Cloudflare guarantee rather than an observed region (it runs in EEUR). The previous database, created without a constraint and holding no user reports, is retired with the deploy that publishes this revision. Any future R2 bucket is created with the same EU jurisdiction. Cloudflare necessarily sees connecting IP addresses, request timing, TLS metadata and the request Origin. The application does not store any of them itself: the rate limiter is Cloudflare's Workers rate-limiting binding keyed by the connecting IP (counters are cached on the serving machine and asynchronously stored in that Cloudflare location; the 60-second period is the limiting window, not a documented deletion deadline), the Firefox per-install Origin is matched by shape only, Workers invocation logs are disabled in wrangler.toml, and application logs carry status and error codes only. Account-level Logpush, Tail Workers and Cloudflare's own edge analytics are governed by Cloudflare's terms, not by this repository, and are not enabled for this service.

Dedicated scanner (planned, #114): a maintainer-operated host that talks only to the authenticated Worker API and never receives direct database access. It holds uploaded media only for the duration of a job plus the deletion window above. Its trust boundary is the Worker's authentication; media never reaches it from any source other than maintainer fixtures or rights-attested uploads.

6. Incident response

1. Contain: disable the affected endpoint (wrangler route removal or an immediate deploy of a refusing worker), rotate the Cloudflare API credentials and any scanner tokens, delete rows known to be affected.
2. Assess: what classes (section 4) and which time window were exposed; record the incident with timestamps in the maintainer's incident log.
3. Notify: users through a one-time in-extension notice and the website; the competent supervisory authority within 72 hours of becoming aware where GDPR requires it; affected creators directly when uploads are involved.
4. Follow-up: a CHANGELOG entry and, where practices change, a policy revision under the change-notification rule.

7. Provider authorization and rights attestation

• Production scanning accepts only maintainer-owned fixtures or files uploaded by a creator or rights holder with an explicit attestation. No automated downloading or retrieval from YouTube or any other provider, unless a later authorization review explicitly permits it and this policy is revised.
• Attestation wording (PROPOSED), shown unchecked before each upload: "I own this media or have the rights holder's authority to upload it to TameFlash for flash-hazard analysis. I understand the file is deleted within 7 days after the scan and that publishing results to the public catalog is a separate choice."
• Catalog publication after a scan requires a catalog-eligible canonical YouTube identity supplied and validated separately from the uploaded bytes, explicit publication consent, and the ordinary review pipeline.

8. Consent wording and placement

Manual report (shipped). The report page shows "The context below was captured when you clicked the report button. Review everything before submitting — nothing is sent without your explicit submit", the exact serialized payload under "Exactly what will be submitted", and, next to the note field, "Your note is stored on the report server when you submit. Do not include health details, names, or contact information." The Submit button is the consent. Each submitted report keeps its one-time deletion code on the device under "Previously submitted reports" with the explanation "Deleting removes the report and its note from the active database at once; Cloudflare's point-in-time backup history can still contain them for up to 30 days before it expires."

Optional diagnostics bundle. Not implemented. If added, it is a separate unchecked checkbox on the report page with its own field list.

Exact video lookup (PROPOSED, #121). Options toggle, off by default, with: "When on, TameFlash sends the identifier of the YouTube video you are watching to api.tameflash.com to check it against verified hazard records. This reveals what you watch to the service at that moment. Cloudflare still handles your IP address and the time of the request. Nothing is stored about the lookup." The toggle shows the exact request body before enabling.

Automatic detector-evidence sharing (PROPOSED, #121). Separate toggle, off by default: "When on, TameFlash uploads one summary per video of what its detector found (video identifier, hazard intervals, detector settings profile). It never uploads frames, notes, your settings strength, or anything about ads or live streams." The toggle shows an example payload before enabling.

Creator upload (PROPOSED, #124). The attestation in section 7, unchecked, followed by the limits and the deletion schedule, on the preflight page.

9. Your rights and how to exercise them

• Access, rectification, erasure, restriction, objection and portability under GDPR. Because reports carry no account, a request must quote the report receipt shown on the device; without it the controller cannot identify a report as yours, and the automatic schedule applies.
• Deletion: the report page's Delete button (immediate) or [email protected].
• Complaints: your national supervisory authority; for the controller's seat, the Czech Office for Personal Data Protection (ÚOOÚ).

10. Store disclosures (Chrome Web Store, AMO)

Mapping to the Chrome Web Store user-data policy and disclosure requirements, and to AMO's privacy questions:

• Collected data categories (Chrome's definitions apply to on-device processing and storage too): "Website content" (on-device) — decoded frames of the video being protected are read and analysed on the device during every protected playback; they are never transmitted or persisted; "Location" — the connecting IP address reaches Cloudflare whenever a report is submitted or deleted, is used by Cloudflare's rate limiter and edge processing as described in sections 4 and 5, and is never stored by the application; "Authentication information" — a per-report deletion code (a random 64-character secret) is created on the device for each submitted report, stored in chrome.storage.local, and sent as a bearer credential only when the user deletes that report; it stays until that deletion or uninstall and authenticates nothing else; "Web history" — the exact origins of websites the user adds to protection are stored on the device (tameflashOriginPolicy, never transmitted), the opt-in diagnostic video labels store page titles or hostnames of videos the extension protected (device only, cleared with the diagnostics), and a manual report identifies the specific public video it is about; "Website content" (transmitted: the public video identifier and playback position of supported providers) and "User activity" (the detector's hazard summary) — only within a manual report, only on explicit submit. Nothing else is transmitted.
• May be collected only inside the optional free-text note, because the service cannot enforce what a user types despite the warning: personally identifiable information, health information, personal communications. The store disclosure therefore lists these as "collected, only if the user types them into the optional note; read by the maintainer only; deleted on sight; never used for any other purpose". Not collected in any form: financial information, account credentials of any kind, personal communications outside the optional note.
• Certifications: data is not sold; not used for purposes unrelated to the extension's single purpose (flash reduction and reporting its failures); not used for creditworthiness or lending.
• Remote code: none; dynamically registered scripts are packaged files (see docs/STORE_REVIEW_NOTES.md).
• Privacy policy URL: https://tameflash.com/privacy (Cloudflare Pages), showing this revision.
• Permissions justification lives in docs/STORE_REVIEW_NOTES.md; the optional all-sites host permission is requested only from a user click and governed by the device-local site policy.
• Diff against the #5 checklist assumptions: the checklist already states "manual incident reports are sent to api.tameflash.com only after the user reviews the exact payload and presses Submit"; this policy adds the 180-day figure (the checklist said nothing), the EU controller identity and the email route, and removes the assumption that the policy would be hosted by the extension's own repository (it is Cloudflare Pages).

11. Change log

• 1.0 (2026-10-18): first approved revision. Decisions recorded on issue #109.