Ask HN: How do you prevent sensitive data leaks in screen-recorded demos?
5 comments
Most of the solutions here assume you control the recording environment, which works well for async demos.
The harder case is live screen shares. If you're walking a client through something in real time and your terminal prints an env variable, or someone opens a config file mid-call to help debug, you can't pause to swap credentials.
The browser is actually a useful interception point for that specific case. Element-level pattern matching (sk-proj-, AKIA, Bearer tokens, key=value in .env format) can blur matching text in real time before it renders on screen. No environment isolation needed, no pre-production setup. Useful specifically because the exposure is transient and unplanned.
auv1107's fake data approach is right for planned async demos. cocodill's ephemeral credentials are right for API testing. Real-time browser-level detection only adds value for the live, uncontrolled session case, which is narrower but harder to solve with either of the other approaches.
Curious what the blurmate approach handles — recordings, live share, or both?
The harder case is live screen shares. If you're walking a client through something in real time and your terminal prints an env variable, or someone opens a config file mid-call to help debug, you can't pause to swap credentials.
The browser is actually a useful interception point for that specific case. Element-level pattern matching (sk-proj-, AKIA, Bearer tokens, key=value in .env format) can blur matching text in real time before it renders on screen. No environment isolation needed, no pre-production setup. Useful specifically because the exposure is transient and unplanned.
auv1107's fake data approach is right for planned async demos. cocodill's ephemeral credentials are right for API testing. Real-time browser-level detection only adds value for the live, uncontrolled session case, which is narrower but harder to solve with either of the other approaches.
Curious what the blurmate approach handles — recordings, live share, or both?
Locally, I would create a second user account on my machine specifically for demos. If I were creating a demo for a web service, hopefully I also would have a test environment with fake data.
It would make me nervous to use a production local account or production server for a demo. The human eye is terrible at catching random bits of text somewhere on the screen.
It would make me nervous to use a production local account or production server for a demo. The human eye is terrible at catching random bits of text somewhere on the screen.
I would not trust blur. It's not a one way process. Just use one time secrets and users you revoke after recording a demo.
Screen Recording tools like ScreenKite (https://screenkite.com) (free) or Screen Studio have blur effect tools. You can apply blur mask
Also use demo account and revoke api keys after recording
(Disclaimer) Dev of the first app
Also use demo account and revoke api keys after recording
(Disclaimer) Dev of the first app
I will prepare a fake data environment, and the screen recording software I use can easily blur/mask in post-production.
My current workflow: 1) use demo-safe seed data 2) identify sensitive fields before recording 3) apply blur/mask before hitting record 4) refresh once to verify persistence 5) run a 30-second dry run
This reduced both editing time and stress.
Curious what workflows/tools people here use for screen recording privacy (especially for SaaS demos and tutorials).
Context/tool I built while solving this: https://blurmate.devstorex.top