Intent to Ship: User Agent string: cap macOS version number to 10_15_7

[Ken Russell]

Contact emails

k...@chromium.org

Explainer

https://bugs.chromium.org/p/chromium/issues/detail?id=1175225

Specification

https://bugs.chromium.org/p/chromium/issues/detail?id=1175225

Design docs

https://bugs.chromium.org/p/chromium/issues/detail?id=1175225

Summary

In the user agent string on macOS, cap the reported OS version number to 10_15_7. Mozilla's Firefox team and Apple's Safari team have encountered a long tail of broken web content when the user agent string reports "Mac OS X 11_0_0" - basically, any macOS major version greater than 10. Per http://crbug.com/1175225 , both browsers have capped the reported macOS version to 10_15_7 to both work around this, and also slightly increase user privacy. We would like Chrome to follow this precedent.

Blink component

Blink>Network

TAG review

Not needed; relatively minor change which has shipped in Firefox and Safari with no TAG review.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Firefox and Safari have already shipped this change to their user-agent strings in order to fix a long tail of broken websites on macOS 11 and later, and to slightly increase user privacy. The risk to interoperability and compatibility is if Chrome doesn't ship the same change - these already-identified web sites are currently broken when visited in Chrome. User privacy is currently also slightly decreased in Chrome compared to Firefox and Safari.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1679929)

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=217364)

Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=1171998#c26) Unity, as one example, would prefer to see a browser-side change for this purpose, as cited in the above bug comment. Other web developers' feedback can be found on issues linked to those provided from Firefox's and WebKit's issue trackers.

Ergonomics

Slight risk that developers who look for other web features in tandem with the OS release would be affected by no longer advertising the true macOS version in the user-agent string.

Activation

Slight risk that web developers or end users may be impacted by no longer being able to see the precise macOS version on the end users' machine in the user agent string. Aside from that, activating this immediately does not seem to pose significant risk, at least as far as feedback to the Firefox and Safari teams has indicated.

Security

None.

Debuggability

No new support needed; DevTools already offers a way to override the user-agent string on a page-by-page basis.

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1175225

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1176035

Sample links

https://bugs.chromium.org/p/chromium/issues/detail?id=1171998

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5452592194781184

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hi Ken,

On 2/8/21 7:38 PM, Ken Russell wrote:
> Interoperability and Compatibility
>
> Firefox and Safari have already shipped this change to their user-agent
> strings in order to fix a long tail of broken websites on macOS 11 and
> later, and to slightly increase user privacy. The risk to
> interoperability and compatibility is if Chrome doesn't ship the same
> change - these already-identified web sites are currently broken when
> visited in Chrome. User privacy is currently also slightly decreased in
> Chrome compared to Firefox and Safari.
>
>
>
> Gecko: Shipped/Shipping
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1679929

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1679929>)

