Privacy Policy

Who is responsible

The controller is Rafal Borzemski, with service address Wrocław, Poland. The controller decides why and how personal data is processed through dmc.

Questions and privacy requests can be sent to privacy@datemycode.com. Safety and abuse notices can be sent to abuse@datemycode.com. This policy applies to the dmc website, installable web app, public profile links, and public event pages.

Information I process

You provide most information directly. Other information is produced when you use a feature, such as sending a message, joining an event, requesting a meet verification, or enabling browser notifications.

Email sign-in requests use Cloudflare Turnstile to reduce automated abuse. The Turnstile challenge sends a token and ordinary network, browser, and device signals to Cloudflare under Cloudflare's privacy policy at cloudflare.com/privacypolicy. Google sign-in is handled by the authentication provider and is not protected by Turnstile. dmc does not receive or store your Google password or an email-account password.

• Account data: email address, authentication provider identifiers, sign-in metadata, and account timestamps.
• Profile data: display name, birthdate, derived age, gender, biography, photos, username, looking-for choice, height, city, occupation, lifestyle choices, interests that you choose to provide, and your preferred interface language.
• Connection data: introductions, first messages, request status, conversations, chat messages, read receipts, blocks, and reports.
• Event data: events you host, organizer display name, venue, city, map link, time, capacity, RSVPs, cancellations, and event reports.
• Verification and notification data: short-lived meet coordinates, attempt counters, verification pairs, push endpoints, encryption keys, user agent, and queued delivery status.
• Technical data: pseudonymized rate-limit identifiers, request and security logs, CSP violation summaries, error details, cache metadata, and consent choices stored on your device.
• Analytics data, only after you allow Analytics: randomly assigned browser and session identifiers, timestamps, fixed page templates and product-action names, the origin of an external referring site, and basic browser, device, and coarse geographic information. I do not send account IDs, profile details, messages, dmc codes, exact locations, query strings, or raw profile, event, or chat URLs to Analytics.

Profiles and who can see them

Anyone who has an active code or username can open its public page. Pause or regenerate a code to disable an old public route. Usernames are public, guessable aliases for the current live code.

Visibility expands only in defined signed-in relationship states. Blocks remove profile, request, conversation, and message visibility in both directions.

• Anonymous visitors see only display name, derived age, verification status, and the main public photo.
• A signed-in person opening an active public link may see the biography, public photos, gender, and optional profile details you supplied.
• A pending request recipient can see the sender’s profile teaser and all sender photos so they can decide whether to accept.
• Accepted connections can see the counterpart profile and every profile photo, including photos marked private.
• Birthdate itself is owner-only; other people receive only the calculated age.

Photos

Photos are stored in a private storage bucket. dmc creates WebP renditions from decoded pixels, which removes embedded EXIF metadata. You can keep up to six photos and choose their supported visibility.

Authenticated photo responses use a year-long immutable browser cache. Changing a photo from public to private rotates its storage path, but bytes already fetched by a viewer may remain in that viewer’s browser cache for up to a year.

• The main photo must be public so an active public profile has a stable image.
• Photo access is checked against ownership, public status, pending requests, accepted connections, and blocks.
• Removing a photo deletes its current storage objects through the application’s cleanup process.
• Do not upload a photo unless you have the right to use it and are comfortable with the visibility you select.

Introductions, chats, blocks, and reports

A scan does not create a connection by itself. The scanner chooses whether to send an introduction and first message, and the recipient chooses whether to accept or decline.

Participants can see their conversation messages and read status. Individual messages cannot currently be deleted separately. Blocking stops access and communication; reporting sends the selected person or event and a reason to the operator.

• First messages are visible to the recipient before acceptance.
• Conversation participants receive realtime message and read-status updates through the app's realtime infrastructure.
• Typing and meet-status signals are transient realtime events rather than chat-history records.
• Reports are not public and are used to investigate safety, abuse, and Terms violations.

Public events and approximate location

