1991383 - omegleapp.me - captcha displayed when accessed

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Calin Tanase]

Environment:
Operating system: Windows 10
Firefox version: Firefox 143.0/145

Steps to reproduce:

1. Go to https://omegleapp.me/
2. Observe the page.

Expected Behavior:
Page loads.

Actual Behavior:
Blocked page displayed.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/179819

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[BugBot [:suhaib / :marco]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

I can reproduce on my home network connection (no VPN used at all), with current Firefox 143 release and 145 Nightly.

Chrome Mask trivially gets me past the block, so this seems to just be UA-sniffing.

Comment 4

[Daniel Holbert [:dholbert]]

Trivial curl commands (reduced from copy-as-curl in network devtools) using our Chrome mask UA-string (good) vs. our real UA string (bad):

curl 'https://omegleapp.me/' \
  -v \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36' \

--> successful response, including HTTP/2 200 and all the expected web content.

curl 'https://omegleapp.me/' \
  -v \
  -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0'

--> unsuccessful response, including HTTP/2 403 (forbidden) and Cloudflare's blocked-page web content.

Comment 5

[Daniel Holbert [:dholbert]]

jschanck & jesup - I think you have contacts at Cloudflare - could you ask them about this? (I'm guessing it's them rather than the site itself doing the UA-based blocking here, but I don't know enough about the internals of this blocking mechanism to know who's doing what.)

If it's helpful, here's a Cloudflare Ray Id from a Firefox 143 session where I was just blocked when trying to load this page (as I am every time with the default UA string): 9879d3dd1d29d02d

Comment 6

[John Schanck [:jschanck]]

A contact there told me that it might be that the site has blocked our UA in their cloudflare settings. So we should reach out to the site operator as well.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

Chrome Mask trivially gets me past the block, so this seems to just be UA-sniffing.

Note, I tested the site a bit more in bug 1992518 and found that I need more thorough UA-spoofing than what Chrome Mask does, in order to actually use the site. (In particular: when you go to launch a chat, the site tries to make connections to wss://ws.omegleapp.me ; and those connections use your default UA string [and get blocked as a result] even if Chrome Mask is activated for https://omegleapp.me .)

With a more thorough UA-spoofing addon like https://addons.mozilla.org/en-US/firefox/addon/user-agent-string-switcher/ , though, I'm able to connect to chats (text chats at least, that's all I've tried; and an audio chat where I didn't actually try speaking or hear the other user attempt to speak). I had some trouble getting it working on my first attempt, as documented on bug 1992518, but then it worked just fine when I tested again in a fresh profile.

So I think the site does seem to work if we can bypass (or get the site to lift) their UA-string-block.

Comment 8

[Daniel Holbert [:dholbert]]

The omegleapp.me website has a contact email-address at the bottom ([e-mail]) -- I sent an email just now to notify them about the issue & see if they can either lift the block or let us know of any reason for it.

Comment 9

[Daniel Holbert [:dholbert]]

This has gotten a bit better.

Firstly, if I have Mozilla VPN activated, then I get "You've been blocked" in all browsers (so, any blockage on VPN is not a Firefox-specific problem; the site must not want VPN/datacenter users). So, the rest of this comment is describing my experience with no VPN activated.

Loading the site in Firefox Release and Firefox Nightly now, I get a single Cloudflare "click the box" captcha that I'm able to click through to reach the real Omegle.me site. Whereas Chrome goes directly to the site with no captcha.

And the curl commands from comment 4 show the same difference; they return captcha-page-HTML for Firefox (with <title>Just a moment...</title> near the start) vs. the actual Omegle HTML for Chrome (with <title>OmegleMe: A Modern and Safe Omegle Alternative App </title> near the start)

So: the behavior-difference now seems to just be that Firefox users are shown a captcha.

Comment 10

[Daniel Holbert [:dholbert]]

(Also, I never heard back from my outreach in comment 8, but maybe it did some good and resulted in the less-bad situation described in comment 9?)

In any case, I'm adjusting this to "minor annoyance" to capture the remaining behavior-difference here, which is that Firefox users get a cloudflare-captcha-checkbox on first load (via UA sniffing, it seems).

Comment 11

[Thomas Wisniewski [:twisniewski]]

Thanks Dan. It doesn't seem like a sitepatch is the way to go here.