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. 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 |
| 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 |
| 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. 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. 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, Google’s applicable arrangements in its transfer information, and Cloudflare’s Data Privacy Framework/Standard Contractual Clauses arrangements in its data-processing terms. 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.
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.
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, 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. 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 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.