Insights

The numbers on the front page say how much was seen. These say what shape it was in — and where the obvious reading of a number is the wrong one.

A real audience is never even

Client populations are power laws. On any domain with real traffic the busiest stack carries far more than its 1/N share — a browser version everyone is on, an SDK every app embeds. So multiply the top stack's share by the number of stacks and organic endpoints land in double digits.

A value near 1 means every stack carried the same load. No audience does that. A roster of profiles being rotated does exactly that.

domainstacksobservationsbusiest stackflatness
app.appsflyer.com20536,4418%1.66
www.dpdgroup.com173,58023%3.85
api.oneme.ru106,55255%5.50
www.budget.com235,53630%7.01
mtalk.google.com2113,43336%7.65
api.github.com116,57375%8.27
content-autofill.googleapis.com275,49233%8.82
services.ticketmaster.com175,06453%9.00
outlook.live.com1311,12076%9.85
appleid.apple.com1214,42182%9.86
android.clients.google.com285,40136%9.97
gql.twitch.tv115,73793%10.21

Only domains with at least ten distinct stacks are ranked. Below that the statistic is arithmetic rather than evidence: with five stacks even a thoroughly dominated endpoint scores low, because there is nothing for the load to be uneven across.

The fingerprint count overstates client diversity

A JA4 is three parts. ja4_b is the cipher list and ja4_c the extensions and signature algorithms — those belong to the client. ja4_a carries the TLS version, the cipher and extension counts, and the ALPN offered — and ALPN is a fact about the destination: a browser offers h3 only where it has learned QUIC works, and http/1.1 alone where it knows there is no h2. One browser build therefore appears under several JA4s.

distinct JA4
2,377
client buildsja4_b + ja4_c
2,057
extension setsja4_c
872
cipher listsja4_b
1,171

13% of the JA4 rows are a client already counted, seen through a different destination. Group by ja4_b + ja4_c when you want clients; keep the whole JA4 when you want sightings.

One stack, a lot of traffic

The other end of the same axis. Volume behind a single client stack is one operator, not an audience — the corpus cannot say who, but it can say there was only ever one of them.

What the traffic is made of

Grouped by cipher list, which is a property of the TLS library build and passes through unchanged to everything using it — so one row here covers a whole family of clients. Named from the same catalogue the fingerprint pages use.

cipher listknown asobservationsshareJA4 rows
8daaf6152771Google Chrome / Chromium814,26837%171
d83cc789557eunnamed386,95418%3
f57a46bbacb6unnamed309,20114%37
5b57614c22b0Android (Conscrypt) / Flutter (BoringSSL)214,93510%73
a09f3c656075Apple Safari / WebKit121,4856%26
e8f1e7e78f70unnamed106,4905%39
85036bcba153unnamed64,6423%11
0633f72d41caunnamed42,1082%2
4b22cbed5bedunnamed36,1942%5
4d8ed5baf28eunnamed32,6041%2
b262b3658495unnamed30,8771%11
76e208dd3e22unnamed30,0841%11

A high JA4-row count against one cipher list is the collapse above, seen from the other side: many destinations, one client family. An unnamed row is a cipher list the catalogue has not been taught yet, not an unknown client.

browse every domain →