UnMasked

UnMASKED intro
Risk in Data
Spark Challenge
Factors into identification
Attacker view
UnMASKED function
Understanding data
How identifiable are students?
How we fix it
Before vs After
Results
Responsible Use+Ethics
Tools used
END

Inspiration

BU wants students to build projects on real institutional data, but sharing that data safely is hard. The usual approach is to remove names and ID numbers and call the file "de-identified." We wanted to test whether that actually works.

Using BU's synthetic version of the National Survey of Student Engagement (20,731 students), we found that it doesn't. With no names at all, 67.8% of students can still be singled out from just eight ordinary survey fields, like class year, major, and program. With just a few more fields and the survey completion date, that rises to 99.99%. Removing names isn't anonymity, we wanted to build a tool that proves it, fixes it, and is honest about what the fix costs. (We also injected generated free-text responses and fake personal info into the survey to better the tool).

What it does

Unmasked is a privacy tool for anyone about to share a spreadsheet of personal data, such as a university data office or a student research team. It walks the user through five steps in a simple web app:

Understand the data. An AI agent labels what each column is. The columns are categorized as direct identifiers (like an ID number), ordinary details that becomes identifying in combination (like year plus major), survey timing, or a sensitive answer. We make sure that the AI implemented only ever sees column names and summary numbers, never any student's actual answers. The user reviews and corrects the labels.
Measure the risk. Unmasked counts how many students are unique, finds the riskiest combinations of fields, and checks hidden leaks like survey timing (the completion date alone singles out 11.7% of students). Then, it simulates as an attacker: it takes 200 students, keeps only what an outsider might know (like a club roster or LinkedIn profile), and tries to match them back to the file. *68.5% were correctly re-identified. *
Fix it. Understanding the risk through overall analysis as well as through the lenses of an attacker, Unmasked replaces the most direct means of identification (like ID numbers) with scrambled codes (originals locked in a separate encrypted file), removes certain names and emails, hides personal details written in comments, and makes ordinary fields less specific (for example, an exact major becomes a field of study) until every student is indistinguishable from at least four others. To make the data still useable for research, it aims to remove no more than 5% of records.
Check the cost. Unmasked reruns the attack (68.5% → 0%, with only 2.5% of records removed), measures how much the data is still useful for research, and shows which groups of students lost the most records.
Explain it. It produces a plain-English report and a one-page release privacy summary that a non-technical reviewer can understand, plus the protected file to download.

Tradeoffs When we let the tool optimize freely, one way it managed the privacy of the dataset by quietly deleting the demographic column. However, when we protected that column, the smallest groups paid the price: they lost about 8× more records than the largest group (6.9% vs. 0.85%). Unmasked makes that tradeoff visible and lets the data owner choose whether they feel comfortable implementing encryption.

Responsible AI and ethics

The AI never sees student data. It receives only column names, counts, and computed statistics. The tool also works fully without AI, using built-in rules, and the app always shows which mode it's in.
Synthetic data only. We used BU's synthetic survey data plus fake names, emails, and comments we generated ourselves. No real student data was used. Because BU's data is access-restricted, our public demo runs on a separate, entirely fake dataset we generated.
Honest limits. Scrambled IDs can be unscrambled by whoever holds the key, so the output is protected, not truly anonymous. Our protection method can't stop every inference about a group, and real attackers may know more than the ones we simulated. A human must approve every release. This is a risk tool, not a legal compliance certificate.
Fairness is measured, not assumed. We report which groups lose data and offer a setting that protects small groups.

How we built it

Unmasked is written in Python, a programming language widely used for data work, and runs as a web app.

Working with data. We used pandas, a tool for working with tables of data (like a programmable spreadsheet), to group students with matching answers and count how many are unique. NumPy handles fast math, openpyxl reads Excel files, and PyArrow saves data in a fast format so the 20,000-row file loads instantly. Our privacy hierarchy (for example, "going from an exact major to field of study to being removed") live in readable settings files using PyYAML, so they're easy to review.

Our privacy methods (our own code):

k-anonymity: every student must share their combination of details with at least $k - 1$ others. We used $k = 5$.
Simulated linkage attack: matching outsider knowledge back to the file to test whether people can actually be found.
Optimizer: a step-by-step program that decides which details to make less specific to protect everyone while losing as little information as possible.
Fairness check: measuring which demographic groups lose the most records.

Machine learning. We used scikit-learn, a standard machine learning library, to test whether protected data is still useful: we trained a model to predict a student engagement score on the original and protected data. Accuracy dropped only modestly (a score of 0.42 to 0.37).

Finding personal details in comments. spaCy recognizes things like people's names in text, and Microsoft Presidio, an open-source privacy tool, finds and hides personal information. We added a rule for BU student ID numbers and tuned it so it stopped mistaking building names like "Mugar Library" for people.

Fake test data. Faker generates realistic but fake names, emails, and IDs. We planted them in the survey data so we could measure exactly what our detector catches, and used them to build our fully fake public demo dataset.

Protecting ID numbers. The cryptography library provides standard encryption. We replace each ID with a scrambled code (an HMAC token) that stays consistent, so records can still be linked, but can't be reversed without a secret key. The originals are stored in a separate encrypted vault (Fernet encryption) that only a key holder can open.

The AI agent. The agent can use Google's Gemini language model, connected through the standard OpenAI Python library so other AI models can be swapped in. It writes the plan, the report, and explanations of each column's role.

