# FictionCore Privacy Policy

> Version `2026-10-30`.

This privacy policy is our notice under Articles 13 and 14 of the GDPR. It
covers https://fictioncore.app, the available FictionCore app functions and
correspondence with the operator.

## 1. Who is responsible

The controller is Sofuwaru OÜ, Ehitajate tee 68-125, 12915 Tallinn, Estonia;
Estonian Commercial Register (äriregister) code 17059718. Contact:
[sofuwaru@gmail.com](mailto:sofuwaru@gmail.com). You do not need an account
to make a privacy request.

## 2. Data, purposes and legal bases

In the table, Article 6(1)(b) of the GDPR means processing necessary for the
service you request or steps before that contract; Article 6(1)(c) means a
legal obligation; Article 6(1)(f) means the stated legitimate interest,
subject to your rights and interests.

| Data and source | Purpose and legal basis |
|---|---|
| Google sign-in proof and verified provider identifier; account/session identifiers, credentials and dates; app version/build | Sign-in, account creation, secure sessions and compatibility: Article 6(1)(b); preventing misuse: Article 6(1)(f) |
| Chosen display name and handle, profile fields and images, language and visibility settings, setup status; Terms acceptance, Privacy Policy delivery and 18+ records | Operate your account and chosen profile, conclude the contract and apply the 18+ rule: Article 6(1)(b); demonstrate that this policy was provided: Article 6(1)(c); evidence for disputes: Article 6(1)(f) |
| Your texts, images, private workspaces, publications, revisions, comments, ads, tags and publication/access settings | Store and display material to the selected audience, provide editing and discovery: Article 6(1)(b) |
| External contacts you add, link-check results and, if you verify an external account, the identifier and username confirmed by that service; contact requests, grants and disclosures; follows, reactions and saved material | Deliver the contact-sharing and community functions you use: Article 6(1)(b) |
| Search choices, saved searches where enabled, private content exclusions; participation/check-in records, reputation earnings and staff awards with their reasons, ranks and quiz answers/results | Apply your preferences, calculate participation indicators and operate the posting rules and quiz: Article 6(1)(b) |
| Reports and supporting material from you or others, reviews started by staff, relevant content snapshots, staff notes/tags, moderation decisions, review requests and access/audit records | Investigate concerns, enforce the rules and protect users and the service: Article 6(1)(f); handle legally required notices, orders and reporting: Article 6(1)(c) |
| Purpose-separated device digest and successful-registration dates; rejection counters, restriction dates and staff interventions | Prevent repeated registration and abusive submission: Article 6(1)(f), protecting service availability and users |
| When the network safeguard is enabled, IP addresses used by your signed-in account with the first and last time of use, and their links to a ban | Protect accounts and the service, investigate abuse, enforce bans and prevent their evasion: Article 6(1)(f) |
| Optional crash diagnostics and usage events described below | Diagnose crashes and improve the selected functions: your separate consent, Article 6(1)(a); declining does not prevent ordinary use |
| Notification preferences, inbox events, your responses to in-app announcements and, when push is enabled, installation/device identifiers and messaging tokens | Deliver the requested notification service and service announcements: Article 6(1)(b); separate device permission where required |
| Support/feedback text, replies and staff messages; optional app/device diagnostics sent with a bug report; screenshots you attach to a request; email and necessary details in correspondence | Answer service requests: Article 6(1)(b); diagnose failures and maintain a reliable service: Article 6(1)(f); data-rights/legal requests: Article 6(1)(c) |
| Website/API request metadata, including IP address received by the host, resource, time, status, app/browser information and diagnostic identifiers; limited deletion records | Deliver and protect the service, including temporary request limits per network address, and investigate failures: Article 6(1)(f); fulfil erasure duties and prevent restoration of erased data: Article 6(1)(c) |

We may also derive aggregated statistics that identify no one, such as
numbers of accounts or publications, to operate and secure the service and
meet legal reporting duties (Article 6(1)(f) and (c)).

