Privacy Policy

The VGSpartans platform (“Platform,” “we,” “our”) is committed to protecting the privacy of everyone who uses it, from students building their first website to visitors browsing a club page. This Privacy Policy explains what we collect, how we use it, and the choices you have.

It is split into clearly labeled parts so you can jump to what applies to you:

• Part I, All Users covers what applies to everyone, visitors and registered users alike.
• Part II, Visitors covers what we collect when you browse public pages without an account.
• Part III, Registered Users covers the extra data we collect once you have an account.
• Part IV, How We Use Your Information explains the reasons behind the collection.
• Part V, How We Share Your Information explains who can see your data and why.
• Part VI, Data Retention explains how long we keep it.
• Part VII, Your Rights and Choices explains the control you have.
• Part VIII, Special Provisions covers children’s privacy, education records, and related rules.
• Part IX, Your Regional Privacy Rights covers extra rights for California residents, people in the EEA, UK, and Switzerland, and residents of other US states and countries.
• Part X, General covers changes, contact, and legal notes.

This Policy covers data. The rules about conduct, accounts, and content are in the Terms of Service, which this Policy forms part of.

Part I: All Users

This part applies to everyone who uses the Platform in any way, whether as a public visitor or a registered user.

1. Who We Are

VGSpartans is an independent project built and run by a single Vista Grande High School student (the “Developer,” also “we” and “our” in this policy). It is made for the Vista Grande community, but it is not operated, hosted, or officially endorsed by Vista Grande High School (the “School”) or the Casa Grande Union High School District (the “District”). It is not a commercial service, shows no advertising, and does not sell anyone’s data.

What began as club sites and personal sites has grown into a set of subplatforms under one login, including school-friendly spaces for student writing, reference articles, campus discussion, campus ideas, student journalism, and campus photography and art. A subplatform may collect information specific to how it works and may publish its own supplementary privacy notice. Any such notice applies together with this Policy, and this Policy governs wherever a subplatform does not say otherwise.

2. Information Collected From All Users

2.1 Infrastructure Data (Cloudflare)

Every request to the Platform passes through Cloudflare, our infrastructure provider, before it reaches our code. This happens automatically and cannot be turned off. On each request, Cloudflare gives us:

• Your IP address.
• A rough location worked out from your IP: city, region, country, postal code, and approximate coordinates.
• Your network operator and its number (ASN), which identifies your internet provider or school network.
• The Cloudflare datacenter that handled the request (for example, “LAX” for Los Angeles).
• Connection details: HTTP version, and the TLS version and cipher your browser used.
• A unique ID for the request (the Cloudflare Ray ID).
• Browser hints your device sends, which can include browser name and version, operating system, platform, and device type.

This is collected on every request, including ones for pages, images, styles, and scripts.

2.2 Standard Request Data

On every request we also receive the usual web data: the URL you asked for, the method (such as GET or POST), your browser’s User-Agent string, the page you came from if any, and request headers like your language and encoding preferences.

2.3 Essential Cookies

We use a small set of essential cookies: a session cookie to keep registered users signed in, a signed rate-limiting cookie that is not tied to your identity or IP, short-lived security tokens tied to the device and browser checks for registered users, and a cookie that remembers your light or dark theme. Submitting a form protected by Cloudflare Turnstile, our bot check, may also set a short-lived technical cookie. See Section 14 for more on cookies.

2.4 No Tracking Cookies or Advertising

We do not use advertising cookies, tracking pixels, or cross-site tracking, we set no analytics cookie of any kind, and we are not part of any ad network. Nothing here follows you to another website.

We do count traffic, and we would rather tell you than have you find the script yourself. The pages the Platform draws carry Cloudflare Web Analytics, which counts page views and measures how quickly pages loaded. It is worth being precise about what that does and does not mean, because “analytics” usually means something worse than this:

• It sets no cookie and stores nothing in your browser, so you are given no ID and nothing links your first page to your second.
• Cloudflare states that it does not fingerprint people by IP address, User-Agent, or anything else for analytics, and that it strips personal information such as IP addresses at its edge before measurements are stored.
• Cloudflare states that it does not log query strings, so the sign-in links and one-time codes that travel there are never part of a measurement.
• What we can see afterwards is counts: which pages were read, roughly which countries and device types they were read from, which sites linked here, and how fast pages loaded. There is no way to pick you out of it, because nothing in it is about a person.
• It is not loaded on published student sites. Those are minors’ own pages, and they are served under a policy that forbids any external script at all.

Also worth separating out: a counter on a single item, such as the number of times a wiki article has been read, is one number stored on that article and is not linked to who read it. Section 4.1 covers all of this in more detail.

2.5 The Help Assistant

Public pages can carry a help bubble you can type a question into. It is a feature the Platform can be run with or without, so it may not be switched on when you visit.

When it is on and you send a question, the text you typed is sent to our own server, and from there to Cloudflare’s AI Search to find the pages that answer it. It never goes to any other company: it is proxied through the Platform rather than talking to Cloudflare from your browser, so no third party learns which page you asked from. Cloudflare states that it does not use this content to train models. We do not attach your question to your account, and we do not keep a transcript of the conversation. The rate limit that stops one person exhausting the service uses the signed cookie described in Section 2.3, not your IP address.

Please do not type personal information about yourself or anyone else into it. It answers questions about how the Platform works, and it needs nothing else to do that.

3. Third-Party Services

We rely on a few outside services to run the Platform. Each one receives only what it needs to do its job:

