Data Collection & Permission Policy

This Data Collection and Permission Policy explains what information Fourth Idly collects through its current mobile application, why that information is required, which device permissions may be requested, how role-specific information is used, and how Users can control permissions through their device settings.

This Policy is based on the current implemented Fourth Idly application flow. It should be read together with the Fourth Idly Privacy Policy, Terms and Conditions, Community Guidelines, Data Deletion Policy, and other applicable Platform policies.

Fourth Idly follows a data-minimisation approach: information and permissions should be requested only when reasonably necessary for an identified Platform function. A permission should not be treated as consent to collect unrelated information.

10.1 Scope

This Policy applies to Donors, NGOs, Volunteers, and other authorised Users who access the Fourth Idly mobile application and its connected services. It covers information entered by Users, information generated through Platform activity, and information processed through supported device or application services.

The current application uses Flutter on mobile, Firebase Authentication for email/password and phone OTP authentication, Cloud Firestore for real-time application data, Firebase Storage for profile photographs and verification documents, Firebase Cloud Messaging (FCM) for push notifications, and UPI deep links/QR generation for Delivery Fee payments.

10.2 User Roles and Data Collection

Fourth Idly uses role-based onboarding. Users first select one of three available roles — Donor, NGO, or Volunteer — and the information collected after role selection depends on the selected role.

• Donor: common account and profile information is collected to enable browsing of NGO requests, creating donations, coordinating delivery where applicable, paying the Delivery Fee, and rating the Volunteer.
• NGO: common account information plus NGO licence/registration information and a supporting licence/registration PDF are collected for verification before the account is activated.
• Volunteer: common account information plus driving licence information, a driving licence PDF, UPI ID, and optionally vehicle type are collected for verification, task assignment, delivery coordination, and Delivery Fee payment.
• Admin: administrators use a separate web panel to approve, reject, block, manage donations and deliveries, resolve disputes, review ratings/feedback, view notifications, and access audit information. The public mobile onboarding flow does not create an Admin account.

10.3 Information Collected From All Registered Users

The current onboarding flow collects the following common account information:

• Email address — required for account authentication and account communication.
• Password — supplied during registration and handled through Firebase Authentication; Fourth Idly does not intend to store a plaintext password in the application database.
• Name — used for account identity and relevant Platform interactions.
• Username — a unique handle used to identify the User within the Platform.
• Location — entered as text or map-area information and used to support donation and delivery coordination.
• Phone number — used as part of the phone OTP verification process.
• Phone verification status — records whether the phone verification step has been completed.
• Profile photograph — optional and uploaded to Platform storage when the User chooses to provide one.
• Role — records whether the account is a Donor, NGO, or Volunteer.
• Account status — may be pending, approved, active, rejected, or blocked depending on the role and administrative process.
• Rating information — average rating and total review count may be maintained where the User receives eligible ratings.

10.4 Authentication and Account Permissions

The current application uses email/password authentication followed by phone OTP verification during onboarding. This means the application needs access to information necessary to create, authenticate, and maintain the User account.

Phone OTP verification may involve sending and receiving a verification code through the supported authentication service. Users should never share an OTP with another person or enter an OTP into an unauthorised application.

Authentication permission or access does not give Fourth Idly permission to read unrelated phone contents, contacts, messages, or other device information unless a separate feature explicitly requests and receives the relevant device permission.

10.5 NGO-Specific Data Collection

NGOs are subject to administrative verification. The current flow collects:

• Licence or registration ID.
• Licence/registration PDF uploaded by the NGO.
• NGO account status, including pending, approved/active, rejected, or blocked states.
• Information contained in the Need Requests created by the NGO, such as request type, quantity, unit, description, required-by date/time, volunteer preference, and optional pickup location.

The licence/registration PDF is stored in Firebase Storage through the current implementation and is made available for the authorised verification process. Users must submit documents only where they have lawful authority to do so.

10.6 Volunteer-Specific Data Collection

Volunteers are subject to administrative verification. The current flow collects:

