Privacy Policy and GDPR information — DoggyRadar

Document version: 2026-09-26-privacy-v6

Status: Draft for the next release. These terms describe the prepared release; this copy does not confirm deployment to the running service or older apps.

1. Controller and contact

The controller is Krzysztof Wołosik – Javor, sole proprietor, ul. Anastazego Wika-Czarnowskiego 1A/7, 80-365 Gdańsk, Poland, Tax ID 5922047567.

Privacy: rodo@doggyradar.com. Support and child safety: office@doggyradar.com.

A privacy contact is not an appointment of a Data Protection Officer. Assessing the duty to appoint a DPO remains the controller's responsibility.

2. Data and optional choices

DoggyRadar provides maps, walks, dog profiles, community features, hazard reports, supervised accounts and business services.

• Account: email, name, password hash, birth date, settings and MFA state, optional phone/profile. A selected SSO provider supplies its identifier and authorised details.
• Supervised account: guardian/child relationship, consent scopes and versions, time, verification method and minimal evidence. A child need not provide an email; an internal identifier is assigned.
• Dogs: profile, photos, breed, behaviour, weight, microchip and health information as entered.
• Location: current position, exact route points and route screenshots, times and distances; also voluntarily submitted places, events and hazards.
• Community: forum/chat content, photos, relationships and abuse reports.
• Business: company/representative details, logo, contact, publication content/radius, place-claim evidence, allowance usage and terms acceptances.
• Billing: transaction/product identifiers, amount/currency, status and entitlement period. DoggyRadar does not receive card numbers from stores.
• Technical data: FCM/APNs push tokens, information necessary for session security, IP address, User-Agent and necessary error logs.

Required account/feature data is needed to provide that service; without it the feature may be unavailable. Optional fields and marketing choices are voluntary. Device GPS/push permission is distinct from the legal basis for processing.

3. Purposes and grounds

• Accounts, profiles, chat, forum, walk recording and business functions: Art. 6(1)(b) GDPR, to the extent objectively necessary for the selected service.
• Voluntary location publication, optional marketing and consent-based features: Art. 6(1)(a). For children under 16, Article 8 applies where processing relies on consent.
• User-selected notifications: consent for the relevant purpose; necessary security/contract messages: contract or legitimate interest as appropriate, without replacing required device permissions.
• Legally required billing records: Art. 6(1)(c). Delivering a purchased entitlement: Art. 6(1)(b).
• Guardian consent evidence: Art. 6(1)(c) with Articles 7(1) and 8(2); necessary legal defence: Art. 6(1)(f).
• Account protection, fraud prevention, moderation and specific legal claims: Art. 6(1)(f), the interest in service and personal safety; Art. 6(1)(c) where legally required.

The controller assesses necessity and proportionality; a general security ground does not conceal marketing or behavioural analytics.

4. GPS and children

GPS requires device permission. Walk tracking is linked to an active walk; Android uses a foreground service with a notification, while iOS uses its platform location mechanism and system indicators.

Ghost Mode hides positions from the public map but does not stop recording necessary for an active walk or anonymise a user from the operator. Sharing and permissions can be managed in the app.

An account under 16 is supervised and remains in Ghost Mode. Guardian access to current location requires separate active scopes and authentication. Supervision does not provide private message contents or route history.

MFA/email verify account access, not government identity or kinship. Safeguards, CSAE/CSAM reporting and contact restrictions are covered by the Child Safety Standards.

5. Advertising and Analytics

FULL disables Google AdMob ads. Labelled sponsored business content may remain. Supervised accounts are excluded from AdMob and marketing profiling.

AdMob uses device signals and privacy choices under the required Google UMP mechanism. Rejecting personalisation is not identical to rejecting all advertising; consent requirements and available ad types depend on jurisdiction and privacy status. Required privacy options allow users to change choices.