Provider	Purpose	Data Processed
Cloudflare, Inc.	Hosting, CDN, DNS, security, edge storage and databases, bot detection (Turnstile), geolocation, AI content checks, the help assistant in Section 2.5, the cookieless page-view and page-speed measurement in Section 2.4, backup email delivery, and the external access gate on the developer console	All request data (IP, headers, payload) and stored content
Bunny.net (BunnyWay d.o.o.)	Streaming and delivery of videos uploaded to the Platform, after they pass the safety checks in Section 7.1	The video file, once it has passed those checks, and, when someone plays a video, the viewer’s request data (IP address and connection details) needed to deliver it. Bunny.net is based in Slovenia, in the European Union.
ZeptoMail (Zoho Corporation)	Primary email delivery	Recipient email address and message content (sign-in codes, account and moderation notices)
Amazon Web Services (SES)	Backup email delivery	Recipient email address and message content, when the primary transport is unavailable
Resend (Plus Five Five, Inc.)	Backup email delivery	Recipient email address and message content, when the transports above are unavailable
OpenAI, L.L.C.	Backup automated safety check on content you post (Section 7.1)	The text or image being checked, only when Cloudflare’s checks are unavailable. OpenAI states that the moderation endpoint retains nothing and that API data is not used to train its models.
Have I Been Pwned	Screening a password you set against known breached passwords (Section 6)	Only the first five characters of a SHA-1 hash of the candidate password. The password itself never leaves our servers, and the service cannot tell which password it was or whose.
GitHub (Microsoft)	Optional archiving of student site content	Copies of student site files
Instatus, Inc.	The public status page, when it is published	Nothing we send. The page is hosted by Instatus, so opening it means Instatus receives your request under its own privacy policy.
Sentry (Functional Software, Inc.)	Error reporting, when it is switched on (Section 3.1)	The error only: its message, the stack trace, the path of the page it happened on, and the trail of what ran just before it. Stripped before it leaves us: no cookies, no request bodies, no query strings, no IP address, and no request headers beyond the three that state what format the request was in. Email addresses and IP addresses are redacted out of every message. Sentry keeps an error for up to 90 days.
Google LLC	Reading the current Chrome version number for the administrator browser check (Section 8.5), through the public VersionHistory API	Nothing about you. Our server asks Google, at most twice a day, which Chrome release is current. Your browser never contacts Google, and no request of yours is part of the question.
The Tor Project	Downloading the public list of Tor exit nodes, used by the security checks in Section 4.3	Nothing about you. We fetch a public text file of addresses on a schedule and do the comparing ourselves, so the Tor Project is never told that you, or anyone, arrived here.

Student and club sites are written by their owners and may include content embedded from other services (for example, a video). When you interact with an embed, that third party may collect data about you under its own privacy policy, which we do not control. If you would rather not share data with an embedded service, do not interact with it.

We do not add a new provider that handles your content or personal information without naming it here first.

3.1 Error Reporting

When something on the Platform breaks, we want to know what broke and where. The Platform can send a report of the failure to Sentry, an error-tracking service. Like the help assistant, this is a feature the Platform can be run with or without, so it may not be switched on when you visit. With the setting absent, nothing is sent from our servers and no error-tracking code reaches your browser at all.

A report describes the fault, not you. Before one is sent we drop the parts that would identify you: cookies, whatever you had typed into the form, the query string (sign-in links and one-time codes travel there), your IP address, and every request header except the three that say what format the request was in. We then run a text pass over the message, the stack trace, and the trail of recent activity, redacting email addresses and IP addresses wherever they turn up. What is left is the page path, the error, the code that produced it, and, for an error raised in your browser, a summary of the browser and operating system you were using, such as “Chrome 141 on Windows.”

Two things worth saying plainly. Your account’s internal ID can survive that scrub when it appears inside a message, because an error nobody can tie to a record is an error nobody can fix. It is an opaque identifier that means nothing outside our own database, and it is not your name or your email address. And we deliberately do not use Sentry’s session replay, which records the screen of the page you are on: these are pages minors are signed into, so no recording of your screen or your typing is ever made, let alone sent.

Part II: Visitors

This part applies to visitors who browse the Platform without an account. If you are a registered user, it also applies whenever you view public pages.

4. What We Collect From Visitors

When you visit public pages (club sites, public student and teacher sites, the main portal, public subplatform pages, the bug bounty page, the policies, the handbook, or the status page when it is published), we collect only what Part I, Section 2 describes: the infrastructure data Cloudflare provides on every request (Section 2.1) and standard request data (Section 2.2). We do not ask visitors to sign in, create an account, or share personal information to browse.

4.1 Public-Page Analytics

One measurement script runs on public pages, and it is the cookieless Cloudflare Web Analytics beacon described in Section 2.4. No cookie is set to measure your visit, you are not given a persistent ID, and nothing follows you from one page or session to the next, on this site or to any other. What it produces is aggregate counts of pages, countries, device types, and referring sites, plus page load timings. It does not run on published student sites.

Three other things are sometimes mistaken for analytics, and none of them is: the request logs in Section 2.1 and Section 2.2, which exist because a web server cannot answer a request without them; a per-item counter such as a wiki article’s read count, which is a single number kept on that article; and the error reports in Section 3.1, which are only created when something breaks. None of these is a profile of you, and none of them is joined up into one.

If per-page view and referrer counts are ever surfaced in a club’s own console, they will be aggregate counts of paths and referrers, never tied to an identified visitor, and this section will say so before that happens.

4.2 Form Submissions

Some public pages have forms, such as club sign-up forms, contact forms, report forms, and bug bounty sign-ups. If you choose to submit one, we collect what you enter. A club membership sign-up, for example, collects your name, email address, grade level, and any note you add. Public forms are protected by Cloudflare Turnstile, which may collect technical signals to tell humans apart from bots, and the Platform can also require your browser to complete a short calculation before the form will send, which collects nothing about you at all. Submissions are used for the purpose stated on the form and delivered to the people responsible for it (such as a club’s officers or the Developer).

