Privacy Policy

The controller is Via Messaging, d.o.o., Avčinova ulica 6, 1000 Ljubljana, Slovenia. The three mailboxes above are monitored: privacy and data-protection requests reach us at legal@viamessaging.eu, app support at support@viamessaging.eu, and waitlist enquiries and removal requests at hello@viamessaging.eu.

End-to-end encryption. Your device encrypts ordinary message and media content before sending it. Via does not hold the private conversation keys needed to decrypt it. This protection does not prevent a recipient from copying, sharing or reporting content, and does not protect readable content on a compromised device.

Delivery and temporary storage. We relay encrypted messages to recipients. If necessary to complete delivery, we temporarily queue an encrypted copy for the recipient’s device. We delete that copy from the active delivery queue after the app acknowledges that it has received and saved the message. This is a delivery acknowledgement, not confirmation that the person has read it. Group recipients’ copies are handled independently.

Queued copies expire 30 days after they are created on our server. Expired copies are removed by an hourly cleanup process, normally within one further hour, and are not delivered after expiry. This delivery process also covers encrypted chat images, group-photo updates, read receipts and other encrypted conversation events. Those images are carried inside encrypted events; there is no separate chat-image library on our servers.

Delivery and expiry do not remove messages already stored on recipients’ devices. Reports have separate retention rules in section 8. Our routine recovery backups exclude queued conversation content and report content.

Launch limitations. Via supports one active device per account, with no web version, linked devices or Via-operated conversation-backup feature. Reinstalling the app, replacing your phone or deleting local data may permanently remove history and keys. When you replace a device, messages still queued for the old device are deleted and are not transferred to the new device. Changing the account’s phone number is not currently supported; contact support before deleting an account to register another number.

Phone number in readable form during verification

Send an SMS code and verify control of the numberUsed for verification only. We do not store your phone number in readable form.

Hashed phone-number identifier

Identify your account and match phone-number searches and contact discovery

Account identifier and signup timestamp

Operate and administer the account

First and last name, if provided

Display your profile to other users

Optional profile photo

Display your profile; visibility is explained below

Date of birth

Apply our minimum-age rule

Device identifier, platform and public encryption-key material

Register your device and enable encrypted communication

Push token, push environment, update timestamp and notification preferences

Deliver and manage notifications

Session and refresh-token records

Keep your session authenticated

We process your readable phone number when you request verification and send it to Infobip, together with the SMS text containing the code. We do not store the readable number in our account or verification databases, or intentionally include it in logs. What we retain is a hashed identifier, so Via does not hold your phone number in readable form. That identifier is still information about you, and we treat and protect it as personal data.

Codes are stored as hashes, are valid for 15 minutes, have limited verification attempts and cannot be successfully used more than once. Successful verification consumes and removes the verification record. Expired records are removed within one hour after expiry. Infobip retains its own records separately; see section 10.

Profile visibility. Your first name, surname (if you choose to provide one) and profile photo are not end-to-end encrypted and are readable by Via. Providing a surname or profile photo is optional. Any signed-in Via user who knows your account identifier can retrieve your first name and any surname you have provided, and view your profile photo if you have added one. Profile photos require authenticated access and are not available through publicly accessible links. Blocking does not restrict this profile access. You may remove your surname or profile photo, but we cannot delete copies already saved by others.

Your date of birth and hashed phone identifier are not part of the profile other users can see. Contact-discovery responses contain matching hashed identifiers and account identifiers for the requesting user. You can correct your profile information in the app or contact us for help.

Address-book discovery runs only after you choose the feature and grant device permission. The app reads contact names and numbers locally, normalises numbers and sends only their hashes for matching against registered accounts. Address-book names and email addresses are not uploaded. With permission enabled, the app may repeat matching when it returns to the foreground, subject to refresh and abuse-prevention limits.

Submitted discovery hashes are processed to answer the request and then discarded; they are not retained in discovery logs or caches. This applies to both matching and non-matching submissions. Registered users’ own account hashes remain in the account database. We do not save an uploaded address-book list, or a relationship stating that you have someone in your contacts. Separately, we retain conversation participant identifiers as explained in section 5.

You can decline or revoke address-book permission. You can still use existing chats, receive messages and start a chat by entering a full phone number, which the app hashes for lookup. Revoking your permission does not stop someone else who knows your number from finding your account. Contact discovery and manual searches reveal whether a number is associated with Via; authenticated lookup limits reduce bulk harvesting but do not conceal individual matches.

We process hashes of non-users’ numbers only transiently for matching, not to create accounts or contact them. Device permission from the person uploading contacts is not consent from everyone in their address book. Section 11 explains the legal basis for this processing.

Although ordinary content is encrypted, we process account and device identifiers, sender and recipient identifiers, group or conversation identifiers, timestamps, and a notification indicator to route events. This can reveal communication relationships and timing. The notification indicator distinguishes events that should produce an alert from other encrypted events; it does not reveal their text.