• Driving licence ID.
• Driving licence PDF uploaded for verification.
• UPI ID used to generate the payment destination for Delivery Fees.
• Vehicle type, where the Volunteer chooses to provide it.
• Task, pickup, delivery, and payment-verification information generated through Volunteer activity.
• Rating information received from eligible interactions.

The driving licence information is collected for the implemented Volunteer verification process. UPI ID is collected so that the application can construct the UPI payment destination and QR/deep link for the applicable Delivery Fee.

10.7 Donor-Specific Data Collection

Donors use the common account/profile information and generate additional information through donation activity.

• Donation item type and description.
• Donation quantity and related donation information.
• Selected NGO and donation relationship.
• Donation status and delivery status.
• Delivery Fee information where applicable.
• Payment status and, where supplied for a dispute, payment reference information.
• Volunteer rating and optional feedback after payment verification.
• Donation history and related impact information displayed in the User profile.

10.8 NGO Need Request Data

When an NGO creates a Need Request, the current application may collect and store:

• Request type: Food or Product.
• Quantity.
• Unit.
• Description.
• Required-by date and time, stored as the request's liveUntil value.
• Volunteer preference: 'I have volunteer' or 'Need platform volunteer'.
• Optional pickup map pin, including pickup latitude, pickup longitude, and pickup address when the NGO chooses to provide it.
• Request status, including open, expired, or fulfilled-related states.
• Fulfilled quantity and related donation information.

Need Request information is used to show eligible open requests to Donors and to coordinate the resulting donation and delivery workflow.

10.9 Donation and Delivery Data

When a Donor makes a donation, the application creates a donation record. The current data model may contain information needed to connect the Donor, NGO, item, quantity, Volunteer assignment, delivery stages, payment state, and rating state.

• Donor and NGO identifiers.
• Item and quantity information.
• Donation status.
• Volunteer assignment or acceptance information where a platform Volunteer is used.
• Pickup and delivery state.
• Payment status and applicable Delivery Fee.
• Volunteer UPI information required for the payment screen.
• Payment verification or dispute state.
• Optional payment reference ID supplied by the Donor for dispute handling.
• Rating and feedback fields generated after eligible completion.

10.10 Location and Map Information

The current NGO Need Request flow allows an NGO to provide an optional pickup map pin. Where the NGO uses this function, the application may collect:

• Pickup latitude.
• Pickup longitude.
• Pickup address.
• Location information entered by the User in the general profile.

The current technical flow does not establish continuous background GPS tracking as part of the standard donation workflow. Accordingly, this Policy does not represent that Fourth Idly continuously tracks a Volunteer’s live location.

If a future version introduces continuous or foreground location tracking, the application should request the relevant operating-system permission at the point of need and this Policy should be updated before that feature is introduced.

10.11 Profile Photo and File Uploads

Profile photographs are optional. When a User chooses to upload one, the selected image is stored through Firebase Storage and associated with the User profile.

NGO and Volunteer verification PDFs are also uploaded to Firebase Storage. These documents are distinct from optional profile photographs and are collected for role-specific administrative verification.

Fourth Idly should not request access to a User's entire photo library merely to create an account. Where the operating system presents a file or photo picker, the User may select the specific image or document intended for upload.

10.12 Device Permissions Overview

Device permissions are controls provided by the mobile operating system. A permission is requested when a Platform feature requires access to a protected device capability. Granting a permission does not automatically mean that Fourth Idly will collect every type of information available through that capability.

Based on the current implementation, the principal permission-sensitive functions are notifications, optional map/location input, profile/document uploads, and QR image download to the device gallery.

