Intent to Implement and Ship: Discard input events targeting recently-moved iframes

[Stefan Zager]

Contact emails

sza...@chromium.org

Summary

This is reviving and updating a previous proposal from 2016.

Unscrupulous web sites can trick users into inadvertently clicking or tapping on a page element via visual bait and switch tactics, as hilariously illustrated by this video. This intervention proposes to quietly discard input events that target cross-origin iframes that have recently resized or moved a non-trivial distance within the embedding page's viewport. In the case of nested iframes, input events will be discarded if any iframe in the frame tree fails the "moved recently" test.

This was broadly considered to be a good idea in 2016, but it has new urgency since IntersectionObserver V2 (IOv2) has shipped. IOv2, in combination with this intervention, provide a powerful tool for combatting a variety of UI redress attacks (e.g., click-jacking).

For the purpose of this intervention, "recently" means "within the last 500 milliseconds", and "non-trivial distance" means "manhattan distance of at least 10 screen pixels." Those numbers were chosen semi-arbitrarily, and will likely need tuning.

Initially, this intervention will only affect iframes that are making active use of IOv2 features. Because IOv2 is very new, and narrowly focused on security-sensitive applications, this will limit any unintended consequences for existing content. If the intervention turns out to be successful and beneficial, we may later consider expanding its scope to all cross-origin iframes.

Ongoing technical constraints

The chromium implementation relies on hit testing in Viz, which is fairly new but appears to be stable.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=603193

Work-in-progress implementation

https://chromium-review.googlesource.com/c/chromium/src/+/1644504

[Daniel Bratell]

It seems like a really good idea to not process clicks that ended up at something the user didn't intend to click. In broad terms, this seems like a reasonable approach.

I do question some of the constants you listed. 500 ms is a long time and it would be easy to scroll down to some static iframe content and click it within that time frame. The listed document talks about 200 ms which is also long but not quite so long. Would there be some kind of research on where the limit between unintended and intended content click lies?

There will be false positive. I can imagine a game where you click flying birds implemented as svg images in iframes. Such an application would break, but if it would be possible to fix without negative side effects it would have been taken care of decades ago so again, need to find the right balance (and here I assume the feature will eventually cover all input events).

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J87kD9OdWw%2Bq4C6wMgwBz7v0jXGSWqw3%3DyKfRKRrSTGFA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Stefan Zager]

On Fri, Jun 14, 2019 at 1:06 AM Daniel Bratell <bra...@opera.com> wrote:

I do question some of the constants you listed. 500 ms is a long time and it would be easy to scroll down to some static iframe content and click it within that time frame. The listed document talks about 200 ms which is also long but not quite so long. Would there be some kind of research on where the limit between unintended and intended content click lies?

There will be false positive. I can imagine a game where you click flying birds implemented as svg images in iframes. Such an application would break, but if it would be possible to fix without negative side effects it would have been taken care of decades ago so again, need to find the right balance (and here I assume the feature will eventually cover all input events).

I agree that 500ms might be too long (and 10px might be too small), we will probably need to tune those numbers based on feedback. Because the initial intervention is so limited; and because it focuses on security-sensitive situations; those numbers are intended to err on the side of minimizing the number of false positives (i.e., permitting "bad" clicks), at the expense of producing some false negatives (discarding "good" clicks).

[Johnny Stenback]

I agree this is a good thing to do, but setting a limit strictly in pixels seems less than ideal. IMO we ought to at least take device pixel ratio into account, and define this more along the lines of a physical distance, or percentage of screen size, or something along those lines.

Cheers,

Johnny

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-H5jo9M6SBu-mBjLyMTewgi4WMOuLhRN3-ESwbE2saMQ%40mail.gmail.com.

[Joe Medley]

Stefan,

Can you please create a status entry for this. Yes, we do status entries for interventions.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZRgz6LxG_%2Bh1St5nWLGqFka_HcBk%3DYfX7TDh-0wc829YhdHA%40mail.gmail.com.

[bratell]

This was discussed at the weekly API owners meeting (Alex, Chris, Daniel, Yoav) and we determined that this does not require blink api owner shipping approval.

We do strongly recommend that the change includes a use counter to determine how much the intervention trigger, and also that the change includes some kind of "kill switch" since it's not without risk.

(As agreed earlier in the thread, there should also be a chrome status entry, and the exact values should be tuned before shipping)

Good luck, may those evil buttons never trigger.

/Daniel

[Stefan Zager]

On Thu, Jun 20, 2019 at 8:50 AM Joe Medley <jme...@google.com> wrote:

Stefan,

Can you please create a status entry for this. Yes, we do status entries for interventions.

Done: https://www.chromestatus.com/feature/5406180975312896

[Sahel Sharifymoghaddam]

This might negatively affect cases that user decides to interrupt an ongoing fling by tap, or to boost it when the tap lands on a unscrollable iframe.

ccing nzolghadr@ from input-dev to investigate/verify.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J_%3DVuyCjb57xftansXwsXb%3DhNK54F1NO4kOCnAUqVx3LA%40mail.gmail.com.

[Stefan Zager]

On Thu, Jun 20, 2019, 3:57 PM Sahel Sharifymoghaddam <sa...@google.com> wrote:

This might negatively affect cases that user decides to interrupt an ongoing fling by tap, or to boost it when the tap lands on a unscrollable iframe.

ccing nzolghadr@ from input-dev to investigate/verify.

I'm sorry, I don't quite understand what you mean. If the user stops a fling with a tap, we would prefer that the tap does not send click or touch events to a cross origin iframe. That's a feature, not a bug.

I'm not sure what you mean by "boost". Is there some circumstance where you think this intervention will result in *more* events being sent to an iframe?

[Sahel Sharifymoghaddam]

I already talked to Navid about this and he explained that the event filtering/discarding happens in pointereventmanager/eventhandler, etc rather than earlier in the pipeline. So the gesture scroll/fling sequence sent to the renderer(s) won't be impacted.

[Joe Medley]

Thanks.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.