Intent to Ship: Feature Policy 'focus-without-user-activation'

[EhsanK]

Intent to Ship: Feature Policy: focus-without-user-activation

Contact emails

ekar...@chromium.org,  icle...@chromium.org, mus...@chromium.org   

Explainer

PR for public explainer

Design doc/Spec

PR against whatwg/html.

Summary

A feature policy to restrict the use of programmatic focus, when not triggered by user activation.

Motivation

Programmatic focus is a potential security problem for users; it can be potentially abused to hijack user input into third-party content. There seems to be little to no justification on use of such features from third party content; let alone cases where the embedded content has not received a user gesture yet. The proposed policy provides a way to control access to focus API without user activation. The immediate use case would be restricting all sandboxed frames. Focus API, in this context refers to focus management API and autofocus.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: Public support.

Ergonomics

This feature is set either in HTTP headers or in the allow attribute of an <iframe> to control access to focus API. Limiting the focus API should not have a negative effect on performance.

Activation

The expectation is to disable this feature policy in all sandbox frames, by default. To enable the feature, or disable for a non-sandbox frame, the feature can be set in the allow attribute of <iframe> or set in the HTTP response headers for the whole document and nested contents.

Debuggability

The Reporting API can be used in conjunction with this feature to collect data on failures in a document. Additionally, console warnings will be produced when programmatic focus is blocked by policy. No changes to DevTools are required.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

This feature is backed by a tentative WPT.

Link to entry on the feature dashboard

Link

Requesting approval to ship?

Yes.

[con...@superhuman.com]

Hey Ehsank,

The bug linked on the feature dashboard is private (at least I see "permission denied" when I go here: https://bugs.chromium.org/p/chromium/issues/detail?id=954349).

Can you please make it public so that I can subscribe to changes — I'm in favour of the change, but use sandboxed iframes a lot and would like plenty of advance notice before these changes land so I can verify that our code keeps working!.

Conrad

[ekar...@google.com]

Thanks Conrad!

I am working removing the "restriction" on the bug. I will keep this thread posted (for when that happens).

Ehsan

[Mustaq Ahmed]

conrad@: Also note that the CLs (behind a flag changes) are still public, you search for them in chromium-review.googlesource.com with "bug:#".  To test the proposed changes, try latest Chrome Canary with the command-line flag:  --enable-features=BlockingFocusWithoutUserActivation

--
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/b0e5a7af-1cdb-4c6b-9bb8-41c6d4c88ce5%40chromium.org.

[ekar...@google.com]

To ensure we can track further progress on an issue publicly, I have created a new bug for this policy. Perhaps Chromium related bugs and issues related to the policy could be posted there?

Ehsan

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Mustaq Ahmed]

Just changed Issue 965495 to type launch bug.

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/ae837dc9-0e15-41da-867c-5648b913b1ec%40chromium.org.

[Conrad Irwin]

https://bugs.chromium.org/p/chromium/issues/detail?id=965495 is also private? I cannot subscribe to that either

Conrad

On Tue, May 21, 2019 at 12:31 PM, Mustaq Ahmed <mus...@google.com> wrote:

Just changed Issue 965495 to type launch bug.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ae837dc9-0e15-41da-867c-5648b913b1ec%40chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/pnUiTrLHHmw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5WyAYX-F%2BU3ernCXtntMvsviB4NapYJjGj_2ifKYWCuQ%40mail.gmail.com.

[Mustaq Ahmed]

Sorry Conrad, we needed to switch it to type=launch for internal reviews!  But in any case, commits are public, and you can track commits for a specific bug through a link like https://chromium-review.googlesource.com/q/bug:954349.

On Tue, May 21, 2019 at 5:15 PM Conrad Irwin <con...@superhuman.com> wrote:

https://bugs.chromium.org/p/chromium/issues/detail?id=965495 is also private? I cannot subscribe to that either

Conrad

On Tue, May 21, 2019 at 12:31 PM, Mustaq Ahmed <mus...@google.com> wrote:

Just changed Issue 965495 to type launch bug.

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/ae837dc9-0e15-41da-867c-5648b913b1ec%40chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/pnUiTrLHHmw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

