E2E School

1. Introduction

This Privacy Policy explains how information is handled in E2E School, the Android application published for E2E School (demonstration portal) and used together with the institution's learning management portal at https://e2eschooldemo.solveetech.com.

E2E School is one of several institution-specific applications built from a single shared codebase. The way the application handles information is therefore the same across those applications; what differs is which institution the application belongs to and which portal and server it connects to. This page describes the application as published for E2E School.

This is a demonstration and evaluation portal operated by the platform provider rather than a live institution.

2. Scope

This policy covers:

• the E2E School Android application (package com.e2ecollegeapp);
• information the application sends to, and receives from, the institution's learning management server at testingportal.solveetech.com.

This policy does not cover:

• the institution's web portal at https://e2eschooldemo.solveetech.com, or any other system the institution operates, except where this page says otherwise;
• third-party applications on the user's device that the application may hand a file or a web link to — for example the browser, PDF viewer or video application the device opens when a user taps an attachment or a lecturer's video link. Those applications are governed by their own privacy policies;
• the device operating system and the app store the application was installed from.

3. Information We Collect

The application is an interface to the institution's existing learning management system. Almost all personal information it displays was already held by the institution; the application requests it, shows it, and sends back the entries a user makes.

It is useful to distinguish four things:

• Information the user enters into the application and the application sends to the institution's server.
• Information the application receives from the institution's server in order to display it.
• Information stored on the device so the application works between launches and when the connection drops.
• Information the application does not handle at all, listed explicitly in the table below, because absence of collection is as important to state as collection.

What the application does not collect

The following were checked against the application's source code, dependency list and compiled Android permissions. None is present in any build produced from this codebase:

• No location data of any kind, precise or approximate.
• No access to contacts, the address book, call logs or SMS.
• No camera access and no microphone or audio recording.
• No Bluetooth access.
• No advertising identifier, no advertising SDK and no advertisements.
• No analytics SDK, no behavioural tracking and no usage profiling.
• No crash-reporting or performance-monitoring SDK.
• No device identifier is read or transmitted — the application does not collect an Android ID, IMEI, MAC address or similar hardware identifier.
• No health, fitness or biometric data. The application never presents a fingerprint or face prompt.
• No payment card details, bank details or any in-app payment. The application contains no payment gateway or billing component.
• No social-media or third-party sign-in. Sign-in is by email address and password against the institution's own server only.

The application also has no sign-up screen. Accounts are created by the institution; a user cannot register themselves through the application.

4. Account Information

When a user signs in, the application sends to the institution's server:

• the email address entered on the sign-in screen;
• the password entered on the sign-in screen;
• the institution code for this application (e2eschool), which tells the server which institution the application belongs to.

The password is sent only to authenticate the user. It is not stored on the device, in the application, or in the application's local cache.

If authentication succeeds, the server returns, and the application stores on the device:

• a session token that identifies the signed-in user on later requests;
• the user's name, email address, user identifier and role (student, parent, teacher or administrator).

The application also lets a user change their own password and request a password reset by email. Both send the relevant details to the institution's server; the reset email is sent by the institution's system, not by the application.

5. Student and Academic Information

Depending on the signed-in user's role and what the institution has recorded, the application may display and — where the user is permitted to edit it — send back the following. This information originates in the institution's learning management system.

• Student identity and enrolment: full name, roll number, student code, registration number, university roll number, programme or course, semester, department, section, intake, enrolment status, and profile photograph.
• Contact details held on the student record: email address, address lines, and the parent or guardian's name, mobile number and email address.
• Attendance: per-subject and per-date attendance records, presence and absence counts and attendance reports.
• Assignments: assignment details and deadlines, submitted work including uploaded files, submission and resubmission history, marks awarded and teacher feedback.
• Quizzes and online examinations: questions, the answers a student submits, attempt history, time taken, scores and pass or fail status.
• Results and academic records: marks per subject, grade point averages, percentages, remarks, mark sheets, transcripts and overall or per-semester progress.
• Subject content and participation: subject plans, chapters, learning resources, and posts and replies a user writes in subject discussions.
• Timetable: class routines and routine attachments.
• Library records: books issued and returned, due dates and any fines recorded.
• Extra-curricular records: activities, categories, trainers, organisers and related documents.
• Teacher comments recorded on a student's record.
• Fee and scholarship information: amounts payable, paid and outstanding, fee lines, instalments, scholarship entries and payment history (date, payment mode and balance).

