Privacy Policy

Current scope

The public website and these notices are available at campusactivityscan.com. The connected attendance app and public demonstration are available at app.campusactivityscan.com. Browser-stored pending entries and analytics choices belong to the site address and browser where they were created.

Campus Activity Scan supports staff-supervised club and activity attendance. The public demonstration is separate from the connected app: it does not sign in, write attendance to Google Sheets, or send its scanned IDs to the demo quota service.

Use with student records requires prior school approval and review of the intended data handling, agreements, and operational safeguards. Account access or this notice does not establish district authorization or regulatory compliance. Provider storage locations and complete retention and recovery arrangements must be confirmed for the proposed use.

Information the connected app uses

Google sign-in requests basic identity permissions (openid, email, and profile). Google and Supabase Auth may process basic profile information, such as a name or profile picture, alongside a verified email address and stable account identifiers. Campus Activity Scan account records use the verified email, available profile name, Google/Supabase identifiers, and available last sign-in time for sign-in, account administration, eligibility, invitation matching, and access controls; they do not establish employment or educator status. An enabled account is not evidence that the person is currently online.

The app stores location memberships, permissions, activity settings, default-activity preferences, invitation details, and the connected spreadsheet identifier to operate the service. Access requests also store the requesting account, request and decision times, status, and any location, role, permissions, or activity assignments selected by an authorized reviewer.

Invitation records can include a sending-attempt history with attempt and provider-acceptance times, provider email references, sending outcomes, and link versions. Authorized retrieval is limited to the manager's location; the manager interface shows access status and invitation controls rather than provider technical details. Resending retains earlier recorded attempts; older invitations may lack this information. An unknown outcome is not proof of a failure, and provider acceptance is not proof of inbox delivery. Current invitation tokens are encrypted server-side alongside verification hashes so authorized managers can retrieve usable links.

An attendance submission includes the student ID, activity, check-in or checkout action, original capture time, time zone and offset, and identifiers needed for authorization and duplicate protection. Google Sheets receives the attendance event and staff email. The app does not require student names, enrollment records, GPS, or an Infinite Campus connection. A valid ID format does not establish identity or enrollment.

An authorized location manager can save a required numeric ID length from 1 to 32 digits and choose whether to remove nonnumeric scan characters before validation. The default remains seven digits with general cleaning off; the compatible one-letter legacy rule remains available. Leading zeros are retained as text. Only a validated numeric ID is queued and submitted, not the raw barcode content. Settings apply to future scanning sessions; a queued ID keeps its original server-issued scan policy and is not reidentified after a settings change.

Camera and device storage

Camera images are decoded on the device. Application code does not upload or retain camera images. Camera permission is optional because an authorized staff member can also enter an ID manually.

The connected app encrypts pending attendance payloads in browser storage, isolated to the original account. Account and scan identifiers and the capture time remain storage metadata. The app also uses necessary session cookies and device preferences, such as sound settings. Clearing browser data or losing the original device can remove pending work before delivery.

A separate encrypted personal Today log stores submissions made by the signed-in account in this browser, including student ID, action, location/activity identifiers, capture time, and delivery status. Account/scan identifiers and the attendance day remain metadata. Today does not retrieve other users' submissions or the same account's submissions from another device.

Google file access

An authorized manager separately connects Google using the drive.file permission. The app keeps the original authorized spreadsheet connected. Google permission applies to the authorized file, not only its Data tab or visible columns.

When a manager chooses an existing file, the app lists names and identifiers of spreadsheets available to it under drive.file. It reads spreadsheet structure and system metadata to verify the connected file and its attendance tables, and reads or writes attendance and Review records to deliver scans, detect duplicates, and support authorized manager review. It does not request access to all files in the manager's Drive.

The app reads attendance and reserved Review fields for delivery, matching, and manager review; it does not request unrelated workbook analysis. Sensitive information entered into those attendance fields can still be read. Google refresh credentials remain encrypted on the server and are not supplied to advisors.

Google file sharing is separate from app permissions. Removing an advisor or manager in the app does not remove direct or group-based Google access. Managers must review Google sharing separately.

You can remove Google authorization through your Google Account's third-party connections settings. Removing access can interrupt spreadsheet delivery and require reauthorization. It does not delete existing spreadsheet records or automatically delete account information already stored by the service. Signing out of Campus Activity Scan is separate from revoking Google authorization.

Who can access information