4.3 Bot Detection and Security

The Platform uses automated bot detection and firewall rules that look at request characteristics to spot and block malicious traffic. This may weigh your IP address, request patterns, and headers. A request that looks harmful may be challenged, slowed, or blocked.

Part III: Registered Users

This part applies to people who create and keep an account. Everything in Parts I and II also applies to you.

5. Account Information

When you register, we collect:

• Your school email address (@cguhsd.org).
• Your first and last name, if you give them at sign-up.
• Your display name, and the handle you choose for your profile URL.
• Your role on the Platform (student, teacher, advisor, webmaster, treasurer, secretary, administrator, or developer).
• For students, a graduation year, where one has been recorded on the account. Student addresses are ID numbers rather than names, so this is not something we can read off the address.
• A profile picture, if you upload one. Without one, we generate a placeholder from your initials.
• Your language preference.

6. Signing In and Account Security

Signing in starts with a one-time code sent to your school email, which is also how an account is created. Codes are short (they expire after about ten minutes) and are stored only as a hash, never in plain text. A signed-in session lasts up to fourteen days before you have to sign in again, and you can end one at any time by signing out.

You can add a second factor to your account, and some roles are required to hold one. What we store depends on which you choose:

• Authenticator app. The shared secret, encrypted at rest. We never see the six-digit codes it generates beyond checking one.
• Passkey or security key. A public key and a credential ID, plus a label and a counter. The private key stays on your device and never reaches us. We do not receive your fingerprint, face, or device PIN.
• Password, used only as a second step after the emailed code. Stored only as a slow one-way hash, never in plain text and never recoverable. We use scrypt at the settings OWASP recommends, which is deliberately expensive in memory as well as time, so that guessing stored passwords in bulk stays costly even for someone with specialised hardware. When you set one, we screen it against a corpus of known breached passwords using a method that sends only the first five characters of a hash, so the service that answers cannot tell which password it was or whose (Section 3).
• Recovery codes. A short list of single-use codes, created for you when you add your first second factor so that losing a device does not lock you out of your account. They are shown to you once, when they are created, and stored only as a keyed one-way hash. We cannot show them to you again or read them back, only replace the set with a fresh one at your request.

Certain sensitive actions ask you to confirm again even during an active session, and those confirmations are logged. We record when each factor was added, last used, and removed. Section 22 of the Terms of Service covers your side of keeping an account safe.

7. Content You Create

We store what you upload, publish, or submit through the Platform, including:

• Files and pages on your personal site.
• Images, text, code, and media.
• Posts, articles, comments, replies, and reactions on the subplatforms.
• Content you add to club sites as a webmaster or authorized contributor.
• Settings, handle choices, and language preferences.
• Form submissions and bug reports.

7.1 Automated Safety Checks

Because this is a school platform, everything you post publicly is checked automatically for unsafe content before or shortly after it appears. This applies to writing, images, and video.

What the check looks for. Blocked language, hate speech, bullying and harassment, sexual content, violence, self-harm, weapons, and content that sexually exploits children. A check produces one of four results: your content is published, published but queued for a staff member to look at, held while it is reviewed, or hidden.

Who does the checking. The first pass happens on the Platform itself, using a blocked-word list that never leaves our servers. Content that passes that list is then checked by AI safety models run by Cloudflare, our hosting provider, which states that it does not use this content to train models. If Cloudflare’s checks are unavailable, the same content is sent to OpenAI’s moderation service as a backup so that your post is not left unchecked. OpenAI states that this endpoint retains nothing and that API data is not used to train its models.

What we keep. We record the result of every check, which model produced it, and a short excerpt of the content (currently up to 600 characters, or the text an AI model read out of an image) so that a staff member reviewing the decision can see what was actually posted. This record is part of our moderation records and is kept under Section 12.5.

A human can always overrule it. No account is suspended or disciplined by an automated check alone. Staff review flagged and hidden content and can restore it. If your content is hidden and you think the check was wrong, you can appeal under Section 24.4 of the Terms of Service, by opening a support ticket, or by contacting us using Section 26.

We do not use your content to profile you or advertise to you, and these checks are not used to make any decision about you other than whether a specific piece of content can appear on the Platform.

7.2 Reports You Make About Content

When you report someone else’s content, we record what you reported, the reason and any note you write, your account, and the time. We need your identity on the record so we can follow up, spot repeated bad-faith reports, and keep the review accountable. We do not tell the person you reported who reported them. Staff reviewing the report can see your identity. Reports are kept as part of our moderation records under Section 12.5.

7.3 Support Tickets

The Support tab in your console opens a ticket, which is a thread between you and the people who can act on it. We store the subject and every message in the thread, your account and display name, any files you attach, the time of each message, and which staff member took the ticket. Attachments are stored privately, not on any public page.

Who reads a ticket depends on what it is. An ordinary support ticket can be picked up by any administrator, and the Developer sees the same queue. A ticket an administrator raises with the Developer is read by the Developer alone. A ticket from a bug bounty researcher is read by the Developer alone, because its contents are unfixed security problems. A reviewer can also attach an internal note to a ticket, which is never shown to the person who opened it.

Tickets go through the same automated safety check as other content, but on a ticket the result is only shown to the reviewer and never blocks the ticket: the most important message anyone can send us is “here is what this person said to me,” and a filter that refused that one would be worse than useless.

7.4 What We Remove From Your Uploads

When you upload an image, the file’s metadata is stripped out on our side before it is stored, and the original is never kept. Cameras and phones write a surprising amount into that metadata: the GPS coordinates the photo was taken at, the device, sometimes the owner’s name, and a second small copy of the picture. None of it is visible in the photo, and all of it would otherwise travel with the file to anyone who downloaded it. The picture itself is not re-compressed, only the metadata blocks are cut out. This happens on every upload path on the Platform, not only in the gallery.

