IDK Can You?

← Back to Home

Privacy Policy

Effective: May 6, 2026  ·  Last updated: July 27, 2026

IDK Can You? (“the Service”) is operated by Elisha Lucero (“we,” “our”). It provides hall-pass and device-checkout tools for K–12 classrooms at idkcanu.com, through the Android app distributed on Google Play, and through the iOS app distributed on Apple’s App Store under the name “IDK Can You?”. This policy explains what information the Service handles, how it’s protected, and the choices schools, teachers, parents, and eligible students have over it.

The Service is designed to be set up and managed by school staff. A school may use the FERPA “school official” exception only after the school determines that the Service meets the exception’s requirements, including the school’s direct control over the use and maintenance of education records. When a school authorizes the Service on that basis, we process student data under the school’s direction and only for the educational purpose the school authorizes.

1. Information we handle

Teacher account information

When a teacher signs in with Google, we receive their email address, name, and Google profile picture from Google’s OAuth service. We use this to identify the teacher, secure their account, and display their profile in the app.

Authorized platform operators may separately view the minimum identified staff-account, organization, claim, configuration, and support information needed to operate, secure, and administer the Service. This can include a staff member’s name, email address, account-created date, school or district memberships and roles, organization settings, claim decisions, and support requests. This operational directory does not include student rosters, named classroom-use analytics, or student and device details.

Student information (entered by the teacher)

Teachers add their roster manually or by uploading a CSV. Roster fields include each student’s name, school-issued ID or barcode, and optional grade and class period. This information may be part of an education record under FERPA when a school maintains it through the Service.

Standing accommodations (set by the teacher)

A teacher can give an individual student a standing accommodation — not auto-flagging them as overdue, giving them a longer custom time limit, or exempting them from automatic banning. We store only the on/off state of each accommodation and, for a custom time limit, a number of minutes. We never record or store a reason, condition, justification, or any medical or disability information — these accommodations are reasonless by design. They are visible only to the teacher on their own dashboard and login-protected classroom kiosk, and are never shown on the public hallway display, which treats every student by the same room-wide time limit.

Service usage records

To operate the Service we record:

These records are linked to the hashed/encrypted student record described above. The audit log is visible only to the teacher who owns the account.

We may derive aggregate, de-identified statistics from account and Service usage records to operate, secure, evaluate, and improve this same educational Service. These statistics are calculated on demand, grouped into fixed signup cohorts, and protected by minimum-group and small-cell suppression. The platform-owner view provides no account-, teacher-, student-, class-, school-, district-, or organization-level drill-down. We do not keep a separate account-level analytics profile. We do not attempt to re-identify these statistics or use them to contact, target, rank, score, advertise to, change access for, or change pricing for a particular person, school, district, or organization. We do not extend source-record retention to preserve a statistic or provide these statistics to a third-party analytics service.

A signed school or district agreement controls wherever its terms are stricter. If it prohibits this aggregate use, records it covers must be excluded before calculation or the aggregate use must remain disabled. This public policy does not override a signed agreement.

Device condition notes

When a device is reassigned, returned, or reported damaged, teachers can add short free-text notes (e.g., “cracked screen,” “keyboard sticking”). These notes describe the device, not the student, and are intended for inventory tracking. Like student names, these free-text fields are encrypted at rest. We still ask teachers not to enter student-identifying information in them.

Technical and diagnostic information

We collect minimal technical information required to keep the Service running and secure:

2. What we do not do

3. Service providers and visitor-initiated external content

We use the following service providers to operate and distribute the Service. Their handling of information is governed by their terms, privacy commitments, and any agreement we have with them.

Google’s OAuth endpoints receive staff sign-in information (email, name, and profile picture), not student roster information. Google also receives ordinary request metadata when the web application downloads its functional assets. Render hosts the application runtime and database; Cloudflare carries Service traffic at its network edge; and Sentry receives the limited diagnostic information described in section 1. Student-identifying database fields are encrypted by the application, and the application runtime uses the key when authorized users need the information. If a school and we sign a Data Privacy Agreement, that signed agreement controls any additional sub-processor notice and data-protection terms for that school.

We disclose information outside these service providers only in narrow circumstances: when required by valid legal process, when necessary to protect the safety of students or others, or in connection with a merger or acquisition — in which case the successor remains bound by the commitments in this policy.