Google may include email, name or other profile claims in its sign-in proof.
We retain a verified email supplied by Google, its observation date and whether
Google is authoritative for that address, privately alongside the account.
Our legitimate interests (Article 6(1)(f)) are finding the right account when
you request support and contacting affected users about necessary security or
material service changes, including when they cannot enter the app. Email is
not a public profile field, a login identifier or proof of account ownership.
We update it from fresh verified Google sign-in information; matching addresses
do not merge accounts. We do not save Google's name or other profile claims,
or the raw sign-in token. FictionCore does not receive your Google password
or request Gmail, Drive or address-book access.

We use the contact mailbox for requested support and necessary security,
contractual or legal communications. We send newsletters or other promotional
email only with your separate consent, which you can withdraw at any time.
You can reply or contact us to object to contact or request correction; we assess objections individually and explain any overriding
need to send a particular necessary notice. This does not remove your right
to object to processing based on legitimate interests. A support request does
not give permission for unrelated messages.

The account email is retained while the account exists and erased with it;
an updated address replaces the previous one. Before registration completes,
the verified claim may be held in a pending sign-in record that expires after
ten minutes. The email is cleared when the record is consumed; otherwise the
expired record is removed by periodic cleanup. If Google provides no usable
verified address, sign-in can still proceed. Accounts registered under an older notice
that said profile claims were not stored are not silently backfilled.
Correspondence and restricted backups follow the separate limits below.

Registration requires a Google sign-in, chosen name/handle, contract language,
Terms acceptance and 18+ declaration; without these the account cannot be
created. Registration does not collect an identity document or exact birth
date. Optional profile fields, including birth date used to display age, are
separate and can be edited or removed. Providing material or contacts is
necessary only for the corresponding function. FictionCore's audience is 18+;
the declaration alone does not verify age. If we learn that an account belongs
to a person under 18, we may close it and delete its data as described in
section 6.

In-app bug reports can include optional diagnostics: app/OS version,
language, theme, viewport/text scale and a limited recent in-memory history
of screen categories, request results and error types/source locations.
You can turn the attachment off before sending. It is sent with your report,
not as a continuous external crash feed; feedback carries no diagnostics.
You can attach up to three screenshots to a bug report or feedback. Only you
and support staff can see them. They are re-encoded without metadata such as
location, stored like other uploads and not sent to automated checks. Keep
passwords, secrets and unnecessary personal information, including other
people's, out of the text and the screenshots.

Genre and fictional relationship selections describe material and filtering
choices. They are not requested as declarations of your sexual orientation,
health or other sensitive personal traits. Avoid unnecessary sensitive data,
third-party private information and criminal allegations in ordinary content.
Sensitive data needed for a specific legal claim requires an applicable
Article 9 condition, such as Article 9(2)(f); criminal-offence data requires
authorisation and safeguards under applicable law. A free-text field or
acceptance of the Terms is not blanket consent to such processing.

## 3. Visibility and automated processing

Your name, handle, avatar and material you publish can be shown to other
users according to access and visibility settings. Optional profile sections,
activity indicators and contact audiences have their own controls. Private
workspaces, saved material and content exclusions are not public profile
fields. Your reputation total and rank can be public; the earnings history
and staff-award reasons are not public profile fields.

Connections from the app to our public API use HTTPS. Account checks and
staff permissions restrict access to private data. Authorised staff can access
data needed for support, security, moderation or legal requests. Private does
not mean encrypted against the operator.

Sharing a contact or opening an external link allows interaction outside
FictionCore. Recipients may keep already disclosed information after you
withdraw access; external services process visits and messages under their
own rules. FictionCore does not host or receive your external roleplay chats.

Software applies chosen filters and access rules, calculates participation
indicators and quiz results, and enforces technical and posting limits.
When enabled, image screening sends a normalised full image to Microsoft Azure
AI Content Safety and can reject or hold an upload; screenshots attached to
support requests are not screened. When enabled, text screening
sends text intended for public surfaces to the OpenAI Moderation API. It can
hide a prohibited version or refer it for staff review after publication;
private workspace drafts are not sent for general text screening. A rejected
public profile text is hidden from other users while its source remains
available to its author for correction. Staff can temporarily pause delivery
of user images across the service during an incident.

Several consecutive policy rejections within a short period can produce
warnings and then temporarily pause content submission; a repeated series
within several days can lead to a longer temporary pause. A successful
submission resets the series; technical provider errors do not count. Staff can review and lift
or reset these measures. This does not by itself terminate the account.

