6
5 Comments

Are session replays too much of a privacy violation?

The product I've been building is for session replays (https://en.wikipedia.org/wiki/Session_replay if you've never heard of them), but submitted only at the explicit request of the end user.

Unlike existing solutions (Full Story, LogRocket, etc.) that send the data directly to the cloud, the tool I'm building allows the end user to review the whole session (and redact portions) before it is submitted. I'm looking for your thoughts on the tool, especially as it relates to privacy (https://development.kitchen/product):

  • Is this still too much of a privacy violation?
  • Do you understand the value?
  • Are the privacy issues worth the time/effort saved in tracking bugs?
  • Would you use it if it was just an internal tool for your dev team and not for customers?
  • Which of the following use cases do you see this tool most valuable for: customer support, QA/non-engineers logging bugs for the team, engineers logging bugs

Thanks!

posted to Icon for group Ethics
Ethics
on March 9, 2020
  1. 1

    It depends entirely on implementation. Session replay done wrong is a privacy nightmare. Done right — with automatic masking of sensitive fields, no cookies, no personal data stored — it's incredibly valuable for understanding UX issues. In Zenovay we built session replay with privacy as the default: sensitive fields are auto-masked, recordings are controlled by the site owner, no personal identifiers stored.

  2. 2

    I'm generally very against session reply tools, but this seems like a good compromise!

  3. 1

    Yep, I think this is a good privacy compromise!

    Giving users control over what gets recorded is basically a golden solution to privacy quandaries. (GDPR would agree, if it could talk.)

    I'd use it across the board internally: for support, QA, and UX.

  4. 5

    This comment was deleted 3 years ago.

    1. 1

      Agreed! If your app has a login and you store data that the user gives you (i.e. what probably most apps do), then you are inherently storing at least some usage data attached to PII. That's just how it works.

      By using the app, you are inherently giving consent for that data to be tracked.

    2. 1

      I've definitely heard that argument - "but the app developers have the data anyway" - and I think there's merit to it. But I think the problem is in general, where applications do track this kind of usage data, they try and capture it anonymously. A good deal spend the time to make sure it is truly anonymous and can't be reconstructed through logs etc., though that's really hard to do. If it was recorded as part of a session replay, it is associated with any personally identifiable information (PII) that is captured for that session. I think if usage data gets captured with PII, that's a big deal. Sure the tools generally don't record passwords and CC fields, but aside from that, they rely on the app developers to mark out any regions that contain PII. It's easy for that to escape, and I think it's harder to get all of this in session replays as compared to making sure you get it from all logs , your data store, etc.

      1. 2

        This comment was deleted 3 years ago.

Trending on Indie Hackers
I shipped a productivity SaaS in 30 days as a solo dev — here's what AI actually changed (and what it didn't) User Avatar 270 comments Never hire an SEO Agency for your Saas Startup User Avatar 110 comments 85% of visitors leave our pricing page without buying. sharing our raw funnel data User Avatar 46 comments Are indie makers actually bad customers? User Avatar 40 comments We automated our business vetting with OpenClaw User Avatar 38 comments I sent 10 cold DMs about failed Stripe payments. Here's what actually happened. User Avatar 33 comments