Privacy Policy

Overlap (“Overlap”, “we”, “us”) is a scheduling app for university students, at overlapclass.com. We are the controller of the information described here, which under the GDPR means we are the ones who decide why it is collected and what happens to it, and under the CCPA means we are the business responsible for it.Overlap is operated from the United States by an individual developer rather than by a company.

We have no published postal address yet; write to the address below and we will give you one that reaches us.

Reach a person at emkawley@gmail.com. That address is the right one for a privacy question, a request to see or delete your data, an appeal against a refused request, a security report, or a complaint. We answer them ourselves.

This notice covers the Overlap app and website, and every account and server that runs them. It does not cover your university, its registrar, or the site you took a screenshot of: those hold their own records about you under their own policies, and section 17 explains where the line falls. It also does not cover a page you reach by tapping a sponsored row, which belongs to the business that bought it.

Using Overlap is governed by our Terms of Service. This notice is the privacy half of that agreement.

Six words below do specific work in the law and are used here the way the law defines them, not loosely. Where a term comes from the California Consumer Privacy Act as amended by the CPRA (Cal. Civ. Code 1798.100 and following) or from the GDPR, the statutory meaning is the one that governs, even where the plain-English gloss here is shorter.

1. (a)Personal Information (California) and Personal Data (EEA and UK) both mean information that identifies you or could reasonably be linked to you, directly or indirectly. Your email address, your handle and your timetable all qualify. This notice uses the two interchangeably.
2. (b)Processing means anything done with that information: collecting it, storing it, reading it, showing it to a friend you approved, deleting it. A row sitting untouched in a table is still being processed.
3. (c)Service Provider (California) and Processor (EEA and UK) mean a company that handles the information on our written instructions and for no purpose of its own. Section 12 names every one of them.
4. (d)Sell has its CCPA meaning: disclosing personal information to a third party for money or for other valuable consideration. Money is not required for a disclosure to count as a sale.
5. (e)Share has its CPRA meaning, which is narrower than the everyday one: disclosing personal information to a third party for cross-context behavioural advertising, meaning advertising aimed at you based on your activity across sites or apps that are not ours.
6. (f)Sensitive Personal Information has its meaning in Cal. Civ. Code 1798.140(ae): government identifiers such as a Social Security, driver’s licence or passport number, precise geolocation, racial or ethnic origin, religious beliefs, union membership, the contents of your mail or messages, genetic and biometric data, health data, and data about your sex life or sexual orientation.

This is the notice at collection required by Cal. Civ. Code 1798.100(a), and it doubles as the Article 13 and 14 disclosure for anyone in the EEA or the UK. The letters are the statutory categories in Cal. Civ. Code 1798.140(v)(1). Only the categories Overlap actually collects appear.

Several statutory categories are not collected at all, and we would rather say so than let the omission be read as an oversight. Overlap does not collect category C (protected classifications such as race, religion, age or sex), category D (commercial or purchase records), category E (biometric information), category G (geolocation of any precision), category I (professional or employment information), or any financial or payment information, because Overlap is free and there is nothing to charge you for. We hold no education records maintained by or for a school: section 17 explains why what we do hold is not one.

We do not collect Sensitive Personal Information as section 2(f) defines it. We do not use or disclose personal information for any purpose that would give you the right to limit under Cal. Civ. Code 1798.121, which is why there is no “Limit the Use of My Sensitive Personal Information” link anywhere in the app: there is nothing for it to switch off. Two honest edges to that. A busy period’s label is free text, so it holds whatever you typed into it; nothing reads it except you, and it is stripped in the database before the row is used to answer a friend. And a screenshot carries whatever was on the screen you photographed, so if a page shows a government ID number, crop it or add the class another way.