[Mustaq Ahmed]

Conrad:  I switched crbug.com/965495 back to public mode; you should be able to access it now.

New launch bug: crbug.com/966021

[Daniel Bratell]

This sounds like a good thing, though it's all the details...

Details:

* The Intent to ship is missing the TAG review (or explanation why it's suitable to bypass TAG).

* The Chrome Platform Status still links to a hidden bug. It should be public, so I assume you should use the bug you're talking about with Conrad.

* There seems to still be some discussions about the exact form this feature should take. Everyone seems to think it's the right idea to add gating of focus requests, but it doesn't look like everyone is yet convinced this is the way to do it. Anything you can do here? This needs to happen before TAG looks at it anyway.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO56Rdaw2fHFoWRGQXDKHmt-_XhV8UBTfZe1LRv2jsN-GQ%40mail.gmail.com.

--

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

[Ian Clelland]

Hi Daniel,

For small FP features, we typically haven't gone through TAG review (the FP infrastructure itself has been, and is being reviewed by TAG) -- comparable features like sync-xhr, autoplay and document-domain were shipped through the blink intent process. This feature is similarly a small addition to the web platform.

As far as the exact form, I'm hoping that this is something that we can iterate on as necessary. Given that the desired behaviour is something like:

  -- allow in top-level documents

  -- disallow in sandboxed frames

  -- give developers the ability to disallow in any or all third-party frames

this appears to fit the existing feature policy model quite well.

There is a separate discussion ongoing about how to treat different kinds of features within feature policy, and the results of that may affect the eventual form of this feature, as well as other already-shipped features. We don't want to block shipping this control on that discussion, though.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z17cisnurbppqq%40cicero2.linkoping.osa.

[Alex Russell]

Hey Ian,

Thanks for the context!

I'll leave it to Alice to determine if she thinks the TAG should have a look at this one. Feature Policies might be a place where we could come up with some sort of blanket approach, but I know there's been some feedback (e.g. from Andrew Betts) regarding the syntax and framing of some of the options and I'd like to make sure those conversations get aired in a place where we'll get broad review. Given the lack of signals from other vendors, do you have a proposal about how we might get that review in lieu of the TAG?

Regards

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ae837dc9-0e15-41da-867c-5648b913b1ec%40chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/pnUiTrLHHmw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5WyAYX-F%2BU3ernCXtntMvsviB4NapYJjGj_2ifKYWCuQ%40mail.gmail.com.

--
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 blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO56Rdaw2fHFoWRGQXDKHmt-_XhV8UBTfZe1LRv2jsN-GQ%40mail.gmail.com.

--

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

--
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 blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z17cisnurbppqq%40cicero2.linkoping.osa.

[Philip Jägenstedt]

Hey all,

The explainer is merged now which makes for easier reading. It matches https://github.com/whatwg/html/pull/4585 in that it doesn't affect default behavior and is just adding a policy to make it possible to disable. It looks like the implementation does the same, which is good!

However, from various comments on web compat and "The expectation is to disable this feature policy in all sandbox frames, by default" in this thread it sounded like the idea was to change the default. Can you clarify if there is an intention to change the default down the line?

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/82db4bcf-fc5e-439c-ad76-ed8ddfaf9c51%40chromium.org.

[Alice Boxhall]

I'll echo Alex's comments about lack of signals from other vendors. Has this been discussed with anyone from another browser, other than on the spec PR?

In terms of a TAG review, that would probably be the first question as well. 

That would probably followed by questions about the user impact - it seems likely to be positive, but it would be nice if e.g. the first example in the original feature request https://github.com/w3c/webappsec-feature-policy/issues/273 was included in the explainer, rather than generic language about stealing focus.

In terms of the feature-policy evolution, I see @Ian Clelland is already heavily involved there (https://github.com/w3ctag/design-reviews/issues/341 and https://github.com/w3c/webappsec-feature-policy/issues/282) 

As to whether or not to raise a new TAG review for this - I think a broader review would be good, but I think you'd be better off getting signals from other browser vendors before bringing it to the TAG.