Bugzilla

This quote from comment 0...
>  Changing ua does not help.
...was from the anonymous reporter, as of May 6 2023. Whether or not that statement was accurate at that point, it's not accurate now at least.
  
Testing today, changing UA *does help*. The site's WebRTC test page is at https://events.webinar.ru/support/test-webrtc and it seems to work fine if I spoof a Chrome UA string with e.g. https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/

Looking at their JS when I load the page without UA-spoofing, it seems we're being judged as failing in `function checkHost(et) {`:

```
            ei = en.unblockUnsupportedBrowsers;
[...]
                eA = navigator.userAgent,
[...]
                eT = eA.match(/firefox\/(([0-9]\.?)+)/i),
[...]
    } else eT ? ei ||
                eu('ProductNotSupportedError') : eE ? eE[1] < 60 &&
```
eT here is truthy (it's an explicit check for `firefox` in `navigator.userAgent`, and `ei` is unset (i.e. they haven't specified `unblockUnsupportedBrowsers` in the associated configuration here), so we evaluate `eu('ProductNotSupportedError')` which ends up resulting in us being blocked.

I'm not sure there's anything else that needs diagnosing here, beyond the fact that the site is simply blocking us with UA sniffing.

This quote from comment 0...
>  Changing ua does not help.
...was from the anonymous reporter, as of May 6 2023. Whether or not that statement was accurate at that point, it's not accurate now at least.
  
Testing today, changing UA *does help*. The site's WebRTC test page is at https://events.webinar.ru/support/test-webrtc and it seems to work fine if I spoof a Chrome UA string with e.g. https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/

Looking at their JS when I load the page without UA-spoofing, it seems we're being judged as unsupported in this part of the site's JS, which is just UA-sniffing:
```
function checkHost(et) {
[...]
            ei = en.unblockUnsupportedBrowsers;
[...]
                eA = navigator.userAgent,
[...]
                eT = eA.match(/firefox\/(([0-9]\.?)+)/i),
[...]
    } else eT ? ei ||
                eu('ProductNotSupportedError') : eE ? eE[1] < 60 &&
```
https://static.webinar.ru/new/js/main.bc03b188.js

Analyzing the control flow here & how we arrive at the `ProductNotSupportedError` outcome:
eT here is truthy (it's an explicit check for `firefox` in `navigator.userAgent`, and `ei` is unset (i.e. they haven't specified `unblockUnsupportedBrowsers` in the associated configuration here), so we evaluate `eu('ProductNotSupportedError')` which ends up resulting in us being blocked.

I'm not sure there's anything else that needs diagnosing here, beyond the fact that the site is simply blocking us with UA sniffing.

This quote from comment 0...
>  Changing ua does not help.
...was from the anonymous reporter, as of May 6 2023. Whether or not that statement was accurate at that point, it's not accurate now at least.
  
Testing today, changing UA *does help*. The site's WebRTC test page is at https://events.webinar.ru/support/test-webrtc and it seems to work fine if I spoof a Chrome UA string with e.g. https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/

Looking at their JS when I load the page without UA-spoofing, it seems we're being judged as unsupported in this part of the site's JS, which is just UA-sniffing:
```
function checkHost(et) {
[...]
            ei = en.unblockUnsupportedBrowsers;
[...]
                eA = navigator.userAgent,
[...]
                eT = eA.match(/firefox\/(([0-9]\.?)+)/i),
[...]
    } else eT ? ei ||
                eu('ProductNotSupportedError') : eE ? eE[1] < 60 &&
```
https://static.webinar.ru/new/js/main.bc03b188.js

Analyzing the control flow here & how we arrive at the `ProductNotSupportedError` outcome:
`eT` here is truthy (it's an explicit check for `firefox` in `navigator.userAgent`, and `ei` is unset (i.e. they haven't specified `unblockUnsupportedBrowsers` in the associated configuration here), so we evaluate `eu('ProductNotSupportedError')` which ends up resulting in us being blocked.

I'm not sure there's anything else that needs diagnosing here, beyond the fact that the site is simply blocking us with UA sniffing.

This quote from comment 0...
>  Changing ua does not help.

...was from the anonymous reporter, as of May 6 2023. Whether or not that statement was accurate at that point, it's not accurate now at least.
  
Testing today, changing UA *does help*. The site's WebRTC test page is at https://events.webinar.ru/support/test-webrtc and it seems to work fine if I spoof a Chrome UA string with e.g. https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/

Looking at their JS when I load the page without UA-spoofing, it seems we're being judged as unsupported in this part of the site's JS, which is just UA-sniffing:
```
function checkHost(et) {
[...]
            ei = en.unblockUnsupportedBrowsers;
[...]
                eA = navigator.userAgent,
[...]
                eT = eA.match(/firefox\/(([0-9]\.?)+)/i),
[...]
    } else eT ? ei ||
                eu('ProductNotSupportedError') : eE ? eE[1] < 60 &&
```
https://static.webinar.ru/new/js/main.bc03b188.js

Analyzing the control flow here & how we arrive at the `ProductNotSupportedError` outcome:
`eT` here is truthy (it's an explicit check for `firefox` in `navigator.userAgent`, and `ei` is unset (i.e. they haven't specified `unblockUnsupportedBrowsers` in the associated configuration here), so we evaluate `eu('ProductNotSupportedError')` which ends up resulting in us being blocked.

I'm not sure there's anything else that needs diagnosing here, beyond the fact that the site is simply blocking us with UA sniffing.