Registration safeguards can limit the number of accounts created per device
signal within a rolling period. Android version 1.0.34 and later
use a random installation signal stored separately from sign-in credentials;
clearing app data or reinstalling resets it. Earlier Android versions send a
purpose-separated digest of Android ID, never its raw value. The server stores
a digest for this safeguard. These are limited abuse signals, not proof of
identity or a guarantee of a physical device.
Shared service limits can also delay registration or other requests.

When the network safeguard is enabled, the service records each distinct IP
address that your signed-in account uses for sign-in, registration, session
renewal or ordinary requests, with the first and last time of use. It is not a
log of every request. Addresses are stored encrypted, with a keyed fingerprint
for matching; they are not public and are not used for analytics or
advertising. Failed sign-in attempts are not added to an account's history.
Only staff with specific security permissions can view this history, to
investigate abuse or account security and to decide on a ban. When staff ban
an account, they can also block every address recorded for it. The service
then compares the address of each request with active blocks and refuses
access, sign-in and new registrations from an address under such a block,
whichever account is used. Addresses can be shared or reassigned, for example
on mobile, public or workplace networks and VPNs, so a block can affect people
who did nothing wrong; an IP address does not prove who someone is. You can
ask us by email for a person to review a block, or object to this processing.

Automated checks can reject or hide submitted material, temporarily limit
registration or posting, or refuse requests from a network under a block. They
can make mistakes. You can use the review route shown with a decision or
contact us for a person to review the measure and the information you provide.
Rank, filter choices and automated flags are not verified facts about your
identity.

## 4. Recipients, device storage and transfers

