FNF MEET Privacy Policy

Effective 15 October 2026. Version 1.2.

This Policy explains how Indian Networks processes information when you use FNF. Features and encryption modes vary by account and conversation. The security indicator and any separate moderation notice explain the mode applicable to your interaction.

Who is responsible

Indian Networks operates FNF MEET (“FNF”, “we”, “us”) at K-142, Shivalik Nagar, Haridwar, Uttarakhand, India. FNF provides messaging, group conversations, attachments, voice notes and voice/video calls through fnfmeet.com and its Android application.

Privacy questions, rights requests and grievances may be addressed to Indian Networks at that postal address. The privacy-request form at /privacy-request verifies control of the sender’s email by a one-time code before accepting a submission. A verification code establishes control of that mailbox; it does not establish legal identity, account ownership or entitlement to another person’s information. Requests can also be sent to fnf@fnfmeet.com or our postal address if the form is inaccessible.

Information we process

Microphone/camera permissions are used for the features you initiate. During a disclosed moderated video call, front-camera snapshots may also be captured at the interval shown before consent. A permission granted to Android or a browser is separate from consent to recording. Private Friend/Family/Business contact labels are chosen by the account holder; they are not public relationship statements.

End-to-end encryption and availability

FNF supports end-to-end encrypted conversations for approved accounts. In a chat marked End-To-End encrypted, supported messages and attachment contents are encrypted on participant devices. Authenticated calls bind their encrypted media negotiation to device identities. Availability is currently limited to approved accounts rather than every registered account. Other conversations use HTTPS transport protection and may remain server-readable; older ordinary conversations are not retroactively encrypted. The conversation security indicator describes the mode in use. Ordinary calls are not routinely recorded by the moderation capture system.

The current E2EE implementation uses the vodozemac Olm ratchet with per-device key delivery for text, attachments, voice notes and groups. Devices hold the private decryption state. Approved devices and contacts have security codes to compare through a trusted channel; first-use identities are unverified until compared, and changed or newly added known-contact identities require verification. Authenticated E2EE calls bind signed negotiation to the registered device identities; participants must still compare device codes to establish who controls those identities. More than one account device requires approval or a user-held recovery proof. A history archive has its own user-held key; the service cannot restore it without that key. Routing metadata, account/device identifiers, membership, timing, approximate sizes and call diagnostics remain available to the service. Client-held readable history and compromised endpoints are outside forward-secrecy protection. Limited Android/browser integration tests have passed. Broader device, group, recovery and relay testing and an independent FNF integration review remain pending. We will not describe ordinary server-readable messages or disclosed moderation recordings as end-to-end private. An account password reset is not a promise to recover encrypted history.

Transport encryption does not hide all metadata or prevent a participant from making their own copy. Compromised devices, screenshots, notification previews and material voluntarily supplied in a report may reveal content independently of FNF’s encryption.

Transparent moderation and screening

An authorized staff member may flag an account following a report, a serious allegation, a safety review or a legally assessed requirement. A flag indicates screening, not a finding that an allegation is true. A legal request is not automatically treated as valid solely because it claims to come from an authority.

The interface identifies flagged participants with a flag indicator. Unflagged participants retain their own lock indicator; that does not mean a moderated interaction is end-to-end private. The screening popup and consent notice explain the protection applicable to the whole interaction.

Before a moderated call connects, both participants must personally accept a disclosure of call audio recording and, for video calls, front-camera snapshots. The configured snapshot interval is shown. Moderated messaging and voice notes also require the applicable disclosure and consent. A general acceptance of these Terms or this Policy does not replace the specific recording notice.

You can decline the moderated feature or end the interaction. Ending a call stops further capture. Evidence already captured with consent may finish uploading and remain subject to retention or a preservation hold. Declining consent does not authorize covert capture. We do not silently decrypt or downgrade existing E2EE history; an eventual moderated interaction must use a separately disclosed mode.

Only staff granted the relevant access may review evidence. Access reasons, decisions and preservation holds are logged. Custom wording added by the operator does not remove the mandatory recording disclosure.

Purposes and legal grounds

We process information to provide requested features, secure accounts, handle support and safety matters, and meet applicable legal duties. Depending on the information, purpose and applicable jurisdiction, the legal ground may be performance of a service agreement, consent, a legal obligation or another ground recognized by law. Where consent is the ground, it must satisfy the applicable requirements and may be withdrawn for future processing. We assess sensitive information and children’s information separately where required.

We do not treat a user’s agreement as a blanket authorization for every future use, indefinite monitoring or processing forbidden by law. A required service restriction or preservation duty may remain even when a user chooses not to continue a moderated feature.

Sharing and service providers

