Issue metadata
Sign in to add a comment
|
iOS user agent not as expected on Chrome 69
Reported by
samuel.k...@airbnb.com,
Sep 7
|
||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. Install Chrome 69 on iOS 11.4.1 2. Visit an enterprise page where browsers are filtered based on patch level 3. User agent is advertised as just iOS 11.4, so it will be blocked What is the expected behavior? The user agent should be: Mozilla/5.0 (iPhone; CPU iPhone OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/69.0.3497.71 Mobile/15E148 Safari/604.1 What went wrong? The user agent for Chrome is supposed to be the same as Safari with Version/<safari version> replaced with CriOS/<chrome version> but this is not the case https://developer.chrome.com/multidevice/user-agent#chrome_for_ios_user_agent The user agent coming through is: Mozilla/5.0 (iPhone; CPU iPhone OS 11_4 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/69.0.3497.71 Mobile/15E148 Safari/604.1 Safari's user agent is: Mozilla/5.0 (iPhone; CPU iPhone OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1 Did this work before? Yes 68 Chrome version: 69.0.3497.71 Channel: stable OS Version: iOS 11.4.1 Flash Version: We use Duo for this enforcement which is based off user agent for now, so we expect user agents to be as documented.
,
Sep 7
We've changed UA on Android recently (https://groups.google.com/a/chromium.org/d/msg/blink-dev/nJ7Izi0QNAQ/5F8ELQuOAQAJ), but not on iOS. This is not Privacy team's change. I also don't see any recent changes in ios/web/public/user_agent.h iOS folks, do you have an idea?
,
Sep 7
Looks like the change happened here https://chromium-review.googlesource.com/c/chromium/src/+/1126105 limiting the iOS version to just the minor version and not patch level. This was done to match Safari, but the Safari change was reverted.
,
Sep 7
Webkit change which readded marketing iOS and macOS versions to user agents, as a partial reversal: https://bugs.webkit.org/show_bug.cgi?id=182629 Chrome bug where this change was made: https://bugs.chromium.org/p/chromium/issues/detail?id=860229
,
Sep 14
Please assess severity
,
Sep 14
[sorry for the slow reply, I was ooo until yesterday] Samuel, thank you for the report, especially for including all the helpful details and pointers. The objective of the change was to reduce the fingerprinting surface of the UA string by freezing the build number. Since on iOS there's a 1:1 correspondence between OS patch level and build number, freezing the build number only makes sense when stopping to send the patch level at the same time. This looked like a riskless change because it was following Safari's footsteps (I had explicitly tested that Safari reported 11.3.1 as 11_3) but now that Safari has reversed their position I'll re-add the patch level to retain compatibility for the time being. (In the meantime, I'd suggest to talk to Duo for a workaround.) A word of caution: Parsing Chrome's UA string to determine the version of the underlying OS is a layering violation and goes against RFC 7231 section 5.5.3. A future version of Chrome may omit this information. Please don't rely on its presence.
,
Sep 14
,
Sep 14
Thanks for the update - I very much wish that we weren't relying on this information, but unfortunately there are a lot of products which only use it. In our case, that is Duo's device policy features which rely solely on parsing user agents https://duo.com/docs/policy#operating-systems. I've been told this will change in the future, but it's still the case today.
,
Oct 29
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by poromov@chromium.org
, Sep 7Components: -Enterprise Internals>Services>Content Privacy