← All cases

Keeping DLP usable as Chrome changes

Trend Micro · QA and SEG leadership · DLP SDK

I built release monitoring, proposed a supported-site scanning design, and improved diagnostic guidance. Each addressed a different source of recurring work.

Catch compatibility failures early

Chrome major and minor updates sometimes broke DLP upload blocking. The team initially discovered these failures through customer cases and then rushed hotfixes.

I wrote a Python program to check Google's official API for new Chrome Beta and Stable versions. It fed a workflow that updated the browser, tested sensitive-file uploads, and emailed the team if blocking failed.

  1. New Chrome version
  2. Browser update
  3. Upload-blocking test
  4. Email on failure

This helped the team address compatibility issues before customer reports and reduced manual effort around Chrome releases.

Reduce resource use with explicit scope

Customers also reported slower browsing. During a team-led DLP refactor, I proposed limiting default browser scanning to a supported-site list. The team adopted and implemented the design.

Before

Scan website data by default

After

Scan supported sites

CPU: at least 10% lowerMemory: at least 10% lower

These relative reductions came from switching the site-list design alone, based on my recollection of the QA performance report. The original report is unavailable; the figures do not represent the whole refactor.

Improve the information in escalated cases

As SEG Leader, I returned incomplete cases with specific collection requests and assigned complete cases by priority, complexity, and workload. I initiated an illustrated DLP guide that taught L2 how to classify issues and collect the required diagnostics.

20-percentage-point drop in missing-data returns to L2

First month after the DLP guide rollout, according to figures shared by my manager. This is a case-return percentage, not resolution time or a relative 20% reduction.

Evidence and limits
Read full incident and beta notes ↗