PatientPrivy

Extension pop up
Simple view on website
Technical view on website
Lawsuit auto application

Inspiration

Patients are unaware of the predatory practices of third-party and private health care applications. They use terms like “HIPAA protected” or “HIPAA certified” that give patients a false sense of security.

In reality, a large amount of extremely sensitive data is being transmitted to cloud services and data stores through a network connection without the user's knowledge. Applications used by millions of patients are observed to take advantage of the lack of strong regulatory guidelines. So, we built PatientPrivy to protect patients.

What we built

PatientPrivy is a client-side observability browser extension that shows patients what sensitive healthcare data leaves their device, which information was exposed, and where it was sent. An interactive visual map places clickable data-flow nodes directly on the website, making each transmission easy to inspect and understand. Its core feature is automated action to save users the headache. With the patient’s explicit approval, PatientPrivy sends a formal opt-out request to the company, requests deletion or discontinued retention of the patient’s data, tracks the applicable response deadline, and begins escalation when the company fails to comply. When patients qualify for class-action litigation, PatientPrivy also autofills the required information and helps file the claim through the appropriate legal process.

How we built it

We built PatientPrivy as a Chrome extension connected to a local privacy-analysis pipeline. The extension observes where a website sends requests, while a local proxy captures the request contents so our Python classifier can identify sensitive fields. We combine rules with an optional on-device semantic model, then display the findings in a React dashboard. Patients can switch between a simple view of where their data went and an interactive 3D network view that shows the destination and exposed information. To test the full journey, we built ScriptWell, a fictional prescription-savings site in React and TypeScript. Confirming an offer sends a real JSON request to a separate analytics receiver, giving PatientPrivy a disclosure to detect. From the findings, users can review an opt-out email before sending it. We also built a class-action form autofill demonstration; it does not submit a real legal claim.

Engineering discoveries and challenges

We started with tshark for plaintext HTTP, but HTTPS forced us to rethink the architecture because request bodies were encrypted. We added mitmproxy for local HTTPS inspection and normalized HTTP, HTTPS, and browser-extension observations into one event pipeline.

Our classifier also evolved from brittle keyword rules into a hybrid system using deterministic checks plus a lightweight local semantic encoder. On the current ScriptWell payload, it detects dozens of raw sensitive fields and consolidates them into a smaller set of meaningful privacy issues, with warm classification taking only a few milliseconds.

Accomplishments that we're proud of

We’re proud that we learned to make an invisible network request visible and understandable. At the start, we knew health data could leave a website, but we didn’t fully understand how to trace it from the browser to a third-party server, which we figured out how to do. For the frontend, we are proud of building the interactive 3D visualization from scratch using React Three Fiber, Three.js, and Drei. We are also proud of designing the live event timeline, which allows users to look back at the data being sent and see where it is going in real time. The panel on the right also gives users more detailed information about each individual request, making it easier to understand exactly what data is being sent and where.

What we learned

None of us had a networking background, so we learned a lot about how browser traffic actually works: HTTP vs. HTTPS, TLS, proxies, certificates, CORS, HSTS, and the limits of browser-extension APIs. We also learned that privacy detection is not just keyword matching. The same concept can appear under many different field names, which pushed us toward semantic classification and a more careful local-first design.

For the Frontend we learned a lot about how browser extensions work and how much information websites can send in the background. We also learned how to use Reach Three Fiber, Three.js, and Drei to build the 3D visualization and connect it with a Chrome extension. Another thing we learned was how to cater the visualizations to all audiences. We have a technical and simple view for users depending on what they prefer.

We learned that simple buttons require careful checks. Our “Opt Out” feature taught us to verify company links and separate starting a request from completing it. Our “File for Me” feature taught us how to autofill forms and why real submissions need accurate answers and user approval.

What's next for PatientPrivy

As we continue working on PatientPrivy, we’ll build direct company integrations for faster opt-outs and check whether sharing actually stops afterward. We’ll also partner with privacy attorneys to review legal requirements and edge cases before connecting eligible patients with potential class actions.

Throughout, we’ll strive to collect only the minimum data needed. Our goal is simple: faster opt-outs, less unwanted sharing, and a lower risk of sensitive medical data being exposed.