• Notifications — Deliver donation, volunteer, delivery, payment, message, expiry, task, rating and dispute-related notifications through FCM. Optional at device level, but useful for timely workflow updates. Can be allowed or denied through device notification settings.
• Location / Map Access — Support an optional pickup map pin when the relevant location feature is used. Optional based on the feature; the current NGO pickup pin is optional. Can be denied; the User may instead provide available location/address information where supported.
• Photos / File Selection — Upload an optional profile photo and role-specific verification PDFs. Only when the User chooses to upload relevant content. Controlled through the operating system picker/permission mechanism.
• Gallery / Media Save — Save the generated Delivery Fee QR image to the device gallery when the User chooses the download action. Optional; only needed for the save-to-gallery action. User chooses whether to save the generated QR.
• Camera — No camera-based collection is established in the current technical flow. Not required by the documented current flow. Should not be requested unless a future camera feature is introduced.
• Contacts — No contact-list collection is established in the current technical flow. Not required by the documented current flow. Should not be requested unless a future feature specifically requires it.
• Microphone — No microphone-based collection is established in the current technical flow. Not required by the documented current flow. Should not be requested unless a future voice feature is introduced.

10.13 Push Notification Permission

Fourth Idly uses Firebase Cloud Messaging (FCM) for push notifications. The current implementation saves an FCM token on the User document so that relevant notifications can be delivered to the correct device/account.

Notifications may relate to:

• Donation offers.
• Volunteer acceptance.
• New chat messages.
• Post tags.
• Donation cancellations.
• Expired Need Requests.
• Delivery arrival.
• Payment pending.
• Payment verification.
• Payment verification completion.
• New Volunteer tasks.
• Urgent Volunteer tasks.
• Payment rejection or dispute status.

Push notification permission is controlled by the device operating system. If a User denies notifications, the User may not receive timely push alerts, but the in-app notification system may still contain relevant notifications when the User opens the application.

The current flow is operational/transactional rather than a documented marketing-notification system. Any future marketing notification programme should be separately disclosed and, where required, based on appropriate consent.

10.14 Location Permission and Optional Pickup Pin

Location-related access is intended to support the donation logistics workflow rather than continuous surveillance. The current Need Request screen allows the NGO to choose whether to provide a pickup map pin.

If the application requests location permission to support map selection or location services, the permission should be requested in context, with a clear explanation of why it is needed. If the User declines, Fourth Idly should not treat the denial as permission to obtain location through another unauthorised method.

The current technical specification identifies pickupLat, pickupLng, and pickupAddress as optional Need Request fields. It does not establish continuous background location collection.

10.15 Photo, Document and Storage Permission

The current Platform uses Firebase Storage for profile photographs and licence PDFs. The User initiates the upload by selecting the relevant file or photograph.

• Profile photo upload is optional.
• NGO licence/registration PDF upload is role-specific and used for verification.
• Volunteer driving licence PDF upload is role-specific and used for verification.
• Users should select only the document or image intended for the Platform.
• Fourth Idly should not use uploaded documents for unrelated purposes outside the purposes described in the Privacy Policy and applicable policies.

10.16 QR Code Generation and Gallery Access

When a Delivery Fee applies, the current Donor payment screen loads the Volunteer UPI ID and applicable fee amount, constructs a UPI URI, and generates a scannable QR code.

The current implementation provides a function to download the generated QR image to the device gallery. This is a User-initiated action and is separate from collecting the User's personal gallery contents.

Fourth Idly does not need to read unrelated photographs merely because the User chooses to save the generated QR image. The relevant operating-system media/storage behaviour will depend on the device and operating-system version.

10.17 UPI and Payment Information

Fourth Idly facilitates a Delivery Fee payment from the Donor to the Volunteer where the delivery workflow requires one. The current application uses a UPI deep link and QR code rather than a conventional in-app card or banking credential form.

The application may process:

• Volunteer UPI ID.
• Delivery Fee amount.
• UPI URI parameters required to construct the payment destination.
• Payment status.
• Payment verification state.
• Optional payment reference ID supplied for a dispute.

The current technical flow explicitly states that the application does not store UPI PINs, banking passwords, or banking OTPs. Users should never disclose such credentials to Fourth Idly, another User, or anyone claiming to represent Fourth Idly.

Processing performed by an external UPI application is governed by that provider's own terms and privacy practices.

10.18 Chat and Communication Data

The current application includes chat associated with donation and Volunteer workflows. Chat rooms and messages are stored as Platform data so that relevant participants can communicate about the donation, Volunteer acceptance, pickup, delivery, and related matters.

• Message content.
• Sender and recipient identifiers.
• Relevant chat-room or donation/task relationship.
• Message timestamps.
• Notification information generated from new messages.

