Privacy policy

Effective 1 October 2026

AUS Classroom Manager is an internal tool operated by Alarab University Support (“AUS”, “the centre”) in North Lebanon. Teachers at the centre use it to upload course media and publish it to the centre’s Google Classroom classes, so that they never have to be given the centre’s Google account password.

It is not a public product. Accounts are created by a centre administrator for the centre’s own staff. Students do not have accounts: a student may be sent a personal link to the student library, which lets them watch and download the material of the courses they are enrolled in and nothing else. The centre keeps a register of which students are enrolled in its classes, described under Student data below.

Google account data we access

There are two entirely separate Google authorizations, and they grant very different things.

1. The centre’s Google account. Authorized once by an administrator. This is the account that owns the media library and posts to Classroom. We request:

• drive.file — permission to create and manage only the files and folders this application itself creates in the centre’s Google Drive. It gives us no ability to see, open or list anything else in that Drive.
• classroom.courses — to list the classes the centre account teaches, so a course can be linked to a class.
• classroom.announcements, classroom.courseworkmaterials, classroom.coursework.students — to create announcements, materials and assignments on the centre’s behalf.
• classroom.rosters.readonly — to read the list of students enrolled in the classes the centre teaches, and the list of teachers of those classes.
• classroom.profile.emails — so that each person in a roster has an email address. This is also how the centre’s own teachers are recognised within a roster and left out of the student register.
• classroom.rosters — used only to send a student an email invitation to a class. When the centre moves to a new Google account, the students of each old class are invited to the class that replaces it. The application never adds anybody to a class or removes them: the student decides whether to accept.
• openid, email, profile — so an administrator can see which Google account is connected.

2. A teacher signing in with Google. Optional, and identity only: openid, email and profile. This tells us a teacher’s name, email address and profile picture so we can recognise their account. It grants us no access to that teacher’s Drive, Gmail, Calendar or Classroom.

What we deliberately do not request

We request no scope covering student work. There is no classroom.student-submissions scope and no classroom.coursework.me, so this application cannot read a student’s submissions, grades or coursework, and never does. We request no classroom.profile.photos, so a student’s photograph is never fetched — the lists in the application draw initials instead. We request no Drive scope beyond drive.file, so nothing in the centre’s Google Drive that this application did not itself create is visible to it. Roster access is limited to reading class lists and sending invitations: the application never adds anybody to a class or removes them from one.

Student data

For each Google Classroom class the centre teaches, the application reads the class roster and keeps a record of every enrolled student: their name, their email address, the identifier Google uses for their account, and which of the centre’s classes they are in. Nothing else about a student is read from Google.

It serves one purpose — so that the centre has an accurate register of who is enrolled in which class, and can account for tuition against it. It is not used for anything else, and it is never sold, shared or transferred.

Alongside what Google provides, the centre records its own administrative details against a student: a telephone number and notes if staff enter them, the fee agreed for each class, and each payment received against that fee. These are entered by the centre’s administrators and are never read from Google. See Financial records below.

Teachers are not students. A teacher appears in the roster of their own class at Google, so every roster is checked against the centre’s staff accounts and the centre’s own Google account, matched by email address, and anybody recognised is left out of the student register rather than recorded in it.

Access is restricted inside the application. An administrator can see every student. A teacher can see only the students enrolled in the classes attached to the courses they are assigned to teach, and nothing beyond that.

Where Google Classroom cannot supply a student, an administrator may enter the student’s name, email address and telephone number by hand. Once Google can supply that student again, the two records are matched by email address rather than kept twice.

The student library keeps copies of lesson videos and files with Cloudflare R2, a storage service, in a private store that nobody can read without an address the application signs for one student and one file, and which expires within hours. A link opens on at most two browsers. When a student opens it, the application records a session for that browser — the date, the network address, the browser’s description and when it was last used — which an administrator can see and end, and which is kept until staff sign that browser out, the student signs out, or the link is replaced or revoked. An attempt to open the link on a further browser is refused, and recorded with that browser’s network address and description. It records nothing about what students watch.

A student who leaves a class is marked as having left rather than deleted, so the centre’s record of who was enrolled when stays accurate. A record can be removed entirely on request — see How long we keep it below.

Financial records

The centre charges a fee per student per course and divides the income between the people who run it and the teachers of each course. The application keeps the records that requires: the price of each course, the fee agreed with each student for each class, every payment received against those fees, and how each payment was divided.

None of this comes from Google, and none of it is payment-card data. No card number, bank detail or payment credential is ever entered into, processed by or stored in this application; a payment record is a note that the centre received a given amount on a given day, written down after the fact.

