(written by claude, analyzed together and challenged/guided along the way by Nathan Pankowsky on real data)

98% of your visitors share a clock: testing a 2018 fingerprinting study on three small stores

A 2018 study of two million browser fingerprints found that on a website serving one country, 98% of visitors report the same timezone. We checked that against three small online stores we monitor. It holds for the clock. It holds less well for language. And the visitors who break both almost never buy.

What the paper found

The study is Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale by Alejandro Gómez-Boix, Pierre Laperdrix and Benoit Baudry, presented at WWW 2018. They collected 2,067,942 fingerprints from one of the 15 most visited French websites.

Its headline result is that only 33.6% of those fingerprints were unique, against more than 80% in the earlier Panopticlick and AmIUnique studies. Fingerprinting identifies people far less well on a mainstream site than on a site that privacy enthusiasts visit.

The part we test is narrower. Because the audience sat in one region, two attributes carried almost no information:

• Timezone. 98% of users reported the same one, Central European Time. Its entropy was 0.164 bits, against 3.338 bits in AmIUnique.
• Language. 97.7% of fingerprints had French as their first language.

The authors drew a privacy conclusion from this: when nearly everyone shares a value, the few who differ stand out, and changing either attribute was often enough to make an ordinary fingerprint unique. We are interested in the same fact for the opposite reason. If nearly every visitor to a single-market store looks alike on these two attributes, the ones who don't are worth a look.

Our data

Three online stores, each selling to one country. Store names are withheld.

For store A we also have one ordinary week with full fingerprints, 20 to 27 May, holding 10,202 observations.

Three differences from the paper matter for reading the results:

• Unit. An observation here is one page load with the device's locale recorded. The paper counted fingerprints from cookie-identified users, so our frequent visitors weigh more.
• Language. The paper took the first language of the Accept-Language header. We test whether the expected language appears anywhere in the browser's language list, which is a looser rule.
• Exclusions. Known search crawlers are left out for all three stores, and store A's own staff addresses are left out too.

Result 1: the clock holds

In an ordinary week, store A matches the paper to within a point: 97.3% of observations reported the home timezone, against the paper's 98%.

Most of store A's clock-only mismatches are not foreign at all. They are phones on Israeli networks reporting a neighbouring zone, Asia/Hebron.

The longer windows and the smaller stores sit lower, and the gap is not noise. In stores A and C it traces to one identifiable source each, covered below.

Result 2: language only partly holds

Language is about ten points less uniform in our stores than in the paper, even under our looser rule.

The main cause is the iPhone. iOS browsers often expose a single language, so a Hebrew speaker whose phone is set to English shows no Hebrew at all. In store A the locale rule failed on 20% of Mobile Safari observations, 31% of Chrome for iOS and 37% of Instagram's in-app browser, against under 5% on Android Chrome.

Stricter rules make it worse. Requiring en-GB as the first language in store B, as the paper's measure would, raises failures from 11.2% to 14.2%.

So this half of the paper's finding does not carry over cleanly. Its data was 88% desktop and nearly a decade older. On phones, a missing home language is common among ordinary customers.

Beyond the paper: do the outliers buy?

The paper measured identifiability, not behaviour. We can add behaviour: devices whose clock and language both fall outside the store's market reach its goal (Nathan's edit: conversion pages) at close to zero in all three stores.

One attribute on its own is not a usable signal:

• Clock alone. In store A these devices reached checkout slightly more often than devices that matched. (Nathan's edit: Claude means here: timezone)
• Language alone. In store C these visitors viewed the cart nearly twice as often as devices that matched.
• Either one. Had store A flagged every device that failed either test, it would have flagged the devices behind 100 of its 799 checkouts.

Rows count devices, defined as an IP address plus a browser family, across all traffic and not only ad clicks.

What broke the pattern

In the two stores that sit furthest below the paper's 98%, the departure came from one source each.

Store A: one ad campaign. A single Google campaign supplied 7,117 of the store's 35,860 paid clicks.

• 1,836 of those clicks came from devices with a foreign clock. All other campaigns together sent 55.
• 1,348 clicks, from 1,346 different IP addresses, carried South Asian timezones. Nearly all arrived in August, where they were 16% of the month's paid clicks.
• The devices were budget Android phones set to English (India) and Hindi. Their details were consistent with each other, which is not what spoofed devices usually look like.
• 0.28% of the campaign's clicks reached checkout, against 2.50% for every other campaign. It produced none of the store's 79 paid orders.

That campaign accounts for much of store A's fall from 97.3% in an ordinary week to 95.0% over twenty.

Store C: one cluster of email-link visitors. 129 IP addresses produced 660 observations in a month.

• Every one was Windows, en-US, America/Los_Angeles, on Chrome 135 to 143 while the store's real visitors were on 151.
• Every campaign-tagged visit came from a marketing email link, bunched on three days.
• None reached the cart.

Our reading is that these are email security scanners opening links on behalf of recipients' mail systems. That is an inference from the pattern, and we have no fingerprints from store C to confirm it.

The paper says the audience a site targets shapes how diverse its fingerprints are. The practical corollary for a small store is that locale uniformity is a baseline, and a drop in it points at a specific source you can name.

Limits

• Shares, not entropy. We compare the share of visitors on the home timezone and language. We did not compute entropy, so this corroborates the paper's 98% and 97.7% figures and not its entropy table.
• Different units and measures. Page loads against cookie-identified fingerprints, and a looser language rule, as described above.
• Three stores, two markets. Stores B and C are small. Counts such as 0 of 135 and 3 of 191 show direction and prove little.
• Goals are proxies. Reaching checkout or viewing a cart is not a payment. Store A had 79 paid orders in twenty weeks.
• One week as the baseline. Store A's 97.3% comes from a single week in May.
• The scanner reading is unconfirmed.

What to do with it

If you sell to one country, the share of visitors on your home timezone is a number worth knowing, and it should sit in the high nineties.

1. Measure it for a quiet week to get your own baseline. The script below does that.
2. Break it down by campaign and by traffic source. A drop will usually belong to one of them.
3. Treat a foreign clock together with a foreign language as a reason to look at that source. Treat either one alone as nothing.
4. Fix the source. For an ad campaign, check its location targeting and its placement report, exclude the apps and sites sending the traffic, or move the budget. For email links, leave that group out of your click reporting.

Act on the combination, not on either test alone. In store A, devices that failed one test were behind 91 of its 799 checkouts. Devices that failed both were behind 9.

Measure it yourself

The check in this post needs two values every browser already exposes. This script reads them, compares them with the market you set, and sends one of five states to your analytics: match, language_differs, clock_differs, both_differ or not_recorded. It sends no raw timezone or language.

<script>
(function () {
  // Timezones your customers live in. Include aliases browsers still report.
  var HOME_TIMEZONES = ['Europe/London'];
  // Languages you expect. 'en-GB' matches only en-GB; 'he' matches he and he-IL.
  var HOME_LANGUAGES = ['en-GB'];

  function matchesLanguage(tag) {
    tag = String(tag).toLowerCase();
    for (var i = 0; i < HOME_LANGUAGES.length; i++) {
      var home = HOME_LANGUAGES[i].toLowerCase();
      if (tag === home || tag.indexOf(home + '-') === 0) return true;
    }
    return false;
  }

  function localeState() {
    var timezone = null;
    var languages = [];
    try {
      timezone = Intl.DateTimeFormat().resolvedOptions().timeZone || null;
    } catch (e) {}
    try {
      languages = navigator.languages && navigator.languages.length
        ? Array.prototype.slice.call(navigator.languages)
        : (navigator.language ? [navigator.language] : []);
    } catch (e) {}

    if (!timezone || !languages.length) return 'not_recorded';

    var clockMatches = HOME_TIMEZONES.indexOf(timezone) !== -1;
    var languageMatches = false;
    for (var i = 0; i < languages.length; i++) {
      if (matchesLanguage(languages[i])) { languageMatches = true; break; }
    }

    if (clockMatches && languageMatches) return 'match';
    if (clockMatches) return 'language_differs';
    if (languageMatches) return 'clock_differs';
    return 'both_differ';
  }

  var state = localeState();

  // Google Tag Manager, or anything else that reads the data layer.
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({ event: 'locale_check', locale_state: state });

  // Google Analytics 4 loaded directly with gtag.js.
  if (typeof window.gtag === 'function') {
    window.gtag('event', 'locale_check', { locale_state: state });
  }
})();
</script>

Set the two lists for your market. For a Hebrew-language store that is ['Asia/Jerusalem', 'Asia/Tel_Aviv'] and ['he', 'iw'], because some browsers still report the older names.

In Google Analytics 4, register locale_state as an event-scoped custom dimension, then break locale_check events down by campaign. The number to watch is the share of both_differ.

This is one check. It tells you where a visitor's device says it is from. It will not tell you whether the visitor is automated.

Concluding Notes from Nathan

Claude did quite a good job on this reasoning, but I would not rely on this alone.

Device checks like this are typical of a particular french antibot, which favors them and frequently blocks on them, as determining the appropriate timezone from a residential proxy is sometimes prohibitive.

Claude did not go deep enough to check with IP location here, which is a source of uncertainty as well as it does not always agree with the JavaScript reported timezone.

Other notes on this: these two sensors are eminently spoofable, and I wouldn't rely on them as a positive indicator that these are real visitors. But they are a useful weed-out metric, according to the analysis. More work is needed, and I would consider this a weaker sensor, as a foreign national could be present in country and purchase.

References

• Gómez-Boix, Laperdrix and Baudry, Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale, WWW 2018.
• We found the paper through the dark-knowledge reading list.