8. Activity and Security Data

To keep the Platform secure and to protect you if your account is ever misused, we log activity and security data tied to your account.

8.1 Activity Logging

Every action you take while signed in is logged: signing in and out, moving between dashboard and console pages, uploading and deleting files, editing content, changing settings, and renaming your site. Each entry records the time, your user ID, what you did, your IP address, the device signature described below, the session, and a request ID.

8.2 Device Recognition

To protect your account and catch unauthorized access, we read device details from your browser when you sign in and on certain sensitive actions. These include your screen size and color depth, timezone and language, hardware details (processor cores, memory, touch support), operating system and platform, your graphics chip (through your browser’s WebGL), and a couple of signatures derived from how your device draws a test image and processes a test sound. We combine these into a single device signature and, over time, build a picture of the devices you normally use, along with similar technical signals used to secure your account.

Why we do this: device recognition exists to protect you. If your account is ever used for something you did not do, we can compare the device signature on those actions against the devices you normally use. A mismatch is strong evidence that someone else was involved, which can keep you from being wrongly blamed. This is read without asking for a browser permission prompt, is visible only to Platform Administrators, and is never shown to other users.

8.3 Network and Connection Data

On every signed-in request, the Cloudflare data from Part I, Section 2.1 is tied to your session and logged with your activity, including your IP address (kept as-is), your network operator (ASN) and its classification (for example, whether it looks like a VPN, Tor, or a school network), your approximate location, the transport details of the connection (TLS version and a fingerprint of the connection, known as JA4), and the Cloudflare datacenter and Ray ID for the request.

For some accounts these details are stored only as keyed one-way tokens instead of as themselves. A token still tells us that two requests came from the same address, which is all the security trail needs, and it cannot be turned back into an address by anyone, including us. Which accounts that covers is a deployment setting; it is applied to the highest-privilege accounts by default, because those are the ones for whom a leaked database would otherwise be a home address.

8.4 Anomaly Detection

We watch for patterns that can signal a hijacked account or abuse, such as active sessions from several devices or places at once, unusually fast actions within a session, sign-ins from a network that is not your usual one, and requests to sensitive pages typed in directly rather than reached through normal navigation. These are logged as security events and used for looking into incidents afterward, not for automatically blocking you in the moment.

8.5 Extra Checks for Administrator Accounts

Accounts with administrative or developer access go through a stricter check before a console will load. On top of Section 8.2, it compares what your browser reports about itself against signals it cannot fake, including the fingerprint of the TLS connection, Cloudflare’s bot score, the browser hint headers your device sends, and a bot check you complete. It also looks for signs that a privacy or anti-fingerprinting tool is altering those readings. The result is recorded against your account. This applies only to elevated roles and never to ordinary student, teacher, or staff accounts. Section 27.3 of the Terms of Service covers the conditions that come with those roles.

9. Who Can See What You Post

Where your content shows up depends on where you put it:

• Public pages, such as club sites and public personal sites, can be read by anyone on the internet and by search engines.
• Member-only areas, including member profiles and some subplatforms, are visible only to other signed-in members of the Platform.
• Your profile shows your display name, handle, profile picture, and the content you have authored to other signed-in members. You can set your activity (what you have liked, saved, or backed) to private in your settings, which hides it from everyone but you. Content you authored stays visible, because it is already published.
• Platform Administrators can see everything, including content that is held, hidden, or deleted. See Section 11.2.

We do not offer end-to-end encryption anywhere on the Platform, and no area of it is private from Platform Administrators.

Part IV: How We Use Your Information

This part explains how we use the information described in Parts I, II, and III.

10. Why We Use Your Data

10.1 Running the Platform

We use your information to run the Platform: signing you in, managing sessions, hosting and serving content, enforcing storage and rate limits, handling your requests and settings, and sending the emails you need (login codes, account notices, expiry reminders, moderation notices).

10.2 Security and Abuse Prevention

We use your information to detect, investigate, and prevent unauthorized access, fraud, abuse, and policy violations. That includes building device signatures, watching for anomalies, enforcing rate limits, keeping threat blocklists, and looking into incidents. This security trail protects both the Platform and you.

10.3 Content Moderation and Safety

We use automated tools and human review to check content against our policies and applicable law, as Section 7.1 describes. Content may be flagged, held, or removed as a result.

10.4 Metrics and Improvement

The Developer may use metrics and usage data to understand how the Platform is used, to improve it, and for the Developer’s own learning and research, provided that data is aggregated, de-identified, and contains no personal or sensitive personal information. Error reports help us find and fix technical problems.

We never sell or rent your data, and we never use it for advertising or marketing of any kind. Not now, not ever.

10.5 Legal Obligations

We use your information to comply with the law, to respond to lawful requests, and to meet records obligations that apply to us.

Part V: How We Share Your Information

11. How Sharing Works

We share your information only in the four ways below. We show no advertising and share nothing with advertisers or data brokers.

11.1 Service Providers

We share data with the providers listed in Section 3, only for the purposes described there. They handle it on our behalf and under their own terms and privacy policies.

11.2 Platform Administrators

Platform Administrators, meaning the Developer and any IT administrator the Developer designates, can access Platform data, including account information, content, activity logs, device records, and moderation records. This access is needed to run, secure, and moderate the Platform. Where a detail is stored as a one-way token under Section 8.3, an administrator sees the token, not the value, because there is nothing to decrypt it with.

11.3 Audit Records

Platform events are logged to a separate, access-controlled audit database kept apart from the main application so that the record of administrative actions stays intact and accountable. This protects everyone by keeping a reliable trail of who did what.

11.4 Legal Requirements

