Invisible Ink: Why Your CSS is a Privacy Nightmare

Introduction

In the ongoing arms race between privacy advocates and the tracking industry, the battlefield has shifted. For years, the security community has focused on third-party cookies and JavaScript-based fingerprinting as the primary threats to user anonymity. This focus led to the rise of robust blockers and the widespread adoption of 'NoScript' environments. However, a new and more subtle threat has emerged from an unlikely place: Cascading Style Sheets (CSS).

In this technical deep dive, we explore original research presented by Leon Trampert and Daniel Weber at Black Hat Asia. They demonstrate that CSS—often considered a 'harmless' layout language—now possesses enough computational power and query capability to bypass traditional privacy defenses. From identifying your hardware architecture to stealing your email subjects, CSS is no longer just about colors and fonts; it is a powerful tool for information exfiltration.

Background & Context

Browser fingerprinting is the process of collecting a unique set of attributes from a user's device to create a persistent identifier. Unlike cookies, which can be deleted, fingerprints are derived from the system's inherent properties. Traditionally, trackers used JavaScript to ask the browser: "What fonts are installed?", "What is your screen resolution?", and "Are you on a Mac or PC?"

As privacy-conscious users began disabling JavaScript, tracking entities looked for alternatives. CSS has evolved significantly to support 'responsive design,' introducing features that allow websites to adapt to a user's environment. While these features make the web more beautiful and accessible, they also create side channels. Because CSS is rarely blocked—disabling it would break the visual integrity of almost every website and email—it provides a perfect 'invisible' medium for tracking.

Technical Deep Dive

The Primitives of CSS Tracking

The core of CSS-based fingerprinting lies in 'conditional loading.' When a CSS rule depends on a system attribute, the browser only fetches a resource (like a background image) if that condition is met. By monitoring which images are requested from their server, an attacker can determine the user's configuration.

1. Media Queries (@media): Used to detect screen width, height, and orientation. More deviously, they can detect prefers-color-scheme (dark vs. light mode).
2. Support Queries (@supports): These detect if a browser supports specific CSS features. Since browsers implement features at different times, this can uniquely identify a browser's engine and version.
3. Container Queries (@container): This is the 'holy grail' of modern CSS tracking. It allows an element to query its own size. Researchers use this to measure the width of text. Because different fonts have different widths, an attacker can load a string of text, apply a 'target' font, and measure the container. If the width matches a known value, the font is present on the system.

CPU Fingerprinting via Math

One of the most shocking revelations is the ability to detect CPU architecture using the calc() function. Different hardware (Intel x86 vs. ARM) and different browser engines (Blink vs. Gecko) handle complex floating-point math with slight variations in rounding.

By executing a calculation involving sin() or pi in a CSS calc() expression and using that value to set a property (like a width), researchers can create a condition that only triggers a network request on an ARM-based MacBook, for instance, while remaining silent on an Intel-based Windows machine.

Email: The Weakest Link

While browsers have some protections, email clients are often much more vulnerable. Most email clients use standard browser engines (like WebKit for Apple Mail) to render HTML. Because email clients almost always block JavaScript, they are often less aggressive about sanitizing CSS, fearing they will break the layout of legitimate marketing emails.

In the 'SogoMail' vulnerability, researchers used a technique called 'CSS Injection.' By injecting an @import rule, they could apply styles to the entire email client UI. They used CSS selectors to target the inbox's subject line elements. By creating rules like "if the first letter of the subject is 'A', load image_A.png," they could systematically exfiltrate the subjects of every email in a user's inbox simply by having the user open one malicious email.

Mitigation & Defense

Defending against CSS fingerprinting is difficult because the features being abused are essential for the modern web. However, there are effective strategies:

• Resource Pre-fetching: ProtonMail utilizes a 'side-channel-free' approach. Their servers fetch every possible resource mentioned in an email's CSS regardless of the user's screen size or settings. These resources are then inlined as data: URIs. When the user opens the email, no external requests are made, leaving the attacker with no data.
• Restrictive Rendering: Using email clients that offer a 'Plain Text' mode or strictly sanitize CSS to remove advanced features like container queries and @import.
• Browser Hardening: Tools like the Tor Browser attempt to standardize ('normalize') CSS outputs so that every user looks identical, though this often comes at the cost of web compatibility.

Conclusion & Key Takeaways

The research into 'Invisible Ink' serves as a critical reminder that complexity is the enemy of privacy. As we add more features to web standards to improve developer experience, we inadvertently expand the attack surface for tracking and data leakage. For developers, the lesson is to be mindful of the information leaked through responsive designs. For security professionals, it is a call to look beyond JavaScript when auditing for privacy vulnerabilities. CSS is no longer just a stylesheet language—it's a sophisticated, albeit accidental, scripting environment.

Always remember to test your applications with 'Remote Content Loading' disabled and consider how your UI reveals system-level information to the network.