The server checks account eligibility and location permissions. Advisors and higher roles can submit attendance within their authorized scope and view their own submissions from this browser in Today. For every role, including the platform owner, Today excludes other people's submissions and submissions from other devices. Advisors follow the location and activity selected in Scan; managers can filter their own device log within their managed scope. Duplicate checks do not disclose another person's attendance details.

Full attendance records remain in Google Sheets. App roles do not automatically grant direct spreadsheet access. Advisors do not receive Google credentials or spreadsheet links from the app; opening the spreadsheet requires independently granted Google permissions.

Invitations are bound to the exact verified Google account, expire, and must be accepted before they grant location access. A joining code creates an approval request; possessing it alone grants no access. General access requests go to the Platform Admin, and location requests go to authorized location managers. Sign-in and eligibility alone do not grant a school membership or manager role. Recent authenticator verification protects privileged changes.

Authorized managers can explicitly resend an invitation or create a replacement link. Both invalidate the previous link and start a fresh 48-hour lifetime without changing the recipient or assignments. Link-only replacement sends no email. Managers can retrieve and copy available current links without rotating them, extending expiry, or sending email. Repeating an ordinary invitation submission reuses the matching pending record without sending another email. Recovery actions are rate-limited and recorded in the security audit.

Advisor-only accounts do not require an additional in-app authenticator step for ordinary authorized use. Accounts with an active manager or administrator role must enter an authenticator code in the app after each new Google sign-in, before protected app access. The highest active role across all locations applies, even when the selected location lists the person as an advisor. An enrolled authenticator or Google sign-in alone does not complete this step.

Authenticator verification for manager and administrator access is bound to the current app session and has a fixed 60-minute window, ending earlier on sign-out, session expiry, revocation, or invalidation. Navigation and token refresh do not extend that window. A fresh code is required at its end, after a new sign-in, or when promotion invalidates the prior grant. Adding an authenticator factor retains a separate 10-minute security check. These checks do not grant permissions or remove pending attendance storage; the underlying session still lasts at most 12 hours.

Access-request notification emails contain a generic request or decision message and an app link, not student attendance or private school details. Review links require sign-in and current authorization. Opening an email link does not approve a request or change permissions; decisions are made in the app.

A saved default activity is a preference for that account and location, not an access grant or a change to another advisor's selection. The server accepts preferences only for available activities and current scanning permission. Revoking location membership prevents new submissions and delivery of old queued scans under that membership; re-invitation does not revive that queued work. Attendance already written to Google remains for manager correction.

Platform administrators, not location managers, can disable or re-enable an account after recent authenticator verification, explicit target confirmation, and an internal reason. Disabling blocks protected app requests and invalidates existing app sessions. Unconfirmed uploads from that account are held for authorized review within their original expiry; already confirmed attendance is not deleted. Re-enabling requires a fresh sign-in and applicable authenticator verification, does not restore separately revoked memberships, and does not automatically replay held uploads. Independent Google spreadsheet permissions are unchanged.

A disable notice goes to the account's verified email with the public support contact. It excludes the internal reason and student attendance. Platform administrators can inspect the action and notification status; email failure does not undo the suspension. Provider acceptance is distinct from confirmed inbox delivery.

Retention and delivery limits

The 24-hour pending deadline is not a promise that all app data is deleted within 24 hours. Different information has different purposes and retention behavior.

Green Captured—confirmation pending acknowledges a durable local check-in save, not a Google Sheets write. Local capture, server acceptance, and confirmed Sheets delivery are separate stages. Retries preserve the original event and reconcile uncertain responses before another append; independent submissions can continue while one visit needs attention. Checkout waits for its matching pending check-in and must satisfy the same-day, location, and activity rules. Keep the browser open and connected, or reopen it before expiry; phone-lock or closed-app delivery is not guaranteed.

