5 ms·

What do you say to potential customers who are concerned with the legality and privacy challenges associated with session replay? I recognize how tools like th

What do you say to potential customers who are concerned with the legality and privacy challenges associated with session replay? I recognize how tools like this could level up product/marketing-level decision-making. But with litigation as recent as October 2022, I'm wary of incorporating something like this into any software I control.

podoman 4y ago
In the past, for customers in healthcare and fintech, we've had to actually pass on signing more restrictive contracts (BAA's, etc..) due to the liability. For such a small company, it was hard to be comfortable with situations like that. Since then, we've done a couple things that will hopefully open up more opportunities to work with these sorts of companies. First of all, we have a "privacy by default" mode that obfuscates all text by default (see https://www.highlight.io/docs/getting-started/client-sdk/replay-configuration/privacy https://www.highlight.io/docs/getting-started/client-sdk/rep...). And secondly, we're hoping that open sourcing the tool will help these companies control the data they're collecting so they don't run any risks, and long-term, these companies pay us a license of sorts.
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.
  - 4y ago

podoman 4y ago

In the past, for customers in healthcare and fintech, we've had to actually pass on signing more restrictive contracts (BAA's, etc..) due to the liability. For such a small company, it was hard to be comfortable with situations like that. Since then, we've done a couple things that will hopefully open up more opportunities to work with these sorts of companies. First of all, we have a "privacy by default" mode that obfuscates all text by default (see https://www.highlight.io/docs/getting-started/client-sdk/replay-configuration/privacy https://www.highlight.io/docs/getting-started/client-sdk/rep...). And secondly, we're hoping that open sourcing the tool will help these companies control the data they're collecting so they don't run any risks, and long-term, these companies pay us a license of sorts.

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.
- 4y ago