Privacy policy

LockIn is run by Affaan Ahmad, an individual based in Pakistan. It is not a company. Questions about your data go to contact@lockinapp.tech.

Four Classroom permissions, all of them read-only. LockIn cannot post, submit, grade, edit or delete anything in Classroom, because it does not request permission to and the read-only scopes it holds do not allow it.

• Your course list, including course names and the section label the teacher set.
• Coursework in the courses you choose to track: titles, descriptions, due dates and links.
• Course topics, used to group work.
• Your own submission state, so work you have already turned in stops appearing as outstanding.

Signing in with Google also involves the two basic sign-in permissions every Google login uses, email and profile. They are requested by the authentication service LockIn signs you in with rather than by LockIn itself, and the Google consent screen lists them alongside the four above. What LockIn keeps from them is your email address and your Google account identifier, which is how it knows whose coursework to show. The profile permission also returns your display name and profile picture; LockIn reads neither and stores neither.

The submission data Google returns also contains your grades. LockIn drops them at the point the response is read, before anything is written, and the database has no column to put them in. No part of the product reads, stores or shows a grade.

The timetable screen is read from a spreadsheet your university publishes. It is not read from your Google account, and it did not require any new permission from you: the consent screen still lists the four read-only Classroom permissions above and nothing else.

LockIn reads that document with a credential of its own, so fetching it sends nothing about you to anyone. The same document is fetched once and shown to everybody who uses LockIn; which parts of it you are shown is worked out afterwards, here, from the programme and section you picked.

The document itself names courses, sections, rooms and times. It contains no student names and nothing about you personally, and LockIn stores none of it against your account.

Only to run the features you can see: listing your courses so you can choose which to follow, organising coursework by deadline, working out which work applies to your section, and marking work you have already turned in so it stops being listed as outstanding.

It is not used for advertising or profiling, it is not sold, and it is not used to train any machine-learning model.

LockIn’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

• Your email address and Google account identifier, to identify your account.
• Your section, programme code, batch and any alternative spellings you add, which is what the section matching runs on.
• Your time zone, which decides when a deadline counts as due today.
• Course names, sections and state for the courses Google shows you.
• Coursework titles, descriptions, due dates and links for the courses you track.
• Whether each piece of work is turned in, and whether it was late.
• What LockIn decided about each assignment, the section evidence it found, and how confident it was.
• Your own decisions: which courses to track, which assignments are yours, and what you have hidden.
• Your Google access and refresh tokens, encrypted.
• A history of sync attempts and any errors, used to tell you how current your data is.

Two things are deliberately not in that list because they are not kept on the server at all: the programme and section whose timetable you asked to see, which is held in a cookie on your device, and your theme choice, which is held in your browser’s local storage. Both are described in the cookie policy.

When LockIn decides an assignment is not for your section, it stores the reason: which section labels it found in the post and how it read them. That record exists so the decision can be explained to you and corrected, rather than being an unaccountable judgement about your coursework. It is also what makes the “Review” screen able to show you why it was unsure.

LockIn does not sell your personal data. Three providers necessarily process it in order for the product to run:

• Google, which is the source of the coursework, handles sign-in, and hosts the timetable document your university publishes.
• Supabase, which hosts the database and the authentication service.
• Vercel, which hosts and serves the application and keeps its request logs.

There is no analytics service, no advertising network, no session recording and no error reporting service. Nothing else receives your data.

LockIn does not disclose your coursework to your teachers, your university, or other students. It reads Classroom as you, and shows the result only to you. Access to the underlying database is limited to the person named above and to the providers listed here in the course of operating their services.

Disconnecting stops all future synchronisation and removes the stored Google credentials from the database. LockIn also asks Google to revoke the grant. If Google is unreachable at that moment the local credentials are still cleared, and LockIn tells you so on the screen, because refusing to disconnect you because a third party was down would be the wrong way round. You can always remove the grant yourself from your Google account permissions page.

Coursework already imported stays where it is. Disconnecting stops the updates; it does not delete what you already have.

Deleting your account removes your profile, your section and aliases, your courses, coursework, submission records, classifications, manual overrides, hidden items, sync history and stored Google credentials. Every one of those tables is tied to your account in the database and removed with it, in one operation rather than a queue.

LockIn asks Google to revoke the grant first, so that it is withdrawn while the credential to withdraw it still exists. If that call fails the deletion still goes ahead and the failure is logged, so it is possible for your data to be gone here while the grant remains listed in your Google account until you remove it there.

Deletion from the live application database is immediate and cannot be undone. It is not a request queue and there is no recovery window. What it cannot reach are the operational copies kept by the providers above: database backups and server request logs, which expire on those providers’ own schedules rather than on demand. Anyone claiming a deletion reaches every copy everywhere the instant it is pressed is describing a system simpler than this one.

Settings has a link that downloads a JSON file containing your email address, your section and the alternative spellings LockIn matches on, your time zone, your courses and which you track, your coursework with its due dates and links, what LockIn decided about each assignment and how confident it was, which section scope it concluded, whether you overrode it, whether the work is turned in, what you have hidden, and when the last successful sync ran.

Some things it holds are not in that file. Assignment descriptions, course topics, the detailed rule-by-rule evidence behind each classification, and the full sync error history are stored but not exported, and the export is capped at one thousand items per category. If you want any of those, ask at contact@lockinapp.tech and they will be provided.

Your Google tokens are deliberately excluded. They are credentials rather than information about you, and putting a live key to your Classroom account in your downloads folder would be a worse outcome than omitting it.

Coursework and your decisions are kept until you delete your account or stop tracking the course.

A record of each sync attempt and any errors is kept so LockIn can tell you how current your data is and so failures can be diagnosed. It is removed when you delete your account. Older sync history is deleted automatically every night, ninety days after the attempt it records. Two runs survive that regardless of age: your most recent attempt, and your most recent successful one. Those two are what the “how current is this?” line on every screen is read from, and deleting either would leave LockIn reporting a synced account as one that had never synced.

Google tokens are encrypted with AES-256-GCM before they are stored, using a key held in the server environment and never in the database, and each token is bound to the account it belongs to so a row copied between accounts fails to decrypt rather than opening somebody else’s Classroom. The table holding them has row-level security enabled with no policies at all, which means no client role can read it through the public API, including yours.

Every other table carries row-level security tied to your account, so one student’s query cannot return another student’s rows even if the application asks wrongly. Those policies are exercised by an automated test suite that signs in as two separate accounts and checks that neither can reach the other’s data.

No system is secure in an absolute sense and this page does not claim that. To report something, write to contact@lockinapp.tech.

LockIn is built for university students and is not directed at children. It does not ask for a date of birth and does not verify age, so it cannot enforce a minimum; it relies on the fact that you already hold a Google account able to access Google Classroom coursework at a university.

If you believe a child has created an account, write to contact@lockinapp.tech and it will be deleted.

This page changes when the product does. Because it is written from the database schema, a change to what is stored is a change here.