• Pending attendance: removed from the separate pending queue after a terminal outcome, or expired 24 hours after its original capture. Original timestamps, attribution, and destination are retained for retries. Expired submissions are rejected before upload and reported as delivery failures, not saves. Browser suspension can delay local cleanup; background delivery is not guaranteed.
• Personal Today history: follows the existing device-local attendance day, not a rolling 24-hour window. Older history is removed from its separate browser log at day change or on the next open/resume. Midnight does not delete spreadsheet rows or cancel pending uploads. Older unresolved captures remain in the pending queue until their existing 24-hour deadline and are reported separately, without appearing in Today.
• Minimal delivery receipts: retained until 25 hours after capture to prevent unsafe repeat writes. They contain a scan identifier, keyed digest, outcome, and retry or issue metadata, not the raw student ID or attendance payload. Cleanup runs when the service executes.
• Google Sheets: attendance and Review records remain in the connected spreadsheet under the manager's control. Signing out does not delete the spreadsheet or its records.
• Accounts and configuration: account identifiers, memberships, file bindings, connection credentials, and related settings persist. A complete verified account-deletion and recovery workflow remains unfinished.
• Access requests and notifications: request and decision records, suspension-notice recipient addresses, generic message payloads, provider references, delivery states, attempt counts, and timestamps remain with the account/request records. They do not have a separate automatic deletion period. The shorter security-audit retention rule does not delete these records.
• Security records: permission-change and account disable/re-enable audit entries contain actor and target identifiers, action, and time; suspension actions also include an internal reason. Entries older than 90 days are removed when an audit update or scheduled cleanup executes; this is not exact-time physical erasure. Sessions have a 12-hour limit, and invitation links expire after 48 hours.
• Current invitation tokens are encrypted server-side alongside verification hashes; only authorized managers can retrieve usable links, and the manager interface does not persist them in browser storage. Eligible expired pending invitation metadata, including available sending timestamps and provider references, remains renewable for seven days after expiry and is removed during subsequent service cleanup. Expired encrypted tokens are discarded during cleanup; accepted or revoked invitations cannot be renewed. Explicit resend or replacement starts a fresh 48-hour link lifetime. Provider email records follow the provider's separate retention settings.
• Provider logs, backups, and recovery copies can follow different retention periods. Their full settings, deletion behavior, and storage regions must be confirmed before school use; the application retention limits above do not describe every provider copy.

Services used

Cloudflare hosts the app and its server-side configuration and delivery records. Supabase Auth supports account authentication and authenticator verification. Google supplies sign-in and the connected Drive and Sheets services. Resend processes advisor invitation emails, including the recipient, location name, and activation link, generic access-request review and decision notifications, and account-disable notices. These emails do not include student attendance. Access and suspension notifications use info@campusactivityscan.com as the reply-to support contact.

Saving a request or invitation, the email provider accepting a message, the recipient receiving it, and granting access are separate outcomes. A provider-accepted status does not establish inbox delivery or location membership. Missing email configuration, rejection, and uncertain delivery are not reported as a successful send. Access requests remain available in the authorized review dashboard even when notification delivery fails; notification retries do not approve a request.

These providers process information needed for their roles, including technical request information. Application-level deletion does not establish deletion from every provider log or backup. This notice makes no claim of a single storage country or completed district data agreement.

Authentication and operational security providers may record account and session references, timestamps, IP addresses, browser/user-agent information, and authentication outcomes to operate and protect the service. These necessary provider records are separate from optional usage analytics and may exist when analytics is declined; provider-specific retention applies.

Public demonstration

Use fake student IDs only. Do not enter real student information.

The public demo presents Advisor-style scanning, Today and personal preferences, plus a limited Manager settings preview for adding activities to this demo only. It does not provide real account management, spreadsheet configuration, authenticator setup or platform administration. Its capture, delivery, duplicate handling, checkout verification, and Today outcomes are simulated in this browser. Confirmed (demo) never means a Google Sheet was updated. No account, school membership, spreadsheet connection, or authenticator enrollment is needed.

Fictional demo attendance and activities added in the Manager settings preview stay in this browser's memory and clear after 60 minutes of inactivity, on an overdue return if the browser was suspended, or when the demo is reset or reloaded. These changes do not affect other visitors or the connected app. Demo Today shows only this browser's submissions for the activity selected in Scan and the current device-local attendance day; it resets on day change or resume. The demo does not offer an offline durable-delivery guarantee.

The demo permits 100 valid scan attempts per public IP address per UTC day. People on the same school or home network may share that allowance. The server uses a day-specific keyed IP pseudonym and random attempt identifiers for the counter; the counter does not store the raw IP or scanned student IDs. Active counter storage expires at the daily reset, subject to service execution and provider recovery retention.

Optional usage analytics

The public website, demonstration, and connected app offer optional Google Analytics to understand which sections and features people use and improve the product. It loads only after you allow it, with separate remembered choices for the website, demo, and connected app. Nothing is loaded or sent to Google Analytics before that choice. Declining does not prevent using the website, signing in, or recording attendance.