We process conversation and participant identifiers where necessary to route encrypted messages and to operate conversations. Server-side conversation metadata is deleted within 30 days of its creation, or earlier when it is no longer needed. Activity in a conversation does not extend the retention period of records already created. Removing a chat locally does not itself delete these server records, and deleting server-side metadata does not delete the conversation history stored on participants’ devices.

When you delete your account, we remove your identifiers from active conversation membership and lookup records, subject to the outgoing-queue exception in section 13: copies already queued for other recipients may retain the routing information needed for delivery until acknowledgement or their original expiry. Restricted recovery copies follow the backup-retention rules in section 12. Group names and photos travel inside encrypted group events, and routing and conversation records may still reveal group-related relationships.

Live connection information is held in memory while devices are connected, and someone you are in a conversation with can see that you are connected. We do not maintain a separate historical last-seen or last-active database record. Limited security and error logs may nevertheless contain IP addresses, request paths, account and device identifiers, connection times and diagnostic events. We minimise these fields and do not routinely log every successful refresh or message delivery. Logs exclude authentication secrets, readable phone numbers, message payloads, report contents and uploaded image contents.

We keep temporary counters for request limits and abuse prevention. These may associate an account or IP address with a count and time window, without retaining the submitted address-book entries. Typing indicators are not a launch feature.

We use Apple Push Notification service (APNs) for iOS and Firebase Cloud Messaging (FCM), provided by Google, for Android. We contact these services directly, without an additional push-delivery aggregator.

Notifications sent by our servers contain a generic “New message” alert, without the sender’s name, message text or images.

Apple or Google still receives your device’s push token, a sender or group routing identifier and the information needed to deliver the notification. These identifiers and delivery timing can allow notifications to be correlated.

You can manage direct-message and group notifications in Via and through your device settings. Turning off your own notifications does not stop the people you message being notified that something has arrived.

When you block someone, we store the two account identifiers and the time of the block so we can apply it. We do not require a reason or a copy of a message. Display names used in your local blocked-user list stay on your device.

Blocking applies to everything that person sends you: our relay stops their messages reaching your device, including messages they send to a group you are both in. You may still see other members replying to them, and group membership and security updates continue to work so that the group’s encrypted state stays consistent. We do not send them a notification of the block. Existing local messages and profile access are not removed. The active block record is deleted when you unblock them or either account is deleted; short-lived recovery copies follow section 12.

You can report a person from your chat with them, or from their profile in a group you share. You choose a reason — spam, harassment or abuse, threats, sexual exploitation, or other — and you may add a description in your own words. The description is optional.

A report does not send us any part of the conversation. No messages, no images, no message identifiers, and nothing quoted from the chat automatically. We receive your account identifier and the reported person’s, the reason you selected, your description if you wrote one, and the time of the report. We do not upload the group roster, group messages or address-book names.

Because we never receive the conversation, reporting does not weaken end-to-end encryption or create a readable copy of your messages on our systems. The only text a reviewer reads is the description you chose to write, so please keep it to what is necessary: avoid other people’s personal data, and do not paste in message content you would rather we did not hold.

Reports are stored separately on access-restricted infrastructure in Germany, and are reviewed by designated personnel; administrative alerts contain only a report reference. Authorised Via personnel use reports to investigate abuse, enforce our Terms and decide whether to warn, restrict, suspend or ban accounts. Since we cannot see what was said, a report is one person’s account of it, weighed against the other signals available to us rather than treated as proven. We may involve legal advisers or competent authorities where necessary and legally justified.

We delete the report and its description within 90 days after closing it, sooner when no longer needed, and ordinarily no later than 12 months after submission. Specific records may be retained longer where necessary for a legal obligation or an actual legal claim, with a documented reason and review date. A minimal enforcement record may remain for the duration of an active restriction, plus up to 90 days to resolve follow-up matters. Reports may survive deletion of either account under these rules.

If you join the waitlist, we collect your email address and the time you signed up, and we use them to tell you when Via is available on iOS and Android. We do not use the list for an unrelated newsletter or for advertising campaigns. You can ask to be removed at any time by contacting hello@viamessaging.eu, and every announcement we send includes a way to opt out.

We remove waitlist entries by the earliest applicable deadline: your removal request; 30 days after both platform announcements have been sent; or six months after the first platform announcement. If neither platform has been announced, an entry is deleted 12 months after signup. Provider recovery copies and email-delivery records follow the retention separately disclosed in section 10.

The website uses Vercel for hosting and request processing, Neon for the waitlist database and Resend for email delivery. The waitlist function and its database are both configured in Frankfurt, Germany. That does not mean all provider processing, support or email delivery occurs exclusively in Germany or the EEA.

