Sentinel

Sentinel was a HackNYU team project built around a practical problem: people accept privacy policies they will never read.

The extension looked for the current site’s privacy-policy link, sent the policy to a serverless analysis API, and returned a score plus specific concerns in a compact browser UI. It also experimented with showing whether the browser’s public IP appeared to be using a VPN.

I built Sentinel with Adam Elsayed as my partner. I owned most of the extension setup, React interface, Lambda and API scaffolding, integration work, result states, and project site. Adam and I developed the product decisions and analysis approach together during the hackathon.

React state and Chrome extension events do not naturally behave like one ordinary web page.

The extension injected or ran browser code to locate a privacy-policy URL, then passed that context into the React popup. A tab change, content-script result, loading state, or API response could arrive outside the component lifecycle the UI expected. We had to define when a scan started, what domain it belonged to, and which result could update the current view.

The final UI separated loading, score, concern list, domain, and detail states instead of blocking on one large request. That made the extension usable inside the small popup surface and prevented a previous tab’s result from looking like it described the current page.

Running policy analysis on every tab open would be slow, expensive, and unnecessary.

The Chrome frontend called API Gateway, which routed to a Python Lambda function. The function validated the policy URL, checked MongoDB for an existing scan on the domain, and returned cached structured output when available. Only a cache miss fetched and parsed the policy before sending text through the analysis model.

The response returned the score and concerns in a shape the extension could render directly. Caching shortened repeat scans and turned the backend into a stable boundary between browser code, policy retrieval, model output, and persistence. AWS SAM kept the function and API resources deployable together.

The product was more useful when it showed the evidence behind a number.

The interface listed specific privacy concerns and allowed the user to inspect a plain-language explanation. Severity and quantity informed the summary score, but the concerns carried the context. A single number without supporting text would have looked authoritative while hiding model uncertainty and the policy language it came from.

That limitation still matters. Sentinel was a hackathon prototype using model-generated analysis, not a legal review or security audit. The score was a navigation aid for a long document, not proof that a company was safe or unsafe. The portfolio describes the pipeline and UX without promoting the prototype beyond what it could establish.

Sentinel compressed product, extension, cloud, and model-integration work into one short feedback loop.

The hardest part was not calling an API. It was moving context from a webpage into an extension, through a cached serverless pipeline, and back into a small interface without losing which site or state the result belonged to. The project also forced quick decisions about cache keys, error states, browser permissions, CORS, MongoDB connectivity, and deployable AWS resources.

I keep it in the archive as a team hackathon project and an early end-to-end build. It shows how I worked across the repository under time pressure, but the writing preserves the team attribution and the prototype’s limits.