Active events appear on the open /events listing, which can be indexed by search engines. The listing includes the event details needed to discover it and the host’s display name. Individual event links are shareable even when marked not to be indexed.

For the Near me view and time formatting, the hosting provider may supply an approximate city and timezone derived from the request IP address. dmc uses those headers for the current response and does not save them to the application database.

• Hosts choose event title, description, venue, city, map link, time, and capacity.
• RSVPs reveal attendance to people who can view the event according to the event rules.
• External map links are opened only when you choose them; dmc does not embed the map provider's tracking content.

QR camera processing

The scanner uses the browser BarcodeDetector when available or a locally loaded QR decoder. Frames are processed in browser memory, are not uploaded to dmc, and are discarded as scanning continues.

• Camera access occurs only after browser permission and while you use the scanner.
• Only the decoded code or URL is used to navigate to a profile.

Meet verification

A conversation participant can voluntarily submit their current coordinates to confirm that both participants are physically close. The second confirmation is compared with the first, and a successful pair contributes to each profile’s verification count.

Coordinates are not exposed through the application API. The system deletes a pending coordinate within 9 minutes 30 seconds, with cleanup running every 30 seconds.

• Daily attempt counters are deleted after 7 days.
• Successful verification pairs and confirmation timestamps remain for the account lifetime.
• A profile badge appears after the configured number of distinct successful pair confirmations.
• The badge does not verify legal identity, age documents, criminal history, intentions, compatibility, or personal safety.

Browser notifications

If you enable notifications, dmc stores a push endpoint, encryption keys, user agent, timestamps, and the account that owns the subscription. You can disable push in dmc and in browser or operating-system settings.

Push payloads pass through the browser vendor’s push infrastructure and may contain a sender display name and up to 140 characters of a message preview. Consider whether previews are appropriate on your lock screen.

• A subscription is removed when you disable it through dmc or when the provider reports it permanently unavailable.
• Delivery records track pending, retry, sent, or permanent-failure status for operational reliability.
• Sent and permanent-failure delivery records, plus processed-message claims, are scheduled for deletion after 30 days.
• Push permission is independent of the Preferences cookie setting.

Security and error monitoring

Rate limiting protects public profiles and sensitive actions. Before an IP-derived identifier is sent to the rate-limiting provider, dmc transforms it with a keyed HMAC; the provider's analytics features are disabled.

The error-monitoring provider receives privacy-scrubbed operational errors and bounded security summaries. Browser monitoring is errors-only, loads only when an error occurs, sends no default personal identity, and stores no monitoring cookie or identifier on your device.

• Dynamic IDs, query strings, tokens, message bodies, form data, and user identity are removed or normalized from monitoring events.
• Content Security Policy violation reports are sent to dmc and reduced before operational reporting.
• Server and provider request logs may contain ordinary network metadata needed for security, reliability, and abuse investigation.
• No security measure is perfect; contact privacy@datemycode.com if you believe an account or personal data is at risk.

Cookies and device storage

Necessary storage includes the dmc_consent choice record, the session-only locale language cookie, the authentication provider's session cookies, PKCE sign-in verifier cookies that are normally removed when consumed but have a maximum 400-day cookie age, a bot-protection security cookie on the API/authentication domain, requested session state, and the existing offline shell.

Preferences can remember a height unit and dismissed installation, push, or promotional prompts. Use the controls below to allow or refuse them.

Analytics is off until you allow it. The analytics service then sets first-party cookies that distinguish a browser and maintain session information for up to 180 days without extending that lifetime on each visit. The analytics script is not requested before consent. Turning Analytics off stops future collection and removes those analytics cookies where the app can access them. The current tab updates immediately; another already-open tab may not reflect a change until reload.

Service providers and international transfers

I use providers for backend infrastructure and hosting, authentication, email and push delivery, Cloudflare Turnstile abuse prevention, error monitoring, and—only with your consent—analytics.