We process IP addresses and submission timestamps to limit automated abuse. These rate-limit records are deleted within 24 hours of collection. Website providers may separately process technical request, security and delivery information. The website does not use advertising trackers or optional analytics cookies, and Via does not use third-party analytics or crash-reporting SDKs in the app. Necessary security or service technologies, if introduced, will be disclosed before use.

Support and privacy mailboxes are hosted through Google Workspace. We process your address, your message and any information you choose to send in order to respond. Ordinary support and general enquiries are deleted within 12 months after resolution. Minimal records of privacy requests and responses are kept for 24 months after closure; identity-verification material is deleted promptly after verification. Actual disputes are handled under separately assessed legal-retention requirements.

Hetzner Online GmbH

Core backend and database hosting, profile photos, report records and selective recovery backupsCore storage configured in Germany; processor acting under our instructions

Infobip Ltd., United Kingdom (company no. 7085757)

Phone number, verification-SMS text, delivery and traffic informationSMS delivery processor; also processes certain traffic and billing data for its own controller purposes

Apple, APNs

Push tokens, sender or group routing identifier, generic notification body and delivery informationDelivers notifications to iOS devices

Google, FCM

Push and installation identifiers, generic notification body, sender or group routing identifier and delivery informationDelivers notifications to Android devices under the applicable Firebase processing terms

Vercel

Website hosting, waitlist requests and operational and security informationThe waitlist function executes in Frankfurt; other request handling may occur elsewhere in its network

Neon

Waitlist database containing email addresses, signup times and temporary rate-limit recordsDatabase region AWS Frankfurt

Resend

Email address, email content and delivery and suppression informationSends the waitlist emails

Google Workspace

Support, waitlist-removal and privacy correspondenceHosts our mailboxes

We use appropriate contractual arrangements with processors. Some providers act independently for particular purposes under their own notices. We do not sell your data or build advertising profiles. Content recipients, group participants and signed-in users who look up your profile also receive data as described above. Telecom operators involved in SMS delivery process the number and SMS according to their applicable roles and obligations.

Infobip’s published defaults retain SMS content and associated logs and reports for three months from communication. Personal data in traffic and billing records used for its own purposes is deleted or anonymised after 12 months unless law requires longer. These periods are distinct from Via’s verification-record deletion, and are set out in the Infobip retention notice.

Registration, verification, account identity, sessions, encryption-key distribution, delivery and necessary conversation metadata

Performance of the messaging contract, Article 6(1)(b)

Optional profile and notification features requested by the user

Contract, Article 6(1)(b), to the extent objectively necessary for the selected feature

Phone matching, including other users’ and non-users’ identifiers and disclosure of matching registration status

Legitimate interests, Article 6(1)(f), in enabling people to find intended contacts, with transient processing and anti-harvesting safeguards

Birth-date eligibility check and limited incomplete-account processing

Legitimate interests, Article 6(1)(f), in applying our 16+ service rule

Security logs, rate limits, backups, abuse handling, blocking and enforcement

Legitimate interests, Article 6(1)(f), in protecting users and maintaining a secure, reliable service

Waitlist announcement emails

Consent, Article 6(1)(a); withdraw at any time

Routine support

Contract where needed to provide the service; legitimate interests for other enquiries

Responding to statutory privacy requests or binding disclosure obligations

Legal obligation, Article 6(1)(c)

Minimal compliance records and actual legal-claim handling

Legal obligation where applicable; otherwise legitimate interests in demonstrating compliance or establishing, exercising or defending claims

These legitimate interests are assessed against individuals’ rights and reasonable expectations. You may object to processing based on legitimate interests. Withdrawing consent does not affect earlier lawful processing. An operating-system permission is a device-access control and is distinct from the legal basis for data about other people.

Readable verification number

Transient verification and SMS processing; not retained in Via databases or logs

Verification code hash and verification record

Consumed and deleted on success; otherwise 15-minute validity and deletion within one further hour

Queued encrypted events

Deleted after recipient-device acknowledgement; otherwise expire 30 days after queuing and are removed within one further hour

Completed account, profile, device and key records

While needed for the account; removed on deletion, subject to the stated exceptions

Server-side conversation metadata and participant links

Within 30 days of creation, or earlier when no longer needed; later activity does not extend it, and deleted users’ links are removed from active records

Optional profile photo

Until replaced, removed or the account is deleted; copies saved by others remain outside Via’s control

Block relationships

Until unblocked or either account is deleted

Refresh-session records

Seven-day rolling expiry; revoked on logout, deletion or device replacement as applicable

Incomplete accounts

Within 48 hours of creation; known underage onboarding accounts are removed promptly

Website rate-limit rows

Within 24 hours of collection

Other anti-abuse counters

Until the relevant limit window ends, within 48 hours of the last counted event

