Privacy policy

1. Data controller

The data controller of personal data is:

2. Introduction

Taski is an instant messaging application available on iOS, Android, Apple Watch, Web (web.taski.chat) and Desktop (macOS and Windows via Tauri). It places privacy and security at the heart of its architecture.

Taski uses 🔒End-to-End Encryption for all 1-1 and group conversations, voice/video calls and media. Only the user and the recipients can read the messages. Not even we, as the developers, have access to their content.

3. Data we collect

3.1 Registration data

• Phone number: primary identifier, verified via SMS (Twilio service).
• Verification code: temporary 6-digit code sent via SMS, valid for 10 minutes. As an alternative to SMS, the user can ask to receive the code through an automated voice call (Twilio, with Amazon Polly text-to-speech), up to 3 calls per day.
• Anti-SIM-swap PIN (optional): a 6-digit code chosen by the user to unlock access from a new phone without the old device. The server does not store the PIN, only a derived verifier (PBKDF2 + HMAC with pepper); after 5 incorrect attempts, access is locked.
• Passkey (optional): an access key managed by the operating system; the server stores only the passkey's public key.

3.1-bis New device, account transfer and recovery

A Taski account has only one primary phone at a time (iPhone or Android). Linked devices (Web, Desktop, Apple Watch) depend on the primary phone.

• Approval from the old phone: when the user activates Taski on a new phone, the primary phone receives a "Sign-in from a new device" request showing the requesting device's name and platform, the date/time and an approximate location derived from the IP address. Approval requires biometric authentication (e.g. Face ID) or the device passcode. Once the transfer is approved, the old phone is signed out.
• Key transfer: if the user approves from the old phone, the private encryption keys (including the identity key and the historical keys needed to read messages already received) are transferred to the new phone end-to-end encrypted to a temporary key generated by the new device. The package passes through our servers, which cannot decrypt it, and is deleted upon delivery (normally within a few minutes).
• Access without the old phone: alternatively, the user can use the passkey, the anti-SIM-swap PIN or assisted recovery. In these cases the keys are not transferred: the account starts over with new encryption keys (see 7).
• Assisted recovery: the user takes a selfie holding a valid identity document and a sheet of paper with a code shown by the app. The photo is uploaded to our servers (Cloudflare R2), reviewed manually by an operator via a temporary link and deleted when the request is approved or rejected, and in any case within 24 hours. No automated biometric recognition is performed. The outcome is communicated by SMS. The request record (phone number, code, outcome, dates) is retained until account deletion.
• Transfer security log: for each request we record the IP address, the requesting device's name and platform, the date/time and the outcome. The log serves to prevent account theft and is retained until account deletion.

3.2 Profile data

These are optional data the user may choose to provide:

• Display name
• Status/Bio (short description)
• Profile photo (stored on our servers, accessible according to the user's privacy settings)

3.3 1-1 conversations (E2EE)

• End-to-end encrypted with X25519 (key exchange) + AES-256-GCM (encryption).
• Messages are not permanently stored on our servers. They remain in the offline queue for a maximum of 7 days to ensure delivery.
• For synchronization across the user's devices (iPhone, Android, Watch, Web, Desktop), messages may remain in encrypted form for up to 7 days after delivery.
• Once the period expires, messages are automatically deleted.

3.4 Group conversations (E2EE)

• Encrypted with a symmetric AES-256 key shared among members, distributed via ECDH (Curve25519).
• Group metadata (name, participants, administrators) is stored for management purposes.
• Keys are regenerated whenever members change.
• Encrypted messages remain on the server for delivery and synchronization for a maximum of 7 days, after which they are automatically deleted.

3.5 Voice and video calls (E2EE)

• Each call derives a unique AES-256-GCM key via HKDF (ECDH + random salt per call + call ID).
• Not even the transport provider (Agora) can access the audio/video content.
• No recording: calls are never stored.
• Metadata retained: who called whom, type (audio/video), duration, date/time — only for the call history within the app.
• Heartbeat: during an active call, devices send a periodic presence signal. If the signal is missing for 90 seconds, the call is considered ended. A single call lasts a maximum of 4 hours.

3.6 Stories

• The media (photo or video) is end-to-end encrypted: the server cannot view its content. Engagement metadata (views, "likes") are instead visible to the server in cleartext, as they are needed to show counts and the "who viewed" list to the creator. Replies to stories travel as regular 1-to-1 chat messages, so they are end-to-end encrypted.
• They are automatically deleted after 24 hours.
• The creator can see who has viewed their story.
• It is possible to "like" and reply to stories.

3.7 Technical data

The technical data collected to operate the service are:

APNs / FCM push tokens

To send notifications to the user.

VoIP token

To receive calls when the app is in the background (PushKit).

Public encryption keys

For the secure exchange of E2EE keys. Private keys are generated and stored on the user's devices (Keychain on iOS, the app's protected storage on Android and in the browser) and are never accessible to our servers: they leave the phone only end-to-end encrypted to the new device during an account transfer (see 3.1-bis).