• From you. Almost everything. Your address, your handle, your classes, your busy hours, your settings, and anything you type into a report.
• From your browser, automatically. The IP address, time, page and browser string in a request log, and the session cookie that keeps you signed in.
• From something you uploaded. The class rows the reader found in your screenshot, and the corrections you made before confirming them.
• From another student, occasionally. A friend request naming you, an invite link you joined through, a block, or a report someone filed about you. A report is the only one of these you are not shown, for reasons section 13 gets into.
• From a published course catalogue. Codes, sections, meeting times, rooms and instructors, as published by a registrar. That is information about a class, not about you.
• From Google Calendar, if you connect it. One read of your own calendar, at the moment you ask for it. Section 8 sets out exactly what is read, what is kept, and what is thrown away.

There is no seventh source. We buy nothing from a data broker, we run no social sign-in that would hand us a profile, we receive nothing from an advertising network, and we do not enrich your account with anything bought or scraped from elsewhere.

Each purpose below is the only reason the data attached to it exists. For anyone in the EEA or the UK, the third column is our legal basis under Article 6(1) of the GDPR, and where that basis is legitimate interests, the interest itself is named rather than implied.

We balanced each legitimate interest against your rights before relying on it, and none of the four involves showing your information to anyone or building a profile of you. You can object to any of them under Article 21: see section 15.

Worth stating plainly, because for an app about where you are during the week these are the assumptions people reasonably arrive with:

• We do not track your location. The app never asks your device for GPS and never receives it. A building and room come from your timetable, which is where you are scheduled to be. Nothing in Overlap knows where you actually are.
• We do not read your contacts, your calendar, your photo library or your messages. A screenshot reaches us because you picked it and sent it.
• We do not run an ad network. There is no third-party advertising SDK in this app, and no advertiser drops a pixel or a cookie on you.
• We do not build a profile of you for advertising, and we do not sell or share your personal information. Under California law those words have specific meanings, including “sharing for cross-context behavioural advertising”. We do neither, for money or otherwise.

A registrar screenshot is the most sensitive thing a student hands this app. It usually has your full legal name on it, sometimes a student ID number, and where you physically are every hour of the week, all in one image. So:

• The image is uploaded to a private folder that only your account can read. It is not public, and it does not have a shareable link.
• It is sent to Anthropic’s API to be read. Anthropic processes it to return the answer and, under their commercial terms, does not use it to train their models.
• Once you confirm the classes it found, the image is deleted. The pixels go; the text the reader extracted stays. You can also delete it earlier yourself.
• We keep what the reader produced next to what you corrected. That difference is how we find out the reader is misreading a Thursday, and it is the only quality signal this feature has. It is class codes, times and room numbers, not the image.
• The reader is not required. Adding a class by CRN, by picking your section off the catalogue, or by hand is always available and never involves an image or a third party at all. If you would rather no screenshot of yours ever leave your phone, use one of those.

Reading the image is automated processing, and we should be exact about what that does and does not amount to. It is not a decision that produces legal effects concerning you or similarly significantly affects you within the meaning of Article 22 of the GDPR: the reader proposes class rows, you see every one of them on the review screen, and nothing is saved until you confirm it. Correcting a wrong room or deleting a class the reader invented takes one tap, and no consequence of any kind follows from what the model guessed before you looked at it. Nothing else in Overlap makes an automated decision about you.

Connecting Google Calendar is one of five ways to get a class onto your week, and it is the only one that involves Google at all. It is off until you tap it, and Google, not us, asks you for the permission. This section is the thorough disclosure Google requires of any app that reads its users’ calendars, and it is also just what happens.

What we ask Google for

One permission, calendar.readonly, which is read-only: nothing Overlap does can create, change or delete an event. We ask for it as a one-time access. We deliberately do not request offline access, so Google never issues us a refresh token, and there is therefore nothing in our possession that could read your calendar again tomorrow. The short-lived access token Google does hand back is spent on the single import described below and then dropped. It is never written to the database.

What we read

Events on your primary calendar, between the first and the last day of your current term, and no other window. For each event we ask Google for six fields and refuse the rest: the event’s id, whether it is one instance of a repeating series, its title, its location, its start and its end. We never ask for guests, organisers, descriptions, attachments, conferencing links, free/busy status, reminders, or any calendar other than your primary one.

