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 concerning pattern is that the data-collecting ones actively hide what they're doing — the Similarweb-linked extensions apparently obfuscate with Base64 or AES-256 before sending.
Worth distinguishing from extensions that are genuinely client-side. A basic test: check the extension's manifest for network permissions (host_permissions). If it only requests the active tab and has no background network access, it physically cannot phone home. The inspection is 30 seconds in chrome://extensions.
The more insidious problem is that users can't easily distinguish between "this extension processes data locally" and "this extension processes data locally and also sends it somewhere." Same UI, very different behavior.
How much overhead did that add to your development workflow? I'm curious if building and maintaining that parallel demo infrastructure became its own project, or if it stayed lightweight.
Also, did you use this for investor demos specifically, or more for development/QA?
I thought this too initially - "just make the fake data look professional."
Where it broke down for me: investors with technical backgrounds would ask edge case questions ("show me how this handles 10K records" or "what does error handling look like with real load?"). The fake environment couldn't simulate that complexity authentically.
The other issue was muscle memory. When I'm demoing something I use daily, I'm fast and fluent. In a fake environment, I'd hesitate or click wrong because it's not my real workflow. Investors noticed.
Thanks for the Mockaton suggestion! I like the API mocking approach - that handles the backend data cleanly.
The challenge I kept running into was the frontend side during live screen shares. Even with mocked APIs, I'd have credentials visible in browser tabs, notifications popping up with client names, or sidebar elements showing sensitive info.
Did you find Mockaton solved the full screen-share exposure problem, or did you combine it with other approaches?
Interesting and smart approach - most noise generators are obviously artificial in their traffic patterns.
I've been thinking about browser privacy from a different angle: not hiding what you browse, but hiding what's visible on your screen when you share it. Screen sharing during video calls basically bypasses every privacy tool you have running (VPN, tracker blockers, etc.) because the other person sees your raw screen.
The layered privacy defense framing makes sense. This handles the ISP/tracking side. But what handles the "accidentally showed my email to my entire team during a screen share" side? Different threat model but equally common.
This is a smart workflow. I've been doing something similar (record screen, then manually write docs) and the AI approach saves hours.
One thing that still trips me up though - the prep before hitting record. I spend like 10 minutes closing personal tabs, clearing browser history, making sure nothing sensitive is visible on screen. By the time I'm "ready" to record, I've lost the spontaneous energy that makes demos feel natural.
Does your tool handle any of that? Like auto-detecting sensitive content before processing or helping sanitize the recording after? Or is it assumed you're recording in a clean environment?
Curious because the actual documentation generation is only half the workflow. The "setup tax" before recording is the part that kills my momentum.
Congrats on shipping this. The 15 minute turnaround is impressive.
Nice execution. The toggle visibility approach is intuitive for live coding.
One use case you might not have considered: pairing this with a persistent "demo mode" profile in VS Code. I've been experimenting with a separate workspace that auto-loads this extension plus other privacy settings.
Have you thought about expanding beyond config files? Sometimes git commit messages in the terminal include sensitive issue IDs or customer names, database connection strings leak in SQL output, or file paths reveal internal org structure. The config file approach is solid but I'd pay for a "demo mode" extension that handles all those edge cases.
What's the performance impact on large config files (like 1000+ line .env files)? Does it parse in real-time or cache the redaction?
Really clean approach to the pre-call panic. The dual reality concept is smart.
I've been working on a similar problem from the browser side (since most of my sensitive stuff lives in tabs - email, Slack, Notion). Different angle but same pain point.
Curious about the multi-monitor scenario - if I'm sharing Screen 1 but a cloaked window spans both monitors, does it cloak the whole window or just what's visible on the shared screen?
Also wondering about the "forgot to cloak" problem. I know I'd 100% forget to toggle before a call at least once a week. Any plans for persistent rules like "always cloak windows matching X pattern"? The mental overhead of remembering seems like it could be a blocker.
Congrats on shipping - the pain point is very real. Have you seen any performance hit on the capture stream itself? Some screen share tools get weird when windows are programmatically hidden.
The browser-vs-app debate aside, the bigger issue for me is what happens once you're in the call.
Screen sharing on Zoom (or any platform) is where the real anxiety kicks in. One wrong tab, one notification, one bookmarked URL you forgot about.
I've moved to keeping a completely separate browser profile for calls - nothing in it except the meeting app. Overkill? Maybe. But it eliminates the pre-share panic entirely.
Congrats on the launch! This resonates - I've dealt with the "accidentally exposed credentials during a demo" problem a lot.
The .env file is one of the most common culprits, but I've found the problem extends beyond just one file type. What I've learned:
The broader challenge:
- .env files in code editors
- Config files in various formats (YAML, JSON, TOML)
- Database GUIs (showing connection strings, table data)
- API tools (Postman, Insomnia showing auth tokens)
- Browser tabs (logged into admin panels, showing URLs with tokens)
- Terminal windows (commands with API keys)
- Slack/email windows (messages with sensitive info)
Most solutions are file-type specific or app-specific. But during a screen share, the sensitivity context switches constantly - one moment you're in VS Code, next you're in a browser, then Postman, then back to the terminal.
How did you decide to focus on .env files specifically vs. trying to tackle the broader problem? Curious about your thinking on scope vs. coverage trade-offs.
Also, what's your approach to detecting what qualifies as a "secret" that needs masking? Pattern matching, or something more sophisticated?
I'm experiencing this exact problem building app that blurs sensitive data for screen sharing and recording.
Users immediately ask: "How do I know you're not collecting my data?"
What I've learned about building trust:
1. Being defensive doesn't work - people's privacy concerns are valid
2. You need to over-explain how it works: no AI, local processing only, no data ever leaves the browser
3. Provide ways they can verify: open DevTools Network tab, check the code, read the privacy policy
4. Be transparent about what you DO collect (I only collect usage analytics, never the actual data being processed)
5. Build in public around the privacy/data protection topic so people see your values
The counterintuitive part: "free tool that protects privacy" sounds good, but it's actually MORE suspicious because "why would you give this away for free?"
The extension is called DataBlur if you want to see how I'm handling the transparency piece in practice. But curious what specific privacy concerns came up for you - was it about data storage, what you're collecting, or something else?
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?