Hacker News Reader

Comment by zeeg | Hacker News Reader

I think this is a great question, especially with the continued shift towards data residency and customer protection in recent years (GDPR, CCPA).

When we did this at Sentry - which is also built on rrweb (we help fund rrweb btw, everyone else should too!) - we realized privacy was really hard to get right (let alone data security), so we just block all elements that are at risk by default and it turns out the experience is still pretty usable. Ben wrote a bit more about this here: https://blog.sentry.io/2023/02/16/introducing-session-replay...

Not commenting on highlight, but most of the mainstream players in this space take an opt-in protection approach, and often its "you can block this specific HTML element".. which glhf getting right

View on HN

Highlight also has a private by default mode. Totally agree that this is the right way to do it. Also, congrats on the recent launch :)

I see[0] your session replay feature also includes network requests. Do you fully capture request & response there and, if so, how do you handle the arising privacy issue? Does the customer have to set up filters by hand?

[0]: https://sentry.io/for/session-replay/

With the highlight.io client, we use an opt-in strategy to be privacy-first (since network request bodies + headers are often sensitive). We're not capturing network requests/responses unless you enable it and allow deeply configuring what should be captured [0].

[0]: https://www.highlight.io/docs/getting-started/client-sdk/rep...

We have a ton of filtering, but great question. I will ask someone from the team to respond as I'm not sure how well we do on this particular thing and/or what we are capturing today.

Right now we just capture network metadata like URL, connection type (fetch, xhr, websocket, etc), status code, filesize, etc. We additionally filter this data at the edge (before anything gets stored) for any known unsafe values like credit card numbers or SSNs, in case they somehow get into the URL.

As of right now we do not capture actual network request headers or bodies.

In addition to the network call data we already attached, that does go through data PII scrubbing on the edges as you mentioned, we're discussing capturing request/response body. We even talked about it today: https://github.com/getsentry/sentry-javascript/issues/7103

Avoiding any PII from getting into the system is always top of mind. And we're considering this as an opt-in regardless of scrubbing on the edge ingestion service.

Reply on news.ycombinator.com