application_settings
ALPS: a Chrome extension that sends HTTP/2 settings inside the TLS handshake. Only Chrome and Chrome impersonators send it.
What it is
application_settings, or ALPS (Application-Layer Protocol Settings), lets the client and server exchange application settings, such as HTTP/2 SETTINGS, during the TLS handshake instead of after it. That saves the time the client would otherwise wait for the server's first HTTP/2 frame.
ALPS was proposed by Google engineers in the draft-vvv-tls-alps Internet-Draft. The draft expired without becoming an RFC, and the extension codes are not assigned by IANA. BoringSSL, Chrome's TLS library, first used code 17513; newer Chrome versions send code 17613, which is the one our test labels application_settings. The older code appears as application_settings_old.
It is implemented in BoringSSL, Chrome's TLS library, and is used between Chrome and servers that support it, such as Google's own. Few other TLS stacks implement it, so in practice it is a Chrome feature.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 2 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
ALPS is one of the strongest Chrome signals in a ClientHello. In our measurements only Chrome 153 and curl_cffi impersonating Chrome send it. curl, Python requests, httpx, Go, Node.js and Guzzle do not, and curl-impersonate chrome116 sends the old code 17513 instead, because that build predates the new code point.
So a client that claims to be a current Chrome in its User-Agent but sends no application_settings is easy to flag.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for application_settings in the TLS details.
Run the TLS fingerprint test