I Can Finally Screen-Share My SQL Client Without Leaking Prod Data

We were halfway through a customer demo when I remembered I was connected to
staging, not to the demo seed database. I had just typed
SELECT * FROM users LIMIT 20 and hit Cmd+Enter. Twenty real email addresses
appeared on my screen, which was mirrored to a conference room of people who
were not supposed to see them.

I alt-tabbed to my Zoom window so fast I think I pulled a tendon.

There was no harm done — staging data is obfuscated, the emails were fake,
the customer is still a customer. But the adrenaline was real, and the sheer
avoidable stupidity of the situation stuck with me. Every SQL client I have
ever used will happily render hunter2 in plaintext to whoever is pointing a
camera at your laptop. That is not a sensible default in 2026.

So I added a data masking layer to data-peek.

What it does

Two things, really.

It auto-masks columns by name. Out of the box, every column whose name
matches email, password, passwd, pwd, ssn, social_security,
token, secret, api_key, or apikey is blurred. Phone and address
patterns are in the rule list but disabled by default because they create too
many false positives on arbitrary schemas. The rules are just regexes, so
you can add your own (for my team: a stripe_ rule that catches
stripe_customer_id and friends).

You can manually mask any column, any time. Click a column header, hit
"Mask Column," done. The masked state is scoped per tab, so masking
users.full_name in one query does not affect a different query.

Masked cells render with filter: blur(5px) and user-select: none. You can
see the shape of the data — same row height, same column width, no layout
shift — but not the contents. When you actually need to see a value, hold
Alt and hover. The cell reveals for as long as you hold it and re-blurs
when you let go.

That hover-to-peek mode is the best part. It keeps you in the flow:
"checking a single email address to verify an account" no longer means
revealing twenty of them.

The rules

These are the defaults, straight from src/renderer/src/stores/masking-store.ts:

const DEFAULT_RULES: AutoMaskRule[] = [
  { id: 'email',    pattern: 'email',                                 enabled: true  },
  { id: 'password', pattern: 'password|passwd|pwd',                   enabled: true  },
  { id: 'ssn',      pattern: 'ssn|social_security',                   enabled: true  },
  { id: 'token',    pattern: 'token|secret|api_key|apikey',           enabled: true  },
  { id: 'phone',    pattern: 'phone|mobile|cell',                     enabled: false },
  { id: 'address',  pattern: 'address|street',                        enabled: false }
]

Two things I learned writing the matcher.

First, case insensitivity is mandatory, not optional. Different ORMs and
naming conventions will give you email, Email, EMAIL, emailAddress,
email_addr. The matcher compiles each pattern as new RegExp(rule.pattern, 'i')
so one rule catches them all. Without that flag, Email slips through
every time and you have a false sense of security.

Second, the effective mask is the union of manual and auto. If you
manually unmask a column but the auto-rule still matches, the auto-rule wins
on the next render. This was a deliberate choice: the whole point is to fail
closed. If you want to permanently exclude a column, you edit the rule,
not the cell.

Here is the resolver that combines both sources:

getEffectiveMaskedColumns: (tabId, allColumns) => {
  const { maskedColumns, autoMaskRules, autoMaskEnabled } = get()
  const manualMasked = new Set(maskedColumns[tabId] ?? [])

  if (!autoMaskEnabled) return manualMasked

  const effective = new Set(manualMasked)
  for (const col of allColumns) {
    for (const rule of autoMaskRules) {
      if (!rule.enabled) continue
      try {
        const regex = new RegExp(rule.pattern, 'i')
        if (regex.test(col)) {
          effective.add(col)
          break
        }
      } catch {
        // Invalid regex — skip
      }
    }
  }
  return effective
}

The try/catch around the regex is there because the rule list is
user-editable. If someone adds user[ as a pattern, I do not want the entire
results grid to crash. The invalid rule silently no-ops. A production-grade
version would surface a red squiggle in the rule editor; I did not do that
yet.

The render path

The masking logic lives in Zustand; the render logic lives in one small
cell component. The meaningful lines from data-table.tsx:

function MaskedCell({ isMasked, hoverToPeek, children }: MaskedCellProps) {
  const [peeking, setPeeking] = useState(false)

  const onMouseEnter = (e: React.MouseEvent) => {
    if (hoverToPeek && e.altKey) setPeeking(true)
  }

  return (
    <span
      onMouseEnter={onMouseEnter}
      onMouseLeave={() => setPeeking(false)}
      style={peeking ? undefined : { filter: 'blur(5px)', userSelect: 'none' }}
    >
      {children}
    </span>
  )
}

That is the whole thing. No canvas trickery, no data-URL sleight of hand,
no modified result set — the raw value is still in the DOM. If someone is
smart enough to open devtools on your SQL client during a demo, they can dig
it out. The threat model here is "accidentally revealing data to a camera or
screen-share," not "malicious insider with inspector access." I think that is
the right level to aim at. Perfect is the enemy of I will actually use it
every day.

The userSelect: 'none' matters more than the blur: it means you cannot
double-click and copy a masked value into the clipboard by reflex. One of
the quiet ways PII leaks is not from someone reading your screen, it is from
you pasting a blurred value into Slack thinking "surely the blur meant that
wasn't the real thing."

What I'd do differently

I wish I had done it the other way around. The blur is a presentation
trick. A truly paranoid version would mask at the IPC boundary — have the
main process redact values before they ever hit the renderer, based on the
same rules. That way a devtools inspector genuinely cannot see the original.
The tradeoff is that hover-to-peek becomes a round-trip through IPC, which
adds latency to the interaction. I chose the fast UX and a weaker threat
model. I still think it is the right call, but I want the IPC-redaction
option as a toggle for security-conscious users.

The rules should be repo-shareable. Right now each user's rules live in
their own Zustand-persisted local storage. But a team would reasonably want
a shared rule set — "our customers table has a pci_encrypted_pan column,
mask that everywhere" — and right now there is no way to distribute that
short of everyone copy-pasting it manually. A .data-peek-masks.json at the
repo root would solve it. Queued up.

The phone pattern should probably be on by default. It is off because
mobile_application_id and friends match the pattern and create noise. But
"noise from too much masking" is a strictly better failure mode than
"leaking a phone number in a Loom." I will flip the default.

The honest pitch

If you have ever had a "I was sharing my screen" moment, this feature is for
you. If you record Loom demos, pair on production bugs, or stream your
coding, this feature is definitely for you.

data-peek is at datapeek.dev. The masking code is
open source — src/renderer/src/stores/masking-store.ts if you want to
read it or port the idea to your own tool. Copy it, improve it, tell me what
you did differently. The goal is fewer adrenaline spikes in conference rooms.