# Primary eng (and PM?) emails
tna...@chromium.org, to...@chromium.org, shai...@google.com
# Summary
Remove the Android build number (e.g. “NJH47F” or “OPM4.171019.021.D1”) from the user-agent identification, i.e. the User-Agent header and navigator.userAgent. – Apply to embedders but postpone changing WebView until the Android Compatibility Definition Document (CDD) has been updated which currently mandates the status quo.
# Motivation
The build number may be used for exploit targeting and on some devices (e.g. Pixel phones) the build number is a relevant fingerprinting surface.
Also to bring Chrome closer in line with RFC 7231 section 5.5.3 which stipulates with regards to the User-Agent header: “[...] SHOULD limit generated product identifiers to what is necessary to identify the product [...] SHOULD NOT generate a User-Agent field containing needlessly fine-grained detail [...]”
# Interoperability and Compatibility Risk
The format of the user-agent strings varies between browsers and consumers of the string often turn to heuristics to parse it which can be brittle at times. Removing a token from the string only seems to incur a low risk, though. To mitigate that risk, a kill switch is to be implemented which is intended to be used only in the face of widespread breakage.
Firefox doesn’t include OS build numbers.
Safari Mobile does include the iOS build number as part of the “Mobile” token. (Chrome on iOS emulates Safari and should probably keep doing so to prevent compatibility issues. iOS is outside the scope of this intent, though, as it’s not a Blink platform.)
Edge doesn’t include the Windows build number. (Neither does Chrome on Windows.)
# Alternative implementation suggestion for web developers
None. Developers that really need access to the OS build number probably shouldn’t target the web platform but write native code instead.
# Usage information from UseCounter
Header usage cannot be measured and there is no UseCounter data for navigator.userAgent. Likely most servers parse the user-agent string in one way or another but the build number field probably doesn’t see a lot of use (apart from fingerprinting).
# Entry on the feature dashboard
https://www.chromestatus.com/feature/4558585463832576
# Requesting approval to remove too?
Yes.
Thiemo Nagel
Software Engineer
Google Germany GmbH, Erika-Mann-Straße 33, 80686 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
# Primary eng (and PM?) emails
tna...@chromium.org, to...@chromium.org, shai...@google.com
# Summary
Remove the Android build number (e.g. “NJH47F” or “OPM4.171019.021.D1”) from the user-agent identification, i.e. the User-Agent header and navigator.userAgent. – Apply to embedders but postpone changing WebView until the Android Compatibility Definition Document (CDD) has been updated which currently mandates the status quo.
# Motivation
The build number may be used for exploit targeting and on some devices (e.g. Pixel phones) the build number is a relevant fingerprinting surface.
Also to bring Chrome closer in line with RFC 7231 section 5.5.3 which stipulates with regards to the User-Agent header: “[...] SHOULD limit generated product identifiers to what is necessary to identify the product [...] SHOULD NOT generate a User-Agent field containing needlessly fine-grained detail [...]”
# Interoperability and Compatibility RiskThe format of the user-agent strings varies between browsers and consumers of the string often turn to heuristics to parse it which can be brittle at times. Removing a token from the string only seems to incur a low risk, though. To mitigate that risk, a kill switch is to be implemented which is intended to be used only in the face of widespread breakage.
Firefox doesn’t include OS build numbers.
Safari Mobile does include the iOS build number as part of the “Mobile” token. (Chrome on iOS emulates Safari and should probably keep doing so to prevent compatibility issues. iOS is outside the scope of this intent, though, as it’s not a Blink platform.)
Edge doesn’t include the Windows build number. (Neither does Chrome on Windows.)
# Alternative implementation suggestion for web developers
None. Developers that really need access to the OS build number probably shouldn’t target the web platform but write native code instead.
# Usage information from UseCounter
Header usage cannot be measured and there is no UseCounter data for navigator.userAgent. Likely most servers parse the user-agent string in one way or another but the build number field probably doesn’t see a lot of use (apart from fingerprinting).
# Entry on the feature dashboard
https://www.chromestatus.com/feature/4558585463832576
# Requesting approval to remove too?
Yes.
--Thiemo Nagel
Software Engineer
Google Germany GmbH, Erika-Mann-Straße 33, 80686 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC%3DO2%2BRD2DtDhq%2B9%3DLdtaH%3DhcNns8PHazHY4m1VoGhvAV8_SfA%40mail.gmail.com.
Removing privacy sensitive data from the UA string makes sense.On Mon, Jul 2, 2018 at 7:43 PM Thiemo Nagel <tna...@chromium.org> wrote:# Primary eng (and PM?) emails
tna...@chromium.org, to...@chromium.org, shai...@google.com
# Summary
Remove the Android build number (e.g. “NJH47F” or “OPM4.171019.021.D1”) from the user-agent identification, i.e. the User-Agent header and navigator.userAgent. – Apply to embedders but postpone changing WebView until the Android Compatibility Definition Document (CDD) has been updated which currently mandates the status quo.
# Motivation
The build number may be used for exploit targeting and on some devices (e.g. Pixel phones) the build number is a relevant fingerprinting surface.
Is the "exploit targeting" issue restricted? I cannot access it... If it is, is there a non-sensitive writeup that can be shared on the subject?
Can you expand on the fingerprinting concerns?
Mozilla/5.0 (Linux; <Android Version>; <Build Tag etc.>) AppleWebKit/<WebKit Rev>(KHTML, like Gecko) Chrome/<Chrome Rev> Mobile Safari/<WebKit Rev>
So just to better understand what this intent proposes: Looking at Android UA string documentation, current strings are marked asMozilla/5.0 (Linux; <Android Version>; <Build Tag etc.>) AppleWebKit/<WebKit Rev>(KHTML, like Gecko) Chrome/<Chrome Rev> Mobile Safari/<WebKit Rev>We're talking about removing the "Build Tag etc" piece, right? Does that mean that the device hardware name will also be removed?If so, that is something that has a legitimate use-case for: figuring out the device viewport dimensions and DPR, for image compression purposes.There's also a shipped replacement for that use-case: Client Hints.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdxL6mYYUk6inxm9Lgbf%3D4KuamZDTibW6diHOwFE7kdAQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_L_7SUmsbThwXU5%3DoM9ZkRMzHaOv5f8tiWR6xZJkaMgpA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjdmd1LM7tKqbcq%3DHA0iswurib0G9draJUMN8KA69n8e2w%40mail.gmail.com.
I see nothing about deprecating so I assume the request is to remove the code directly.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC%3DO2%2BTCSzXA0ngL9CavO%2BUXMqbwxPRCbCJMH4ZEMcGAbiR60Q%40mail.gmail.com.