Our classifier's worst false positives this month.
Publishing these is awkward. Not publishing them would be dishonest. Here's where our classifier got it wrong in the last 30 days, and what we've done about it.
The Dismissmode classifier has a 0.17 per cent false-positive rate over the last 30 days across about 4.1 billion page loads we've instrumented. That's low enough that most users never encounter one. But 0.17 per cent of 4.1 billion is still seven million events, and a fraction of those were genuinely user-disrupting. Here are the three most embarrassing, what happened, and what we've done.
1. A Wordle clone had its share modal removed as a cookie banner
The site is a popular open-source Wordle implementation. After completing a puzzle, it shows a modal with a 'Share' button and two style options. Our DOM classifier saw 'modal, bottom-centre position, buttons with labels matching consent-dialog lexicon' and removed it. Users who finished a puzzle got no confirmation, no share link, nothing.
Fix: added a check for 'Share', 'Copy link', or game-score language in the modal content. The classifier now requires that a modal contains at least two of [consent, cookie, GDPR, privacy, preferences, tracking] to be considered a cookie banner. Previously it required one. This fix rolled out on April 3rd.
2. A news site's legitimate newsletter opt-in was removed as a dark pattern
A UK news publication has an in-article 'Sign up for our morning briefing' block. It's inline, not a modal. It's not a dark pattern. The user chose to sign up, and the publication doesn't block content if they don't.
Our newsletter-detector was too eager. It saw 'sign up', 'email field', 'submit button' and removed the entire block as a subscribe-wall variant. Readers who wanted the newsletter couldn't find it.
Fix: the detector now distinguishes modal and overlay patterns (blocking, intrusive, dark) from inline embeds (offered, non-blocking, legitimate). Inline newsletter signups are left alone. Modal and full-page ones are still dismissed. This fix rolled out on April 7th.
3. A video player's controls were categorised as autoplay-video overlay
A niche lecture-hosting site uses a custom HTML5 video player with controls positioned bottom-right, semi-transparent background, and specific aria labels that matched our autoplay-video classifier. The classifier removed the controls. Users could play, pause, and mute, but they couldn't scrub or change playback speed.
Fix: autoplay-video-overlay detection now requires the element to be positioned bottom-right, semi-transparent, and to contain the word 'autoplay' or a pause icon without corresponding full playback controls. Added an allow-list for common open-source video players (Plyr, Video.js, JW Player). This fix rolled out on April 10th.
Why we publish these
Every extension in our category says it doesn't break sites. Most extensions in our category do break sites occasionally. The combination of 'claim to be perfect' and 'actually imperfect' is how you lose user trust once they find out.
We publish every incident we know about. The live transparency feed is linked in the footer. Users can report new incidents from the extension toolbar. Fixes are attributed to whoever reported them.
The numbers will continue to include embarrassment. We'll keep publishing them anyway.