emoji rendering fingerprint

every operating system renders emoji differently — different fonts, different supported sequences, different fallbacks. by measuring the getBoundingClientRect() width of emoji sequences placed in a hidden span, any page can infer your emoji font, os version, and which unicode sequences are supported. no canvas required. no permission required.

zwj sequences (👨‍💻) should render as a single glyph on modern systems. if they render as multiple glyphs, the width will be a multiple of the base glyph width — and that tells the page your emoji support level precisely.

• no canvas blocker helps. this measurement uses plain dom layout, not canvas pixel reads. canvas fingerprint defenders don't intercept getBoundingClientRect().
• zwj support narrows os + version. zwj (zero-width joiner) sequences like 👨‍💻 render as a single glyph on ios 10.2+, android 7.1+, and macos sierra+. on older systems they render as separate glyphs with proportionally larger width. the ratio is a version number.
• regional flags are even more differentiating. apple encodes all country flags. google encodes most. microsoft historically encoded very few. the flag set tells you the os vendor with high confidence.
• recent emoji are a version beacon. 🫠 (melting face, 2021) and 🫶 (heart hands, 2022) fall back to a replacement character on pre-update systems. measuring which ones render as emoji vs boxes directly encodes your update recency.