A payment is never edited or deleted once recorded. A mistake is corrected by marking the payment void, with a reason and the person who marked it, and recording the correct one — so the centre’s own history of what it believed it had received stays intact and auditable.

Access is restricted more tightly here than anywhere else in the application. Only administrators can see or record a fee or a payment, or see what any individual student has paid. A teacher can see what they themselves have earned and nothing further — not what a course took, not what any student paid, and not what anyone else earns.

What we store, and where

• Staff accounts — name, email address, role, and a password hash (Argon2id; we never store the password itself). If Google sign-in is used, the Google account identifier and profile picture URL.
• Course structure — universities, categories, courses, lessons, and which teachers are assigned to them.
• Media records — filename, size, type, checksum, duration and the Google Drive file identifier. The uploaded videos and documents themselves are stored in the centre’s Google Drive, not on our server.
• Classroom post records — title, description, which files were attached, and the identifier Google returned.
• Student records — name, email address, the Google account identifier, and which of the centre’s classes the student is enrolled in, together with any phone number or note the centre adds itself. See Student data above.
• Financial records — the price of each course, the fee agreed with each student for each class, each payment the centre has received against those fees, and how each payment was divided between the centre and its teachers. No card or bank detail. See Financial records above.
• An audit log — which staff member did what and when, including the IP address of the request. We use it to investigate problems and to rate-limit sign-in attempts.
• The centre’s Google authorization — held as AES-256-GCM encrypted ciphertext. It is never returned by any part of the interface and never written to a log.

Everything above is held in a private database on a server controlled by the centre, reachable only over an encrypted (HTTPS) connection.

How we use it

Solely to provide the service described at the top of this page: authenticating staff, organising course material, uploading it to the centre’s Google Drive, and publishing it to the centre’s Google Classroom classes. Nothing else.

Sharing

We do not sell, rent or trade any data. We do not share it with third parties. The only external services involved are Google’s own APIs — Drive and Classroom — which is the entire point of the application, and the hosting provider running the server. There is no advertising, analytics or tracking of any kind in this application.

Limited use of Google user data

AUS Classroom Manager’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically, data obtained through Google APIs is never used for advertising, never sold or transferred to data brokers or information resellers, never used to determine creditworthiness, and never used to train generalised artificial intelligence or machine learning models. Humans do not read it except where required for security, to resolve a fault the user has reported, or where the law requires it.

How we protect it

• All traffic is encrypted in transit with HTTPS.
• Google authorization tokens and upload session addresses are encrypted at rest with AES-256-GCM.
• Passwords are stored only as Argon2id hashes.
• Access is limited by role: a teacher can reach only the courses assigned to them, and only the students enrolled in the classes attached to those courses.
• Every change of consequence is written to an audit log.

How long we keep it, and how to have it removed

Records are kept for as long as the centre uses the system. A staff member who leaves can have their account removed by an administrator; their name is then detached from the records they created, which are retained because they describe material that is still published in Classroom.

Student records are kept for as long as the student is enrolled with the centre, and thereafter for as long as the centre must be able to account for their tuition. A student who leaves a class is marked as having left rather than deleted, so the record of who was enrolled when stays accurate; a record can be removed entirely on request.

Fee and payment records are kept for as long as the centre must be able to account for its income, which outlasts the enrolment they belong to. While a payment is recorded against a student, the student’s record cannot be deleted — the payment would otherwise refer to nobody. A request to remove a student who has paid is therefore handled by the centre directly, so that the accounting record and the personal one are dealt with deliberately rather than together.

An administrator can disconnect the centre’s Google account at any time from within the application, which deletes the stored authorization immediately. The centre can also revoke this application’s access at myaccount.google.com/permissions.

To request a copy of your data or its deletion, write to alarabunisupport2@gmail.com. Note that files already published to Google Classroom cannot be withdrawn through this application — the Google Classroom API provides no way to delete a post once it has been created — and must be removed in Google Classroom itself.

Children

This application is used only by the centre’s teachers and administrators. Students have no accounts and cannot sign in. The centre supports university students, so the people named in its class registers are adults. As set out under Student data and Financial records, the student information held is a name, an email address, a Google account identifier, class membership, any telephone number or note the centre records, and what the centre has charged and received in tuition; no submission, grade or photograph is ever read, and no payment-card or bank detail is ever held. A student, or a parent or guardian, may write to the address below to ask what is held about them or to have it removed.

Changes

If this policy changes materially, the effective date above changes with it and the centre’s staff are notified.

Contact

Alarab University Support, North Lebanon — alarabunisupport2@gmail.com