Google/Firebase Analytics collection is disabled in the prepared release. This does not mean Analytics is disabled in already distributed older versions. Any future activation requires a separately explained purpose, appropriate legal basis/consent, updated information and withdrawal controls. UMP advertising consent does not replace Analytics consent.

6. Recipients and transfers

Recipients include authorised other users according to content visibility; hosting/email providers; Google Firebase Cloud Messaging and Apple APNs; relevant Apple/Google entities for purchases and selected SSO; and Google AdMob for permitted advertising. Another payment gateway is a recipient only where it actually handles the selected transaction.

Not all providers are processors: stores, payment, advertising and SSO providers may also be independent controllers under their terms. OVHcloud is identified in the operator's infrastructure documentation; the particular service agreement, backup scope and locations require confirmation before the final notice is published.

The identified providers may process data outside the EEA. Each transfer needs an appropriate mechanism, such as an applicable adequacy decision covering the recipient or SCCs with a transfer assessment and necessary additional measures. Merely naming DPF/SCCs does not establish coverage for every service. Ask rodo@doggyradar.com about a particular recipient, mechanism or copy of safeguards.

7. Retention and erasure

1. Account/profile data and content needed for the service remain during use unless deleted earlier or a specific preservation duty applies.
2. Exact GPS history stored on the server has one 1–90 day limit, maximum 90 days (default 90). This covers server-side raw points, saved exact route points and route screenshots. Database cleanup is periodic; files enter a permanent-deletion queue. Summaries without exact routes, such as time/distance, may remain until user deletion. There is no diagnostic opt-out from this limit. Device offline queues require a separate lifecycle test before final release; this draft does not confirm erasure in older installations.
3. Account deletion removes the profile, associated dog data, GPS and walks. It removes private messages involving the user, their group messages, memberships and created groups according to their relationships. Photos are queued for physical deletion.
4. Author forum threads retain an empty shell marked deleted to preserve other people's replies; the author's title and body are erased, and their replies are deleted. All of the author's alerts, active and inactive, are deleted. Copies or quotations by others may require a separate request.
5. After a relationship ends or an account is deleted, guardian/business acceptance evidence is limited to pseudonyms, version/scope, method/time and necessary evidence; unnecessary direct identifiers, full IP addresses and User-Agent are removed. Pseudonymisation is not anonymisation.
6. Minimal evidence retention depends on the particular duty or claim, its start date and exceptions. Before release the controller must approve the retention matrix and enable verified erasure. This draft does not confirm an operational final evidence purge; missing approval blocks publication of this version, not authorisation for indefinite retention.
7. Tax/accounting documents follow the applicable statutory period and its rules for the document and obligation. Not every technical identifier is an accounting record. Full technical webhook payloads have a separate 30-day limit.
8. Withdrawal of supervised account consent locks the account for a 7-day reversal period, then it is deleted.
9. Backups have a separate lifecycle. Application and OVH backup retention requires documentation before publishing the final policy. Restoration must apply deletion requests and retention before service access is restored; this draft does not confirm such a test on production backups.

8. Security and rights

TLS protects communications. Chat is encrypted on the server using AES-256-GCM; it is not E2EE. The server can decrypt messages for delivery and necessary moderation. Photos undergo metadata removal before publication; access to evidence and child data is restricted.

You have rights of access/copy, rectification, erasure, restriction, portability where applicable, objection and withdrawal of consent without affecting prior lawful processing. Contact rodo@doggyradar.com, including to delete selected data without closing your account; identity checks are proportionate. The usual response deadline is one month; a justified extension must be communicated within that month.

Delete the account in Profile → Settings → Your Data (GDPR) → Delete Account, or on the public deletion page. The deletion procedure explains details and the separate need to cancel store subscriptions.

Complaints can be made to the President of UODO, ul. Stanisława Moniuszki 1A, 00-014 Warsaw, or the competent authority in another country. Geographic publication matching is not a solely automated decision with legal effects.

Material changes will be communicated in the app or by email before application, respecting required consents and user rights.