What we keep

Far less than we read. An event survives the import only if all four of these are true: it repeats, its title contains something shaped like a course code, it falls on a weekday, and it has a real start and end. What survives becomes proposed class rows on the review screen, and nothing is written to your account until you confirm them. What is kept afterwards is the same thing a screenshot or a typed CRN leaves behind: a course code, a title guess, meeting days, times, and a building and room if the location field gave us one.

What is thrown away

Everything else, and this is the part worth being exact about. Your one-off events, your all-day events, your weekend events, and every event whose title does not look like a course, are read into memory on our server so that they can be sorted through, and are then discarded when the import returns. They are not written to a database, not written to a log, not shown to anyone, and not sent anywhere else. If you abandon the review screen without confirming, even the proposed rows go the same way.

Turning it off

Because we hold no refresh token, disconnecting is mostly already done: the permission you granted lets us read your calendar once, at the moment you asked. You can still revoke Overlap’s access at any time at myaccount.google.com/permissions, and you should if you would rather the grant not sit there. Classes already imported stay on your week until you delete them, because at that point they are your class rows and no longer Google’s data.

The import is not required and never will be. Adding a class by CRN, by picking your section off the catalogue, or by hand involves no third party at all. And an event title is not a schema, so this path guesses which course an event refers to more often than a registrar CRN does: check what it proposes before you confirm it.

The iOS and Android apps hold the same information as the website and collect nothing extra about you. What differs is that a phone has things a browser does not, so three of them are worth setting out.

Push notifications

If you allow notifications, your device is issued a push token, which is an address for this installation of the app and not a name for you. We store it against your account so a friend request, an acceptance, or a new overlap can reach you, and we send through Expo’s push service, which hands the message to Apple or to Google for delivery. The token is deleted when you sign out of that device and when you delete your account. Refusing the permission, or revoking it later in your device settings, costs you nothing else in the app.

Device permissions we ask for, and the ones we do not

• Notifications, for the above. Optional.
• Photo library, when you pick a profile picture or a schedule screenshot. We receive the one image you chose. We never browse your library, and the permission is asked for at the moment you tap, not at launch.
• Location, contacts, calendar-on-device, microphone and camera roll access beyond the picker are never requested. The app has no code that would use them.

What sits on the device itself

Your signed-in session, so you are not asked for a code every time you open the app, and a small pre-computed payload for the home-screen widget, in a container the app and the widget share. Both are on your phone rather than with us. The widget never talks to our servers: it draws only what the app last wrote for it, which is why it keeps showing your last known week when you are offline.

No advertising identifier

We do not read your device’s advertising identifier, the IDFA on iOS or the Advertising ID on Android, and there is no advertising or analytics SDK in either app. This is also why iOS never shows you an App Tracking Transparency prompt in Overlap: that prompt asks permission to track you across other companies’ apps and sites, and we have nothing to do with it.

The app stores

Apple and Google distribute the apps and keep their own records of your download and of crashes, under their own privacy policies rather than this one. That includes TestFlight, Apple’s beta programme: if you joined the beta through it, Apple collects your participation and crash information on Apple’s terms. We receive from them only aggregate counts, which name nobody.

This is the part of the policy the product is actually built around, so it is written as the rule the database enforces rather than as an intention:

No detail of your schedule crosses to another account without both of you accepting the friendship first.

That is enforced in the database, one layer below the app, so a bug in a screen returns nothing rather than someone else’s week. In practice, a friend sees:

• Your name, handle and picture, and the classes you share with them. A class you have hidden is not one of them; hiding is per class.
• When you are free, if you have free-time sharing on. You can limit that to specific friends rather than all of them.
• The shape of your busy time and nothing else. A shift shows up to a friend as a stretch when you are not free. It never shows up as “work”, or as whatever you named it. The label is stripped in the database before the row leaves it, and no friend anywhere in the app can read your busy list.

