How I'd approach web compatibility at DuckDuckGo

A short tour through how I'd think about the role and a small harness I built to test the thinking. Written for a few people at DDG, so the tone is direct, and honest about what I can and can't see from outside.

I started as a web-compatibility engineer at Mozilla, then a platform PM there, then Meta and Spotify. Reading DDG's public source, mining Mozilla's current webcompat corpus, and comparing how Brave / Mozilla / Safari / Chrome run their programs sharpened those priors into the strategy page on this site. To pressure-test the thinking I built a small AI-driven evaluator harness that drives the actual DDG.app and judges what real users see. The harness sits next to the strategy, not as the answer but as evidence that I've worked the problem in detail and that the numbers I'd bring into the role are mine.

One number to set the room. Pointed at the same 26 top sites, a "DDG-like" Chromium proxy reports 19% of them broken. The real DDG.app, driven by a Claude Computer-Use agent through the same evaluator, reports 0%. The five "broken" findings under the proxy all turn out to be cases where anti-bot defenses blocked the automation tool, not real bugs a user would hit. The honest way to test DDG webcompat is to drive the actual DDG app.

Strategy

Three shifts, one umbrella

Reactive → proactive · per-site → root-cause · invisible → measured. The umbrella: make webcompat an owned function. Read →

Methodology

Real DDG, plus a faster proxy

Every test runs two ways: in the actual DDG app, and in a faster Chromium proxy. The difference between them is itself a finding. Read →

Results

Three runs, with caveats

Mode A reproduces known bug reports against today's web. Mode B asks "would changing the UA fix it?" Mode C scans top sites with no anchor. Read →

The premise, in one paragraph

DDG ships no browser engine. It's a privacy shell over each OS's native WebView (WebKit on Apple, Blink on Android/Windows). That means webcompat splits cleanly in two: self-inflicted breakage from privacy protections and the Ddg/ user-agent token (DDG's to own), and inherited engine bugs, where the lever is detection and upstream escalation. From outside, what's visible is a mature exceptions mechanism (privacy-configuration, on the order of 1,200 site mitigations) but no named webcompat owner, no public metrics, and no published policy. I'd come in with the model below as a working hypothesis to refine on week one, not a verdict. I assume DDG is further along than the public surface shows.

What's on this site

Strategy: three shifts (proactive, root-cause, measured), the UA decision framed as an honest fork, and a 30-60-90 with explicit decision gates against measured data.
Methodology: the agent harness, why it has two drivers, and why the gap between them is the point.
Results: three runs. Mode A reproduces existing webcompat bug reports against today's web. Mode B asks whether a UA swap would fix the sites that are broken. Mode C scans top sites for breakage with no anchor. Plus the calibration status of the AI evaluator.
About: who I am, why DDG specifically, and how to reach me.

All code is on github.com/adamopenweb/webcompat-harness (private, ask for access).