A tiny point of clarification, a Firefox patch exists, but has not yet
shipped. But a number of Firefox engineers in the bug are supportive
(it's been blocked on a final r+ for a few weeks for unknown reasons).

That said, I think this is the right thing to do for compatibility, and
a nice incremental gain for privacy.

thanks,
Mike

[Yoav Weiss]

Gotta love UA sniffing...

Seems like Unity have fixed the issue in their code, but applying it on the long tail of apps would require a non-trivial amount of work from many people who don't necessarily care.

LGTM1

--
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/e2465409-2566-4bfa-3ced-b106b13b0f0b%40google.com.

[Rick Byers]

This makes sense to me. But will there still be some non UserAgent header way to determine the actual MacOS version number (client hints etc.), eg. for sites trying to correlate performance or functionality issues to specific OS releases? If not, I'd want to put more effort into working with our partners to understand the cost of eliminating this functionality from the platform.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEg8riK0KOzX1CBfpX1%2B1hkSvwjywPad%2B7bMOxreKawrNw%40mail.gmail.com.

[Mike Taylor]

Hi Rick,

On 2/9/21 10:57 AM, Rick Byers wrote:
> This makes sense to me. But will there still be some non UserAgent
> header way to determine the actual MacOS version number (client hints
> etc.), eg. for sites trying to correlate performance or functionality
> issues to specific OS releases? If not, I'd want to put more effort into
> working with our partners to understand the cost of eliminating this
> functionality from the platform.

`Sec-CH-UA-Platform-Version` will provide this once UA Client Hints is
enabled by default, so figuring out the "real" macOS version will be
possible in the very near future.

In the meantime, this change aligns us with Safari is reporting today.

thanks,
Mike

[Rick Byers]

On Tue, Feb 9, 2021 at 12:13 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Rick,

On 2/9/21 10:57 AM, Rick Byers wrote:
> This makes sense to me. But will there still be some non UserAgent
> header way to determine the actual MacOS version number (client hints
> etc.), eg. for sites trying to correlate performance or functionality
> issues to specific OS releases? If not, I'd want to put more effort into
> working with our partners to understand the cost of eliminating this
> functionality from the platform.

`Sec-CH-UA-Platform-Version` will provide this once UA Client Hints is
enabled by default, so figuring out the "real" macOS version will be
possible in the very near future.

LGTM2 to fix the UA string, but only after some API (Sec-CH-UA-Platform-Version or anything else) is fully available as a work-around.

Since we know it will be possible to request this information "in the very near future", it seems wrong to have any period / versions where developers are potentially impacted by the lack of information but don't yet have access to the workaround for requesting it if they really need it. This is consistent with our "ease of adaptation" compat principle. 

[Mike Taylor]

Hi Rick,

On 2/9/21 11:32 AM, Rick Byers wrote:
> LGTM2 to fix the UA string, but only after some API
> (Sec-CH-UA-Platform-Version or anything else) is fully available as a
> work-around.
>
> Since we know it will be possible to request this information "in the
> very near future", it seems wrong to have any period / versions where
> developers are potentially impacted by the lack of information but don't
> yet have access to the workaround for requesting it if they really need
> it. This is consistent with our "ease of adaptation

> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>"
> compat principle.

We enabled UA-CH by default today in [1], so there shouldn't be any
version gaps between `Sec-CH-UA-Platform-Version` being available and
the "capped" macOS version shipping.

Hopefully that addresses your (valid) concerns. :)

[1] <https://chromium-review.googlesource.com/c/chromium/src/+/2525742>

thanks,
Mike

[Rick Byers]

Thanks Mike, it does! When you said "soon" I really wasn't expecting anywhere near that soon :-)

[Chris Harrelson]

LGTM3

--

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/CAFUtAY8_DvhCZ%3DZMp3oOt4dM8qAJdhiEV4Yuh-5Z0%2BvN38TcLA%40mail.gmail.com.

[Alex Russell]

I'm worried that this isn't great precedent. Fixing the UA string for one small-ish class of content that we haven't quantified breakage in may have as much downside risk for other sites over the medium term as this fix delivers -- risks we're going to sort out in the larger Accept-CH discussion.

Do we have a list of sites broken and a sense of their scope/use? Have we done the devrel work to reach out to the biggest of them first? Is Unity's fix a one-off or will it be resilient to other UA changes over time?

Regards 

[Eric Portis]

Just to share a sad and somewhat relevant story:

Safari doesn't decode images -- it passes that responsibility off to the underlying OS. Cloudinary has been dealing with mounting customer complaints about certain WebPs not working in in iOS ≥ 14.3 & MacOS ≥ 11.1. As Safari pioneered this change (freezing the OS bit of the User-Agent string), our best option right now is to turn off all WebPs to all Safaris.