Someone who is not your friend can find you by typing your exact handle, and gets your name, handle and picture. They cannot browse a list of everyone at your school, because no such list is readable, and they cannot see a single class of yours. If you block them, they cannot find you at all.

Overlap is free. It is paid for by local sponsorships sold flat-rate: a coffee shop buys a row in the week grid for a term. There is no ad network involved, no bidding, and no third-party code.

A sponsorship can be aimed at a campus and at a time of day. That is the entire targeting capability, and it is a fact about the database rather than a promise about our restraint: there is no field for a building, a course, a friend or a person, so no advertiser can ask for one. Nothing records that you were shown a row or that you tapped it.

Advertisers receive nothing about you. They are not told who saw the row, how many people did, or anything else.

The statutory statements follow from that, and they are unqualified:

• We do not sell personal information, as section 2(d) defines selling.
• We do not share personal information for cross-context behavioural advertising, as section 2(e) defines sharing.
• We have not sold or shared personal information in the twelve months before the effective date at the top of this page, and Overlap has never done so in its existence.
• We do not sell or share the personal information of any user we know to be under 16, which follows from the two lines above and is stated separately because Cal. Civ. Code 1798.120(c) asks for it separately.

Because there is no sale and no share, there is no “Do Not Sell or Share My Personal Information” link in the app: an opt-out link that switches off nothing would be theatre. We still honour an opt-out preference signal, including Global Privacy Control, when your browser sends one. Treating it as a valid request under Cal. Civ. Code 1798.135(b) changes nothing about your account, because the setting it asks for is already the only setting we have.

We use a small number of companies to run the app. Each is a service provider under the CCPA and a processor under Article 28 of the GDPR. Each is under a written contract that limits them to what we ask them to do, bars them from selling or sharing what reaches them, bars them from keeping it or using it for any purpose of their own, and requires them to keep it secure and to delete it when we say so.

Apple and Google sit one step further out, and are not our service providers: Apple’s and Google’s push networks carry a notification the last hop to your device, and the two app stores distribute the apps, each under their own privacy policy rather than under this one. Section 9 covers both.

Google Calendar is not on the table above either, and for a different reason: Google is not processing anything on our instructions there. It is a source we read from, once, with your permission, and section 8 is the disclosure for it. We send Google nothing about you.

Beyond the providers above, personal information leaves Overlap in three situations and no others:

1. (a)When the law actually requires it. A subpoena, a court order or other valid legal process. We read what arrives, we push back on anything overbroad, and where we are allowed to tell you first, we will.
2. (b)When someone is at risk. A credible threat to a person, a safety emergency, or investigating abuse of the app. This is a narrow door and we treat it as one.
3. (c)If Overlap is acquired or transferred. Personal information would move with the app as part of the deal. This policy travels with it, we will say so on this page before anything changes, and a buyer who wants to use your information for something new has to ask you, not us.

• Your account and your friendships stay until you ask us to delete them. Friendships deliberately survive the end of a term; your classes do not, so each new term starts as an empty week with your people still in it.
• Screenshot images are deleted as soon as you confirm the classes read from them.
• What was read from a screenshot is kept while your account exists, and goes when it does.
• Calendar events that were not classes are never kept at all. They are discarded when the import returns, as section 8 sets out, and the Google access token behind the import goes with them.
• Push tokens go when you sign that device out, and when you delete your account.
• Reports outlive the account they were made about, because a record that only exists until the reported person deletes their account is not a safety record.
• Server logs are kept briefly and then rotate away.

To each of those, add the standard exception: or as long as the law requires us to keep it. If a legal duty, a preservation demand or an unresolved dispute means something has to stay after you asked for it to go, we keep only that, we stop using it for anything else, and we delete it when the reason expires.

Your data is separated at the database level rather than by application code, which is the part worth knowing: the rules about who may read which row are enforced by the database itself, so a query that forgets a condition returns nothing instead of somebody else’s week. Sign-in is a one-time code with no clickable link in it, so there is no password to reuse and no link in an email for someone to imitate. Screenshot uploads are locked to the folder belonging to the account that made them.

