Wow, this is evil. The cursor decodes to an offset pointer. Should this not be reset when you leave the content area?

Deleted: download.jpeg 239 bytes

	download.jpeg 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?

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 https://developer.mozilla.org/en-US/docs/Web/CSS/cursor 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 https://www.w3.org/TR/css-ui-3/#propdef-cursor 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/cursor_utils.cc'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.

I think it makes sense to land some initial metrics tracking cursor sizes. I'll see if I can take an initial look.

Sounds good. We should also look to see what other browsers allow for cursor sizes.

From the spec [1]:
The concrete object size is determined using the default sizing algorithm. If an operating system is incapable of rendering a cursor above a given size, cursors larger than that size must be shrunk to within the OS-supported size bounds, while maintaining the cursor image’s intrinsic ratio, if any.

[1]: https://drafts.csswg.org/css-ui-3/#cursor

Yeah. Other browsers seem to allow for huge custom cursors too.

I think Safari's limit is 128x128. BTW I made a quick test site:
http://cr.kungfoo.net/style/cursor/abusive-cursor.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/270b976afc30f4aa7498a82f34ad8c08212f49f3

commit 270b976afc30f4aa7498a82f34ad8c08212f49f3
Author: Charlie Harrison <csharrison@chromium.org>
Date: Wed Oct 10 22:19:30 2018

Add UseCounter for cursor size

Large cursors with transparency are being used to trick users on
abusive sites (see bug for more details). This CL adds use counters
to track how often large (> 32x32) and small (<= 32x32) custom images
are used on the web.

Bug: 880863
Change-Id: I631e308f08cd8a14d74fa9d9b6f08821e2839d03
Reviewed-on: https://chromium-review.googlesource.com/c/1272097
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#598541}
[modify] https://crrev.com/270b976afc30f4aa7498a82f34ad8c08212f49f3/third_party/blink/public/platform/web_feature.mojom
[modify] https://crrev.com/270b976afc30f4aa7498a82f34ad8c08212f49f3/third_party/blink/renderer/core/frame/local_frame_view.cc
[modify] https://crrev.com/270b976afc30f4aa7498a82f34ad8c08212f49f3/tools/metrics/histograms/enums.xml

Tried verifying the fix on latest chrome #71.0.3577.0 using Windows 10 by following steps as per comment#0. The fix of the issue is not seen consistently, below are the observations noted while trying to verify the fix.

Observations:
===========
1.Sometimes when the file is opened (reference: browlock_custom_cursor.html  in comment#0) it makes whole browser inactive, where no button works.
2.In case if the browser is active after opening the file, on clicking "ok" button and tried to close the tab then observed that it does not close the tab rather it focuses the text in the browser page.
3.On clicking the close tab button the tab gets closed after multiple trials.

Attached screencast for reference.
@Charlie Harrison: Could you please verify the attached screencast and let us know if anything is missed so that it would be really helpful in verification of fix.
Thanks.!

Deleted: 880863(M-70).mp4 3.0 MB

	880863(M-70).mp4 3.0 MB View Download

swarnasree.mukkala@, this issue is not fixed. The CL in c#15 just adds metrics so we can evaluate whether a fix can be landed without breaking web compatibility.

I'll be sure to mark the issue as fixed when the final CL goes through, there will likely be a few more though.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6072eb20a5d5007d5cc0a9ca316f7b23b95c660f

commit 6072eb20a5d5007d5cc0a9ca316f7b23b95c660f
Author: Charlie Harrison <csharrison@chromium.org>
Date: Fri Oct 12 19:01:02 2018

Add custom cursor image size to UseCounter ukm whitelist

This API is being used for abuse.

Bug: 880863
Change-Id: I122e23f589d62eecc01a4418db3573c53779de7f
Reviewed-on: https://chromium-review.googlesource.com/c/1275165
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599314}
[modify] https://crrev.com/6072eb20a5d5007d5cc0a9ca316f7b23b95c660f/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc

Requesting a merge of https://chromium-review.googlesource.com/c/1275165 to M71 (see comment #18). This was a one-liner change which will allow for metrics collection.

Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c4d3d2abaf6ff083374c98fdafbb90a8da8743f5

commit c4d3d2abaf6ff083374c98fdafbb90a8da8743f5
Author: Charlie Harrison <csharrison@chromium.org>
Date: Tue Oct 16 14:31:19 2018

Add custom cursor image size to UseCounter ukm whitelist

This API is being used for abuse.

TBR=bmcquade@chromium.org

Bug: 880863
Change-Id: I122e23f589d62eecc01a4418db3573c53779de7f
Reviewed-on: https://chromium-review.googlesource.com/c/1275165
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599314}(cherry picked from commit 6072eb20a5d5007d5cc0a9ca316f7b23b95c660f)
Reviewed-on: https://chromium-review.googlesource.com/c/1283389
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#36}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/c4d3d2abaf6ff083374c98fdafbb90a8da8743f5/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc

Able to reproduce the issue on chrome reported version# 69.0.3497.81 using Windows-10, tried verifying the fix on latest Dev# 71.0.3578.10 using Windows 10 with steps mentioned below:

Observations:
===========
1. Launched chrome reported version, dragged and dropped the '.html' file provided in comment# 0
2. clicked on 'OK' dialog button that says 'Your Computer is permanently blocked' and observations are as follows
Observations:
=> Sometimes on clicking 'OK' on the popup, doesn't close the popup but we are able to close the particular tab(attached screencast for reference)
=> In some situations, on clicking 'OK' on the popup, closed the popup but unable to close the tab we are currently working on.  

@Charlie Harrison: Please verify the attached screencast for your reference and let us know if this issue is fixed or nor? (or) is there any other pending CL's for this issue?
Thanks.!

Deleted: 880863.mp4 2.3 MB

	880863.mp4 2.3 MB View Download

viswa.karala: This issue is not fixed, and there is still a lot of pending work. As I mentioned in c15, I will be sure to mark the issue as fixed if I fix it.

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/c4d3d2abaf6ff083374c98fdafbb90a8da8743f5

Commit: c4d3d2abaf6ff083374c98fdafbb90a8da8743f5
Author: csharrison@chromium.org
Commiter: csharrison@chromium.org
Date: 2018-10-16 14:31:19 +0000 UTC

Add custom cursor image size to UseCounter ukm whitelist

This API is being used for abuse.

TBR=bmcquade@chromium.org

Bug: 880863
Change-Id: I122e23f589d62eecc01a4418db3573c53779de7f
Reviewed-on: https://chromium-review.googlesource.com/c/1275165
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599314}(cherry picked from commit 6072eb20a5d5007d5cc0a9ca316f7b23b95c660f)
Reviewed-on: https://chromium-review.googlesource.com/c/1283389
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#36}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

I'd just like to point out that this wider security implications than just browlocking users.
By observing the mouse position and various user browser metrics (such as screen resolution and OS), address bar content can be predicated and replaced.
This can be leveraged for more elaborate scams.

Consider this quick-and-dirty PoC (not optimized for all screen sizes):
http://storage.googleapis.com/cdn.guard.io/tmp/poc.html

Quick update: I was hopeful we could just deprecate images larger than 32x32, but they seem to be used quite a bit (~.05% of page visits). One common use-case is large magnifying glass style UIs on e-commerce sites. 

I am landing more metrics to measure larger images > 64x64, which hopefully are an order of magnitude more rare.

It also seems like Chrome does not respect the spec wrt larger cursor images. We don't scale them down. Changing this behavior could help the deprecation process.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c3b223bb6f5bfbdef557c70fb9c44e025bd0378

commit 2c3b223bb6f5bfbdef557c70fb9c44e025bd0378
Author: Charlie Harrison <csharrison@chromium.org>
Date: Wed Nov 07 18:25:36 2018