Fee information is displayed only. The application contains no payment gateway, card entry, checkout or in-app purchase. No payment instrument details are collected or transmitted by the application.

6. Teacher, Staff and Parent Information

Teachers and staff. For a signed-in staff user, and for staff records an administrator is permitted to view or edit, the application may display and send back: name, email address, phone number, address, department, assigned programmes, subjects and semesters, role, profile photograph, and leave requests (type, dates and reason). Staff may also submit internal purchase requests to the institution, which include the items and amounts requested; these are institutional procurement records rather than a financial service offered to the user.

Teaching activity. Where a staff user teaches, the application sends the work they do in it: subject plans and chapters they publish, learning resources and files they upload, quizzes and question banks they author, assignments they set, attendance they record, marks and feedback they enter, and discussion posts and replies they write.

Parents. A signed-in parent sees the records of the children linked to their account by the institution: each child's profile, attendance, assignments, results and online examination results. The application does not ask a parent to supply information about a child; the link between parent and child is established in the institution's system, not in the application.

What any given user can see is decided by the institution's server according to the role and permissions it has issued, not by the application.

7. Device and Technical Information

The application reads very little about the device, and transmits none of it as a user identifier.

• Network connectivity state. The application checks whether the device currently has a usable internet connection, so that it can show cached content instead of failing when the connection is down. This is read on the device and is not sent anywhere.
• Operating system. The application checks whether it is running on Android or iOS in order to lay screens out correctly. This is not transmitted.
• Files the user chooses. When a user attaches a file, the application reads that file, and its name and size, from the device. Nothing else on the device's storage is read.

As with any internet service, the institution's server necessarily receives the technical details that accompany a network request, such as the device's IP address and the standard request headers, and may record them in its own server logs. That logging happens on the server, not in the application. What the institution's server logs, and for how long: [NEEDS HUMAN CONFIRMATION]

The application itself contains no crash-reporting, diagnostics or performance-monitoring component, and writes no diagnostic log of its own. If the application stops unexpectedly, no crash report is sent by the application. Google Play may separately collect crash information from Android devices under Google's own terms, independently of this application.

8. Push Notifications

E2E School does not send push notifications.

The application contains no push-notification service, no Firebase Cloud Messaging or equivalent messaging component, and no notification permission. It does not generate, request or store a device push token, and no push token is transmitted to the institution or to any third party.

Deadlines and other time-sensitive items are shown inside the application when the user opens it. Any notification a user receives by email or SMS comes from the institution's own systems, not from this application.

9. How We Use Information

Information handled through the application is used to:

• authenticate the user and maintain their signed-in session;
• determine which role the user has and therefore which screens and records they may access;
• display the user's academic, attendance, assessment, timetable, library and fee records held by the institution;
• carry the user's own entries — assignment submissions, quiz answers, discussion posts, attendance marking, grading, leave and purchase requests — to the institution's system;
• keep recently viewed content on the device so the application starts quickly and remains usable when the connection is poor;
• apply the user's own display preferences, such as theme and layout.

Information is not used for advertising, for profiling, for behavioural analytics, or for any purpose unrelated to the institution's educational administration. The application contains no component capable of doing so.

10. How Information Is Shared

From the application's side, information travels to exactly one destination: the institution's learning management server at testingportal.solveetech.com. The application contains no other network client, no analytics endpoint, no advertising endpoint and no third-party data collection SDK. This is verifiable in the application's code.

Within that system, information is visible to:

• the user themselves, for their own records;
• the institution's teaching staff and administrators, according to the permissions the institution grants them — for example, a teacher sees the submissions, attendance and marks of the students in their subjects;
• a linked parent or guardian, for the children the institution has linked to their account;
• other participants in a subject discussion, for posts and replies written there.

Two further cases involve the device rather than the network. When a user taps an attachment or a lecturer's video link, the application hands that link to another application on the device — typically the browser or a video application — which then loads it under its own privacy policy. When a user exports a mark sheet, the file is written to the application's own storage area and opened with whichever application the user chooses.