We may disclose your information if the law requires it, or if we believe in good faith that doing so is needed to protect the rights, property, or safety of the Platform, its users, or the public.

Part VI: Data Retention

12. How Long We Keep Data

12.1 While Your Account Is Active

We keep your account information, content, activity logs, device records, and security events for as long as your account is active, so that the Platform works and so that a security question about your account can still be answered later.

12.2 Account Expiry

When an account expires (graduation for students, term expiry for teachers, or administrative deactivation):

• Your access ends and your sessions stop working.
• Your site content is archived before it is removed from active storage.
• Your profile is marked deleted, which takes it off the Platform, and the underlying record stays until it is swept.
• Archived content is kept until a deletion runs, and is then destroyed on the schedule in Section 12.7.
• Audit entries tied to your account (activity logs, security events, device records) are kept for the record.

Being honest about the last two: expiry is not itself a deletion, and it does not start a purge of everything left behind. What it does is end access and archive the content. A deletion starts when you ask for one under Section 13.5, when you delete something yourself, or when an Administrator deletes it, and from that moment it runs on the schedule in Section 12.7.

12.3 Visitor Data

Routine request data from visitor traffic is kept in logs for a limited period and is not archived long-term. Security events are the exception and are kept in the audit records.

12.4 Form Submission Data

Data from public forms is kept for the purpose of the form (such as membership tracking, event management, or bug reports). Support tickets and their attachments (Section 7.3) are kept as part of that record so a later ticket can be read alongside an earlier one.

12.5 Security and Moderation Records

Audit entries, security events, and records of moderation actions and reports are kept as our lasting record and are not routinely deleted. Where an investigation needs a bundle of that evidence assembled in one place, the bundle is deleted after 90 days, though the underlying records it was built from remain.

When content is taken down for good, the evidence of what it was is captured first, and two different things exist from then on. One is the preserved copy of the content itself. The other is the record of the decision: what was removed, when, by whom, under which rule, and a fingerprint of the content. They are kept for different lengths of time, on purpose.

The preserved copy is kept for up to one year and is then destroyed. An Administrator can destroy it sooner by arming a permanent deletion, which runs on a 72-hour clock and can be cancelled by any Administrator until it runs out. The record of the decision outlives the copy and stays as part of the lasting record described above, because a decision nobody can look up afterwards is not a decision anyone can be held to.

Two things run the other way and pause any clock in this part. Where the law requires us to preserve something for longer, such as a report we are obliged to make and to keep, and where an authority has asked us in a form the law recognizes to hold something while it is looked into, nothing is destroyed until that lifts.

Being straight about where this stands today: the 72-hour clock is built and runs on its own. The one-year limit and the holds above are applied by hand until the sweep that enforces them is built, and this section will say so until that is true.

12.6 Backups

The databases are snapshotted nightly and those snapshots are kept for 100 days. Copies of uploaded files are backed up separately and kept for 45 days. Backups exist to bring the Platform back after a failure, they are not searched for ordinary requests, and they are the reason deleting something does not always make every copy of it vanish at once: a deletion reaches active storage immediately and works its way out of the backups as they age out.

Counting from the day a deletion actually runs, the last database snapshot holding a copy ages out 100 days later and the last file backup 45 days later. That is where the outer dates in Section 12.7 come from. In between, the copy sits in a backup we do not open, do not search, and do not use for anything except bringing the Platform back.

One consequence worth stating plainly. If we do restore from a backup after a failure, anything deleted since that snapshot was taken comes back with it. We re-apply those deletions by hand once the Platform is up, and until an automatic re-apply is built, that is the honest description of it.

12.7 The Deletion Schedule

Deleting is not one thing, so it does not run on one clock. Which of the three below applies depends on what started it.

You delete something yourself, or an Administrator deletes it. It leaves the Platform straight away and nobody can reach it there. It stays recoverable for 30 days, so that a mistake can be undone, and it is destroyed at the end of that. Counting the backups in Section 12.6, the last copy anywhere is gone within 130 days.

You ask us to erase your personal information. There is no 30-day hold. We act within 7 days of verifying the request, because a grace period exists to let you change your mind and you have just told us you will not. Counting the backups, the last copy is gone within 107 days. Section 13.5 sets out what the sweep reaches and the two things it does not.

We removed something because it broke the rules. The preserved copy is kept for up to one year under Section 12.5, so that an appeal, a complaint about how we handled it, or a lawful request has something real to look at, and the record of the decision is kept after the copy is gone. You have 30 days to appeal, under Section 24.4 of the Terms of Service.

Any of these can be paused. If the law requires us to keep something, or an authority has asked us to preserve it, the clock stops until that lifts, as Section 12.5 explains.

Two of these three periods are enforced by hand today rather than by a sweep that runs on its own. That is a gap in the Platform, not a gap in the promise: the periods above are what we hold ourselves to, and Section 12.5 names which part is automatic.

Part VII: Your Rights and Choices

13. Registered User Rights

13.1 Access and Correction

You can view and update account details like your display name, handle, profile picture, and language from your dashboard. To ask about other information we hold about you, contact the Developer.

13.2 Login History

Students and teachers can view a summary of recent sign-ins (time, rough city, and device type) from the dashboard. This helps you spot access you did not make.

13.3 Reporting a Compromised Account

If you think someone accessed your account without permission, report it through the compromised-account process or by contacting the Developer. We will secure your account and review the audit trail to work out whether disputed actions were yours.

13.4 Content Removal

You can delete your own content from the dashboard. It leaves the Platform straight away, stays recoverable for 30 days in case you did not mean it, and is destroyed after that, on the schedule in Section 12.7. Deleted content may remain in backups, archives, and audit logs for the periods named in Part VI.

13.5 Deletion Requests