Users should not use chat to share passwords, OTPs, UPI PINs, banking passwords, or unnecessary sensitive personal information.

10.19 Ratings and Feedback Data

The current Platform records ratings generated from completed donation interactions.

• Donor → Volunteer: star rating and optional text feedback.
• NGO → Donor: rating.
• NGO → Volunteer: rating where a Volunteer participated.
• Average rating and total review count may be updated on the relevant User profile.
• An Admin may view live ratings and feedback through the administrative Feedbacks page.
• Legacy app-survey feedback may also exist in the feedbacks collection.

Ratings and feedback are collected to support trust, quality, dispute review, and community accountability. They should be based on genuine Platform interactions.

10.20 Impact Posts and Community Content

Following completion, the current flow encourages or directs eligible NGOs to create an impact post. Such posts may contain text, photographs, and information describing the social impact of a completed donation.

Content submitted through impact posts is User-generated data and may be displayed through relevant Platform surfaces. Users should obtain appropriate permission before posting identifiable images or personal information concerning beneficiaries or other individuals.

10.21 Notification and In-App Activity Data

The current in-app notification system is backed by Firestore and may store information such as:

• Notification ID.
• Receiver ID.
• Sender ID and sender name where applicable.
• Notification type.
• Title and message.
• Related donation, task, post, or other item ID.
• Read/unread state.
• Creation timestamp.

Notifications are marked as read when the User taps the relevant notification according to the current implementation.

10.22 Administrative and Security Data

The Admin web panel supports User approval, rejection, blocking, donation and delivery management, dispute resolution, ratings/feedback review, notifications, audit logs, and settings.

Accordingly, Fourth Idly may maintain administrative information necessary to determine account status, review NGO/Volunteer verification, investigate payment disputes, manage donations and deliveries, protect Platform integrity, and document administrative actions.

Administrative access should be restricted according to role and operational need. Users do not receive access to internal administrative information merely because that information relates to their account.

10.23 Data Storage and Processing Services

The current technical implementation uses the following principal services:

• Firebase Authentication — email/password authentication and phone OTP verification.
• Cloud Firestore — real-time storage for Users, Need Requests, Donations, notifications, posts, feedback, and related Platform records.
• Firebase Storage — profile photographs and NGO/Volunteer verification PDFs.
• Firebase Cloud Messaging — push notification delivery and FCM device tokens.
• UPI deep links and QR generation — construction and presentation of Delivery Fee payment instructions.

The use of these services means that relevant information is processed by the applicable service infrastructure. Third-party processing is addressed in the Fourth Idly Privacy Policy.

10.24 What Fourth Idly Does Not Collect Through the Current Flow

The current technical flow does not establish collection of several categories that were present in the older Charitey policy or may commonly be associated with other applications. Unless a future feature is introduced and separately disclosed, Fourth Idly does not represent that it collects:

• Date of birth as a standard onboarding field.
• Gender as a standard onboarding field.
• Emergency contact information as a standard onboarding field.
• Google Sign-In data as part of the documented current authentication flow.
• Continuous background GPS location.
• Contact-list contents.
• Microphone recordings.
• UPI PINs.
• Banking passwords.
• Banking OTPs.
• Full device photo-library contents simply because an image is uploaded.
• Corporate affiliation, FCRA details, 80G/12A certificates, or bank account details as standard current NGO onboarding fields.

This list is intended to distinguish the current implemented flow from the broader and more generic information categories contained in the older Charitey privacy materials.

10.25 Permission Denial and Feature Availability

Users may deny an optional device permission. Denial may limit a feature that depends on that permission but should not, by itself, authorise Fourth Idly to obtain the information through an alternative method.

• If notifications are denied, timely push alerts may not appear on the device.
• If location access is denied, a map-based location feature may be unavailable or the User may need to provide the supported location/address information manually.
• If photo/file access is not granted, the User may be unable to upload a selected profile photo or verification document until the relevant file-selection mechanism is permitted.
• If gallery/media access is unavailable, saving the generated QR image may not work; this does not affect the underlying UPI payment information itself.