Only explicitly selected, fixed events are measured: public page views, home-page section views, opening the demo, app feature views, and generic navigation actions. Labels such as scanner, activities, settings, and help describe the feature, never the selected school or activity. Events distinguish the website, demo, and connected app, use fixed page addresses and titles, and send an empty referrer. After consent, the browser locally derives a coarse device category: mobile, tablet, or desktop. Only that category is forwarded with events, not raw user-agent strings, device models, operating-system versions, or screen resolution. Sign-in flows, authentication callbacks, invitations, account APIs, policy pages, and sensitive or unrecognized routes are excluded.

Analytics does not receive scanned IDs, attendance events or results, names, email addresses, account identifiers, school/location/activity names or identifiers, spreadsheet details, form values, invitation codes, tokens, or free-text errors. Analytics is not derived from Google account or spreadsheet data. A same-site collection endpoint validates the fixed event fields before forwarding them to Google; application code does not copy account cookies, authorization headers, or incoming browser headers into that request. Cloudflare and Google can still process technical connection information, including IP addresses and browser information, when loading the optional script and transporting events. Accepted events use pseudonymous browser identifiers; this is not anonymous browsing.

Analytics uses optional host-only cookies with a 24-hour lifetime that is not extended by later visits, and a remembered device consent choice. Use Privacy preferences on each surface to allow, decline, or withdraw permission. Withdrawal stops future measurement and removes that surface's analytics cookies; it does not remove attendance or pending entries or automatically delete data already processed by Google. Global Privacy Control and Do Not Track signals override an allowed choice. An earlier limited page-view opt-in does not authorize the expanded usage measurement; a fresh choice is required, while earlier declines remain respected.

Automatic page views, Enhanced Measurement (including browser-history tracking), Google Signals, advertising features, and user-provided data collection are disabled; User-ID is not used. Event and user retention in the dedicated property is set to two months with no reset on new activity; Google performs retention cleanup on its schedule and standard aggregated reports can remain longer. Google processes analytics information under its applicable terms and Privacy Policy. The analytics controls are separate from necessary sign-in cookies and application storage.

Institution information requests

The information-request form on Use Cases and Contact asks for your name, email, institution, and optional department, role, and intended-use message. It is available without an app account and is used to respond to your inquiry. Do not include student records or IDs, passwords, payment-card details, or unrelated sensitive information. Submitting does not create an account, invitation, subscription, trial, or payment.

We send the submitted fields and a UTC submission time through Resend to info@campusactivityscan.com, using the verified application sender and your validated email as Reply-To. No automatic email is sent to the visitor. A received acknowledgment means the email provider accepted the inquiry, not that inbox delivery has been confirmed.

To prevent repeated emails and abuse, the server temporarily retains a keyed digest of the fields, a random request reference, attempt status, timing, and the configured sender, not the submitted message or contact fields. Network limits use a day-specific keyed IP pseudonym rather than storing the raw address in the application counter. Retry receipts expire within 23 hours and quota records at their hourly/daily boundary, with cleanup on service execution. An uncertain inquiry is retried only explicitly with the same provider idempotency key within that deadline. Browser form values are held in memory, not persisted by the app; the mailbox and email provider keep their copies under their own retention and deletion settings. No separate automatic mailbox deletion period has been configured by this feature.

The Use Cases and Contact pages, inquiry fields, submissions, acknowledgments, and errors are excluded from usage Analytics. Necessary hosting/email security records remain separate from optional analytics. You can contact info@campusactivityscan.com about an inquiry or its deletion.

Problem reporting and screenshot availability

The Contact page offers a Report a problem option, but online problem submission and screenshot uploads are not enabled. Availability is explained before fields can be filled, and the form remains disabled. You can email info@campusactivityscan.com for support. Do not include student records or IDs, passwords, authentication codes, invitation links, or other private credentials.

Form entries are held only in page memory, not saved by the application to browser storage. Changing between Contact options does not discard an existing draft. If reporting availability cannot be confirmed, no report or image is submitted; an existing draft remains on the page. Closing or reloading the page can lose it. No private screenshot bucket or reporting retention period is active in this release.

Emailing support uses your email service and the support mailbox, whose processing and retention are separate from the application. No report is sent automatically by visiting Contact or checking availability. Contact information and form contents are excluded from optional usage Analytics.

Questions and corrections

Ask the location manager about attendance corrections and access to the connected spreadsheet. For support or privacy questions, contact Battle Born Geckos LLC, at info@campusactivityscan.com. Do not send student IDs, authentication codes, passwords, or private credentials by email.

Privacy and deletion requests can be raised through that contact. The app does not currently offer a complete self-service account-deletion workflow, and this policy does not promise immediate deletion from school spreadsheets or provider backups. We will explain applicable limitations when responding to a request and update this policy as the service changes.