Other participants receive the account and conversation information necessary for the features you use. We use hosting/database services, email delivery, Firebase push delivery and Cloudflare TURN services. TURN relays may handle encrypted call traffic and connection metadata. Push delivery requires notification tokens; notification previews may reveal information to someone with access to a device.

Providers receive information necessary for their services and may process it outside your country, including outside India, depending on the provider and service configuration. Where applicable law requires safeguards for international transfers, those requirements apply. You can contact us about the providers used for your information. Staff access is restricted and audited. Information may be disclosed in response to a valid legal obligation, to address a demonstrable safety incident where lawful, or to a successor operator under appropriate safeguards and notice. We assess the scope, necessity and legal validity of such disclosures. We do not promise to notify you where notice is legally prohibited.

Retention and deletion

The current moderation-evidence policy is 90 days after a call ends, unless an authorized administrator places a preservation hold with a recorded reason. The super administrator can change the configured period. A shorter period can affect existing unheld evidence; a hold excludes evidence from automatic deletion until released. Comments alone do not create a hold. Releasing an old hold can make evidence eligible for deletion at the next cleanup.

Cleanup is not instantaneous: the current implementation is activity-triggered, at most daily, and may be delayed by inactivity or processing. It removes eligible recordings, audio segments, snapshots and generated versions while retaining necessary call/review metadata. Selected unheld evidence can also be removed manually. Copies held by other participants are outside FNF’s control.

Account deactivation revokes access; it is not complete erasure of all linked information. Message removal marks content removed from normal conversation access and may preserve safety/audit records. Other account, conversation, diagnostic and audit information is retained as needed for its documented purpose and assessed on a rights request. The 90-day moderation-evidence period is not a deletion deadline for all information. Records that remain necessary for account operation, security, dispute handling or a lawful preservation requirement may remain after content is removed. Contact us for an assessment of the information associated with your account; no fixed backup-expiry promise is made here.

Your choices and rights

You can manage active sessions, notification permissions, available privacy settings and participation in conversations. You may request access, correction, deletion, restriction, a copy of relevant information or an explanation of processing, as applicable to your jurisdiction. You may raise a grievance or challenge a screening decision. We may need proportionate additional verification and will not disclose another person’s private information merely because you control an email address.

Some requests may be limited by others’ rights, an applicable preservation duty or a lawful security requirement. We will explain the outcome where permitted and respond within the applicable legal timeframe. You may have a right to complain to a competent supervisory authority. Mandatory statutory rights are not waived by using FNF.

Age and children

You must be at least 13 years old, or the higher minimum age required by the law applicable to you. Additional parent or guardian authorization may be required in your location. FNF does not currently provide a verified parental-authorization process: if such a process is required for your use, do not register or continue using the service until it is available. Contact us if you believe a child has registered contrary to these requirements so that we can assess and restrict the account where appropriate.

Security, storage and changes

We use private evidence storage, authorization checks, encrypted connections and audited staff access. No service can guarantee absolute security. Essential cookies and local application storage support sign-in, device state and, when implemented, device-held encryption keys. Clearing device storage may remove keys and affect access to encrypted history.

Material changes to processing, retention or encryption require a revised notice and any additional consent required by law. The effective date and version appear above. A material change will be identified in the revised notice, with further notice or consent where required.

Attachments, previews and reports

File attachments may be unavailable while the attachment button is hidden. Existing attachments can remain accessible. The current service stores uploaded attachment files on FNF hosting; files in supported E2EE conversations are encrypted on the device before upload. The proposed personal cloud-drive integration is not available in this release. We do not claim that FNF currently stores no attachment files. Shared-media previews are processed on participant devices and may be cached there. Ordinary server-readable attachments are subject to the access and moderation rules described above.

If you deliberately submit a message report with recent-message context, your device can disclose readable text from up to ten recent messages, including encrypted messages, and attachment names to authorized moderators. Attachment file contents are not automatically included in that report.

Optional GIF services, when enabled and used, may receive search terms and network/request information. FNF can use GIPHY, KLIPY, Gifukai and Nekos.best, depending on the enabled service. External GIF links and their hosting are controlled by those providers. Provider access is separate from access to encrypted message content.

Optional mobile-number verification

When SMS authentication is enabled, you can register or sign in using a verified mobile number. Existing accounts must confirm their account password and verify the number before linking it; entering a number does not establish ownership of another account. We process the mobile number, verification times and security events for authentication and recovery. The SMS provider, 2Factor.in, receives the destination number and the verification code needed to send the SMS. Verification codes are short-lived, attempt-limited and are not included in normal staff audit records. Expired challenge records are cleaned up during subsequent verification activity. SMS verification confirms possession of the number; it is not, by itself, two-factor authentication and does not recover lost encryption keys or approve a new encryption device. Provider delivery and country availability can vary. The enabled sign-in and backup choices are shown in the app.

See also our Phone Sign-in and Contacts privacy supplement.