La página 'Browser Verification' es una referencia técnica que describe métodos pasivos para identificar navegadores web sin depender únicamente del campo HTTP User-Agent, fácilmente falsificable. El autor defiende que, aunque el User-Agent resulta poco fiable para distinguir navegadores genuinos de simuladores, varias técnicas de fingerprinting pasivo permiten detectar incoherencias en el comportamiento del cliente.
La primera técnica analiza el orden de las cabeceras HTTP. Firefox envía una secuencia característica (Host, User-Agent, Accept, Accept-Language, Accept-Encoding, Accept-Charset, Keep-Alive, Connection, Referer), mientras que Chrome sigue otro orden (Host, Connection, Accept, User-Agent, Referer, Accept-Encoding, Accept-Language, Accept-Charset, Keep-Alive). Internet Explorer 6 y sus versiones posteriores también presentan órdenes distintivos. Los simuladores de navegador rara vez replican estas secuencias exactas, y algunos proxies introducen o eliminan cabeceras, lo que convierte el orden en una señal útil de detección.
La segunda técnica examina las opciones TCP negociadas durante el handshake. Los sistemas Linux negocian las opciones SACKOK, TSTAMP, NOP y WINDOWSCALE en un orden fijo, y las instancias de Amazon EC2 presentan típicamente un valor WS=7. macOS finaliza con TSTAMP, SACKOK y EOL, mientras que Windows coloca siempre NOP en primer lugar. Aunque algunos cortafuegos eliminan opciones, rara vez las reordenan, por lo que la secuencia de opciones sigue siendo informativa.
El documento recomienda además mantener una base de datos de cadenas User-Agent con sus fechas de lanzamiento, ya que navegadores como Chrome se actualizan automáticamente en menos de 90 días, con más de la mitad de los usuarios actualizando en 30 días. Esto convierte los User-Agents obsoletos en indicadores sospechosos.
Una técnica más avanzada explota la implementación de Math.random() en JavaScript. Las versiones antiguas de Firefox e Internet Explorer usaban registros de desplazamiento con realimentación lineal (LFSR) con parámetros conocidos, lo que permitía reconstruir el estado interno a partir de dos números aleatorios consecutivos. Chrome usó históricamente un generador Multiply-With-Carry (MWC) que requería cinco muestras y menos de 5×2¹⁶ pruebas para identificarlo. Sin embargo, el autor señala que Firefox, Safari y Chrome actuales utilizan Xorshift128 del proyecto V8, lo que imposibilita este tipo de diferenciación.