# Anyra Anonymizer — Privacy Notice for District Review **Effective Date:** April 18, 2026 **Tool version:** 1.0 **Intended audience:** District data privacy officers, chief technology officers, and legal counsel --- ## Executive Summary The Anyra Anonymizer is a single HTML file published by Anyra, Inc. It runs entirely inside the user's web browser on the user's own device. No student data is transmitted to Anyra, stored by Anyra, or processed by Anyra at any point. Anyra's role is that of the software's publisher. **Compliance determinations are the district's responsibility.** This document describes the tool's architecture and how data flows (and does not flow) during its operation. It does not state whether any particular law applies, nor what agreements, approvals, or reviews your district may require before using the tool. Those are determinations for your district's data privacy officer, legal counsel, and IT leadership, based on your own policies and applicable law in your jurisdiction. Nothing in this document constitutes legal advice. --- ## 1. What the Tool Does The Tool accepts a spreadsheet file (XLSX, XLSM, or CSV) from the user's local disk, reads it inside the browser, transforms its contents according to user-configurable rules, and produces three downloaded files: - `anonymized.xlsx` — with direct identifiers removed or pseudonymized - `real_data.js` — a JavaScript data file for use with Anyra dashboards - `mapping.json` — a lookup between pseudonyms and original identities Transformations performed in-browser: 1. **Strip**: direct identifiers (names, emails, phones, addresses, dates of birth, Social Security numbers, parent/guardian contact information, free-text notes) are removed entirely. 2. **Hash**: stable identifiers (student IDs, state-assigned identifiers) are replaced with non-reversible pseudonyms generated using SHA-256 hashing with a randomly-generated per-document salt. 3. **Suppress**: small-cell demographic values are replaced with `(suppressed)` based on multi-attribute k-anonymity checks to reduce re-identification through column combinations. 4. **Keep**: non-identifying columns pass through unchanged. --- ## 2. What the Tool Does Not Do The Tool does not: - Transmit data to Anyra or any external server - Store data beyond the duration of the browser session - Collect analytics, telemetry, or usage statistics - Require an account, login, or sign-in of any kind - Send network requests containing user data under any condition - Execute macros or scripts embedded in source files - Modify the user's source file --- ## 3. Architectural Facts for Your Legal Review This section is **not a legal analysis**. It is a description of architectural facts about the tool that your district's counsel, data privacy officer, and IT team can use as an input to their own determinations under applicable law. We are not your lawyers; we don't know what law applies in your jurisdiction or how your local policies treat tools like this one. **Facts about data flow:** - The tool is an HTML file that renders in the user's web browser - When a user drops a file into the tool, the file's contents are read by JavaScript executing inside the browser's own memory - No part of the user's file contents is transmitted to Anyra's infrastructure, any cloud service, or any third-party API during the tool's operation - The tool makes no outbound HTTP requests containing file data under any condition (verifiable in the browser's DevTools Network tab, or by running the tool with the network disconnected) - Output files are written to the user's local disk via the browser's standard download mechanism **Facts about Anyra's role:** - Anyra publishes the software and the URL where the tool is hosted - Anyra does not receive, store, transmit, or process any user-loaded data through the tool - Anyra does not collect telemetry, analytics, or usage data from the tool - Anyra does not authenticate, identify, or log individual users of the tool (beyond the optional access code check, which validates a hash client-side) **Laws and agreements your district may want to evaluate:** - FERPA (34 CFR Part 99) and its de-identification standards (§ 99.3, § 99.31(b)) - California AB 1584 / Ed Code § 49073.1 - California SOPIPA (Cal. Bus. & Prof. Code § 22584) - CSDPA and any state-level student privacy agreements your district uses - COPPA (if TK-8 student data is in scope) - NY Ed Law 2-d, IL SOPPA, TX HB 2087, or other state statutes applicable to your jurisdiction - Your own district's acceptable-use policies, data governance policies, and vendor-review requirements Whether any of these laws applies to your district's use of the tool, whether any agreement is required with Anyra or not, and what other reviews or approvals apply are determinations for your district and its counsel — not for Anyra to declare. --- ## 4. Verification Methods District IT and security staff can independently verify all claims made above: ### Method 1: Network Traffic Audit 1. Open the Tool in a modern browser (Chrome, Safari, Firefox, Edge) 2. Right-click → **Inspect** → open the **Network** tab 3. Clear the log, then drag a file into the Tool and run the anonymization 4. **Expected result:** zero outbound requests contain file data. The only network activity is the initial page load (Google Fonts, SheetJS library). ### Method 2: Offline Mode Verification 1. Save the HTML file to your local disk or flash drive 2. Open it once in a browser to allow caching of dependencies 3. **Disconnect the network** — turn off Wi-Fi, unplug ethernet cable 4. Run the full anonymization flow 5. **Expected result:** the Tool functions completely, proving no network connection is required to process data. ### Method 3: Source Code Review Two levels, based on your review depth: **Level A — Hosted source (immediate, no access required):** 1. Right-click → **View Source**, or save the tool's HTML file and open in a text editor 2. The Tool is a single file with no bundled or obfuscated code except for the SheetJS library (open source, auditable at [sheetjs.com](https://sheetjs.com)) 3. All anonymization logic, pattern detection, and file handling is visible in readable JavaScript 4. IT staff can audit the code against any specific concern your district has **Level B — Full repository review (on request):** 1. The full source repository (including commit history, test suites, prior versions, and build artifacts) is held privately by Anyra 2. District IT and security teams may request read-only access by emailing [anyra.ai](https://anyra.ai) 3. Anyra grants temporary GitHub read access for the duration of your review 4. Access is revoked once the review completes Level A is sufficient for most district reviews. Level B is for security teams who need to verify the hosted code matches an auditable history and want to trace changes across releases. --- ## 5. Data Minimization and Privacy-by-Design Features ### Direct identifier removal Columns matching known PII patterns (names, email, phone, address, DOB, parents, SSN) are auto-classified as STRIP. The Tool recognizes common naming conventions from Aeries, PowerSchool, Infinite Campus, Synergy, Q SIS, CALPADS, CAASPP, and Ed-Fi exports. ### Cryptographic pseudonymization Student identifiers are replaced with SHA-256 hashes using a per-document salt stored in the user's browser `localStorage`. The salt is never transmitted. Same raw identifier produces the same pseudonym within a document (enabling joins), but different pseudonyms across different documents (preventing cross-reference). ### Multi-attribute k-anonymity Cell suppression runs in three passes: 1. **Per-column:** each demographic column × grouping columns (site × grade) — cells below threshold (default 10) are suppressed. 2. **Combined quasi-identifier tuple:** each row's combination of (grouping + all demographics + status flags like ELL/SED/IEP/gender) is checked — rows in tuples below threshold have their demographic values suppressed. 3. **Residual uniqueness:** rows whose combination is still unique after suppression are flagged in warnings for the user to review and optionally redact. ### Free-text detection Columns whose sample values average more than 60 characters are auto-classified as STRIP, even if their header name does not match a known PII pattern. This catches custom or non-standard columns that might contain counselor notes, medical observations, or other embedded PII. ### Typed-confirmation for risky overrides If a user attempts to override an auto-detected STRIP classification to KEEP — exposing PII in the output — the Tool requires them to type the explicit phrase "I ACCEPT THE RISK" before proceeding. This prevents one-click accidental exposure. ### No mapping transmission The pseudonym↔real-identity mapping file (`mapping.json`) is downloaded to the user's own device. It is never uploaded, transmitted, or accessible to Anyra. The user is responsible for handling it securely. --- ## 6. Residual Risks and Limitations The Tool reduces re-identification risk but does not eliminate it. Districts should be aware of the following residual risks: 1. **Combination re-identification through KEEP columns.** If a combination of KEEP columns (e.g., pathway + site + grade + IEP status) yields a unique row in the dataset, that row may be identifiable even without any demographic suppression. The Tool flags such rows in warnings; manual review is required. 2. **Custom column names that don't match patterns.** The Tool recognizes 200+ column-name patterns from major SIS exports. Non-standard or district-invented column names may require manual classification by the user. 3. **Brute-force hash reversal with small known populations.** If a district has only 5,000 students and an attacker somehow obtains both the salt and the anonymized file, the SHA-256 hashes could theoretically be reversed by generating candidate hashes for every possible student ID. The risk is low because the salt is never transmitted, but districts handling particularly sensitive cohorts may prefer to run the Tool on a trusted local machine with disk encryption enabled. 4. **Free-text in non-obviously-named columns.** If a district has a free-text column whose sample values happen to all be short (under 60 characters), the heuristic may miss it. Users are instructed to review classifications before proceeding. 5. **Browser memory residue.** Raw data remains in the browser's memory until the tab is closed. Forensic memory analysis or malicious browser extensions could theoretically recover it. Mitigation: users should close the browser tab after each session; districts may require use on machines with current security patches and trusted browser configurations. 6. **Not a substitute for district policy.** Use of the Tool does not waive, modify, or satisfy any of the district's own data-governance policies. Districts should incorporate the Tool into their Acceptable Use Policy and staff training with clear guidance on when and how it may be used. --- ## 7. Recommended District Controls For districts that wish to formally authorize use of the Tool: 1. **IT review:** Conduct the three verification methods above. Document the review in your vendor-review records. Note that because Anyra is not a processor, this is a *software audit*, not a *vendor review*. 2. **Policy integration:** Add the Tool to your Acceptable Use Policy for AI and data handling. Specify: (a) which roles are permitted to use it, (b) what data classes it may be applied to, (c) where anonymized outputs may be shared, (d) how mapping files must be stored. 3. **Staff training:** Require a short training (typically 20–30 minutes) covering: (a) how to review auto-classifications, (b) how to handle the mapping file securely, (c) when to escalate a review to the data privacy officer. 4. **Vendor record:** Document in your vendor records what Anyra is (the software's publisher) and how the tool operates (entirely within the user's browser, no data transmitted to Anyra). Your district decides what form of vendor agreement, if any, is required under your own policies and applicable law. If a minimal agreement that reflects the factual description above would satisfy your internal review, contact Anyra and we can respond. 5. **Version tracking:** The Tool displays a version number and build date in the footer. Record which version was used for any specific anonymization that will be shared externally. --- ## 8. Changes to This Notice Anyra may update this Privacy Notice when the Tool is updated. The effective date and version at the top of this document indicate the current revision. Districts wishing to monitor changes can check the [Anyra GitHub repository](https://github.com/anyra) (link subject to change) or request direct notification. --- ## 9. Contact Questions about this Privacy Notice, the Tool's technical operation, or compliance-related concerns may be directed to: **Kevin Bice, Anyra, Inc.** Via [anyra.ai](https://anyra.ai) --- *This Privacy Notice is provided for informational purposes and does not constitute legal advice. Districts should consult their own counsel regarding any compliance obligations specific to their jurisdiction and circumstances.*