Handout A: Fake Browser Update Prompt

Captured from designer workstation at Pixel & Co., Wednesday 9:14am. Reconstructed from browser history and download logs.

The Prompt Players See

IM Notes

When to release: Start of Round 1, before players act. Static artifact – does not depend on player decisions.

Facilitation: Do not narrate the red flags. Place the handout in front of players and ask: “What do you notice?” If players miss both the domain name and the registration age after 3 minutes, offer Clue 1: “Tracker, the download logs show that three workstations pulled an executable from adobeupdate-secure.net yesterday afternoon. The domain was registered six days ago.”

Why it worked: Adobe branding and a recognizable product name appearing mid-task at a plausible moment. Designers were sourcing stock imagery – media-related prompts feel normal in that workflow. Deadline pressure means click first, question later.

Red flags players should find (do not point out):

Domain is adobeupdate-secure.net, not adobe.com – visible in the title bar
Domain was registered only 6 days ago – visible in the small print
Legitimate Adobe updates come from within the application, not a browser pop-up linking to a third-party download

Key discussion questions:

“Why would a designer under deadline pressure click this?” (Plausible moment, recognizable brand, high cognitive load two days before the biggest pitch. Stopping to verify felt like friction, not safety.)
“What would you check before clicking an update prompt like this in real life?” (Verify the domain against the vendor’s official site. Check whether the application itself is prompting – not a browser pop-up from a third-party domain.)