Contact list

If the user grants permission, only the cryptographic hashes (HMAC with pepper) of the phone numbers and email addresses in the contact list are synchronized. Plaintext numbers and addresses are never sent to our servers. When a contact in the contact list turns out to be registered on Taski, the server stores the link between the user's account and the contact's account. Synchronization is required to start new 1-1 chats: to prevent spam and the harvesting of phone numbers, a new chat can only be opened with people in the synchronized contact list or with whom the user already shares a group (the user can always reply to anyone who has already contacted them).

Access timestamps

For "last seen" and message delivery (respecting privacy settings).

Conversation metadata

Conversation ID, timestamps, read/delivery status.

Linked devices

Platform, client type (browser or desktop app), device name, user-agent, session ID, last access and opening of the Web/Desktop client (used to notify the user on their phone, at most once every 24 hours, that a linked session is in use).

IP address

Used for service security (rate limiting, abuse prevention, account transfer log) and recorded in the technical logs of the Cloudflare platform, which are sampled and retained for a limited period. URL parameters are removed from the logs.

Location Push token (iOS)

If the user grants location permission "Always", the primary phone registers an Apple token dedicated to the live location and Trusted contact features (see 3.11 and 3.11-bis). It is deleted on logout, on account deletion or when Apple reports it as no longer valid.

3.8 Media