10.26 Permission Changes

Users can generally review or change application permissions through their device settings. The exact menu names and controls vary by Android version, device manufacturer, and operating-system configuration.

Changing a permission does not necessarily delete information that was previously provided to Fourth Idly. Data deletion is governed by the Fourth Idly Data Deletion Policy and applicable privacy rights.

Where a permission is no longer necessary for a feature, Fourth Idly should not continue requesting it solely because it was previously granted.

10.27 Data Minimisation

Fourth Idly is designed around a defined donation and delivery workflow. The Platform should collect only the information reasonably necessary to provide the relevant function, maintain account security, coordinate donations, support delivery, verify role-specific accounts, process Delivery Fee verification, provide notifications, support ratings, resolve disputes, and comply with applicable obligations.

Optional information should remain optional unless a legitimate Platform function requires it. A User should not be required to provide unrelated personal information merely to access a feature that does not need it.

10.28 Consent and User Choice

Where the Platform requests a device permission, the User makes the permission decision through the operating system. Where information is optional and entered directly by the User, the User may choose whether to provide it unless it is required for the relevant feature or legal obligation.

Where processing depends on consent, the applicable consent mechanism should clearly identify the purpose of the processing. Withdrawal of consent should not affect the lawfulness of processing that occurred before withdrawal.

10.29 Children and Age-Related Use

The current Fourth Idly policy framework should define the minimum age and any applicable parental or guardian requirements consistently across the Terms and Conditions, Privacy Policy, and this Policy. The current technical flow document does not specify an age field in onboarding.

Until the final legal position is confirmed, Fourth Idly should not request a date of birth merely because an older policy contained one. Any age verification mechanism introduced later should be separately documented and implemented only where necessary.

10.30 Security and Permission Protection

Permissions and collected data should be protected through the security controls applicable to the Platform and its infrastructure. Access to verification documents, payment-dispute information, account records, and administrative data should be limited to authorised functions.

• Authentication is handled through Firebase Authentication.
• Verification PDFs and profile photographs are stored through Firebase Storage.
• Application records are stored through Cloud Firestore with appropriate access controls.
• FCM tokens are used for notification routing and should not be treated as general device-identification data.
• Sensitive banking credentials such as UPI PINs, banking passwords, and OTPs are not stored by the current application flow.

10.31 Retention and Deletion

Data collected through permissions or Platform features is subject to the retention principles described in the Fourth Idly Privacy Policy and Data Deletion Policy.

Deleting a permission from the device is not the same as deleting data already stored by Fourth Idly. Users who want stored personal data deleted should use the applicable account/data deletion process.

Certain records may be retained where necessary for unresolved disputes, fraud prevention, security, administrative accountability, legal obligations, or the integrity of transaction records, as described in the Data Deletion Policy.

10.32 Changes to the Data Collection and Permission Policy

Fourth Idly may update this Policy when the application introduces a new permission-sensitive feature, changes its authentication or storage architecture, adds new categories of personal data, changes notification functionality, or becomes subject to new legal or platform requirements.

Material changes should be reflected in the application permission prompts and the Privacy Policy so that Users are not asked to grant permissions for purposes that are not clearly disclosed.

10.33 Contact and Privacy Enquiries

Questions concerning data collection, device permissions, personal information, or privacy should be directed to the official Fourth Idly privacy/support contact details published through the Platform.

The final official Fourth Idly privacy and grievance email addresses should be inserted here once confirmed. Legacy Charitey contact addresses have intentionally not been carried over.

10.34 Summary of Current Permission Position

For clarity, the current Fourth Idly application is primarily a donation logistics platform. Its core data collection is account information, role-specific verification information, donation and Need Request information, delivery and payment-verification information, notifications, ratings/feedback, chat, and optional community/impact content.

The current documented permission-sensitive functions are push notifications, optional map/location selection, user-initiated image/document upload, and saving a generated payment QR image to the device gallery. Camera, microphone, contact-list access, and continuous background location are not established by the current technical flow and should not be presented as current required permissions without a corresponding product change.