Back in https://bugs.webkit.org/show_bug.cgi?id=163220, the `navigator.languages` property was added to WebKit. At the time, it was decided that this property should only list a single language in order to prevent fingerprinting. This made sense, at the time, because the `Accept-Language` request header was also only listing a single language. In the current version of WebKitGtk, as well as Safari 17 on an iPhone (so I assume WebKit on iOS in general), the `Accept-Language` header can list multiple languages, but the `navigator.languages` property continues to list only the default language. This is a tripping hazard for developers. The behaviour differs from both Firefox and Chrome, and documentation such as MDN (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/languages) clearly suggeststhe two values should be the same. In addition, the specification specifically calls out fingerprinting and suggests a mitigation: > To avoid introducing any more fingerprinting vectors, user agents should use the same list for the APIs defined in this function as for the HTTP `Accept-Language` header. From: https://html.spec.whatwg.org/#navigatorlanguage Considering that, the reasoning for the existing behaviour doesn't really fit. Instead, the `navigator.languages` property should always list the same languages as the `Accept-Language` request header.
Agreed, these should match. The fixes for Gtk and for iOS will be separate. On iOS, we'll likely need to use InternationalSupport framework for this.
<rdar://problem/116597209>