[css-ui] Should mention the posibility to ignore custom cursors that go outside of the viewport

[emilio]

Both Firefox and Blink are switching to limit custom cursors bigger than a particular size which intersect UI:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1445844
• https://bugs.chromium.org/p/chromium/issues/detail?id=880863

It was suggested in the dev-platform@ intent to ship thread that maybe adding some kind of text to the spec for this case could be worth it.

[frivoal]

Right. Given that this limitation is not rooted in picking some arbitrary limit for implementation convenience, but rather finding it desirable that cursors larger than a certain size get ignored (in some cases) for security reasons, reflecting that in the spec would seem reasonable to me.

[frivoal]

If I understand correctly, both Firefox and Chrome have now shipped some variant of this, but what you have shipped isn't exactly the same. I'm curious if we learned anything after shipping, which should influence what goes in the spec.

As a reminder, what the spec currently has to say about cursors that are too large is:

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.

Maybe we want to keep this as is and add a "may reject or clip cursors above a certain size, for security reasons", but if nobody does the shrinking, we way want to do away with that.

Agenda+ to raise attention and attempt to get feedback.

[emilio]

What is the "not exactly the same" part, other than the value being configurable in Gecko? IIUC both engines should fall back to the next cursor.

[css-meeting-bot]

The CSS Working Group just discussed Should mention the posibility to ignore custom cursors that go outside of the viewport.

The full IRC log of that discussion

<dael> Topic: Should mention the posibility to ignore custom cursors that go outside of the viewport
<dael> github: https://github.com//issues/3728
<dael> florian: Can spec image as cursor. If image is too large browsers expected to shrink
<dael> florian: Recently Chrome and FF fiured out security concern and they wanted to reject instead of shrink. I know they've tried things, reject or crop. I believe what they do is not what spec says. Maybe need to change spec to allow. Maybe experiment points to a right thing.
<dael> florian: I would like people experimenting to report their findings after doing it for a few months
<dael> emilio: In FF we fallback to next image or to default. We treat as invalid. You can't shrink b/c you can set a hotpoint and then need to shrink that too. I think Chrome did the same
<dael> emilio: I could be wrong on Chrome
<dael> astearns: Anyone know who looked at this on Chrome?
<dael> chrishtr: Need to follow up
<dael> florian: I'd appreciate follow up.
<dael> astearns: Let's see if we can get information on Chrome and continue discussion then
<emilio> whoops :-)

[smfr]

I'm confused. Is this issue about cursor size, or about custom cursors that have hotpoints configured such that they try to confuse the user about where they are clicking?

[emilio]

@smfr the combination of both. Basically, if you have a big cursor that due to the hotspot would go outside of the content viewport.

[smfr]

I think a diagram of the potential attack here would be useful, but I get the idea.

[emilio]

You can basically trick the user so that they think they are pointing to the URL bar but instead they're pointing inside the page.

You can see a (very intentionally obvious) test-case in https://bug1445844.bmoattachments.org/attachment.cgi?id=9030715. You can disable layout.cursor.block.enabled in Firefox's about:config to see the before / after.