ID Secure Hub

Introduction

ID Secure Hub is the Android institute administration application identified by package name com.idsecurehub.app. It is designed for authorized institute personnel to manage student and staff records, ID card workflows, award distributions, design approvals, card controls, photo capture, and order tracking through the ID Secure Hub ERP.

This policy explains, in plain language, what the Android app and its online service collect, why each item is needed, when it is used, how it is protected, and what choices are available. Precise foreground location is a required institute-security condition: if it is denied, the app cannot complete sign-in or open protected institute features. The registered educational institute is responsible for giving any additional notices and obtaining any consents required for student, staff, guardian, and location data processed through its account.

Data Collected and Purpose

1. Institute account and authentication data

• Collected: Institute email, password submitted for authentication, session token, session expiry, institute name, branch ID, vendor ID, contact details, address, and institute logo.
• Purpose: To authenticate authorized institute personnel, create a time-limited session, select the correct branch and vendor data, display the institute profile, and protect records from cross-institute access.
• Local handling: The app stores the session token and required institute profile locally so the signed-in shell can reopen. It does not display or store the password after login.

2. Device identity, app, and operating-system data

• Collected at login and explicit app activity events: An app-specific device identifier supplied by Android or created for this app, manufacturer/brand, model, operating-system name and version, app version name, app build/version code, and a readable device summary.
• Collected by the API: Source IP address, request time, authenticated session ID, branch/vendor association, and server request metadata needed for audit and abuse prevention.
• Purpose: To identify the signed-in device, detect unauthorized or unusual access, bind activity to the correct institute session, support troubleshooting, show the installed build, and allow institute administrators to review or block a device.
• The app does not intentionally send an empty or placeholder device identity such as unknown. The API rejects incomplete device fingerprints rather than substituting an IP-based or user-agent-based device identity.

3. Precise foreground location for institute security

• Collected: Precise latitude, longitude, location accuracy, device location timestamp, the precise-permission marker, and the authenticated session/device association.
• When: Before sign-in, Android must grant the Precise option and the device Location setting must be on. At each successful institute login, the app obtains one current foreground location reading and sends it together with the login and device details. If an upgraded or older session needs server-side verification again, the app keeps the session but asks for one fresh foreground reading before protected records load. If the user revokes precise location or turns off device Location, the app is locked until access is restored and the security verification succeeds.
• Purpose: To record the location context of the authenticated branch session, support institute security auditing, investigate suspicious access, and enable authorized administrators to review or block device activity under their security rules. The current service validates and records the reading; it does not claim that a configured map boundary has been checked.
• Limits: The app checks Precise permission and the device Location setting when opened or brought back to the foreground, but it does not request background location and does not continuously track location. Approximate/coarse-only location is not accepted for the security check and is not recorded as a successful precise verification.

4. Student, staff, and guardian records

• Collected: Names, guardian names, admission/reference numbers, class and section, gender, date of birth, blood group, contact numbers, addresses, Aadhaar or other institute-defined identifiers, status fields, and custom fields entered by authorized institute users.
• Purpose: To maintain the institute database, prepare official ID cards, manage student/staff status, support class and designation workflows, and provide authorized administrative reports.

5. Awards and academic records

• Collected: Student identity, class information, marks or scores, rank, award criteria, award status, and related institutional fields.
• Purpose: To prepare award and certificate records and manage the institute award workflow.

6. Photos, camera captures, and design files

• Collected: Photos of students, staff, guardians, or awards captured after the user starts a capture flow, photos selected through the Android content picker, and ID-card design approval files.
• Purpose: To place approved images on official ID cards, let the authorized user crop and prepare them, upload them to the institute account, and review design artwork before printing. The Android app does not perform face detection or face analysis.
• Limits: Camera access is not used in the background. Temporary previews and app caches may exist locally while an upload or review is in progress.

7. App activity, session, and security audit data

• Collected: Login, logout, app open, foreground, background, location verification, forced logout, API activity, session timestamps, device fingerprint, app build, IP address, and security status.
• Purpose: To maintain session security, audit institute access, update the latest device state, support authorized force logout or device blocking, and investigate errors or abuse.

8. Google Play update status

• The Play-installed release checks Google Play through the Play Core update service whenever the app opens or returns to the foreground. The initial launch check completes before the app enters its protected screens. When an already-open screen repeats the check, it remains responsive while Play responds; if a strictly newer eligible version is available, the app immediately blocks use and starts a Google Play update. The update must finish before protected features continue; returning without updating causes the check to run again.
• If Google Play cannot verify the installed version, the app remains locked until the user retries or opens Google Play. This check is used only to keep security fixes and required behavior current. The app does not use the ERP PHP API to decide whether an update exists.

Android Permissions and Their Purposes

ID Secure Hub asks only for access needed for the features described below. The explanations here use everyday language so users can make an informed choice. Access is used only for the stated purpose.