Add one more cursor size to UseCounter / UKM

Bug: 880863
Change-Id: I90983adf6d7ebd3ead1652c85b7c65a04b142a99
Reviewed-on: https://chromium-review.googlesource.com/c/1313510
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606079}
[modify] https://crrev.com/2c3b223bb6f5bfbdef557c70fb9c44e025bd0378/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc
[modify] https://crrev.com/2c3b223bb6f5bfbdef557c70fb9c44e025bd0378/third_party/blink/public/platform/web_feature.mojom
[modify] https://crrev.com/2c3b223bb6f5bfbdef557c70fb9c44e025bd0378/third_party/blink/renderer/core/frame/local_frame_view.cc
[modify] https://crrev.com/2c3b223bb6f5bfbdef557c70fb9c44e025bd0378/tools/metrics/histograms/enums.xml

Issue 905305 has been merged into this issue.

Issue 917850 has been merged into this issue.

I wonder how bad the UX would be if we allowed custom cursors only when the entire cursor is contained in the content area, and fell back to a default cursor as soon as any portion of the cursor left it? I suppose that could be pretty jarring. 

A better UX would be to clip custom cursors to the content area, but unfortunately I don't think there's any reasonable way to implement that without sacrificing cursor performance.

> I wonder how bad the UX would be if we allowed custom cursors only when the entire cursor is contained in the content area, and fell back to a default cursor as soon as any portion of the cursor left it? I suppose that could be pretty jarring. 

FWIW the Firefox bug for this very same issue is https://bugzilla.mozilla.org/show_bug.cgi?id=1445844.

Thanks emilio, what do you think about the proposed approach of restricting size to 64x64 as a first pass? I am hopeful the breakage will be small while making this attack much less viable.

The two approaches listed in #32 seem to align with your thinking on the bug, but both have drawbacks of their own.

I think that makes sense, off-hand, if breakage is not big.

I've seen a bunch of pages with big-ish cursors specially for zoom icons and such, but not sure they'd be bigger than that. It's great that you have telemetry on this now (was my next thing to do when I got a chance to look at that bug).

Let me know if your data indicates that it's safe enough to do that, and I'd be happy to coordinate and land the same change in Firefox or what not.

Our usage data for this is public and can be found here:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2620

Caveat: this is only measuring our beta channel so far (M72).

As noted on the intent to deprecate, I think the biggest compat risk is  feature rich games and content creation tools (e.g. photoshop style programs):
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/e0bzxOfL-2I

There will certainly be a trade-off, but I hope the breakage will not be too big.

Asynchronous clipping, with and without extra 300ms jank added on the main thread.

avi: WDYT about an approach like this for large custom cursors?

Deleted: cursor-no-jank.webm 1.3 MB

	cursor-no-jank.webm 1.3 MB View Download

Deleted: cursor-with-jank.webm 354 KB

	cursor-with-jank.webm 354 KB View Download

Looks pretty slick. I think such an approach would be solid if we can make it work.

Yeah, this technique basically swaps out the underlying cursor image every mousemove update if it intersects with the visual viewport. This only incurs performance implications in the "large + overlapping" case, which should be rare.

A really really evil site could have extremely long jank and effectively browserlock until we detect the site as "hung" though. 

Update: chatted with Avi and I think we agree the following plan would be good:

1. For cursors > 32x32, implement async clipping to the visual viewport
2. Keep the max size restriction to 128x128
3. If abuse is successful (e.g. via the scenario in #39), ratchet down the max size as a v2. Note that browserlock via janking the browser IO / UI threads is already a viable attack in Chrome. 

emilio: Any thoughts from the FF POV?

In terms of compat risk, I'm seeing ~.05% of page visits using cursors >32x32. UKM shows that these are ecommerce / games / children sites. None of the ~10 top sites I visited would have meaningful breakage via clipping that I could tell.