You can ask us to delete personal information we hold about you, and unless we are required to keep it, we act within 7 days of verifying the request rather than holding it for the 30 days in Section 12.7. Verifying usually means confirming that you control the school email address on the account.

The deletion sweep we run removes your account record and profile, your personal site and its files, your profile picture and other uploaded profile assets, your club memberships, your support tickets and their attachments, and your device and fingerprint records. Two things it does not reach on its own, so you should know about both. Content you posted on a subplatform, such as an article, a post, or a comment, is not swept by it: you can delete that yourself, and where you cannot, say so in your request and it is removed by hand. And it keeps the governance audit trail, meaning the record of who did what on the Platform, along with the moderation records under Section 12.5, because those protect everyone and stop being a reliable record the moment the person they are about can edit them.

We will tell you if we cannot fully honor a request and why. Closing your account is covered by Section 22.5 of the Terms of Service.

14. Cookies, Tracking Signals, and Your Choices

You can clear or block cookies in your browser. Blocking essential cookies will break signing in and some security features. The theme cookie only remembers your light or dark preference and is safe to clear.

We do not track you across other websites, so browser signals aimed at cross-site tracking have nothing here to act on. We do not respond to Do Not Track headers, because there is no tracking to switch off. The same is true of Global Privacy Control, as Section 21 explains.

Device recognition and the security checks in Section 8 are not optional while you are signed in. They are how the Platform tells your session apart from someone using your stolen cookie, so there is no way to opt out of them and keep an account.

15. Visitor Rights

Visitors who want to ask about data collected during a visit can contact the Developer using the details in Section 26. Because visitor data is not tied to an identified person (no accounts, no persistent IDs), specific access or deletion for visitor data may not be possible.

Part VIII: Special Provisions

16. Children’s Privacy

The Platform is meant for students and staff of Vista Grande High School and is not intended for children under 13. We do not knowingly collect personal information from children under 13. If we learn that we have, we will delete it. A parent or guardian who believes we hold information about a child under 13 can contact us using Section 26 and we will remove it. The age rules for holding an account are in Section 21.2 of the Terms of Service.

17. Education Records (FERPA)

The Family Educational Rights and Privacy Act (FERPA, 20 U.S.C. § 1232g and 34 CFR Part 99) protects the privacy of student education records and applies to schools that receive federal funding. VGSpartans is an independent student project, not the School or District, so the Developer is not a “school official” and is not the custodian of anyone’s education records. The Platform is not itself subject to FERPA. If any information here would count as an education record, the School remains its custodian, and parents and eligible students exercise their FERPA rights by contacting the School directly.

18. Data Security

We use reasonable administrative and technical measures to protect your information, including:

• All traffic between your browser and the Platform is encrypted with TLS.
• Login codes and recovery codes are hashed before storage, and passwords are stored only as a slow, memory-hard one-way hash (Section 6).
• Session tokens are stored as a hash, so a stolen copy of the database does not hand anyone a working session.
• Authenticator secrets are encrypted at rest, and passkey private keys never leave your device.
• Metadata is stripped from uploaded images before they are stored (Section 7.4).
• Administrative actions require an extra confirmation step.
• The Platform sits behind DDoS protection, a firewall, bot detection, rate limits, and threat intelligence.
• Access to data is limited by role, on a need-to-know basis.
• Administrative actions are recorded in the audit trail.

If a security breach ever affects your personal information, we will notify you consistent with Arizona law (A.R.S. § 18-552), which calls for notice within forty-five days of determining that a breach occurred, and with any breach-notification law that applies to you where you live if it requires more.

No method of transmission or storage is perfectly secure, so we cannot promise absolute security, but we take it seriously.

19. Where Your Data Is Handled

Our infrastructure runs on Cloudflare, a United States company with datacenters worldwide. Your data may be processed at any Cloudflare location and stored on servers in the United States. Our other providers may also process data outside your area. Using the Platform means your data is handled this way. If you are protected by a law that restricts international transfers, Section 22 explains the safeguards we rely on.

Part IX: Your Regional Privacy Rights

This part gives extra detail and extra rights to people in certain places, including California, the European Economic Area, the United Kingdom, Switzerland, and other US states. It adds to the rest of this Policy and takes nothing away from it. Section 20 explains which of these laws bind us and which we follow because we choose to.

20. How These Rights Apply

The law we are actually under. The Platform is built and run in Arizona, for a community in Arizona, and Arizona law is the law it answers to. Arizona has no comprehensive consumer privacy statute: there is no Arizona equivalent of California’s right to demand a copy of your data or its deletion. What Arizona does put on us, we follow. That means keeping reasonable security around personal information and telling you if it is ever breached, within the forty-five days A.R.S. § 18-552 allows, as Section 18 sets out. Where a federal law reaches us, such as the rules on children under 13 in Section 16, the same is true.

Why the laws in this Part probably do not reach us. Privacy laws like California’s and Europe’s are written mostly for commercial businesses that meet size or activity thresholds, and several of them do not cover non-commercial activity at all. VGSpartans is an independent, non-commercial student project. It earns no revenue, shows no advertising, and does not sell or share personal information, so it does not meet the definition of a “business” under California law, which the California Attorney General describes as applying to for-profit entities over set thresholds, and it does not meet the size thresholds most of these laws set. It is very likely outside their formal scope, and we would rather tell you that than let you assume otherwise.

What we do about that. None of it is a reason to give you less, so we do not. We extend the rights in the sections below to anyone who asks, wherever you live, because people take part in things like our bug bounty program and testing from many places, and because these rights are fair whether or not a statute makes them compulsory. We would rather answer a request we did not have to answer than hide behind a threshold.