No system is perfectly secure and we will not pretend otherwise. If you find a hole, mail emkawley@gmail.com. We would much rather hear it from you. If information of yours is ever exposed, we will tell you and the relevant regulators as quickly as the law requires, which is 72 hours to a supervisory authority under Article 33 of the GDPR and without unreasonable delay under the US state breach statutes, and we will do it in plain language rather than in the usual paragraph about an abundance of caution.

The controls in the app are the fastest route and need nobody’s permission. The statutory rights below sit behind them and apply whether or not you live somewhere that grants them: we do not run one policy for California and a worse one for everyone else.

In the app, right now

• Hide any single class from your friends.
• Turn off free-time sharing entirely, or narrow it to specific friends.
• Delete your whole schedule from Settings → Privacy. It happens immediately, not on a nightly job, and it cannot be undone, which is why it asks you to type the word.
• Unfriend someone, or block them silently.

Requests by email

Everything else is one message. You can ask for a copy of what we hold about you, ask what we collected and who received it, ask us to correct something, ask us to delete your account and everything attached to it, or ask for your data in a portable file.

How we check it is you. We mail a one-time code to the address on the account, the same way signing in works, and act on the request once it comes back. We will not ask you for a photograph of an ID, and we will not ask for anything beyond what it takes to be sure the request is really yours. If we cannot verify you, we will say so and tell you what would settle it.

How long it takes. Under the CCPA we confirm receipt within 10 business days and answer within 45 calendar days, which we may extend once by a further 45 days where a request is genuinely complicated, telling you inside the first 45 that we have. Under the GDPR we answer within 30 days, extendable by up to 60 more for a complex request, again with notice inside the first 30. In practice one person reads that inbox and most requests are done the same week.

There is no fee. Not for the first request, not for the fourth. We reserve only the narrow statutory right to charge for, or refuse, a request that is manifestly unfounded or repetitive, and if we ever use it we will explain why in writing.

Authorized agents

Under Cal. Civ. Code 1798.135 you may use an authorized agent to make a request for you. Send us written authorization signed by you, and we will verify both your identity and the agent’s authority before acting. A power of attorney valid under California Probate Code 4121 to 4130 stands on its own and we will not ask you for more.

If we say no: your right to appeal

If we refuse a request, in whole or in part, we will tell you why and you may appeal. Reply to the same thread, or write to emkawley@gmail.com with “Appeal” in the subject line. A different look at the request is not the same as the first one, so an appeal gets a fresh read of the facts. We will respond in writing within 45 days with our decision and our reasoning. If we still say no, we will tell you how to lodge a complaint with your state Attorney General. This right is granted by the consumer privacy statutes of Virginia, Colorado, Connecticut, Montana, Oregon and Texas, and we apply it to everyone who asks.

No discrimination

Exercising any right on this page costs you nothing and changes nothing about your account. We will not deny you the app, degrade it, slow it down, charge you, or offer you a worse version of anything because you asked. Overlap is free and identical for everybody, which makes this one easy to keep.

California: Shine the Light

Cal. Civ. Code 1798.83 lets a California resident ask, once a year, what personal information a business disclosed to third parties for those third parties’ own direct marketing. Our answer is fixed and we can give it here: none. We disclose nothing to anyone for their own direct marketing, so there is no list to request.

If you are in the EEA or the UK

The GDPR and the UK GDPR give you these rights by name, and they are the same requests as above: access to your data and information about how it is processed (Article 15), rectification of anything wrong (Article 16), erasure (Article 17), restriction of processing while a dispute is open (Article 18), portability in a machine-readable file (Article 20), objection to processing we base on legitimate interests (Article 21), and the protections around automated decisions in Article 22, which section 7 explains do not arise here.

Where we rely on your consent, you can withdraw it at any time under Article 7(3): delete your profile picture, or add classes by CRN, from the catalogue or by hand rather than by screenshot. Withdrawing does not unpick what was lawfully processed before you did.

