4 ms·

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

by zeeg 4y ago

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-from-sentry-bridge-the-gap-between-code-and-ux/#our-privacy-first-approach 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

podoman 4y ago
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 :)
codethief 4y ago
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/ https://sentry.io/for/session-replay/
- zeeg 4y ago
  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.
  - bentlegen 4y ago
    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.
    - brungarc 4y ago
      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 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.
- vadman97 4y ago
  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/replay-configuration/recording-network-requests-and-responses https://www.highlight.io/docs/getting-started/client-sdk/rep...

by zeeg 4y ago

podoman 4y ago

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 :)

codethief 4y ago

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/ https://sentry.io/for/session-replay/

zeeg 4y ago
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.
- bentlegen 4y ago
  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.
  - brungarc 4y ago
    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 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.
vadman97 4y ago
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/replay-configuration/recording-network-requests-and-responses https://www.highlight.io/docs/getting-started/client-sdk/rep...