The one thing we will not overpromise. There is no support department here. One student runs this alongside school, and there will be stretches when nobody is at the keyboard. So where we are extending a right voluntarily, this is the commitment: we will do what is reasonably practical and feasible for us to do, in good faith and as quickly as we can manage, and where a request reaches something we cannot do, we will tell you plainly what we cannot do and why, and then do the part we can. Read those sections as a genuine undertaking to try, not as a guarantee of a particular result or a particular date.

Where a law does bind us, it wins. If one of the laws in this Part applies to us by its own terms, that law controls, its deadlines and duties are the ones we are held to, and the practical-and-feasible wording just above it does not cut down anything it gives you. The same goes for any mandatory rule of the law where you live. And asking us to exercise a right never counts against you: we will not deny you service, charge you a different price, or treat you differently for making a request.

21. California Residents (CCPA and CPRA)

This section is for California residents and reflects the California Consumer Privacy Act as amended by the California Privacy Rights Act. This Policy, including this section, serves as our notice at collection.

Categories we collect. California’s law asks for a twelve-month look-back, and we do not have twelve months to look back on. Work on this project started in June 2026, which is a matter of public record in the repository, and it has collected nothing from anyone before then. Rather than describe a year that has not happened, the table below lists every category the Platform is built to collect, described in more detail in Parts I to III. For as long as the Platform is younger than a year, that table is also the complete record of everything it has ever collected, which tells you more than the look-back would have.

Statutory category	Do we collect it?	Sold or shared?
Identifiers (name, school email, handle, user ID, IP address, device signature, request IDs)	Yes	No
Customer records (name and email in account and form data)	Yes	No
Internet or network activity (page views, request logs, activity and security logs)	Yes	No
Geolocation (approximate city and region from your IP, never precise GPS)	Yes	No
Audio, electronic, or visual information (images, files, media, and a profile picture you upload)	Yes	No
Professional or education-related information (your role, and a grade or graduation year where one is recorded)	Yes	No
Sensitive personal information (account log-in credentials, described below)	Yes	No
Inferences (the picture we build of the devices you normally use, for security only)	Yes	No

We do not collect the other statutory categories, such as biometric information, precise geolocation, or financial account numbers.

Sensitive personal information. California treats account log-in credentials as sensitive personal information, and that is the one sensitive category we hold: the hashed second-factor password, encrypted authenticator secret, passkey public key, or hashed recovery codes described in Section 6, together with the school email address they protect. We also log your IP address and rough location for security. We do not collect a Social Security number, precise geolocation, racial or ethnic origin, religious beliefs, health data, or the contents of your mail, and we do not use or disclose sensitive information to infer characteristics about you. Because we only ever use it to sign you in and secure your account, which is a use California exempts from the right to limit, exercising that right would not change how we operate, but you may still contact us about it.

Sources and purposes. We collect this information from you directly, from your browser and device, and from Cloudflare as each request passes through it. We use it for the business purposes set out in Part IV: running the Platform, security and abuse prevention, content moderation and safety, aggregated metrics, and meeting legal duties.

No sale or sharing. We have never sold personal information and have never shared it for cross-context behavioral advertising, not in the past twelve months and not at any point since the project started, and we never will. We show no advertising and work with no ad networks. Because we do not sell or share, there is nothing for an opt-out preference signal such as Global Privacy Control to act on, and we do not publish a “Do Not Sell or Share My Personal Information” link because none is needed. We also do not knowingly sell or share the personal information of anyone under 16.

Your California rights. You have the right to know the categories and specific pieces of personal information we hold about you, the right to delete it, the right to correct inaccurate information, and the right not to be treated differently for exercising any of these rights. You also have the right to opt out of the sale or sharing of your information and to limit the use of sensitive information, though as explained above neither changes how we run the Platform.

Shine the Light. California’s “Shine the Light” law (Civil Code section 1798.83) lets residents ask about personal information shared with third parties for those parties’ own direct marketing. We do not share personal information for third-party direct marketing, so there is nothing to disclose.

California minors. If you are a registered user under 18 and a California resident, Business and Professions Code section 22581 gives you the right to remove, or to ask us to remove, content you posted publicly. Here is how: most of your own content you can delete yourself from your dashboard, and where you cannot, open a support ticket or email the Developer at the address in Section 26 saying what you want taken down and where it is. As that section itself requires us to tell you, removal is not necessarily complete: it takes the content off the Platform, and it does not reach copies kept in backups (Section 12.6) or in the audit and moderation records (Section 12.5).

How to make a request. Because we operate only online and deal with you directly, you can exercise any of these rights by emailing the Developer at the address in Section 26. To protect your account, we will verify a request against information we already hold, usually by confirming that you control your school email. You may use an authorized agent, who must show your written permission. We will respond within 45 days and may take up to 45 more if we tell you why. There is no fee unless a request is clearly unfounded or excessive.

22. European Economic Area, United Kingdom, and Switzerland (GDPR)

This section is for people whose personal data is protected by the EU General Data Protection Regulation, the UK GDPR and Data Protection Act 2018, or the Swiss Federal Act on Data Protection.

Article 3 reaches a controller outside the Union that offers goods or services to people in it, or monitors their behaviour there. We do neither: the Platform is built for one school in Arizona and is not aimed at anyone in Europe, so we do not believe the GDPR applies to us by its own terms. Where it does apply, this section is a legal obligation and every deadline in it binds us. Where it does not, we follow this section anyway, on the footing set out in Section 20.

Data controller. The Developer is the controller of personal data processed through the Platform, and you can reach the Developer using the details in Section 26. Given the small size and nature of this project, we have not appointed a data protection officer or an EU or UK representative, and we do not believe we are required to.

Legal bases. When a law in this group applies, we rely on these bases from Article 6 of the GDPR:

What we do	Legal basis
Create your account, sign you in, host and serve your content, and provide the features you ask for	Performance of a contract with you (Article 6(1)(b))
Register and verify a second factor you choose to add, and screen a password against known breached passwords	Performance of a contract, and our legitimate interest in account security (Article 6(1)(b) and (f))
Secure the Platform: device recognition, the extra checks on administrator accounts, anomaly detection, rate limits, threat blocking, and audit logging	Our legitimate interest in keeping the Platform and its users safe, and yours in not being wrongly blamed for someone else’s actions (Article 6(1)(f))
Moderate content for a school-appropriate, lawful platform, and handle reports about content	Our legitimate interest in a safe community, alongside compliance with legal duties (Article 6(1)(f) and (c))
Send account and security emails, such as one-time codes and notices	Performance of a contract, and our legitimate interest in security (Article 6(1)(b) and (f))
Count page views and page speed without cookies or identifiers, and diagnose a failure from the error reports in Section 3.1	Our legitimate interest in a Platform that works and stays fast, weighed against a measurement that identifies nobody (Article 6(1)(f))
Handle a form you choose to submit, ask the help assistant a question, or load content from an embedded third party	Your consent, given by choosing to submit or interact, which you can withdraw (Article 6(1)(a))
Keep audit and moderation records, respond to lawful requests, and notify you of a breach	Compliance with a legal obligation, and our legitimate interest in accountability (Article 6(1)(c) and (f))

We do not ask for or intentionally collect special category data (such as data about health, race, religion, or sexual orientation). Please do not post it.

Your rights. You have the right to access your data, to have it corrected, to have it erased, to restrict or object to how we use it, to receive it in a portable form, and, where we rely on consent, to withdraw that consent at any time without affecting what came before. To exercise any of these, contact the Developer at the address in Section 26; as Article 12(3) provides, we will respond within one month and may extend that by two further months for complex requests, telling you why within the first month. Where the request is erasure and nothing requires us to keep the data, we do not treat that month as a waiting period: Article 17 says without undue delay, so the erasure itself runs within 7 days of verifying you, on the schedule in Section 12.7. Copies in backups are a documented exception to that: we put them beyond use rather than open a backup to reach them, and they age out on the dates in Section 12.6. Some data we must keep, such as security and audit records that protect everyone, and we will explain when that limits what we can do.

Automated decisions. Our automated safety checks look at content, not at you, and no account is ever suspended or disciplined by an automated check alone (see Section 7.1). We do not make decisions producing legal or similarly significant effects about you based solely on automated processing, so the Article 22 right does not arise; even so, a human reviews and can overturn any moderation outcome.

International transfers. The Platform is operated from and hosted in the United States, so using it means your data is transferred there and to the other places our providers operate. Where a transfer of data protected by these laws leaves the EEA, UK, or Switzerland, we rely on the European Commission’s Standard Contractual Clauses (Implementing Decision (EU) 2021/914), the UK’s International Data Transfer Agreement and its Addendum to those clauses, and equivalent safeguards, together with the protections providers such as Cloudflare offer, so that your data keeps a comparable level of protection.

Complaints. If you think we have mishandled your data, we would like the chance to put it right, so please contact us first. You also have the right to complain to your local supervisory authority, such as your country’s data protection authority in the EEA, the Information Commissioner’s Office in the UK, or the Federal Data Protection and Information Commissioner in Switzerland.

23. Other United States State Privacy Rights

Every one of these laws is written for organizations above a size threshold, usually a hundred thousand residents’ data in a year, and several of them exempt non-commercial activity or small businesses on top of that. A platform for one high school is not close to any of those lines, so we do not believe a single one of these laws reaches us. You are being told that rather than left to work it out, because it is the difference between a right you can enforce against us and a courtesy we choose to extend.

We extend it. If you live in a US state with its own consumer privacy law, such as Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, or one of the other states whose laws have since taken effect, ask us and we will treat your request as though the law did reach us, as far as it is practical and feasible for us to do: confirm whether we process your personal information, give you access to it, correct it, delete it, or give you a portable copy. The three opt-outs those laws provide, from the sale of personal information, from targeted advertising, and from certain profiling, have nothing here to act on, because we do none of the three. Make a request, or appeal one we decline, by contacting the Developer using Section 26; if we deny an appeal, we will tell you how to raise it with your state attorney general. Where your state’s law does apply to us by its own terms, its deadlines are the ones we keep. Nevada residents may ask us not to sell their covered information under NRS 603A.345, which we do not do in any case.

24. Other International Users

The Platform is run for a community in Arizona, in the United States, and is not aimed at any particular country abroad. If you use it from outside the United States, such as to take part in the bug bounty program or testing, you do so on your own initiative and are responsible for following your local law. Whatever protections your country provides, such as Canada’s PIPEDA, Brazil’s LGPD, or Australia’s Privacy Act, we will work with you in good faith rather than point at a map. The simplest path is to contact the Developer using Section 26, and we will do what is practical and feasible for us to let you see, correct, or delete the limited data we hold about you. If a request needs something we do not have, whether that is a presence in your country, a language we can read, or a person free that week, we will say so and do the part we can.

Part X: General

25. Changes to This Policy

We may update this policy from time to time. If we make a meaningful change, we will update the “Last updated” date above, and for registered users we will also flag it in the Platform (for example, a dashboard banner or a notice at sign-in). Continuing to use the Platform after a change means you accept the updated policy. Please check back now and then.

Because this policy is a file in the public repository, every change to it is a matter of record. The “Edit this page on GitHub” link at the bottom of this page opens the file itself, which is also how you tell us a sentence in here is wrong.

26. Contact

If you have questions, concerns, or requests about this policy or how we handle data, contact:

Developer: developer@dev.vgspartans.org

If you have an account, a support ticket reaches the same people and keeps the thread in one place.