5 min read · pdf · http · deployment
Why PDF honeytokens often do not fire (Preview, Gmail, Chrome)
PDF open-beacons only run in Adobe Acrobat/Reader. Preview, Gmail, and browser PDF viewers sandbox remote callbacks on purpose. Use HTML, Word, Excel, QR, or HTTP instead.
If you open a HorasEye PDF in macOS Preview, attach it in Gmail and preview it, or download it and open it locally without Adobe, and nothing shows in Trigger History, that is expected. Those apps block the mechanism the PDF uses. The token is not broken; the viewer refused to call home.
How the PDF works: HorasEye embeds a PDF OpenAction (and a page open action) that runs Adobe JavaScript to open your beacon URL, plus a tiny invisible link annotation. Adobe Acrobat and Adobe Reader usually execute that on document open. Almost everything else does not.
Why Preview stays silent: macOS Preview does not run PDF JavaScript and does not fetch remote content when you open a file. Same for Quick Look. Opening the PDF after download in Preview will never hit /t/….
Why Gmail (and most webmail) stays silent: attachment preview is sandboxed. The viewer will not run OpenAction, will not launch URLs for you, and will not treat a PDF like a tracking email with remote images. Previewing or downloading the attachment alone is not a trigger. A clickable link or image outside the PDF can still fire if the user fetches it.
Why Chrome, Safari, and Edge PDF viewers stay silent: in-browser PDF renderers do not execute PDF JavaScript. Opening the file in a new tab is not the same as opening it in Acrobat.
What does fire reliably: Adobe Acrobat or Adobe Reader on Windows or Mac when the PDF is opened (and sometimes when the hidden link is clicked in readers that support link annotations). Test with Acrobat if you need to confirm the PDF path.
Clever alternatives for common apps: use the same PDF token’s HTML download (format=html). Double-click the .html file, a browser opens, the tracking pixel loads, and you get an alert. That path works in Safari, Chrome, and Edge, and is the right Mac “open the decoy” test when default PDF apps are Preview.
For Windows office floors, prefer Word or Excel honeytokens. Linked images can fetch on open in Microsoft Word and Excel, and often in LibreOffice. Pages, Google Docs, TextEdit, Quick Look, and Numbers usually will not. See How to use Word and Excel honeytokens for placement.
For email curiosity, prefer QR, HTTP beacon, or web-image tokens: “click to view the report” or a QR on a slide/printout. Gmail opening a PDF attachment almost never fires; Gmail following a link or loading an image can.
Dual-file bait works well in practice: plant Board-Pack.pdf (Adobe path) next to Board-Pack.html or a short “view online” URL (browser path), and optionally a Word copy for office staff. Curious users and attackers often try more than one.
What will not reliably work, even with clever PDF tricks: remote images embedded in the PDF, Rich Media / Flash, URI open actions without JavaScript, or making the PDF “look more legitimate.” Modern viewers treat outbound callbacks as tracking or malware and kill them. There is no dependable PDF-only technique that fires in Preview + Gmail + Chrome’s PDF viewer.
Use HTML download of the PDF token for Mac and browser open detection. Use Word or Excel for Microsoft Office, not Pages or Google Docs on open. Use QR, HTTP, or a web image for mail and browsers. Two token types in the same folder cover more apps than one perfect file.