The website. Streamlit turns Python into an interactive website. Our app has six tabs guiding users from data to report. Plotly draws the interactive charts, with colorblind-friendly colors and labels on every chart.

Testing. pytest runs our automated tests, and Hypothesis generates hundreds of random datasets to confirm our key guarantees always hold, such as "after protection, every group has at least five students" and "a scrambled ID always unscrambles to the original." We also wrote checks that reproduce our headline numbers exactly.

Teamwork with Kiro. We built Unmasked in Kiro, an AI-powered development environment from Amazon Web Services. We split the project into three parts with one structured plan ("spec") each, with requirements, a design, and tasks that each ended in a check against expected results. Shared rule files ("steering") kept all three of us aligned on file ownership and privacy rules, and an automated "hook" reran our tests whenever core code changed. Three people built separate pieces at the same time and combined them without conflicts.

Sharing it. Our code is public on GitHub, and the live demo is hosted free on Streamlit Community Cloud, where anyone can try it in a browser.

Challenges we ran into

Privacy and usefulness pull against each other. Protecting all nine demographic-style fields naively would have meant removing 90% of the records. We had to design an optimizer that makes careful tradeoffs.
The optimizer hid its own cost. Our first unconstrained version reached the privacy target by deleting the demographic column entirely. It looked like a success until we asked who was affected, which became our main finding.
Hidden leaks. Some columns are derived from others (a major's name and its code). If we coarsened one but not the other, the detail leaked back, so we built rules to change related columns together.
Not fooling ourselves. Tuning the text detector on our own test data gave a perfect score, which was too good to trust. We wrote a separate set of hand-made sentences it had never seen, which revealed real weaknesses (some second names in a sentence were missed). We report both.
A false alarm in our own checks. A data comparison said two files differed in 120 columns. The real cause was that missing values were being counted as different from each other. After fixing the comparison, the files matched exactly.
A bug that could give false reassurance. In final testing, we found that switching datasets in the app could reuse old column labels and report 0% risk on a file that was actually 74% identifiable. We fixed it so switching datasets resets everything.
Restricted data. BU's data can't be shared publicly, so we generated a separate fully fake dataset with the same structure so anyone can run the demo.

Accomplishments that we're proud of

Cutting simulated re-identification from 68.5% to 0% while removing only 2.5% of records.
A clear, measured fairness finding: protection costs the smallest groups up to 8× more, and an unconstrained optimizer can hide that by deleting the group column.
Honest evaluation: detection scored against known ground truth (100% for emails, phones, and IDs; 91% for names), plus a separate out-of-sample test, with misses reported rather than hidden.
A tool that works with or without AI, where the AI never sees student data.
A live, public demo anyone can try, with fully fake data and nothing to install.
Three people building in parallel with zero code conflicts.

What we learned

Removing names is not enough. Ordinary details combine into fingerprints surprisingly fast.
Privacy protection isn't free, and it isn't evenly paid. Measuring who pays matters as much as measuring the risk.
A good-looking number can hide a problem. Our optimizer's "success" and our detector's perfect tuning score both needed a second look.
Agreeing on how the pieces connect before building is what let three people work separately and still fit everything together.

What's next for Unmasked

Stronger privacy methods, such as differential privacy (adding carefully calibrated statistical noise) and checks that prevent inferring a group's answers.
"Must-keep" analyses, so a researcher can tell the optimizer which comparisons must survive.
Better name detection, using a larger language model combined with the AI detector, and more realistic attacker simulations.
A pilot with BU IS&T on real data inside a secure university environment, with a data steward reviewing every release.

Built With

cryptography
faker
gemini
github
hypothesis
jupyter
kiro
numpy
openai
pandas
plotly
presedio
pytest
python
pyymal
scikit-learn
spacy
streamlit
streamlit-community-cloud

Submitted to

DS+X Hackathon 2026

Created by

I coordinated the project and built the privacy mitigation side. I planned the architecture, split the work into three roles with fixed interfaces so we could build in parallel, wrote each teammate's build brief, and kept us on track: running integration and edge-case testing, auditing the repo, merging branches, deploying the live demo, and preparing both submissions. On the technical side, I built the optimizer that decides which fields to generalize or remove to reach k-anonymity, the encrypted token vault for student IDs, the planted fake PII and Presidio-based detection (including an out-of-sample stress test), the usefulness and fairness measurements behind our main finding, the fake demo dataset, and our property-based tests and Kiro hook. As an industrial engineering student, the optimizer felt like familiar territory, but it was my first time using Kiro and leading a technical build, and I learned a lot about privacy and testing honestly.

Kealoha Comcowich
I’m Kieran, an Electrical Engineering student at Boston University. I handled the data for our project. I loaded and cleaned BU’s student survey so the whole team could use it. I built the risk measurement, which showed that 68% of students could be singled out even with no names in the file. I also built the simulated attack. Finally, I made our presentation charts, and recorded and edited our videos.

Kieran Mcbride
I built Unmasked’s app (on Streamlit), and integrated its AI privacy agent, Gemini. I also implemented release warnings, LLM-mode indicators, demo-data fallback, and dataset-switching fixes, while managing the GitHub repository, README, and submission drafts. My biggest challenges were keeping student data away, and connecting functions of my teammates to integrate with the LLM. I also had to make sure our project maintained useful AI features while resolving Git issues from coordinating our completion.

William Wang