Browser Fingerprinting on iPhone (Safari)

Browser Fingerprinting on iPhone (Safari)

This iPhone runs on WebKit, the engine every browser app on iOS is required to use, so the fingerprinting surface the inspector above measures here is really Safari's surface no matter which app icon you tapped to get here. Two separate defenses stack on top of that shared engine: the WebGL renderer string has returned an empty value since Safari 12, years before any dedicated anti-fingerprinting feature existed, and Apple's Advanced Fingerprinting Protection (AFP), on by default since iOS 26, separately modifies canvas rendering, WebGL output, audio processing, and font access.¹ Neither protection touches hardware or locale signals, so a handful of rows in the scan above still report values as real as they would on a browser with no defenses at all.

Specifications

Two different protections are stacked on this iPhone, and they cover different signals

WebKit has returned an empty string from the WebGL renderer query since Safari 12,² a restriction that predates Advanced Fingerprinting Protection by years and has nothing to do with the iOS 26 rollout. AFP itself is newer and narrower in a different way: it modifies canvas rendering output, WebGL rendering, OfflineAudioContext processing, and font access, reducing the uniqueness of each without hiding that a scan ran at all. Reading the rows on this page as one undifferentiated "protected" block misses that two unrelated mechanisms, one old and one new, are doing the actual work.

The WebGL renderer row is empty here for a reason that predates AFP

Calling getExtension('WEBGL_debug_renderer_info') and reading UNMASKED_RENDERER_WEBGL on this iPhone returns an empty string rather than a GPU model name, a restriction Safari has applied since version 12.² That stands in contrast to Android Chrome, where the same query on a Galaxy phone returns a full string like "Adreno (TM) 750" identifying the exact chipset. The row will read blank here whether or not AFP is active, because the WebGL renderer restriction and AFP are two separate protections that happen to affect the same API surface for different reasons.

Because the renderer string has been unavailable for so long, most fingerprinting scripts targeting iOS Safari never relied on it in the first place; the practical effect of the block is closer to background noise than a recent policy shift. It is worth knowing regardless, since a reader comparing this scan against a friend's Android phone will see a populated WebGL row on the Android side and a blank one here for a reason that has nothing to do with either device's actual privacy settings.

What AFP changes here versus what stays real

On this iPhone, AFP means the canvas hash, the WebGL rendering readout, and the audio fingerprint rows will differ from a capture taken before iOS 26, and the font-detection row is limited to a common subset rather than every font Safari can technically render.¹ navigator.hardwareConcurrency, screen.width and screen.height, window.devicePixelRatio, and the timezone and language rows are not part of what AFP modifies, so those continue to report this iPhone's real values every time the scan runs.

That split matters for reading the entropy score above. A drop in the CANVAS, WEBGL, and AUDIO groups after an iOS update reflects AFP doing its job; a row in IDENTITY or the hardware group staying exactly the same across scans is not a sign the protection missed something, it is a signal AFP was never designed to touch in the first place.

Why every app on this iPhone runs the identical protections

Apple's App Store Review Guidelines state that apps which browse the web on iOS must use the WebKit rendering engine and WebKit JavaScript, a requirement numbered 2.5.6 that has applied since the App Store launched.³ In practice that means Chrome, Firefox, Edge, and every other browser you can install on this iPhone wraps WebKit in its own interface rather than shipping Blink or Gecko the way those same browsers do on a laptop. Switching apps here changes the toolbar, the extensions available, and which account syncs your history, but it does not change which engine renders the page or which fingerprinting defenses apply underneath it.

The layout viewport stays fixed even when you pinch to zoom

iOS separates the layout viewport, the width Safari uses to lay a page out, from the visual viewport, which is what you actually see after zooming. Apple's own viewport documentation describes pinch-to-zoom as changing the visual viewport's scale while leaving the layout viewport's width unchanged, and window.devicePixelRatio stays fixed at the same value throughout that gesture regardless of how far in you have zoomed.⁴⁵ A script reading either property back gets the same number before, during, and after a pinch-zoom gesture on this device.

That stability is exactly why devicePixelRatio and the layout viewport width sit among the real, unmodified values discussed above: they behave like fixed hardware constants tied to the physical panel rather than something a reader's own zooming or resizing habits could change moment to moment, which is also what makes them a genuinely useful, repeatable match signal for this specific iPhone model rather than noise AFP would need to touch.