• Images, videos, voice notes, documents: all end-to-end encrypted (AES-256-GCM) before upload, temporarily stored on Cloudflare R2.
• Static location: sent as an end-to-end encrypted message (coordinates and address). For live location, see 3.11; for location on request with Trusted contact, see 3.11-bis.
• GIFs: searches go through our proxy (the query is not associated with the user's account). The chosen GIF is then downloaded by the sender's and recipient's devices, including for the preview in notifications, directly from Giphy's content delivery network, which therefore receives the device's IP address.
• Emoji reactions: stored as metadata.
• AI-generated stickers: generated on-demand via OpenAI (gpt-image-2.5-flare or gpt-image-1 depending on the style). Only for stickers created from text, if OpenAI is unavailable, a fallback is used (Anthropic Claude Haiku 4.5 + Flux Schnell on Cloudflare Workers AI); photos are never sent to these fallback providers. In "photo → sticker" mode the source image is sent in cleartext to the Taski worker and from there forwarded to OpenAI: it is NOT end-to-end encrypted at this stage (only protected by TLS in transit; the worker does not store it). The resulting sticker is then end-to-end encrypted like other media before being sent in chat.

3.9 Music listening (optional)

• Taski can share the user's music listening status with their contacts (Apple Music or Spotify).
• Data shared: track title and artist name currently playing.
• Can be disabled in privacy settings. It is not saved on the servers.

3.10 Backup

• iCloud backup: in the user's personal iCloud space.
• AES-256 encryption with a password chosen by the user.
• Includes messages, contacts, E2EE keys and optionally media.
• We do not have access to user backups. If the password is lost, the data is unrecoverable.

3.11 Live location (optional)

In 1-1 chats, the user can share their live location for 15 minutes, 1 hour or 8 hours. The feature is available on iPhone and Android; on Web and Desktop the recipient sees only the starting point. It is not available in groups.

• What is sent, end-to-end encrypted: coordinates, time of the reading, accuracy, speed, heading, mode of travel estimated by the phone (walking, running, cycling, driving, stationary), stops, start and end of sharing and, on iPhone, the battery level. This data is encrypted on the device with the same encryption as 1-1 messages (X25519 + AES-256-GCM): the server cannot read it.
• Start message: when sharing starts, an end-to-end encrypted message with the starting point and the sharing duration is sent in the chat.
• What the server sees: the metadata needed for delivery, namely who is sharing with whom, the sharing identifier, start, expiry and end, the originating device identifier, sequence number, arrival time and size of each update. Since updates are more frequent when moving, their frequency makes it possible to infer approximately whether the user is moving or stationary.
• Retention on the server: encrypted updates are retained for the duration of the sharing and for up to 36 hours after it ends, so that the recipient can retrieve the full route even if they have not opened the app. They are then deleted automatically. They are deleted immediately if the chat or the account is deleted.
• Retention on the device: on iPhone, the route (track, trips and stops) is saved in the "Routes" section of the chat profile by both the sharer and the recipient, and remains on the device until the user deletes it. The sharer cannot delete the copy saved on the recipient's device. If "Data protection" is enabled (see 7), the track, trips and stops are also encrypted at rest on the device.
• Permissions and background operation: on iPhone, sharing requires the "Always" location permission and, optionally, the Motion & Fitness permission (to estimate the mode of travel). To keep updating the location while the app is closed, iOS background services and Apple's Location Push service are used: if the recipient opens the chat and the latest update is old, or if the sharing stays silent for too long, the server may ask the sharer's phone for a new location (subject to frequency limits). On Android, sharing uses a foreground service with a persistent notification and a "Stop" button.
• Maps and addresses: to show addresses and arrival times, the iOS app sends the relevant coordinates to Apple (MapKit), without account identifiers. On Android, maps are downloaded from OpenStreetMap (see 5).
• Stopping: sharing can be stopped at any time, only by the person who started it. It ends automatically at expiry, on logout and on account deletion. A new sharing session in the same chat replaces the previous one.
• Notifications: starting a sharing session generates a notification with generic text ("Live location"), without coordinates. Subsequent updates do not generate notifications.

3.11-bis Trusted contact: location on request (optional)

From the profile of a contact with whom they have a 1-1 chat, the user can make that person a trusted contact. From then on, that person can ask where the user is even when no live location sharing is active, and the user's phone replies on its own with a single point, the location at that moment: it is not continuous sharing. Trust works in one direction only, can be granted to at most 5 contacts, and the person made trusted is informed by a message in the chat, without having to accept it (if they use Android, they only see a generic "Location on request" message). At present, granting trust, asking for the location and being located are possible only with the iPhone app (on Apple Watch, requests can be seen in the chat); the feature is not available in groups or on Android, Web and Desktop.

• Who decides: only the user who grants trust, with an action on their own phone. The phone replies only to people confirmed on that phone: a list received from the server is not enough. After logging out or reinstalling the app, trusted contacts remain "to be confirmed" and the phone does not reply until the user confirms them again.
• Automatic reply: the request reaches the phone through Apple's Location Push service, and the phone replies even when it is locked or the app is closed, without the user having to do anything. The "Always" location permission is required. If the permission is missing, if the phone is switched off or offline, or if it cannot reply within about one minute, no point is sent and the requester sees "Not reachable".
• What is sent, end-to-end encrypted: coordinates, accuracy, time of the reading and, if available, the battery level. The point is encrypted on the located person's phone for the requester only (X25519 + AES-256-GCM), with the requester's verified public key (see 7): the server cannot read it.
• What the server stores: the list of trusted contacts (who granted trust to whom and since when) and, for each request, who made it, to whom, in which 1-1 chat, the times of the request, expiry and reply, the outcome (location sent, not sent, pending) and the encrypted point. The reason for a missing reply is not stored. From the outcome the server can infer whether the phone was reachable, not the coordinates; as with any call to the server, the phone's reply arrives with its IP address (see 3.7).
• Retention on the server: the encrypted point remains available to the requester for 24 hours, after which it is no longer delivered and is deleted at the next daily automatic cleanup (within 48 hours at the latest); request data is deleted by the daily automatic cleanup after 30 days (within 31 days at the latest); the list of trusted contacts remains until trust is revoked. Trust and requests are deleted immediately, in both directions, when the account is deleted.
• Retention on the device: requests appear in the 1-1 chat of both people (and on the paired Apple Watch) as messages created by the app, which do not pass through the server as chat messages: the requester sees the point on a map, the located person sees that their location was sent (with the map) or that it was not sent. On the located person's phone, requests appear when the app syncs with the server, at the latest the next time it is opened, but only if they are among the last 50 requests of the past 7 days and the chat is still on the phone. These messages cannot be forwarded and remain on the device until the user deletes the chat; like other messages, coordinates included, they are part of the encrypted backup, if enabled (see 3.10), until the backup is replaced or deleted. The located person cannot delete the copy on the requester's device. The located person's phone also keeps a technical copy of the latest points sent (at most 50, with recipient and time), used to show the map in the chat: points older than 7 days are removed only when a new one is sent, so the copy stays on the phone, even after logout, until it is replaced by new points or the app is uninstalled.
• Maps and addresses: to show the map and the address, the app (including on Apple Watch) sends the relevant coordinates to Apple (MapKit), without account identifiers.
• TaskiAI: if either person in the chat invokes @TaskiAI or uses the "Explain" or "Suggest" actions, the requests and points among the last 20 messages, decrypted on the device and with their coordinates, are included in the context sent to Anthropic (see 5.6 and the TaskiAI policy).
• Notifications: every time the phone sends its location, Taski sends a notification to the located person even if the chat is muted, provided that Taski notifications are allowed in the phone's settings; the notification is not queued for later retries, so if the notification service does not deliver it, it does not arrive. In any case, the request appears in the chat and among the recent requests in Settings → Privacy → Who can see where you are, within the limits described above. The requester is alerted when the point arrives, according to the chat's normal notification settings (for example, no alert if the chat is muted or open at that moment). Notifications do not contain coordinates.
• Limits: each trusted contact can ask for the location at most once every 5 minutes and 20 times in 24 hours; for the server, requests left without a reply also count. The located person's phone, on its own, does not send the same person more than one point roughly every 5 minutes or more than 20 points in 24 hours, even if the server did not enforce the limits.
• Reminder: as long as there is at least one trusted contact confirmed on the phone, roughly every 30 days a notification reminds the user who can still ask for their location (it names up to three contacts). The next reminder is scheduled by the app while it is in use (at launch or when the list changes): if the app is not used for a long time, only one arrives, and none arrives if Taski notifications are turned off.
• Revocation: at any time, from the contact's profile ("Trusted contact" toggle) or from Settings → Privacy → Who can see where you are, which also lists trusted contacts and recent requests. Blocking a contact revokes trust in both directions. After revocation the phone no longer replies and the server accepts neither new requests nor replies to requests in progress. Removing the "Always" location permission in the system settings stops the phone from sending points.

3.12 Urgent and silent messages

• The user can send a message as silent (it arrives without sound or vibration) or as urgent (on iPhone it uses iOS "Time Sensitive" notifications and can break through Focus and Notification Summary, depending on the recipient's settings; on Android it uses a dedicated notification channel).
• The urgent/silent flag travels inside the end-to-end encrypted message: the server does not see it.
• The app allows at most 1 urgent message every 60 minutes per recipient.

3.13 Taski Plus and in-app purchases

• The Taski Plus subscription is purchased in the iPhone app through Apple's App Store, which handles payment. We do not receive or store card or payment method details.
• To associate the purchase with the account, the app provides Apple with a pseudonymous account identifier. From Apple we receive the transaction data: product purchased, transaction identifiers, purchase, renewal and expiry dates, subscription status (trial, active, renewal, refund, expiry) and store country.
• We retain the subscription status and transaction history for the lifetime of the account. After account deletion, transaction records are dissociated from the account and retained only to prevent fraud (for example, reuse of the same purchase on another account), handle refunds and disputes, and comply with legal obligations.

4. How we use user data

We use the data we collect exclusively to:

• Provide the messaging service (delivery, synchronization, notifications, calls).
• Manage the user's account (authentication, verification, profile).
• Ensure security (prevent abuse, spam, automated attacks).
• Improve the app (anonymous analytics to identify bugs and optimize performance).
• Comply with legal obligations if required by competent authorities.

4.1 Legal basis for processing

Under Article 6 of Regulation (EU) 2016/679 (GDPR), each processing activity relies on a specific legal basis:

Where the basis is legitimate interest, the user has the right to object to the processing (Art. 21 GDPR). Where the basis is consent, it can always be withdrawn from the app settings, without affecting the lawfulness of processing carried out before withdrawal.

5. Sharing data with third parties

5.1 Cloudflare

• Service: backend hosting (Workers), D1 database, R2 storage, KV cache, WebSocket and temporary storage of encrypted live location via Durable Objects, technical logs (Workers Logs), aggregated technical metrics without user or conversation identifiers (Workers Analytics Engine), AI models for moderation and sticker fallback (Workers AI), Web client hosting (Pages), bot protection (Turnstile).
• Data shared: all data stored on our servers. For bot protection, Turnstile collects IP address, TLS fingerprint and User-Agent; these signals are classified as strictly necessary and are not used to identify, profile or track users.
• Privacy Policy: cloudflare.com/privacypolicy
• Turnstile Privacy: cloudflare.com/turnstile-privacy-policy

5.2 Apple (APNs, PushKit, Location Push, MapKit, App Store)

• Service: push and VoIP notifications; Location Push for live location and for Trusted contact; maps, addresses and travel times (MapKit); App Store for in-app purchases.
• Data shared: APNs/VoIP/Location Push tokens. The notification content is normally a placeholder; decryption happens locally in the app extensions using the user's private key, which does not leave the device. Location Push requests contain only technical identifiers (conversation, sharing session, recipient, expiry), never coordinates. The same applies to Trusted contact requests (request, requester, conversation, expiry); the related notifications contain the other person's display name and phone number, so that they can be shown with the name from the contact list, never coordinates. For maps, addresses and arrival times, the app sends the relevant coordinates to MapKit. For purchases: the transaction data described in 3.13.
• Privacy Policy: apple.com/legal/privacy

5.3 Google — Firebase Cloud Messaging (FCM)

• Service: push notifications for Android devices.
• Data shared: FCM push token and the metadata needed to compose the notification (conversation and sender ID, sender display name and phone number, signed avatar URL). The message content is end-to-end encrypted and Google does not hold the keys to decrypt it. Only for non-encrypted service messages (e.g. support replies) the notification title and body are visible.
• Privacy Policy: firebase.google.com/support/privacy

5.4 Twilio

• Service: sending SMS and automated voice calls for phone number verification and for communications about account recovery. For voice calls, the code is read out by an Amazon Polly synthetic voice via Twilio.
• Data shared: phone number, verification code, message text.
• Privacy Policy: twilio.com/legal/privacy

5.5 Agora

• Service: infrastructure for voice/video calls.
• Data shared: E2EE-encrypted audio/video stream (not accessible to Agora), channel ID, anonymized user ID.
• Privacy Policy: agora.io/en/privacy-policy

5.6 Anthropic (TaskiAI)

• Service: AI assistant for the inline @TaskiAI mode in chats with other people, for quick actions on messages, for rewriting drafts (AI Rewrite) and for the dedicated "Taski AI" chat (Claude Sonnet 5, Claude Opus 4.7, Claude Haiku 4.5).
• Data shared (inline mode): ONLY upon explicit invocation of @TaskiAI — last 20 messages of context (including any locations, with their coordinates: those shared in the chat and, for the "Trusted contact" feature, the location requests and the point sent in reply by the phone of the person who received them), max 3 recent photos (described by Haiku as captions), name of the invoker, question.
• Data shared (dedicated chat): on every message sent in the dedicated chat — message text, recent history of the dedicated chat, any attached photos and PDFs (sent as files), the chatbot's persistent memory as part of the prompt.
• Data shared (AI Rewrite and quick actions): only the text of the draft or of the selected message; the "Explain" and "Suggest" actions also receive, as context, the last 20 messages of the chat (locations included, as above).
• Contractual guarantee: Anthropic does not use the data to train its models.
• See also: TaskiAI policy
• Privacy Policy: anthropic.com/legal/privacy

5.7 OpenAI

• Services: on-demand AI sticker generation (gpt-image-2.5-flare, gpt-image-1), TaskiAI image generation and photo retouching (inline and dedicated chat) on explicit user request (gpt-image-2.5-flare, with gpt-image-2 as fallback), full-duplex voice call with the Taski AI chatbot (gpt-realtime-2.1 + gpt-4o-mini-transcribe).
• Data shared: text prompt; the source photo in "photo → sticker" mode and in photo retouching (which in inline mode may be a photo sent by the other chat participant); microphone audio streaming and any photos sent during voice calls; initial system prompt with user's name and the chatbot's memory. Details in the TaskiAI policy.
• Privacy Policy: openai.com/policies/privacy-policy

5.8 Giphy

• Service: GIF library: search via our proxy, GIF downloads from Giphy's content delivery network.
• Data shared: search query (not associated with the user's account); IP address of the device downloading the GIF.
• Privacy Policy: giphy.com/privacy

5.9 Amazon Web Services — Key Transparency Witness

Taski publishes a public, append-only, verifiable log (Merkle tree, RFC-6962 standard) of users' public encryption keys (Key Transparency), so that clients can detect any covert key substitution. To also make a server equivocation detectable (showing divergent logs to different users), the log's fingerprints (Signed Tree Head) are co-signed by an independent witness hosted on Amazon Web Services (AWS Lambda, Tokyo region, Japan).

• Data transmitted: exclusively aggregated cryptographic hashes (Merkle root hash), digital signatures and consistency proofs. No personal data, message content, private keys, phone numbers or user identifiers.
• Purpose: to guarantee the integrity and non-equivocation of the public-key log.
• How: co-signing happens server-side (clients never contact AWS) and only at the periodic sealing of the log (a few calls per day).
• Privacy Policy: aws.amazon.com/privacy

5.10 Tavily

• Service: web search during voice calls with the Taski AI chatbot (at most 3 searches per call).
• Data shared: the search query formulated by the AI (max 400 characters) and the country inferred from the language. No user identifiers.
• Privacy Policy: tavily.com/privacy

5.11 OpenStreetMap

• Service: maps (tiles) displayed by the Android app for live location.
• Data shared: the device's IP address and the map area displayed. No account identifiers.
• Privacy Policy: osmfoundation.org/wiki/Privacy_Policy

6. Data retention

7. Technical security

• E2EE: X25519 + AES-256-GCM for 1-1 chats and groups.
• E2EE calls: HKDF (ECDH + random salt) + AES-256-GCM.
• AKD (Auditable Key Directory): hash chain on key_events to detect tampering of public keys (MITM).
• Key Transparency: a public, append-only, verifiable log (Merkle tree, RFC-6962) of every public-key change, whose signed fingerprints (Signed Tree Head) are co-signed by an independent witness and cross-checked between devices: a malicious server cannot covertly substitute a contact's key without being detected (see 5.9).
• Identity Key pinning: each user's key changes are signed by a personal identity key that is never accessible to the server (it leaves the phone only end-to-end encrypted during a transfer to a new device). Each identity key can belong to only one account. If a contact's key appears to have been substituted in an unverifiable way, sending is blocked with a warning until resolved (reading is never blocked) — active downgrade protection.
• Key reset: if the user signs in from a new phone without transferring the keys (PIN, passkey or assisted recovery), the account starts over with new encryption keys. In this case contacts are notified that the security code has changed, linked sessions are signed out, and messages not yet delivered to the old device can no longer be decrypted and are lost.
• Key rotation: automatic regeneration of E2EE keys every 10 days (with a minimum of 7 days between consecutive rotations). Previous private keys remain available locally in a grace period to decrypt historical messages already received.
• Encryption in transit: TLS 1.3 + secure WebSocket.
• Encryption at rest (server-side): databases and storage protected with AES-256.
• Data protection (on-device, at rest): optional layer (iOS and Android) that also encrypts messages, media and live location routes stored on the device, keeping them unreadable while the phone is locked (hardening against forensic extraction). Can be enabled in Settings.
• Trusted contact: the point is end-to-end encrypted for the requester only with a verified public key (identity key pinning and AKD check) and contains the request identifier, so it cannot be attributed to another request; the recipient verifies the sender's key before showing it. The phone replies only to people confirmed on that device and enforces the frequency limits on its own: a compromised server can neither add trusted contacts nor cause points to be sent beyond the limits, and it can never read the points.
• No plaintext fallback: in case of an encryption error, the message is not sent.
• Authentication: code via SMS or voice call + Passkeys (post-onboarding) + optional anti-SIM-swap PIN + Face ID/Touch ID for app lock.
• Anti-SIM-swap: a new phone can activate the account only with the approval of the primary phone (with biometric authentication) or with a passkey, PIN or assisted recovery; the SMS code alone is not enough. SMS verification on web is blocked if the user has an active iOS device within 30 days.
• Destructive actions from the primary phone only: account deletion and the deletion of conversations on the server can only be requested from the primary phone, not from Web or Desktop.
• New linked devices: on iPhone, linking a new Web/Desktop device requires Face ID/Touch ID; in calls from the Web, the end-to-end encryption security code is visible.
• App Attest (iOS): cryptographic attestation of app integrity via Apple App Attest, to block API access from tampered or counterfeit clients.
• Rate limiting on all sensitive endpoints.
• Device management: view and revoke sessions from settings.

8. Platforms and clients

• iOS (iPhone): native app with all features, requires iOS 17.6 or later.
• Android: native app with the E2EE features (chats, groups, calls, media, stories, voice messages, live location, Key Transparency); requires Android 8.0 (API 26) or later. Push notifications via Firebase Cloud Messaging. Trusted contact is not available on Android: an Android user made a trusted contact only sees a generic "Location on request" message in the chat.
• Apple Watch: companion to view and reply to messages (including E2EE voice notes).
• Web: client accessible at web.taski.chat, linked via QR code. Supports chats, calls, media and the E2EE features; it does not allow sharing live location, using Trusted contact or deleting the account.
• Desktop: macOS and Windows (Tauri build), automatic signed updates.

Web/desktop sessions are visible and can be revoked at any time from Settings → Linked devices.

9. User rights (GDPR)

Pursuant to EU Regulation 2016/679 (GDPR), the user has the right to:

• Access: obtain a copy of personal data (Backup function).
• Rectification: correct inaccurate data from the app (Profile settings).
• Erasure: delete the account and the associated data from the primary phone (Settings → Delete account), with the exceptions set out in Data subject rights.
• Portability: receive personal data in a readable format (export backup).
• Objection: object to processing for specific purposes.
• Restriction: request restriction of processing.
• Complaint: file a complaint with the competent data protection authority in the relevant EU country (e.g. the Italian Garante per la protezione dei dati personali — garanteprivacy.it). Residents in other EU countries can find the relevant authority on the EDPB website.

For detailed instructions see: Data subject rights.

10. Privacy settings in the app

• Last seen: everyone / contacts only / nobody.
• Profile photo: everyone / contacts only / nobody.
• Status/Bio: everyone / contacts only / nobody.
• Read receipts: can be enabled/disabled; the choice is saved to the account and applies on all devices.
• Music listening: sharing can be enabled/disabled.
• Notifications when Web is active: receive or not receive notifications on iPhone when Web is connected.
• Block users: block without notice.
• Live location: can be stopped at any time from the chat; saved routes can be deleted from the chat profile; location and motion permissions can be managed from the system settings.
• Trusted contact: enabled and revoked from each contact's profile; Settings → Privacy → Who can see where you are lists trusted contacts and recent requests, with the option to confirm or revoke; blocking revokes trust; reminder roughly every 30 days.
• Urgent messages: the recipient decides whether to allow Taski's Time Sensitive notifications from the iOS settings.
• TaskiAI: full opt-out (see TaskiAI policy).
• Anti-abuse system: transparency on moderation (see Acceptable use policy).
• Linked devices: view and revoke Web/Desktop sessions.

11. Minors

Taski is intended for users aged 16 years or older. We do not knowingly collect data from minors under 16. Anyone who becomes aware that a minor has provided data is asked to contact us immediately for removal.

To protect minors, Taski adopts a zero-tolerance policy on child sexual abuse material (CSAM): see Acceptable use policy.

12. International transfers

User data is hosted on Cloudflare, which operates a global network. Data may be processed edge-side in the geographically closest data center. Cloudflare is certified under the EU-U.S. Data Privacy Framework for EU → US transfers. The Key Transparency witness is hosted on Amazon Web Services in Japan and receives only aggregated cryptographic hashes and signatures of the public-key log, which do not constitute personal data. Transfers to providers (Apple, Google, Twilio, Agora, Anthropic, OpenAI, Giphy, Tavily, OpenStreetMap Foundation, Amazon Web Services) take place under Standard Contractual Clauses approved by the EU Commission. Japan, where the witness is hosted, is also covered by an adequacy decision of the European Commission. Users may request a copy of the safeguards in place (Standard Contractual Clauses) by writing to [email protected].

13. Changes to this policy

We may update this policy to reflect changes to the service or to legal obligations. Material changes will be communicated via:

• In-app notification
• Update of the "Last updated" date at the top of this document

Continued use of Taski after the changes constitutes acceptance of the new policy.

14. On-device semantic search

Taski includes an intelligent semantic search across the user's chats that runs entirely on the user's device. No text, embedding or query ever leaves the device.

How it works

• Messages are transformed into vectors (512-dim embeddings) using the open EmbeddingGemma model, executed on-device on iPhone and Android. The model file is downloaded only once from Taski's servers: the download contains no user data.
• The index is stored locally on the device, encrypted at rest by the operating system.
• When the user runs a search, the query is also transformed into a vector on-device and compared locally.
• Works offline / in airplane mode.

Two intelligence levels

• Base version (iPhone with iOS 17.6+ and Android): full semantic search with on-device embeddings, time-decay scoring.
• Advanced version (iPhone with Apple Intelligence, iOS 26+): additional re-ranker using Apple's on-device Foundation Model to better order results by relevance.

In both cases everything runs on-device: neither the Taski server, nor Apple, Google or any provider receives text or queries (models run locally).

Controls available to the user

• Toggle ON/OFF in Settings → Privacy → Semantic Search.
• The user may clear the index at any time; it will be rebuilt at the next bootstrap.
• Faceted filters (date, message type, sender, chat) applied locally on ranked results.

15. In-app support

Taski provides a built-in support system, accessible from Settings → Support. Support conversations are not end-to-end encrypted, as support staff (and an AI first-response assistant) need to read messages in order to help.

• Encryption at rest: support messages are encrypted server-side (AES-256) in a dedicated database. No data is transmitted or stored in plaintext.
• Separate infrastructure: the support system runs on a dedicated Cloudflare Worker, database (D1) and storage (R2), fully isolated from user chat data.
• AI assistant: a language model (Anthropic Claude Haiku) may process support messages to provide automated initial responses. The same conditions described in section 5.6 Anthropic (TaskiAI) apply.
• Retention: support conversations are retained for the time needed to resolve the request and no longer than 12 months after ticket closure, after which they are automatically deleted.
• Attachments (screenshots, logs) sent by the user to support are encrypted at rest on Cloudflare R2 and deleted together with the conversation.

16. Contact