Privacy Policy

What we collect

• Account: your username/email, a securely hashed password (we never store it in plain text), and your birthday, which we ask at sign-up to know whether a parent needs to approve the account. An educator account (a tutor, teacher, coach or learning specialist) also has the title and school or organization they typed.
• School: the name of your school, which a student picks at sign-up or in Settings (or types in, if it isn't on our list), and, if the student verifies it, the school email's domain (like @ecfs.org) and when. Suggesting a school from your email. At sign-up we fill in a school from the email address in only three cases: the address is at a domain on our own checked list of school email domains; it is at a domain two students already confirmed for that school (see below) and the domain's name spells that school's name; or it is at a college or university domain from the official US college list (outside the US, a public, community-kept list of world universities) under an ending only schools can register (like .edu or .ac.uk), that the list gives to that one college and no other school, where the list names one college and not a college system, district, office, laboratory, hospital or health system, or a school district's career center, whose name part is that college's initials, a word of its name or its name run together (like @unsw.edu.au) and no other school's, college or K-12, and that our regular check has not found unregistered, parked, for sale, without email or with a homepage that is plainly someone else's now. We fill in nothing for a school the school lists mark as closed or that we found has closed. In every case the address must be at the domain itself or at a student mail address under it (like students.ecfs.org), not at another part of a school's domain such as a hospital's, a laboratory's or an alumni forwarding address. We never fill in a college or university for a student under 16, from any of these. We never fill in a school from any other address: not a school district's or a college system's, not a K-12 school's domain from the government's school list on its own, and not a personal address or one at a company, hospital, government or other organization. The student types their school instead. Verifying it. To verify, we send a 6-digit code to the school email you enter. We keep that address only while the code can be used (15 minutes, and an unused code and its address are deleted within the hour after that); after the check we keep only the part after the @. A school that has trusted domains is verified only at one of them: one on our checked list, one two students confirmed for it, or its college domain described above, and only from the domain itself or a student mail address under it. That happens with the code, without a code when the email they signed up with is at a trusted domain and was already proven (by their sign-up code, or by Google or Apple confirming the address when they signed in), or when they sign in with their school's Google account. For a school with no trusted domain (most K-12 schools, and every school a student typed in), one code verifies it at once, at the address's domain, when the address is one that can make a claim (below). We also keep a claim: the domain, the school, the account and a scrambled fingerprint of the address that can't be turned back into it (so one address counts once, even written with a +tag). When a second student, with a different address, confirms a code at the same domain for the same school, that domain becomes trusted for that school, so it can fill in and verify that school for other students, and we delete the claims, keeping only the domain and the school. A claim is deleted when the student changes or removes their school, when the account is deleted or reset, and after 90 days, and an account, or a domain, can make only a few claims a day. Some addresses never make a claim. A personal address (one anyone can get, like Gmail or Outlook) or an alumni one (like alum.mit.edu) never does, and neither does a part of a school's domain that is not its students' mail (like a hospital's or a laboratory's). Nor does an address at an ending anyone can buy for a product or a personal site (like .io or .fun) or under an ending a company sells to anyone (like sch.ac), at a government's or a registry's name (like state.ny.us or sch.uk), at a website host or at a placeholder (like nonesupplied.com). Nor does a look-alike: an address with letters from another alphabet, a school's domain inside a longer name (like ecfs.org.evil.com or harvard.edu.pl), or a school's domain written with a hyphen or no dot for the dot (like ecfs-org.com or harvardedu.com) or with a word added by a hyphen (like mail-ecfs.org), unless the school lists give that very domain to the student's own school (like a district's polk-fl.net). Nor does a dead domain: our regular check covers every domain the school lists give under an ending anyone can register and every college domain we fill in from, and finds those unregistered, parked, for sale, without email, registered again after the list recorded them, or with a homepage that is plainly someone else's now (like a gambling site); a domain the school lists give only to schools that have closed is dead too, unless our checked list gives it to an open school or it looks like the domain of the closed school's district. Nor does a domain that is another school's: one on our checked list or under the college rule above for a different school, one the school lists give to other schools and not to this one, one already confirmed by two students for another school (unless the school lists give it to this school too), or one at an ending only another country's or US state's schools can register (like ox.ac.uk for a school in Idaho). A school that has left the school lists, as one does when it closes, takes no claim, and a domain two students confirmed for it no longer verifies it. An Aluma admin can remove a domain a school learned this way, and it is never learned again. The code email names the school only as the official list spells it, never as a student typed it, and an account can ask for a limited number of codes each day. Whenever anyone signs in with Google (students, parents and educators), we note the Google Workspace domain of a school or work account (like ecfs.org); a personal Gmail has none. We count schools together to see which schools and places use Aluma, and Aluma's admins can see which accounts picked each school, with each account's name, email, grade and whether its school is verified. An educator can also link their account to a school; it is never verified. The school is never sent to the AI provider.
• Your content: messages, projects, uploaded files, and preferences you create in the app.
• Quarters, semesters and transcripts (if you use them): each quarter or semester you set (its name, its first and last day, the day its grades come out, and whether your grades then start fresh or continue); when one ends, each class's grade as it stood then; and, if you add a transcript or report card, the grades you check and save from it (each class as printed and its grade, and the GPA if it shows one) and the file's name. The photo or PDF itself is not kept. The grades from your past terms are part of what the tutor knows about your classes.
• Billing: handled by Stripe. We store your plan status and a Stripe customer ID - never your card number.
• Usage: basic counts, to enforce plan limits and so Aluma's admins can see how the app is used: messages and requests per day, which part of Aluma each request was for (like the tutor chat or Assignments, never the page address or anything you typed) and the hour messages were sent. Admins can also see, for each saved chat, the class it is in, where it was opened (the main chat, Lumi or the extension), when, and how many and how long its messages were, never what was said, and the settings you saved, except what you wrote for the tutor. We work out the country an account is in from its school, or else from the time zone it saved.
• Family (if you use it): your family's name, who is in it and their roles (like "Mom"), invites (the address invited and who sent it), the family code, the rules a parent sets and the time zone they run in, a family activity log, and a daily count of each student's AI questions. If a student or a parent adds an educator (a tutor, teacher, coach or learning specialist), or an educator invites a student who accepts, we keep who they are, the title and organization they gave, who added them, what they're allowed to do (reminders, plan changes, notification settings), the reminders they sent, and a log of what they did.