Application, system and security logs

At most 30 days; shorter where feasible

Web-server logs

Daily rotation, fourteen retained archives plus the current log; removed within 15 days

Report records: reason, description and the two account identifiers

Within 90 days after closure and ordinarily within 12 months after submission; documented legal exceptions only

Routine correspondence

Within 12 months after resolution

Minimal privacy-request records

24 months after closure; verification material removed promptly

Waitlist

The earliest deadline described in section 9

Selective recovery backups

At most seven days

Completed inactive accounts are not automatically deleted solely for inactivity. Records must still be necessary for providing the continuing account; we review our retention practices rather than retaining unnecessary data indefinitely.

Selective encrypted recovery backups contain necessary account, device and service metadata, not queued conversation payloads, report records, verification records or profile-photo files. Deleted records may remain in these restricted copies until expiry. If we restore a backup, we reapply deletion and expiry records before restoring normal service. Providers may retain separate service and recovery records under the arrangements described in section 10.

You can request account deletion in the app, or contact legal@viamessaging.eu if you cannot access your account. We verify the request appropriately.

Deletion removes active account and profile data, device and session records, associated keys, block relationships, profile photos, incoming queued messages and the account’s links in conversation metadata. The app attempts to leave groups before deletion so that remaining members can update their encrypted group state.

Outgoing queued events are an exception: copies already sent for other recipients may remain with the routing identifiers needed for delivery until their devices acknowledge receipt or the original expiry is reached. Deleting your account does not withdraw those messages. Report records, necessary enforcement records, correspondence, limited logs and recovery copies follow their separate retention schedules. Specific records may also be retained where necessary to comply with law or to handle actual legal claims.

Copies already on other people’s devices are unaffected. Local message history and keys are not backed up by Via and may become permanently unrecoverable when local data is removed. Deleting the app alone does not delete the server account.

Via is intended for people aged 16 and older. We use the birth date you supply to check eligibility; this is not independent verification of your age. Incomplete accounts cannot use messaging or discovery before the check passes. If you provide an under-16 date during onboarding, access is refused and the incomplete account is removed promptly. Other abandoned incomplete accounts are deleted within 48 hours.

We retain the supplied birth date as account information and do not display it to other users. If you believe an under-16 child has an account, contact legal@viamessaging.eu. We investigate and take appropriate steps to restrict and remove ineligible accounts, subject to necessary legal preservation. A minimum-age rule does not mean Via never processes information about children, for example when someone submits a report.

Depending on the applicable conditions, you may request access, correction, erasure, restriction or portability, or object to processing based on legitimate interests. You may withdraw consent for waitlist communications at any time. GDPR rights under our EU establishment are not limited here to users with EU citizenship.

Contact legal@viamessaging.eu. We normally respond within one month. Where permitted for complex or numerous requests, we may extend by up to two further months and explain the extension within the first month. Requests are normally free. We may seek proportionate additional information where we reasonably doubt the requester’s identity, using an authenticated account or another suitable method rather than routinely asking for identity documents.

Our response covers the relevant personal data we process, including applicable account, operational, correspondence and report information. We protect other people’s rights, and do not disclose authentication secrets or automatically reveal confidential reporters. We cannot recover local conversation history from your device or decrypt ordinary queued content. An access response includes the required information about purposes, recipients, retention and relevant safeguards, rather than simply a database dump.

You may complain to a competent supervisory authority, including the Slovenian Information Commissioner (Informacijski pooblaščenec): www.ip-rs.si, gp.ip@ip-rs.si. You may also complain to the authority where you habitually reside or work, or where an alleged infringement occurred.

We do not use profiling, and we do not make solely automated decisions producing legal or similarly significant effects, with one exception: the age check in section 14 automatically refuses registration when the date of birth supplied is under 16. If that happens because a date was entered incorrectly, contact legal@viamessaging.eu and a person will look at it.

Our core messaging infrastructure and the waitlist function and database are located in Germany. SMS delivery, push notifications, email services and provider support may involve processing outside the EEA. A provider’s European storage setting does not exclude overseas access.

Where required, we use an applicable adequacy decision or appropriate safeguards for international transfers. You can ask legal@viamessaging.eu for information about these, or for a copy of the relevant safeguards, with confidential information redacted where necessary.

We use encrypted client connections, protected internal service connections, encryption at rest for retained databases and image storage, restricted administrative access, authentication controls, deletion processes and tested recovery procedures. End-to-end encryption does not apply to profile names and photos, routing metadata or the description you write in a report. No system can guarantee absolute security. We assess security incidents and make legally required notifications.

We update this notice when the service or its processing changes. Material changes are communicated through an appropriate channel before new processing begins, where required. A revised notice does not itself authorise a new purpose, or replace consent where consent is required.

Questions: legal@viamessaging.eu.