| Recipient/service | Processing involved |
|---|---|
| Heroku / Salesforce | API and PostgreSQL hosting, account/content data and technical operations; the selected primary database region is EU |
| Cloudflare | Public website and DNS requests; R2 stores uploaded media and a limited account-deletion journal in the selected EU jurisdiction |
| Microsoft Azure AI Content Safety | Normalised full uploaded image (not a support screenshot) and technical request metadata for enabled image screening; the configured resource is Sweden Central |
| OpenAI | Text intended for public surfaces and technical request metadata, only when text screening is enabled; provider handling is described in its [API data controls](https://developers.openai.com/api/docs/guides/your-data) |
| Google Firebase Crashlytics and Analytics | Optional crash diagnostics and usage events, respectively, only where available and with the separate choice described below; SDKs also process app/device and installation information |
| Google sign-in | Authentication interaction and sign-in proof; Google's own account processing follows its [Privacy Policy](https://policies.google.com/privacy) |
| Google Firebase Cloud Messaging | Optional device registration and requested push delivery; payloads use event identifiers and generic notification text, not the body of your post or support conversation |
| Discord, Telegram, X, Reddit and Instagram | When you ask to check a contact, the API requests the relevant public profile using its public identifier and the server's request metadata; opening a link later uses your browser/app and that service's own context. If ownership verification is offered and you use it, you sign in to Discord or Telegram in your browser and that service confirms your account identifier and username to us; we keep these with the verification status and dates, not its sign-in tokens |
| Google (Gmail) | Messages and replies through our contact mailbox |

The contact-link checker does not send your FictionCore account identifier,
session credentials or device IP to the external platform. It checks public
availability, not ownership of the external account. Staff, necessary service
providers, professional advisers and competent authorities may receive data
for the purposes above or a specific legal duty or claim. Other users
receive what the sharing/publication function makes available to them.
If FictionCore or the operator's business is transferred, merged or
reorganised, data can pass to the successor that continues the service under
this policy, based on our legitimate interest in continuing the service
(Article 6(1)(f)); we inform you of such a transfer.

Optional crash reporting and usage analytics, where offered by the installed
version, have separate switches in **Settings** and are off by default.
Availability depends on the installed version. You can decline both and continue using the app, or turn
either off later. Acceptance of the Terms is not consent to either service.

Crash reporting uses Firebase Crashlytics. The app supplies bounded error
categories, source locations and selected screen/app context; Firebase also
collects technical crash, app, OS/device, installation and session-stability
information. Usage
analytics uses Firebase Analytics for selected screen and action categories
(such as sign-in, registration, finding partners, publication and contact
requests), outcome categories and coarse duration bands. When you enable
analytics, Google also uses a technical app-instance identifier, app/device
information and approximate location derived from the device's IP address.
We do not request GPS location for analytics, collect advertising identifiers,
or enable Google Signals or advertising personalization.
We do not deliberately
send post text, contacts, search text, full request URLs, account identifiers,
sign-in credentials or raw error messages in these app-defined events.
SDK-generated technical identifiers are not the same as anonymity.

Turning a switch off stops new optional collection; it does not automatically
delete reports already received by the provider. Contact us about deletion of
previous data. Firebase describes its handling and retention in its
[privacy information](https://firebase.google.com/support/privacy). Crashlytics
starts removing crash traces and associated identifiers after 90 days; our current Analytics property retains event data for two months and
user-level data for fourteen months, with that user-level period restarting on
new activity. Standard aggregated reports follow separate retention rules.

The website has no advertising or audience analytics scripts. Current app
builds bundle their fonts. The app stores credentials in device-protected
storage, and local caches, unsaved editor work, requests awaiting a retry and
preferences needed for its functions; the website remembers your selected
theme. Optional push registration starts after you enable it and can be
turned off in the app. OS notification permission separately controls display.

EU hosting does not mean all processing stays in the EEA. Heroku's separately
captured logical database backups are stored in the United States. Google,
Cloudflare, OpenAI and the external contact services operate internationally; their
processing can involve the United States and other countries outside the
EEA. For Azure image input, Microsoft describes regional processing and no
input retention or model training in its
[service-specific privacy information](https://learn.microsoft.com/en-us/legal/cognitive-services/content-safety/data-privacy).
That statement does not describe every provider or every technical record.

Transfers require an applicable adequacy decision or other lawful safeguard.
Provider information describes Salesforce's processor Binding Corporate Rules
and Data Privacy Framework scope in the
[Heroku security and privacy description](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/misc/heroku-security-privacy-and-architecture.pdf),
Google's applicable arrangements in its
[transfer information](https://policies.google.com/privacy/frameworks), and
Cloudflare's Data Privacy Framework/Standard Contractual Clauses arrangements
in its [data-processing terms](https://www.cloudflare.com/cloudflare-customer-dpa/).
An adequacy decision covers only eligible transfers. You can request the
safeguard applicable to a transfer of your data and a copy or further
information at [sofuwaru@gmail.com](mailto:sofuwaru@gmail.com).

## 5. Retention

We keep active account data and material while needed for the corresponding
account or function. If we end the account contract under the Terms, the
account is deleted as described in section 6. You can edit or remove supported items and request
erasure. Unpublishing changes visibility; it is not necessarily deletion of
your source, a reported revision or a limited case record.

- **Temporary records:** sign-in challenges and exchange-recovery records
  expire after ten minutes; access credentials after fifteen minutes and
  refresh sessions after at most thirty days. Reauthentication authorisation
  lasts five minutes; ordinary write-recovery records generally last up to
  24 hours. Scheduled cleanup removes expired records; expiry is not an
  exact physical-deletion deadline.
- **Feature records:** ads expire at the time shown and retained ad history
  is normally purged thirty days after expiry or an earlier terminal event.
  Contact requests expire after seven days; a request's record and any
  resulting grant are normally purged seven days after the request is
  answered, cancelled or expires. Contact-disclosure records and ordinary
  inbox notifications normally expire after ninety days. Ending a
  relationship or deleting the account removes the relevant active records.
  Reputation earning records remain until the recipient account is deleted;
  the current content-exclusion settings remain until replaced or deleted
  with the account. Staff messages and their command records follow the
  ninety-day inbox lifetime. Records of your responses to in-app
  announcements, including opening an announcement's link, expire after
  thirty days; they also let a response be safely retried. The record that
  you dismissed or acknowledged an announcement remains while the account
  exists, so that it is not shown again. A publication request waiting for
  image review remains until it is applied, rejected or cancelled; its record
  is normally purged thirty days later.
- **In-app support:** the report/feedback, attached screenshots and
  diagnostics, and replies expire thirty days after the original submission,
  or earlier on account deletion. A reply does not restart the period.
- **Moderation:** ordinary reports expire after ninety days. Decision and
  review evidence generally uses six-month periods from the relevant notice
  or case closure, extended by an active restriction, a later decision or a
  pending review, followed by cleanup. Such evidence can remain after account
  deletion with account links removed; this does not by itself anonymise
  personal information in the text. Separate legal preservation requires a
  specific reason; it is not indefinite retention of the whole account.
- **Abuse prevention:** registration admissions and their device digests expire
  30 days after successful creation, including if that account is deleted, to
  prevent creation/deletion loops. The account-owned submission-limit state
  lasts until account deletion; its event history expires after 90 days or
  earlier on account deletion. The escalation window is not the retention
  period of the entire event history. Account IP history is kept at most
  while the account exists and is deleted with it. The links between those
  addresses and a ban are removed when the ban is reversed or when the account
  or decision records concerned are deleted, whichever comes first.
- **Technical records and correspondence:** retain only what is needed to
  resolve the request or incident and complete related actions, or for a
  specific legal obligation or claim. Provider-managed logs and residual
  copies follow the relevant provider's applicable lifecycle. Deleting email
  to Gmail Trash alone leaves it there for up to thirty days.
- **Backups and deletion records:** active-service erasure does not instantly
  erase every backup. Logical database backups under our control are removed
  within 30 days of capture and restricted to recovery; before a restored copy
  returns to service, completed account deletions are reapplied. Limited
  deletion identifiers and dates are kept through
  the permitted restore period and command-recovery period to prevent erased
  accounts from returning. Provider disaster-recovery copies and separately
  captured logical backups have separate lifecycles; a backup capture alone
  does not set an automatic expiry. Retained copies must remain restricted
  to recovery or another specific lawful purpose.

Where a legal duty or dispute justifies longer retention, only necessary
records are retained for that purpose and removed when the reason ends.
We explain applicable exceptions and the period or criteria in the response
to an erasure request.

<a id="account-deletion"></a>

## 6. Delete your account

In the app, open **Profile → Settings → Account → Delete account**. Confirm
the request and authenticate again with the Google account bound to this
FictionCore account. The service makes an accepted deletion unavailable for
ordinary use and processes deletion. The app shows progress; if interrupted,
reopen the app to resume the same request.
Completion removes active account data and owned content, subject to the
limited records and exceptions in section 5. The app then clears its
account-scoped local data. It does not delete your Google account or copies
already held by other people or external services.

You can also email [sofuwaru@gmail.com](mailto:sofuwaru@gmail.com), including
without app access. Identify the FictionCore account by handle or account ID
if available. No particular subject line is required. Do not send a password
or sign-in token. If there is reasonable doubt about authority over the
account, we request proportionate verification. Signing out, revoking a
session or uninstalling the app does not delete server records.

Public instructions: https://fictioncore.app/privacy?locale=en#account-deletion.

## 7. Rights and requests

Subject to GDPR conditions, you may request access and a copy, correction,
erasure, restriction and portability. Where consent is the legal basis,
you can withdraw it without affecting earlier lawful processing.

**Right to object:** for reasons relating to your particular situation, you
may object to processing based on legitimate interests. We must stop unless
we demonstrate overriding compelling grounds or need the data for legal claims.

Write to [sofuwaru@gmail.com](mailto:sofuwaru@gmail.com). The app's privacy
request screen prepares an email; opening that screen or copying a message
does not itself send a request. Send access and portability requests to this
contact; the app has no automatic full-account download.
We respond without undue delay and within one month; where permitted because
of complexity or number of requests, we explain an extension within that
month, for up to two further months. Requests are generally free; any lawful
refusal or fee is explained with the available complaint route.

You may complain to Estonia's
[Andmekaitse Inspektsioon](https://www.aki.ee/en) or the competent authority
where you live, work or consider an infringement occurred. Judicial remedies
remain available. When someone supplies information about you in a report,
the source is that person and their material; where required, we separately
provide you the information required by GDPR Article 14.

## 8. Changes

We update this policy when processing changes and inform you before new
processing where required. Any consent required for a separate purpose is
requested separately; receiving this policy or accepting the Terms does not
supply it.