4. Security

School organizations. A school can operate idkcanu as an organization with designated school administrators. Administrators see aggregate, school-wide counts and audit metadata. If the school itself uploads its student roster and enables the live dashboard (both are deliberate, per-school switches), administrators additionally see — by name — the students the school itself provided: who is out right now, pairing rules the school created, and a capped recent record of teacher overrides of those rules, including the teacher’s optional note. This name visibility is source-based: it covers only students on the school’s own upload. An open pass for a student a teacher added privately can appear as a generic “Student” row with live operational details, but the organization does not resolve that student’s name from the teacher’s roster. The live view provides no hall-pass history or export, and the dashboard provides no per-student analytics.

The base organization scope does not move teacher-owned data. When school roster mode is separately enabled, however, a school administrator can preview and apply the school’s upload. That audited synchronization can create, update, reactivate, or archive school-sourced roster records inside member teachers’ accounts; teacher-added local records that are not school-sourced remain outside the school’s named directory.

Breach notification. If we confirm a breach of student data, we will notify the affected school without undue delay — within the timeline agreed with the school (commonly within 72 hours after confirmation) — including, to the extent known, the nature of the breach, the categories and approximate number of records affected, the likely consequences, and the steps we are taking in response.

5. Children’s privacy (COPPA & FERPA)

Accounts are for school staff, but students may use a staff-configured kiosk to scan a school-issued barcode. Students cannot create accounts. Before entering student information or asking a student under 13 to use a kiosk, the staff member represents that their school or district has authorized the Service. Federal Trade Commission COPPA guidance allows a school to consent on a parent’s behalf when an online service is used for the school’s benefit and for no other commercial purpose. If that school authorization does not apply, the Service must not be used to collect personal information from a child under 13 without verifiable parental consent.

We commit to handling student records consistent with FERPA. We do not disclose personally identifiable information from education records to any third party except as needed to provide the Service, with parental consent, or as required by law. An authorized school representative may request a review, export, or scoped deletion of data tied to its teachers’ accounts by emailing the address below.

We support schools’ compliance with applicable state student-privacy laws, including California’s SOPIPA, Illinois’ SOPPA, and New York Education Law § 2-d. A school that requires a state-specific addendum must contact us and complete that agreement before using the Service where the addendum is required. Student data is collected only as reasonably necessary for the educational service, used only for the school’s educational purpose, and never sold, rented, or used for targeted advertising.

6. Your rights and choices

7. Retention

Active account and roster data remain until an available product control changes them or an authorized request is reviewed and completed. Backend and frontend Sentry diagnostic events are retained according to IDK Can You?’s Sentry subscription and account configuration; those controls are managed outside this repository. Hosting and network request logs follow the applicable provider and service retention settings, which are also managed outside this repository.

Transactional usage records — hall-pass sessions, device scan and administrative logs, returned device checkouts, resolved damage reports, and the security audit log — are automatically purged after 365 days by default. That automatic window is configured for the deployment as a whole; the shared Service does not currently support a different automatic window for each school. Active device checkouts, unresolved damage reports, student rosters, and device assignments do not auto-expire because deleting them could erase current classroom state. Teachers should use the dashboard’s reset tools between terms. After deletion from the active database, limited copies may remain temporarily in encrypted provider backups until those backups roll off under the provider’s retention cycle. They are not used except to restore the Service. Current product controls do not remove the staff User row. SecurityAuditLog entries are linked to that row, are hash-chained, and follow the same deployment-level 365-day default retention window. For broader requests, we verify authority and provide a written scope, retention explanation, and timeline before claiming completion.

8. International users

The Service is intended for schools in the United States and is not currently targeted to users outside the United States. Hosting and telemetry regions are selected in provider accounts rather than fixed by this repository, and providers may process information in the account-selected or global locations described in section 3.

9. Changes to this policy

We may update this policy from time to time. We will post revisions here and update the “Last updated” date above. When applicable law or a signed agreement requires advance notice, we will use available account contact information or an in-product notice before the change takes effect.

10. Contact

Questions, requests, or concerns about this policy or your data? Email elisha@idkcanu.com. We aim to respond within 5 business days.