Some providers may process data in the United States or other countries outside the European Economic Area. Where GDPR requires transfer safeguards, I use the applicable adequacy decision or contractual safeguards, including the European Commission’s Standard Contractual Clauses. You can request information about those safeguards or a copy at privacy@datemycode.com.

Why I use information

Providing accounts, profiles, introductions, chats, events, requested notifications, and account controls is necessary to perform your agreement with me. Security, abuse prevention, reliable operation, and carefully minimized error monitoring support my legitimate interests and those of the community.

Consent applies where required, including optional Preferences storage, optional analytics measurement, and browser-controlled camera, location, and notification permissions. Legal obligations may require limited processing or disclosure.

• Contract: provide the service and features you request.
• Legitimate interests: secure, debug, improve reliability, prevent abuse, and moderate the service with minimized data.
• Consent: optional Preferences and Analytics storage and device permissions where applicable; it can be withdrawn prospectively.
• Legal obligation: respond to valid legal process and meet applicable compliance duties.
• dmc does not sell personal data, serve behavioral advertising, or use automated compatibility scoring or matching.

How long information remains

Profiles, relationships, conversations, and messages generally remain while the relevant account exists. Individual-message deletion is not currently available. In-app reports and related database moderation state are deleted when either related account is deleted. Correspondence received through the privacy and abuse mailboxes is stored separately and is normally retained for 12 months after a case closes, unless a legal hold or a valid erasure decision changes that period.

Deletion from live systems does not necessarily remove provider backup copies immediately. Residual copies may remain isolated until the provider’s routine backup-expiry cycle and are not restored except for disaster recovery.

• Pending meet coordinates: no more than 9 minutes 30 seconds, with cleanup every 30 seconds.
• Meet attempt counters: 7 days.
• Successful verification pairs: account lifetime.
• Terminal push-delivery records and processed-message claims: scheduled for deletion after 30 days.
• Consent choice: 180 days from the latest choice.
• Preference storage: until you revoke Preferences, clear site data, or the relevant browser session ends for session-scoped values.
• Released usernames: retained permanently as de-identified tombstones so they cannot be re-issued or used for impersonation.
• Photos already delivered to a viewer: potentially present in that viewer’s immutable browser cache for up to one year.
• Analytics cookies: up to 180 days from when they are first set. Event-level and user-level analytics data is configured for 14-month retention; standard aggregated reports may remain longer under the analytics provider's reporting rules.
• Account-deletion evidence: retained indefinitely under legitimate interests to demonstrate completion, investigate failures, and meet accountability duties. The row contains the account UUID; final phase and status; processing-attempt, consecutive-failure, and lease-revision counts; and requested, last-updated, and completed timestamps. Completion clears lease timing, retry eligibility, and error state. It contains no email, content, message, or Storage path, but the UUID remains an account identifier and is not anonymous.

Your choices and privacy rights

Send requests to privacy@datemycode.com from the account email where possible. I may ask for proportionate verification and will respond without undue delay, normally within one month under GDPR, subject to lawful extensions.

Some requests can affect other people’s rights—for example, a conversation export contains counterpart information. I will scope disclosures and deletions carefully and explain any lawful limitation or refusal.

• Access personal data and receive information about its use.
• Correct inaccurate or incomplete information.
• Request deletion where applicable.
• Receive portable data where the portability right applies.
• Restrict processing in qualifying circumstances.
• Object to processing based on legitimate interests.
• Withdraw consent prospectively and change optional Preferences or Analytics cookies at any time.
• Complain to Poland’s President of the Personal Data Protection Office (UODO) or another competent supervisory authority, and appeal applicable United States privacy-request decisions by replying to my response.

Adults only

Birthdate is required and the application and database enforce an 18+ rule. If I learn that a minor created an account, I may suspend and delete it. Contact privacy@datemycode.com if you believe a minor is using dmc.

Changes to this policy

The current policy is published at this URL. Material changes will be communicated through the service or account contact information when appropriate. Continued use after an effective change is subject to applicable law and the choices described here.