(Here's the WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=219977)

Although Chromium doesn't rely on the OS for image decoding, I don't think it's immune to all bugs that are tied to things that you can't discern from just `Sec-CH-UA` and `Sec-CH-Mobile`. A future where targeted workarounds for such bugs are impossible (as with Safari, right now) or merely impossible for some large percentage of our customers (who can't for whatever reason configure the Permissions Policies necessary to send Cloudinary detailed UA Client Hints) is a bit scary.

[Mike Taylor]

Hi Eric,

On 2/11/21 5:20 PM, Eric Portis wrote:
> Although Chromium doesn't rely on the OS for image decoding, I don't
> think it's immune to all bugs that are tied to things that you can't
> discern from just `Sec-CH-UA` and `Sec-CH-Mobile`. A future where
> targeted workarounds for such bugs are impossible (as with Safari,
> right now) or merely impossible for some large percentage of our
> customers (who can't for whatever reason configure the Permissions
> Policies necessary to send Cloudinary detailed UA Client Hints) is a
> bit scary.

I'm not sure I understand how Cloudinary works (I guess the User-Agent
header is pretty important?), but if there's some feedback you have
related to UA-CH and developer ergonomics (or important missing use
cases), I'd be interested in learning more.
https://github.com/WICG/ua-client-hints/issues/new is a great place to
start.

thanks,

Mike

[Ken Russell]

Hi Alex,

It's a fair point. My understanding is that Apple discovered after releasing their beta at WWDC last year that reporting "Mac OS X 11_0" in the UA string caused widespread breakage of content, leading to their decision to freeze it at 10_15_6 or 10_15_7 - at least for the time being. I'm not sure whether the breakage the Safari team found was just Unity content, or other sites too.

I can't find written evidence of this though. Have linked to additional Firefox bugs from http://crbug.com/1175225 that have more documentation of the decisions made by that team and Safari.

Outreach has happened to some of the bigger sites like itch.io. There is however a long tail of content, across many sites, that's currently broken only in Chrome. Please see http://crbug.com/1171998 for more details.

Unity's most recent export path should be resilient to further UA changes.

Does this additional information, along with the decisions that have been made by the Firefox and Safari teams, help motivate making this change?

-Ken

[Rick Byers]

It seems there's two overlapping concerns here:

1) Concern over the long-term direction of freezing much of the UA string and making high-entropy data available on request only. I know this is a long debate and not totally resolved (and not something we probably want to block this specific issue on entirely). But where folks fall on that debate will probably have a lot to do with how they feel about the more immediate question:

2) This short-term immediate step of freezing the MacOS version number in particular.

My personal LGTM was based on my conviction that some flavor of #1 is inevitable eventually, and so taking this small step in that direction (where there is some clear user upside and browser precedent for doing so) is net helpful in learning and planning for that. But I think there is plenty of room for debate on the tradeoffs of taking this step now vs. later.

From our compat principals, in addition to data on the extent of breakage Alex is asking about, I think the key other question that could use more data is the "ease of adaptability" and "outreach" pieces. I notice that Sec-CH-UA only provides a JS mechanism (via getHighEntropyValues) for reading the OS version, no HTTP mechanism. What sort of outreach / partnership work has been done to understand the impact of that decision? Do we have any examples of partners confirming that they've successfully replaced their usage of OS version numbers with client hints? Has any existing OS-version-reporting logic in popular analytics or A/B testing tools been updated to take advantage of Client Hints?  +Addy Osmani and +Shubhie Panicker who I imagine may have some insight into the ecosystem here.

The other part of the compat principles that carries a lot of weight for me here is interoperability. Given the high fraction of Safari usage on MacOS, would we really be doing much to help the developer ecosystem by leaving Chrome divergent from Safari? Or would we potentially just increase confusion as behavior differs between Safari and Chrome users?

Eric, thank you for raising the Cloudinary WebP case here - that's a great example of the sort of issue that comes with OS version numbers being unavailable. In that specific case I'd hope this is just a short-term issue since Apple should be motivated to fix their WebP decoding issue in MacOS 11 (once many sites have disabled WebP for Safari generally). So what worries me more is your ability to learn that the issue is MaxOS 11 specific (since that seems important in getting traction from Apple in fixing it). Do you know to what extent having OS version numbers in User-Agent was critical to tracking down the issue? To what extent do you have the ability to run script ("navigator.userAgentData.getHighEntropyValues(["platformVersion"])") for getting diagnostic telemetry in such cases?

Rick

[Mike Taylor]

On 2/12/21 10:09 AM, Rick Byers wrote:

From our compat principals, in addition to data on the extent of breakage Alex is asking about, I think the key other question that could use more data is the "ease of adaptability" and "outreach" pieces. I notice that Sec-CH-UA only provides a JS mechanism (via getHighEntropyValues) for reading the OS version, no HTTP mechanism. What sort of outreach / partnership work has been done to understand the impact of that decision? Do we have any examples of partners confirming that they've successfully replaced their usage of OS version numbers with client hints? Has any existing OS-version-reporting logic in popular analytics or A/B testing tools been updated to take advantage of Client Hints?  +Addy Osmani and +Shubhie Panicker who I imagine may have some insight into the ecosystem here.

Just a small point of clarification - the default low-entropy hints (`Sec-CH-UA` and `Sec-CH-UA-Mobile`) do not provide OS version. But `Sec-CH-UA-Platform-Version` is a hint that can be requested and will provide that info via HTTP.

[Rick Byers]

Oh perfect, thanks for that correction! I made the silly mistake of skimming the explainer (which doesn't mention this particular header) instead of the spec. I should have known the headers would match the JS API (I was thinking it was a high-entropy thing). Still, perhaps the explainer should be updated to add the missing headers or mention that it's a subset?

Thanks,

   Rick

[Mike Taylor]

All good -- that's great feedback as well. I filed https://github.com/WICG/ua-client-hints/issues/201 to make things more obvious.

[Anne van Kesteren]

On Tue, Feb 9, 2021 at 3:01 PM 'Mike Taylor' via blink-dev
<blin...@chromium.org> wrote:

> On 2/8/21 7:38 PM, Ken Russell wrote:
>> Gecko: Shipped/Shipping
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1679929
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1679929>)
>
> A tiny point of clarification, a Firefox patch exists, but has not yet
> shipped. But a number of Firefox engineers in the bug are supportive
> (it's been blocked on a final r+ for a few weeks for unknown reasons).

FWIW, the patch has landed.

[Ken Russell]

Thanks Anne for following up.

Mike organized a face-to-face meeting between stakeholders on the Firefox and Chromium teams today. There was agreement that this change will fix a long tail of web content and has low chance of regression. If a sufficient amount of this content is fixed, it would be easy to uncap the reported OS version, if that's desired in the future.

Given the three owner LGTMs above, I'm planning to CQ https://chromium-review.googlesource.com/2667135 tomorrow, unless there are any further concerns.

Thanks for all of the discussion to date.

-Ken

[Yoav Weiss]

Hey Ken,

I don't believe Alex's questions were fully addressed, specifically the one about quantifying the breakage. 

It seems like we could do that by e.g. searching the HTTPArchive for sites that use unity, and e.g. contain the faulty regex (assuming it's used in JS rather than on the server side, I'm not sure about that last point). Alternatively, we could use HA to get a list of sites that use Unity and then crawl them to see which break.

If you suspect that such research will take us beyond the branch point, you could add a feature flag and then turn it on server-side after branch, or try to merge this back once we have more data.

Cheers,

Yoav

--

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/CAMYvS2eP7pi6kKy3Pdsiio3jnSfwov%2BJCatfwk3a4vtvUt4yXw%40mail.gmail.com.

[Ken Russell]

Hi Yoav,

Apologies - since Alex didn't reply to my email on February 11, I assumed his concerns were addressed.

On your advice I spent some time investigating querying the HTTPArchive, and set up a project and billing. However, there's a high cost to making a mistake in the initial query - it will likely eat up the free quota, and I can't use my corporate card for this purpose. Do you have a suggestion for the precise query that should be run against the archive, and which specific table?

My initial triage of this problem was to search for Unity's WebGL Player on Google - there are literally thousands of individual sites containing this code, so it's not possible for e.g. itch.io to solve the problem for even a majority of the games on the web. A random sampling from them and the links on http://crbug.com/1171998 showed that most are still broken.

Could we let the three LGTMs above stand, and allow https://chromium-review.googlesource.com/2667135 to land? Again, Safari and Firefox have already moved in this direction, so at this point we're just aligning Chromium's behavior with other major browsers, and fixing a significant web compatibility problem.

-Ken

[Yoav Weiss]

On Thu, Feb 25, 2021 at 1:58 AM Ken Russell <k...@chromium.org> wrote:

Hi Yoav,

Apologies - since Alex didn't reply to my email on February 11, I assumed his concerns were addressed.

On your advice I spent some time investigating querying the HTTPArchive, and set up a project and billing. However, there's a high cost to making a mistake in the initial query - it will likely eat up the free quota, and I can't use my corporate card for this purpose. Do you have a suggestion for the precise query that should be run against the archive, and which specific table?

Let's sync off thread. Happy to help you get started and run the query you need here.

[Ken Russell]

Hi Alex, Yoav, all,

Yoav helped immensely by constructing and running the queries against the HTTPArchive data set - thank you so much Yoav!

The query we ran was:

SELECT url
FROM (
SELECT url, body
FROM `httparchive.response_bodies.2020_10_01_desktop`
WHERE url LIKE "%UnityLoader.js%" and body LIKE "%Mac OS X (10%"
)

It looks like the HTTPArchive processing pipeline might be broken - 2020-10-01 was the last one containing response bodies.

 

I'd like to stress that it's clear the data is incomplete. None of the itch.io games from http://crbug.com/1171998 show up, while https://samhogan.itch.io/grey-box-testing , as just one example, is definitely still broken. Also, a Google search for "Unity WebGL Player" returns over 20,000 results, and again from random sampling, only a small fraction of them have been fixed so far.

Anyway, the result is 216 URLs out of 5506819 sites queried. This is 0.0039%, which is still higher than the 0.003% threshold usually used for deprecating functionality in Blink. The sites are highly varied - see the results directly.

Does this sound OK to move forward with this user-agent string modification?

Thanks,

-Ken

[Alex Russell]

The deprecation threshold historically was 0.03% (or 10x the breakage ratio here), but measured via UMA histograms (so pageload based rather than URL-count based). 20K URLs could be a reason to make this change if any of them are top-1K sites. Do we have visibility into that?

[Yoav Weiss]

I ran another scan and another interesting number is that there are 272 Unity sites in the HTTPArchive. So another way to look at this is that 79.4% of Unity sites out there are broken in Chrome at the moment.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e32e04bc-6af5-493d-81fd-49e7d125725bn%40chromium.org.

[Mike Taylor]

On 2/25/21 3:05 PM, Yoav Weiss wrote:
> I ran another scan and another interesting number is that there are 272
> Unity sites in the HTTPArchive. So another way to look at this is that
> 79.4% of Unity sites out there are broken in Chrome at the moment.

It's probably redundant to point this out, but Chrome will be the only
browser that can't display the content on these sites as soon as Firefox
87 ships on ~March 23[1].

Firefox has been shipping the change for more than a week in Nightly and
Beta and so far don't know of any compat fallout[2].

[1] https://wiki.mozilla.org/Release_Management/Calendar
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1679929#c43

[Ken Russell]

Alex, could you provide your go-ahead on this, or other feedback?

-Ken

[Anthony Bowker]

Inspired by Ken and Yoav's querying of HTTPArchive, I ran a query to see what extent other content includes similar UA string parsing problems.  Running the following:

SELECT DISTINCT page

FROM (

SELECT url, page, body

FROM `httparchive.response_bodies.2020_10_01_desktop`

WHERE body LIKE "%Mac OS X (10%"

);

SELECT COUNT(DISTINCT page)

FROM `httparchive.response_bodies.2020_10_01_desktop`;

Gives 57,427 pages (sites) were found out of 5,506,740 i.e. 1.04%

Looking at a small random sample, there are some recurring JS libraries: YTPlayer, jwplayer; and the (now-deprecated) implementation of jQuery.browser

My analysis is imperfect: the matched regex code and JS fragments may be entirely unused by the sites in question.  But it does illustrate the extent to which the web in general has assumed a "Mac OS X (10" user agent string pattern for a long time.

Thanks, Anthony

[Ken Russell]

Thanks Anthony for your additional input. I hope this provides more motivation to move forward with this change.

-Ken

[Yoav Weiss]

+Alex Russell - thoughts on the above? 1% of HA sites sure sounds like a lot, and while we don't know they are broken, we're also not sure they aren't...

[Alex Russell]

So @Annie Sullivan was kind enough to dig up a list of top 1K sites (by time spent) on Mac, and I looked for the intersection with likely-broken origins from your recent query. The subset (top-site on left, busted origin on the right) was:

github.io       tensaix2j.github.io
github.io       poesimulator.github.io
abc.net.au      qed.splash.abc.net.au

amazonaws.com   s3.eu-central-1.amazonaws.com 

This seems to indicate to me no top 1K site is currently broken.

With that in mind, I'm happy for us to put a bandaid on this for a few releases while we come up with a better way to track breakage in the wild, but I'd also like to commit to removing this intervention at some date certain. Maybe we identify a list of sites and build a way to feed them the "wrong" UA..that would be OK. Perhaps the breakage we track goes down that we can flip back w/o any extra work. Whatever the eventual solution, short term, can we agree on a time-limit for freezing this? Say 3-6 releases?

[Ken Russell]

On Thu, Mar 4, 2021 at 11:00 AM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

So @Annie Sullivan was kind enough to dig up a list of top 1K sites (by time spent) on Mac, and I looked for the intersection with likely-broken origins from your recent query. The subset (top-site on left, busted origin on the right) was:

github.io       tensaix2j.github.io
github.io       poesimulator.github.io
abc.net.au      qed.splash.abc.net.au

amazonaws.com   s3.eu-central-1.amazonaws.com 

This seems to indicate to me no top 1K site is currently broken.

With that in mind, I'm happy for us to put a bandaid on this for a few releases while we come up with a better way to track breakage in the wild, but I'd also like to commit to removing this intervention at some date certain. Maybe we identify a list of sites and build a way to feed them the "wrong" UA..that would be OK. Perhaps the breakage we track goes down that we can flip back w/o any extra work. Whatever the eventual solution, short term, can we agree on a time-limit for freezing this? Say 3-6 releases?

Hi Alex,

Yes, I'll certainly commit to removing or limiting and rephrasing this intervention in that timeframe. Have filed http://crbug.com/1184851 against Chrome 96, and will work on it as that date gets closer.

Thanks to you and Annie for your analysis, and for your agreement to move forward with this intervention for the time being.

-Ken

--

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/CANr5HFVgp3T%2B_%3DKQ3cprduiTVhEXxZSEq-N49LHYmqNM%3DGkbKA%40mail.gmail.com.

[Yoav Weiss]

It seems reasonable to ship this now and re-discuss in 3-6 releases. I'm not sure the outcome of that discussion would be that we need to reinstate the UA string to expose the real platform on BigSur, but we'll probably have more data on the problem and on UA-CH as a viable alternative at that point.

[Domenic Denicola]

FWIW apparently this problem prevents medical board exam students from taking their exam using Chrome on macOS 11. The problematic page is https://prod.examity.com/systemcheck/check.aspx and the problematic file is https://prod.examity.com/systemcheck/SystemReadiness/OSBrowserCheck.js line 127:

osVersion = /Mac OS X (10[\.\_\d]+)/.exec(nAgt)[1];

(A friend reached out to me to ask for help as to why they couldn't take their medical exam.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss]

Thanks for letting us know. Seems like the problem extends beyond just Unity, and we might be closer to the 1% number than we initially hoped...

On Thu, Mar 11, 2021 at 4:31 PM Domenic Denicola <dom...@chromium.org> wrote:

FWIW apparently this problem prevents medical board exam students from taking their exam using Chrome on macOS 11. The problematic page is https://prod.examity.com/systemcheck/check.aspx and the problematic file is https://prod.examity.com/systemcheck/SystemReadiness/OSBrowserCheck.js line 127:

osVersion = /Mac OS X (10[\.\_\d]+)/.exec(nAgt)[1];

(A friend reached out to me to ask for help as to why they couldn't take their medical exam.)

oh my :(

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.