How we use it

• To run the Service - store your work, generate responses, and apply your plan.
• Your messages are sent to Anthropic's Claude API to produce replies, subject to Anthropic's terms.
• If you add a transcript or report card, its pages are sent to Anthropic's Claude API to read the grades on it, subject to Anthropic's terms. Only the grades you check and save are kept.
• If this Aluma is set up to transcribe recordings, an audio or video file you attach is sent to OpenAI's transcription API to be turned into text, subject to OpenAI's terms; only the text is kept with your chat. Where transcription is not switched on, the file is refused and nothing is sent.
• To process payments through Stripe.

Lumi Anywhere (Chrome extension)

Lumi Anywhere puts Aluma's tutor in a Chrome side panel. It's covered by this policy, and it handles the following data.

• Your Aluma sign-in. When you press Authorize extension, your browser stores a token that identifies your Aluma account. It stays on your machine and is sent only to Aluma to authenticate your requests. The extension never sees or stores your password.
• Page content you choose to share. Page text, captions, and images are sent to Aluma only when you turn on Whole page or Point at part for that message. Whole page sends the tab's readable text and available video captions from the page or player (YouTube, Edgenuity, and other players), including loaded transcript lines outside the visible area, together with a screenshot of the visible tab. Lumi never clicks Show transcript or turns captions on. Point at part sends everything Whole page does AND a cropped screenshot of the area you marked, so Lumi can answer about that part while still understanding the page around it. With both off, your message is sent without any page capture. What you do share is sent to Aluma to answer that message. Your messages and replies are saved in your Aluma History, the same as any other conversation.
• Assessment status. Each chat message may include a small assessment status, reason code, and confidence level so Aluma can enforce its assessment rules. This status is sent even when all sharing chips are off; it contains no page URL, title, text, or images.
• School assignments you ask to sync. When you tap Connect or Sync in Aluma, Lumi reads structured fields (title, due date, class, link, id, and available activity type, assessment status, and progress) from a school tab you are already logged into (Google Classroom, Canvas, Schoology, Blackboard, Edgenuity). It never sends the page HTML. Aluma never sees your school password. Once you have synced a school site yourself in this Chrome, Lumi 1.5.2 and later also keep its assignments current while Aluma is open: about every half hour it opens that site in a background tab of its own, reads the same fields, and closes the tab. It never brings that tab forward, never signs in for you, never reads a site you have not synced yourself with your own Aluma account, and stops when you disconnect the site.

The extension reads pages locally to prepare that optional snapshot and detect assessments. It never types into a page to do homework, fill answers, click Turn in, or submit schoolwork. If it detects a live quiz or exam, it stops and won't use the page or answer at all. The only typing exception is when you choose Have Lumi sign in and type your school login; Lumi may then fill that login form in this Chrome. Those credentials stay in this browser and are never sent to Aluma. If you tap Remember, Lumi keeps that school username and password in this Chrome so it can fill the login next time without asking. Remembered logins are bound to your signed-in Aluma account, stay on this computer, and are never sent to Aluma. Forget or Disconnect this browser clears them. 2FA and CAPTCHA still need you.