Whether E2E School or the platform provider discloses information held in the learning management system to any other party — for example a university, an examination board, a government body, or a contracted service provider — and on what legal basis: [NEEDS HUMAN CONFIRMATION]

11. Third-Party Services

The application integrates no third-party data-collection or data-processing service. Specifically, and contrary to what is common in mobile applications, the following are not present in any build produced from this codebase:

• No Firebase Cloud Messaging.
• No Firebase Analytics or Google Analytics.
• No Firebase Crashlytics or any other crash-reporting service.
• No Firebase Performance Monitoring.
• No Google Play services SDK integration, and no Google Mobile Ads.
• No Sentry, Bugsnag, App Center or comparable error-reporting service.
• No OneSignal or any other push-notification provider.
• No Mixpanel, Amplitude, Segment or comparable analytics provider.
• No payment provider or payment gateway.
• No third-party cloud storage provider, authentication provider or social-media SDK.

The only services the application depends on are the institution's own learning management server, and the operating system and app store of the device it is installed on.

The libraries the application is built from — for navigation, form handling, date formatting, icons, file selection and PDF generation — run entirely on the device and send nothing anywhere.

Whether the institution's learning management server is operated on the institution's own infrastructure or by a hosting provider, and the identity of that provider: [NEEDS HUMAN CONFIRMATION]

12. Data Storage

On the device

The application stores the following on the device it is installed on:

• The session token, in the Android system keystore (the operating system's protected credential store), not in ordinary application storage.
• Basic profile details of the signed-in user — name, email address, user identifier and role — in the application's private storage.
• A cache of recently loaded content, so screens the user has already opened appear immediately on the next launch and remain readable when the connection drops. Cached content older than 24 hours is discarded when the application starts.
• Display preferences: theme, accent colour and list or grid layout.
• Exported mark sheets, when the user chooses to export one, in the application's own document folder.

The cache is tied to the institution and to the account that created it. If a different account signs in on the same device, the previous account's cached content is erased before any screen is shown. Signing out erases the session token, the stored profile details and the cache.

Android's automatic application backup is disabled for this application, so its stored data is not copied into a device backup or to a cloud backup account.

On the server

All records described in sections 4 to 6 are held in the institution's learning management system. The location of that server and of any backups of it: [NEEDS HUMAN CONFIRMATION]

13. Data Security

Measures verified in the application:

• Encryption in transit. All communication with the institution's server uses HTTPS. Unencrypted (cleartext) network traffic is disabled at the operating-system level in every released build, so the application cannot fall back to an unencrypted connection.
• Protected credential storage. The session token is held in the Android system keystore rather than ordinary application storage.
• No stored password. The password is used to sign in and is never written to the device.
• Session invalidation. If the server rejects the session, the application immediately erases the stored token so it cannot be reused.
• Backup disabled. Application data is excluded from Android system backups.
• Account separation on shared devices. Cached content belonging to a previous account is erased before a new account's screens are shown.
• Release hardening. Released builds are code-shrunk and obfuscated, and are signed with a private upload key.

This application does not use end-to-end encryption. Information is encrypted between the device and the institution's server, and the institution's system can read it — which is necessary, since the institution is the party that maintains these records.

No system can be guaranteed completely secure. The security measures applied to the institution's server and database, and the institution's procedure in the event of a data breach: [NEEDS HUMAN CONFIRMATION]

14. Data Retention

On the device, retention is determined by the application and is as follows:

• Cached content is discarded once it is more than 24 hours old, and is erased entirely on sign-out or when a different account signs in.
• The session token and stored profile details persist until the user signs out, the server rejects the session, or the application is uninstalled.
• Uninstalling the application removes everything it has stored on the device.

On the server, academic records are retained by the institution under its own records policy. The application neither sets nor enforces any retention period for them. The retention periods E2E School applies to student, staff and parent records: [NEEDS HUMAN CONFIRMATION]

15. Account and Data Deletion

The application provides no in-app account deletion. Accounts are created and removed by the institution.

A user can, using the application alone:

• sign out, which erases the session token, the stored profile details and all cached content from the device;
• uninstall the application, which removes everything it has stored on the device.

Neither of those removes records held in the institution's learning management system. To request deletion of those records, a user must contact E2E School using the details in section 20.

Whether E2E School will delete a user's records on request, which records can be deleted, which must be retained as an academic record and on what legal basis, the procedure for making such a request and the time taken to respond: [NEEDS HUMAN CONFIRMATION]

This section must be completed before the Google Play data-deletion declaration for this application can be answered accurately.

16. Children's Privacy

E2E School is intended for the enrolled students, parents, teaching staff and administrators of E2E School. The application has no sign-up screen: it can only be used with credentials the institution has already issued.

The application shows no advertising, contains no advertising identifier, and performs no analytics or behavioural profiling. This is verified in the application's code and permissions.

Whether any student whose information is processed through this portal is under the age of 13, and the consent basis that applies to them: [NEEDS HUMAN CONFIRMATION]

17. Cookies and Similar Technologies

The mobile application uses no cookies, no web tracking pixels, no web beacons and no embedded browser view. It contains no WebView component, so no web page is rendered inside the application and no site can set a cookie through it.

The application does store the small set of items listed in section 12 in its own private storage on the device. These serve the same practical purpose as a cookie — keeping the user signed in and remembering their preferences — but are readable only by this application and are not shared with any website or third party.

When a user taps an attachment or a video link, the device opens it in a separate browser or application, which may set cookies of its own under its own policy.

Whether the institution's web portal at https://e2eschooldemo.solveetech.com uses cookies is a matter for that portal's own privacy notice and is outside the scope of this page.

18. User Privacy Requests

Because the records shown in the application are the institution's, requests about them should be made to E2E School using the details in section 20. Such a request might be to:

• obtain a copy of the information held about the user;
• correct information that is inaccurate — for example a wrong contact detail, attendance entry or mark;
• ask for information to be deleted, subject to section 15;
• ask how a particular record is used or who can see it.

The privacy rights available to users of this application, the law under which they arise, the procedure for exercising them, the response time E2E School undertakes to meet, and the route for escalating a complaint: [NEEDS HUMAN CONFIRMATION]

This page does not assert compliance with the GDPR, with COPPA, or with any other specific privacy regime. Whether and how those regimes apply to E2E School is a legal question that has not been determined here.

19. Changes to This Privacy Policy

This policy may be updated when the application changes or when the institution's practices change. The revised version is published on this page and the “Last updated” date at the top is amended.

Where a change materially affects how personal information is handled, E2E School will make users aware of it. The method and notice period used for that: [NEEDS HUMAN CONFIRMATION]

Continued use of the application after an update indicates acceptance of the revised policy.

20. Contact Information

For questions about this policy, about the information E2E School holds, or to make a privacy request:

Institution

E2E School (demonstration portal)

Portal

https://e2eschooldemo.solveetech.com

Application

E2E School (Android package com.e2ecollegeapp)

Privacy contact email

[NEEDS HUMAN CONFIRMATION]

Telephone

[NEEDS HUMAN CONFIRMATION]

Postal address

[NEEDS HUMAN CONFIRMATION]

Data protection or privacy officer

[NEEDS HUMAN CONFIRMATION]

A contact email address is mandatory for a Google Play listing. This page must not be published until the contact details above are filled in with a monitored address.

21. Developer and Service Provider Information

E2E School is developed and published by the provider of the E2E learning management platform, and is one of several institution-specific applications built from a single shared codebase. The application's Android signing certificate identifies the publisher as SolveeTech, and the platform's servers are operated under the solveetech.com domain.

The platform provider acts on the institution's behalf in respect of the records held in the learning management system. The institution decides what is recorded, who may see it and how long it is kept.

Platform

E2E Learning Management System

Application server for this institution

testingportal.solveetech.com

Registered legal name of the developer

[NEEDS HUMAN CONFIRMATION]

Registered address of the developer

[NEEDS HUMAN CONFIRMATION]

Developer support or privacy email

[NEEDS HUMAN CONFIRMATION]

Data processing agreement between the developer and the institution

[NEEDS HUMAN CONFIRMATION]