PrivacyMirror - Submission

Inspiration

Did you know that simply by browsing a website, it's possible to identify who you are and infer your personality? This happens because of the information your device silently sends out : information that can be pieced together into a full profile of you.

Knowing that, we asked ourselves: is there a way to stop this?

That's how Privacy Mirror came to be : a tool that lets anyone browse the web while protecting their anonymity, by revealing what information is being sent to a website, how sensitive it is, and, most importantly, giving them the power to stop it.

How we built it

We're a team of two, and neither of us had built a browser extension before, so the first decision we made was to deliberately keep the scope small. Rather than trying to build a full ad-blocker, a complete fingerprinting detector, and an AI engine all at once, we picked one clear MVP: detect, explain, and block.

Stack: TypeScript, Chrome Extension Manifest V3, Vite for the build pipeline, and React for the popup UI. Storage is handled entirely with chrome.storage.local — no backend, no database, no external API. That constraint became one of our core selling points: all analysis happens locally.

Splitting the work: we divided the project into two tracks that could be built almost independently:

- Browser/Privacy Engine: the extension shell, network request detection via chrome.webNavigation, fingerprinting signal detection (Canvas, WebGL, AudioContext, screen/timezone/hardware info), and blocking rules built with declarativeNetRequest. - Analysis/UI: turning that raw technical data into something a person can actually understand: a tracker analyzer that categorizes domains and explains their risk, a rule-based inference engine that guesses likely interests from page metadata (and flags sensitive categories), a weighted risk-scoring system (0–100, Low/Medium/High), and the React dashboard that ties it all together.

We kept the two codebases loosely coupled through one shared contract: a PageAnalysis type that both sides agree on. The privacy engine writes to chrome.storage.local, the UI just reads from it which meant we could build and test both halves in parallel without blocking each other.

For the inference engine specifically, we used a local keyword-rule system instead. It's simpler to build, easier to explain to a jury, and, ironically, more transparent about its own limitations than a black-box model would be.

We tested each module in isolation with small scripts before wiring anything into the actual extension, then spent our last stretch of time on integration, a controlled demo page (a fake site loaded with trackers and fingerprinting scripts), and polishing the before/after story: load the page, see the risk score, hit "Protect me" reload, and watch the numbers drop.

Challenges we ran into

We had a challenge from the start, we had to decide what exactly were we supposed to build. We had many ideas similar to the one we originally wanted to make, but we had to change our plans a little bit because what we were about to build didn't respect the constraint which forbade us to collect any additional data about the user.

We also had to understand how to deal with the Chrome Extension V3 Manifest framework which was necessary in order to build the extension, just as we had to deal with the Vite build structure.

By the end of the hackathon, we had quite the trouble with our git management of the project. We made a pull on a code that was no longer functional and had to recover what was lost.

What we learned

It is important to know how to use git in order to build a project without having any issues.

Constraints are a feature, not always a limitation. Deciding upfront that everything had to run locally, with no backend and no AI API, felt restrictive at first, but it ended up being helpful since it forced simpler architecture, made the privacy story more credible, and meant we spent our limited time building instead of debugging infrastructure.

None of our blockers were conceptually hard : A module resolution error here, a naming mismatch there, but each one cost real minutes during a 24 hours marathon. Getting the dev environment fully working and verified before building on top of it, rather than debugging tooling and features at the same time saves life.

Built With

• chrome
• html
• javascript
• manifest-v3
• react
• typescript
• vite