Other access: The app does not ask for background location, contacts, microphone, SMS, phone-call access, or broad file-storage access. When a user chooses an existing image, Android's standard photo/file chooser is used so the app can receive only the selected item.

Data Sharing and Security Infrastructure

Who receives the data

Institutional data is never sold and is not used for advertising or advertising profiles. Data is shared only where needed to operate or secure the service:

• The ID Secure Hub online service, database, and hosting infrastructure used to authenticate users, store institute records, receive device/security events, receive the current precise location at login or re-verification, and provide application functions.
• Fast2SMS, when enabled by the ERP workflow, only for OTP delivery during design approval verification.
• Google Play services for Play Store availability and update status when the release was installed through Google Play. The update button opens only the Google Play listing for ID Secure Hub.
• The registered institute's authorized administrators, limited to the institute data and security activity they are permitted to access.

Security Protocols

• HTTPS/TLS is used for Android app communication with the production API. Users should avoid using modified or untrusted app builds.
• Bearer token authentication governing all protected endpoints.
• Automated session expiration (maximum 30 days) combined with comprehensive server-side activity logging.
• Device activity records use an app-specific device identifier and the reported model, brand, operating system, app version, and build. The service rejects missing, placeholder, or mismatched device details and does not replace them with an unknown device or an IP address.
• A login is accepted only when the current precise foreground location has valid coordinates, a usable accuracy value, a current device timestamp, and the precise-location permission indicator.
• Immutable read-only protection applied to all printed or issued records.
• Cryptographic hashing of OTPs with strict 5-minute expiration windows.

Data Retention and Removal

• System logout clears the app's local session and temporary cache. Server-side authentication, device, audit, and location records are not automatically erased by a local logout.
• Login sessions expire after a maximum of 30 days unless they are logged out or otherwise invalidated.
• The device activity history retains the latest 200 activity events for a device record. Location data is retained with the related security/audit history while needed by the institute and service for security, support, legal, or operational purposes.
• Records (student, staff, awards) may only be deleted if they remain unlocked and unprinted. Once printed, records become read-only to ensure the integrity of issued IDs.
• Authorized institute users may remove eligible business records through the application interface. Account, audit, device, or location deletion requests must be submitted by an authorized institute representative to the contact below and may be limited by legal, fraud-prevention, or record-integrity obligations.

User Choices and Institutional Control

• Precise location: This is required before sign-in and remains a condition for protected institute use. A user may deny it or disable it in Android settings, but the app will not complete sign-in or open the protected dashboard until precise foreground location is enabled and the security check succeeds.
• Camera: This is optional for the photo features. Denying camera access does not prevent the user from using features that do not require a camera capture.
• Logout: Users can log out from the app. This removes the local session and cache; it does not by itself delete records already sent to the ERP.
• Privacy policy: A link to this public policy is available on the sign-in screen so users can review the permissions and data practices before signing in.
• Access, correction, or deletion: Requests should be made by an authorized representative of the registered institute. The institute controls the accuracy and lawful use of its student, staff, guardian, photo, and location records.
• Account termination: Contact the developer using the details below. We may need to verify the institute representative and retain limited records where required for security, legal compliance, fraud prevention, or issued-record integrity.

Minors and Institutional Data Governance

While ID Secure Hub processes records pertaining to minors, the application is strictly provisioned for use by authorized adult personnel representing the educational institute. It is not designed for, nor made accessible to, children.

The registered educational institution retains sole responsibility for securing the necessary parental consents, permissions, and lawful bases required to collect, digitize, and manage student information, including photographs and contact data, within their jurisdiction.

Terms of Use

Accessing and utilizing ID Secure Hub constitutes agreement to the following binding terms:

1. Access is strictly limited to authorized personnel of the registered educational institute.
2. Users are mandated to maintain the absolute confidentiality of their login credentials and session tokens.
3. The application must be utilized solely for lawful institutional administration.
4. Users shall not upload, manipulate, or manage records without explicit authorization from the institute's governing body.
5. Cross-institutional data access, modification, or exportation is strictly prohibited.
6. Users shall not attempt to circumvent security controls or read-only record protections.
7. Users bear full responsibility for the factual accuracy of the data entered into the system.
8. The platform shall not be used to facilitate harassment, fraud, data theft, or any illegal acts.
9. Result Hosting™ reserves the right to immediately suspend or permanently revoke access upon detection of abuse, security threats, or terms violation.
10. Operational continuity may depend on third-party hosting and communication gateways, which are subject to occasional service interruptions.
11. The application is provided strictly on an "as is" basis, without guarantees of uninterrupted or error-free operation.
12. To the maximum extent permitted by applicable law, the developer accepts no liability for data loss, operational disruption, or damages stemming from unauthorized access, misuse, or third-party service outages.