Signing out (door icon in the side panel header, or Disconnect this browser on the upgrade wall) removes the token and the saved transcript from that browser. To revoke the token on our side as well, use Sign out everywhere in Settings, or change or reset your password. Any of those invalidates the extension token immediately.

Two limits worth knowing. First, that token is issued per account rather than per device, so revoking it signs out every surface at once - the web app and Lumi Anywhere - you cannot currently revoke the extension on its own. Second, until you revoke it, the token does not expire on a timer.

Chat and account requests go to Aluma. To prepare captions locally, Lumi may also fetch an available caption track from the current site or YouTube before you share it. That lookup retrieves captions into your browser; it does not send page text or images to Aluma. The extension does not send data to third-party analytics or advertising services, and it loads no code from outside the installed package.

What we don't do

We don't sell your data. We don't use your private conversations to train models. We don't use anything the extension collects for advertising, and we don't receive page text, captions, or images for chat until you explicitly share them, message by message. Assessment status and school sync are described above.

Your choices

• Export: download your data anytime from Settings → Data & Privacy.
• Delete: deleting your account permanently removes your data from our storage.

Cookies, local storage & analytics

Aluma sets two first-party cookies on the app: a signed session cookie that keeps you signed in, and a device-trust cookie (aluma_did) that helps recognize this browser after you sign in again (for example, when a new device needs a verification code). Both are HttpOnly, SameSite=Lax, and stay on this site. The session cookie is required to use an account. We also use your browser's local storage to remember preferences like light/dark theme. Neither cookies nor local storage are used for advertising, profiling, or tracking you across other sites, and we set no third-party cookies.

We count pageviews on our own server so we can see which pages get used. What is stored is a count per day and page, and nothing else - no IP address, no device or browser fingerprint, no account id, no cookie, and no identifier that could link two visits together. We do not use Google Analytics or any other third-party analytics or advertising service.

To clear the session and device cookies, sign out (or clear this site's cookies in your browser). To clear preferences, clear this site's data in your browser.

Data retention & security

Your data is stored for as long as your account exists. Passwords are hashed (PBKDF2); sessions use signed cookies. No system is perfectly secure, but we take reasonable measures.

Children and families

Under 13. A student under 13 can use Aluma only after a parent or guardian approves the account. At sign-up we ask for the student's email, a password, their birthday and a parent or guardian's email. Until the account is approved, we use these only to confirm the student's email and to ask the parent: the account can't be used, and we send it no other email. The parent gets an email that says what Aluma collects, with a link to approve the account on their family dashboard. When a parent invites their child from the parent app, that invite is the approval. The request is good for 14 days. If nobody approves by then, we delete the sign-up, and the student can sign up again. A parent who tells us it isn't their child gets no more emails about it.

After approval, Aluma collects the same information it does for any student (see What we collect above), and the questions the student asks the tutor are sent to Anthropic's Claude API to write the replies. We don't sell children's information, use it for advertising, or use their conversations to train models.

What a parent sees. In the parent app, a parent sees their child's assignments, due dates and anything overdue; their calendar (what is due each day and the study time they planned, never the notes they wrote on it); classes and grades; streak, study time, goal, topics mastered and weak spots; the educators who help them and what those educators did; when the child last used Aluma, and their age; and, if the parent set a daily limit, how many AI questions the child used today. Parents never see chats with the tutor, notes, files, connected accounts, their school or passwords. Until a child turns 18, a parent can also set rules: pause the tutor, a daily AI limit, nightly downtime, and Lumi Anywhere on or off.

Educators. A student 13 or older, or a parent, can invite an adult who helps the student, like a tutor, teacher, coach or learning specialist, and an educator can invite a student, who decides whether to accept (under 13, a parent decides). Educators have their own account and app. They see that one student's assignments and due dates, calendar and study plan, classes and grades, streak, study time, goal, topics mastered and weak spots (the practice questions they missed, never chats), test prep progress and when the student last used Aluma. They can't change rules, and they never see the student's age, school, chats with the tutor, notes, files, connected accounts, or anyone else in the family. When the student or a parent allows it, an educator can send the student a reminder, add to-dos and study time to the student's planner or move them, and change which reminders Aluma sends; the student always sees who did it, and the student and their parents can read a log of every such action. The parents in the family are emailed when an educator is added and can remove them; so can the student (13 or older) and the educator. For a student under 13, only a parent can add or remove one, or change what they can do.

A parent's choices. A parent or guardian can ask to see the information we hold about their child, ask us to delete it, or tell us to stop collecting it, which closes the account. Email privacy@aluma.fun from your parent account's address, or the address we wrote to. A student can also delete their own account in Settings.

13 to 17. Students 13 and older can sign up on their own. If you're under 18, use Aluma with a parent or guardian's involvement; you can invite one in Tools > Family, where you can also invite an educator and choose what they can do.

Contact

Privacy questions: privacy@aluma.fun.