Data protection

Heardfix is built for apps that handle health data. This page lists what Heardfix stores, where, for how long, and what the operator of a back office must set up. It is technical guidance, not legal advice: your data protection officer validates the final setup and your privacy policy.

What is personal or health data

Treat a whole report as health data. That is the simplest rule and the one Heardfix applies.

Where data lives

• Reports, images, replies and the access log live in the back office. Health data needs an HDS certified host in France: the client's own host, or OwnWeb's shared instance once HDS certified (not yet: until then it accepts no health data without OwnWeb's agreement, see decisions.md).
• On a shared instance, each client is an organization. Its members only see its data, in a panel split by organization, and the OwnWeb admin panel never shows the content of a report. Every query of the panel, every attachment download and the ClickUp and Trello webhooks are bound to one organization.
• The task tracker of the app, ClickUp or Trello, only receives what a triager reviewed and cleaned of any health data: report excerpts with masked emails and the pictures they ticked. The task is personal data, never health data. ClickUp, and Trello (Atlassian) once an organization connects it, are sub-processors, hosted in the United States: list them in your privacy policy. The triager alerts receive the title of each new report, never its description, images or logs: members' mailboxes and the organization's Slack or Discord hold these titles. Slack and Discord, once set, are sub-processors: list them in your privacy policy. Sentry and Crashlytics receive technical data and the installation id. The full table is in architecture.md.

The public roadmap only shows the public texts, status, period and tags of the topics a triager made public. It sets no cookie and needs no consent.

The public form sends its reports to the back office only, like the web module, and loads nothing from a third party. It sets no cookie and needs no consent.

What never leaves the back office

• unmasked reporter emails;
• replies written by users;
• logs and stack traces attached to reports;
• images and report texts the triager did not send to the task tracker;
• the access log.

Outgoing calls from the back office: ClickUp and Trello APIs (the task reviewed by a triager, with report excerpts, masked emails and ticked pictures, technical custom fields in ClickUp, the same technical data at the end of the Trello card description; the lists and boards the token reaches; for Trello, the webhooks of the boards of the apps), alert emails, Slack and Discord (app name, then the title, kind, time, system, browser, app version, or "Public form" with its browser and system, and image count of each new report, count of lowered store ratings, links), Firebase (App Check public keys), emails to reporters, the Google Play and App Store Connect APIs (reading reviews, publishing the public replies a triager reviewed), and Mistral when the instance has a Mistral key and the plan of the organization includes AI (title and description of visible reports with emails masked, titles of topics and of the proposals waiting for triage, the public title and description of the topic being closed with its kind, the name and description of the app and the example reply its team wrote). Mistral is not HDS certified: an instance storing health data leaves HEARDFIX_MISTRAL_KEY empty, see decisions.md.

Reporter emails and alerts go through your mail provider. Choose one whose servers and logs meet your hosting constraints, since an email names the bug, and the confirmation email quotes the title of the report.

On the device

• Reports waiting in the offline queue are stored in the app's private directory, encrypted at rest by the OS, never in shared preferences. They are deleted once the back office confirms reception, after 7 days at most, and the queue holds 10 reports at most.
• The installation id and the shake setting are stored in shared preferences. Uninstalling the app deletes them.
• The log ring buffer lives in memory only: the last 200 lines, lost when the app stops.
• The web module keeps nothing in the browser: no cookie, no storage. The caught errors of the page stay in memory, lost when the page closes. A report that fails is not kept: the form stays filled until the visitor closes it.

Retention

Excerpts sent to the task tracker have no automatic retention period: neither the 13 month purge nor erasure covers them for a reporter without email. The rule is to be set with the client's data protection officer.

Last activity is the latest of: report received, message sent to the reporter or received from them, resolution email sent, store review edited by its author. Only the reviews of the last 7 days are imported, so a purged review never comes back unless its author edits it again.

Example: a report received on 3 September 2026, whose reporter is emailed when the bug closes on 20 October 2026, is purged on 20 November 2027. Without any email or reply, it would be purged on 3 October 2027.

A bug closed after its reports were purged emails nobody: the purged reporters are no longer known.

The purge runs daily (heardfix:purge, see laravel.md). It deletes the stored files with the database rows.

Erasure on request

A user may ask for their data to be deleted. In the back office, open a report of this user and run "Delete this reporter's data". It deletes every report and message sent with this email, across all the apps of the organization, files included. The same email in another organization's apps is another client's data, left untouched. It cannot be undone.

The action is logged: who ran it, when, how many reports were deleted. The log does not keep the email, so the erasure leaves no trace of the person.

Hidden reports, received beyond the quota of the plan, are erased too. The reception log keeps their lines, which hold neither the email nor any content.

Anonymised bugs stay, with their remaining reports.

The task trackers keep what was sent: report excerpts and pictures of this reporter may remain in the ClickUp tasks or Trello cards of their bugs. The back office cannot delete them. After the erasure, the notification lists the tasks of the bugs the reporter's reports belong to, and of the bugs whose task received one of them before it was removed from them: open each one and delete the reporter's excerpts and pictures by hand, to complete the erasure in the tracker too (GDPR articles 17 and 19).

Store reviews have no email either: the author deletes their review on the store, and the 13 month purge deletes the report. A public reply stays on the store until it is deleted in the store console.

A triager can also delete selected reports from the list, such as test or spam reports: the same deletion of files and messages, logged with the count. Store reviews are left out of it, so the import does not bring them back. The task trackers keep what was already sent.

Reports sent without an email cannot be erased by reporter. The back office only links them to the installation id, shown to the user in the form's "Attached information" block. The prototype has no erasure by installation id: the 13 month purge deletes them. A report from a website carries an id of its own, never shown to the visitor: without an email, only the purge deletes it.

Access log

• Every triager has a named account with two factor authentication. No shared account. The host panel enforces both (see laravel.md).
• Opening a report, downloading an attachment, erasing a reporter's data, deleting reports in bulk, creating a ClickUp task or a Trello card and sending a picture to it each write a line: who, what, when. The task line also says whether the triager kept the prefilled description or edited it.
• Lines are kept 12 months, then purged.
• Triagers read the log in the panel, under Heardfix, Access log. The panel offers no way to edit or delete a line.

Backups

Purge and erasure act on the live database and the attachment disk. Host backups keep the deleted data until their rotation removes it (for example 30 days).

State this period in your privacy policy, for example: "Deleted data remains in encrypted backups for up to 30 days, then is destroyed." Make sure backups are stored on the same certified host as the back office.

Sentry and Crashlytics

Sentry and Crashlytics are outside the health data boundary. Send them an allowlist of data, never a blocklist: new fields stay out until someone adds them on purpose.

Recommended Sentry setup for Flutter:

const allowedBreadcrumbCategories = {'navigation', 'http', 'app.lifecycle'};

await SentryFlutter.init((options) {
  options.dsn = sentryDsn;
  options.sendDefaultPii = false;
  options.replay.sessionSampleRate = 0;
  options.replay.onErrorSampleRate = 0;
  options.attachScreenshot = false;
  options.attachViewHierarchy = false;
  options.beforeBreadcrumb = (breadcrumb, hint) =>
      allowedBreadcrumbCategories.contains(breadcrumb?.category) ? breadcrumb : null;
  options.beforeSend = (event, hint) {
    Heardfix.maybeInstance?.recordSentryEventId(event.eventId.toString());
    event.user = SentryUser(id: event.user?.id);
    return event;
  };
});

Rules:

• sendDefaultPii off: no IP address, no cookies, no request bodies.
• User: only id, set to the Heardfix installation id. No email, no username.
• No Session Replay, no screenshots, no view hierarchy: they can show health data on screen.
• Breadcrumbs: only the categories you list. Console logs and UI clicks stay out, since they can carry text typed by the user.
• Navigation breadcrumbs: route names without parameters (/sessions/:id, not /sessions/1234), and no route arguments.
• HTTP breadcrumbs: URLs without query strings.
• No custom tags or contexts holding user input or measurements.

Crashlytics: set only the user identifier (installation id). Do not use setCustomKey or log with user data.

On the server side, enable Sentry's server side data scrubbing as a second line of defence. It does not replace the allowlist in the app.