You can also complain to a supervisory authority. In the UK that is the Information Commissioner’s Office at ico.org.uk; in the EEA it is your national data protection authority, normally the one where you live or work. We would rather you came to us first, but nothing here requires it.

Article 27 representative. We have not appointed one. Article 27 requires a representative in the Union or the UK where a controller established outside it offers goods or services to people there or monitors their behaviour. Overlap is built for students at United States universities, is not marketed or offered in the EEA or the UK, and monitors nobody’s behaviour anywhere. If that stops being true we will appoint a representative and name them on this page. Until then, write to the developer directly at emkawley@gmail.com, which reaches the controller rather than a mailbox in front of one.

Overlap is for university students. You must be at least 13 to use it. We do not knowingly collect anything from a child under 13, and if we learn we have, we delete it.

That is the line the Children’s Online Privacy Protection Act (COPPA, 15 U.S.C. 6501 and following) draws, and Overlap sits on the right side of it by not being for children in the first place: there is no under-13 account to create, and nothing in the app is directed at one. A parent or guardian who believes a child under 13 has an account can write to emkawley@gmail.com and we will look, delete the account and everything attached to it, and confirm when it is done.

Plenty of first-year students are 17. Nothing here treats them differently, but the parent or guardian of a user under 18 can write to us at the same address to see or delete their child’s information. We verify the account holder’s identity the usual way before acting, because a request about a 17-year-old is still a request about a person who may not want it made.

Overlap is not affiliated with, endorsed by, or operated on behalf of any university. You sign up as yourself, with your own email address. Your school does not have an account, does not receive your schedule, and cannot ask us for it outside of a valid legal process.

Course catalogue information (the codes, sections, meeting times and instructors published by a registrar) is not personal information about you, and is shared between everyone in the same class. That is what makes matching work: two students in the same section join on the same row.

The Family Educational Rights and Privacy Act (FERPA, 20 U.S.C. 1232g) governs education records maintained by a school or by someone acting for it. Overlap holds neither. Your schedule reaches us from you, by typing, by CRN, off a public catalogue, or out of a screenshot you chose to send; it never reaches us from your registrar, we have no data-sharing agreement with any institution, and we are not a school official acting under a university’s direction or control. So what we hold is not a FERPA education record, and the consequence matters more than the label: a school cannot obtain your Overlap data by pointing at FERPA or at a student agreement, because neither one reaches us. It would need valid legal process, and section 12(a) is how we would treat that.

Overlap is operated from the United States and your information is stored and processed there, including by the companies in section 12. If you use Overlap from outside the US, you are sending it to the US, where privacy law is different from the law where you live, and in particular where public authorities can obtain data under powers that have no direct equivalent in the EEA or the UK. That is a real difference and not a formality.

For personal data of anyone in the EEA or the UK, the transfer mechanism is the European Commission’s Standard Contractual Clauses (2021/914), together with the UK International Data Transfer Addendum where the transfer is from the UK, incorporated through the data processing terms our providers publish. Where a provider offers them, they are the terms we are on. We rely on no other mechanism, and if the ones above ever stop being valid for a given provider, we will move the data or stop using them rather than continue on nothing.

If we change this policy in a way that matters (new information collected, a new company receiving it, a new use), we will post the new version here with a new effective date and tell you in the app before it takes effect. Smaller corrections go up with a new date and no announcement. The date at the top always tells you which version you are reading.

Where a change requires your consent under the GDPR or a notice at or before collection under the CCPA, we will get it or give it first rather than treat continued use of the app as an answer. We review this notice at least once every twelve months, which Cal. Civ. Code 1798.130(a)(5) requires, and update the date whether or not anything changed.

emkawley@gmail.com, for questions, requests, appeals, complaints and security reports alike. A person reads it.

Postal mail is available on request for anyone who needs a written address for a formal notice: ask at the address above and we will give you one. For the record, this notice is available in this format on every device the app runs on, and we will send a plain-text or printed copy to anyone who cannot read it here, which is what Cal. Civ. Code 1798.130(a)(6) and the accessibility guidance under it ask for.