New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Sign in to add a comment

Custom cursor prevents user from closing tab in browser locker tech scam

Reported by, Sep 5

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce the problem:
1. Open the attached example in Chrome
2. Click on the 'OK' dialog button that says 'Your Computer is permanently blocked' to gain focus for the current window
3. Try to close the tab or browser window

What is the expected behavior?
The user should be able to access the UI buttons in order to close the offending tab.

What went wrong?
The custom mouse cursor prevents the user from closing the tab. This is particularly worse when browsing in maximized mode.

Did this work before? No 

Chrome version: 69.0.3497.81  Channel: stable
OS Version: 7.0
Flash Version: 

Tech support scammers use this technique to lock users' browsers.

Browlocks are responsible for many tech support scams where victims that panic will call for assistance. Instead of speaking with what they think is Microsoft, they are dealing with scammers that will defraud them of hundreds of dollars.
22.4 KB View Download
Wow, this is evil. The cursor decodes to an offset pointer. Should this not be reset when you leave the content area?
239 bytes View Download
This is amazing. Yes, the cursor returns when the user moves it outside the window, but it's offset so much that the user thinks they're moving it outside the window when they're not.

Should we be clipping transparency around the cursor?
Status: Available (was: Unconfirmed)
Labels: OS-Chrome OS-Linux OS-Mac
We should be clipping transparency, possibly up to a percentage so that abusers don't make their transparency 0.001% opaque and avoiding a fix.

This is all desktop platforms.
As per we should:

1. Clip transparency around the edges (transparency up to a clearly-visible level to avoid people easily getting around this)
2. Adjusting the hotspot values to match the transparency clipping
3. Bounds-checking the hotspot values and clamping them to the size of the image

Note that the hotspot values are, per the spec, "Two unitless nonnegative numbers less than 32". Why are images larger than 32x32 allowed, then?

The spec at specifies no hotspot value maximum.
Here are the specifics:

- third_party/blink/public/platform/web_cursor_info.h has a "external_handle" field on WIN32. Rip that out. It's not used.
- why do we have content/public/common/cursor_info.h and WebCursorInfo? We really should remove one of them
- the fix from comment 5 should live in content/renderer/'s InitializeCursorFromWebCursorInfo
Come to think of it, even if we clip transparent pixels from the edges they'll switch to fully opaque pixels near the edges that blend in with the page. At the limit, we're solving a computer vision problem on the cursor image. We may need to put some upper bounds on a cursor size.

Sign in to add a comment