Intent to Ship: delegateStickyUserActivation

[Becca Hughes]

Contact emails

becca...@chromium.org, mlam...@chromium.org, dah...@chromium.org

Explainer

https://github.com/WICG/gesture-delegation/blob/master/explainer.md

Spec

https://github.com/WICG/gesture-delegation

Tag review: https://github.com/w3ctag/design-reviews/issues/199

Summary

Add a delegateStickyUserActivation attribute to <iframe> that allows the page to delegate browser context user activation to child frames. It is meant to be used by the Vibration API and the new autoplay policy, both currently require a browser context user activation.

Intent to Implement

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/e7I1tZAfavU/wjgW9s0EBAAJ

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

Yes.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive

This is a new attribute so if it is not implemented by other browsers or partially implemented, for example if they do not support all the possible values it will be ignored. Therefore the compatibility risk is low for developers who wish to add this to their site.

Only Firefox implements the Vibration API and they do not support browsing context user activation at the moment. The autoplay policy is Chrome specific at the moment. Therefore the interoperability risk is medium because the feature is based on a concept that is not yet interoperable.

Ergonomics

This is part of Unified Autoplay and will also be used by the Vibration API.

Activation

Developers can easily change the autoplay policy in chrome://flags to take advantage of this. It will be enabled for all users in M65.

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

WPT reflection tests are here.

There are also LayoutTests to test the autoplay effects of this attribute, but they are dependent on internals so they cannot be upstreamed.

Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6025124331388928

[Jochen Eisinger]

Can you clarify whether this can delegate user activation on non-secure contexts?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEJQkHsCv4eXq2A0fuFwyyairoDjLgHg2%2BReiaXqOi1YnA%40mail.gmail.com.

[Becca Hughes]

Yes it will allow delegation on non-secure contexts. The attribute is to prevent user annoyance and with autoplay we don't want to break the website's experience, which could be using non-secure contexts.

For instance a website may have embeds that are important to be autoplayed but are in a non-secure context.

[PhistucK]

Why not just use the feature policy API or similar for this instead of having a separate attribute (following a cross-vendor consensus, obviously)?

allow="autoplay autovibrate"

(If I remember the feature policy API correctly)

☆PhistucK

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/CAFeLsE%2Bg9xaVdC5gY%3D4K_QhvUxZd-Z%2BPGE0Y-A9zV1Fo4veesQ%40mail.gmail.com.

[Becca Hughes]

Feature Policy is about allowing/blocking a feature while this feature is only about allowing an iframe to use the activation that a parent frame received. It doesn't mean the feature would be allowed or blocked instead it's more like a "state" that possibly defines the outcomes of some features.

[Jochen Eisinger]

I'm worried about the following case: assume something injects ads into random sites you visit. Normally, at least they can't vibrate. But since it's all insecure, they can also just inject the activation delegation.

[PhistucK]

I understand the goal of feature policy API itself, though the name does suggest it can encapsulate your goal as well.

Besides, the attribute name ("allow") is generic enough to encapsulate your goal as well, so you can create an extension specification that adds more tokens for your goal.

While I understand this is bikeshedding (sorry), the name you suggest is very long and generally incomprehensible and unintuitive for (at least non-native-English-speaker) developers, in my opinion.

Perhaps if you extended the feature policy API, you will have more signals (even negative ones are signals) from other vendors, as well as have a more reasonable feature story to web developers.

However, I now see that the intent to implement already got this sort of feedback (adding this to the feature policy API), so I guess there is not much more to discuss.

This is a very awkwardly named API...

☆PhistucK

[smaug]

On 10/27/2017 03:36 PM, PhistucK wrote:
> I understand the goal of feature policy API itself, though the name does suggest it can encapsulate your goal as well.
> Besides, the attribute name ("allow") is generic enough to encapsulate your goal as well, so you can create an extension specification that adds more
> tokens for your goal.
>
> While I understand this is bikeshedding (sorry), the name you suggest is very long and generally incomprehensible and unintuitive for (at least
> non-native-English-speaker) developers, in my opinion.
>
> Perhaps if you extended the feature policy API, you will have more signals (even negative ones are signals) from other vendors, as well as have a more
> reasonable feature story to web developers.
>
> However, I now see that the intent to implement already got this sort of feedback (adding this to the feature policy API), so I guess there is not
> much more to discuss.
>
> This is a very awkwardly named API...
>

It is. It does smell a bit like a hack.
Has anyone thought if there are other similar issues in the web platform and whether there could be some more generic API for all those cases?


-Olli

>
> ☆*PhistucK*

>
> On Fri, Oct 27, 2017 at 3:12 PM, Becca Hughes <becca...@chromium.org <mailto:becca...@chromium.org>> wrote:
>
> Feature Policy is about allowing/blocking a feature while this feature is only about allowing an iframe to use the activation that a parent frame
> received. It doesn't mean the feature would be allowed or blocked instead it's more like a "state" that possibly defines the outcomes of some
> features.
>

> On Fri, Oct 27, 2017 at 1:07 PM, PhistucK <phis...@gmail.com <mailto:phis...@gmail.com>> wrote:
>
> Why not just use the feature policy API or similar for this instead of having a separate attribute (following a cross-vendor consensus,
> obviously)?
> allow="autoplay autovibrate"
> (If I remember the feature policy API correctly)
>
>

> ☆*PhistucK*

>
> On Fri, Oct 27, 2017 at 3:01 PM, Becca Hughes <becca...@chromium.org <mailto:becca...@chromium.org>> wrote:
>
> Yes it will allow delegation on non-secure contexts. The attribute is to prevent user annoyance and with autoplay we don't want to break
> the website's experience, which could be using non-secure contexts.
>
> For instance a website may have embeds that are important to be autoplayed but are in a non-secure context.
>

> On Fri, Oct 27, 2017 at 12:44 PM, Jochen Eisinger <joc...@chromium.org <mailto:joc...@chromium.org>> wrote:
>
> Can you clarify whether this can delegate user activation on non-secure contexts?
>

> On Fri, Oct 27, 2017 at 12:39 PM Becca Hughes <becca...@chromium.org <mailto:becca...@chromium.org>> wrote:
>
> Contact emails
>
> becca...@chromium.org <mailto:becca...@chromium.org>, mlam...@chromium.org <mailto:mlam...@chromium.org>,
> dah...@chromium.org <mailto:dah...@chromium.org>
>
>
> Explainer
>
> https://github.com/WICG/gesture-delegation/blob/master/explainer.md
> <https://github.com/WICG/gesture-delegation/blob/master/explainer.md>
>
>
> Spec
>
> https://github.com/WICG/gesture-delegation <https://github.com/WICG/gesture-delegation>
>
> Tag review: https://github.com/w3ctag/design-reviews/issues/199 <https://github.com/w3ctag/design-reviews/issues/199>

>
>
> Summary
>
> Add a delegateStickyUserActivation attribute to <iframe> that allows the page to delegate browser context user activation to child
> frames. It is meant to be used by the Vibration API and the new autoplay policy, both currently require a browser context user
> activation.
>
>
> Intent to Implement
>
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/e7I1tZAfavU/wjgW9s0EBAAJ
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/e7I1tZAfavU/wjgW9s0EBAAJ>
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
>
> Risks
>
> Interoperability and Compatibility
>
>
> Edge: No signals
>
> Firefox: No signals
>
> Safari: No signals
>
> Web developers: Positive
>
>
> This is a new attribute so if it is not implemented by other browsers or partially implemented, for example if they do not support
> all the possible values it will be ignored. Therefore the compatibility risk is low for developers who wish to add this to their site.
>
>
> Only Firefox implements the Vibration API and they do not support browsing context user activation at the moment. The autoplay
> policy is Chrome specific at the moment. Therefore the interoperability risk is medium because the feature is based on a concept
> that is not yet interoperable.
>
>
> Ergonomics
>
>

> This is part ofUnified Autoplay <http://blog.chromium.org/2017/09/unified-autoplay.html>and will also be used by the Vibration API
> <https://developer.mozilla.org/en-US/docs/Web/API/Vibration_API>.

>
>
> Activation
>
> Developers can easily change the autoplay policy in chrome://flags to take advantage of this. It will be enabled for all users in M65.
>
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> WPT reflection tests are here <https://github.com/w3c/web-platform-tests/pull/7964>.
>
>
> There are also LayoutTests <https://chromium-review.googlesource.com/c/chromium/src/+/672883>to test the autoplay effects of this

> attribute, but they are dependent on internals so they cannot be upstreamed.
>
>
> Link to entry on the Chrome Platform Statushttps://www.chromestatus.com/features/6025124331388928
> <https://www.chromestatus.com/features/6025124331388928>
>
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEJQkHsCv4eXq2A0fuFwyyairoDjLgHg2%2BReiaXqOi1YnA%40mail.gmail.com

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEJQkHsCv4eXq2A0fuFwyyairoDjLgHg2%2BReiaXqOi1YnA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsE%2Bg9xaVdC5gY%3D4K_QhvUxZd-Z%2BPGE0Y-A9zV1Fo4veesQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsE%2Bg9xaVdC5gY%3D4K_QhvUxZd-Z%2BPGE0Y-A9zV1Fo4veesQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_L3b4qg4mqhQ_OMDmpGsnTTmrOqAzFkQjCoqRSxPGFZCA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_L3b4qg4mqhQ_OMDmpGsnTTmrOqAzFkQjCoqRSxPGFZCA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Mounir Lamouri]

On Fri, 27 Oct 2017, at 13:13, Jochen Eisinger wrote:
> I'm worried about the following case: assume something injects ads into
> random sites you visit. Normally, at least they can't vibrate. But since
> it's all insecure, they can also just inject the activation delegation.

If something injects an ad into random sites you visit, how couldn't
they also inject script that could vibrate? How could they not redirect
user gestures to the iframe using postMessage()?

On Fri, 27 Oct 2017, at 13:54, smaug wrote:
> > This is a very awkwardly named API...
>
> It is. It does smell a bit like a hack.
> Has anyone thought if there are other similar issues in the web platform
> and whether there could be some more generic API for all those cases?

The name was discussed with Domenic and Anne in a GitHub issue. It's not
particularly nice but they wanted something clear and explicit. Anyone
is welcome to propose name by opening a GitHub issue.

FWIW, this API is a generic API that addresses two use cases to limit
user annoyance: only allow some features on a frame if the frame was
interacted with but still allow top frames to drop the requirement. What
other use cases would you like to be addressed here?

-- Mounir

[smaug]

The more I think this, the more I see sandbox="", various allow* attributes and this new proposal to deal
with rather similar issues, basically changing the privileges the iframe has.
Could we come up with some unified API for all that rather than adding new small APIs one by one?


-Olli

[Ian Clelland]

On Fri, Oct 27, 2017 at 6:01 PM smaug <sm...@welho.com> wrote:

On 10/27/2017 04:14 PM, Mounir Lamouri wrote:
> On Fri, 27 Oct 2017, at 13:13, Jochen Eisinger wrote:
>> I'm worried about the following case: assume something injects ads into
>> random sites you visit. Normally, at least they can't vibrate. But since
>> it's all insecure, they can also just inject the activation delegation.
>
> If something injects an ad into random sites you visit, how couldn't
> they also inject script that could vibrate? How could they not redirect
> user gestures to the iframe using postMessage()?

They certainly could -- there's not much the platform can do to restrict what colluding sites can do. (Vibrate is also an especially bad example for this, because a vibration triggered from an iframe has exactly the same real-world effect as a vibration triggered from the main frame. Autoplay might be a better strawman to lean against, since in that case the frame with the video content *has* to be the one that can trigger autoplay, for it to have an effect. A postMessage from the frame to its parent isn't sufficient.)

 

> On Fri, 27 Oct 2017, at 13:54, smaug wrote:
>>> This is a very awkwardly named API...
>>
>> It is. It does smell a bit like a hack.
>> Has anyone thought if there are other similar issues in the web platform
>> and whether there could be some more generic API for all those cases?
>
> The name was discussed with Domenic and Anne in a GitHub issue. It's not
> particularly nice but they wanted something clear and explicit. Anyone
> is welcome to propose name by opening a GitHub issue.
>
> FWIW, this API is a generic API that addresses two use cases to limit
> user annoyance: only allow some features on a frame if the frame was
> interacted with but still allow top frames to drop the requirement. What
> other use cases would you like to be addressed here?
>
> -- Mounir
>

The more I think this, the more I see sandbox="", various allow* attributes and this new proposal to deal
with rather similar issues, basically changing the privileges the iframe has.
Could we come up with some unified API for all that rather than adding new small APIs one by one?

+1 to merging some (or all) of these -- I had started an intent to express sandbox features in terms of feature policy, as a first step. I'll refresh that and post it for discussion (on a new thread)

As far as this attribute goes, I see this as being orthogonal to the question of "what features are allowed/blocked" -- autoplaying video may be allowed in a child frame with or without this attribute, without it, the user just has to activate the child frame explicitly. This attribute expresses the idea that the child frame is sufficiently "part of" the parent such that if the parent is activated, so is the child.

I had written a doc a while ago that motivated some of this idea; it didn't get much coverage at the time, but you can take a look here[1]

[1] https://docs.google.com/document/d/11gqqQhHcVNhYRclVGL6h7prt_n9rjbYstvCWgZu-E7M

-Olli

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68a1d118-b00a-d6b4-070e-92125bfb2a67%40welho.com.

[Philip Jägenstedt]

This thread has been sitting inactive for a while now, TPAC last week not helping.

Ian, from your replies here and on the intent to implement, I gather that you don't think this makes sense as part of Feature Policy, iframe sandbox, or any other existing mechanism, is that right?

FWIW, the proposed model makes sense to me, we have some parts of the web platform that have, essentially, "touch/click anywhere first" as the user annoyance mitigation, and propagating this bit of state into iframes makes sense.

I see that there are now two issues filed by Maciej (WebKit):

https://github.com/WICG/gesture-delegation/issues/12

https://github.com/WICG/gesture-delegation/issues/13

There's some discussion with unclear outcome here:

https://github.com/w3ctag/design-reviews/issues/199

https://github.com/w3ctag/design-reviews/issues/203

Becca, do you think that this intent should be blocked on resolving those issues? To ship something is to effectively to resolve them one way or the other, so doing it explicitly would be nice. To be clear, complete consensus isn't required, it happens that issues come to an impasse and we still decide to ship something.

Across all the threads and issues I see folks from all of EdgeHTML, Gecko and WebKit, so that's good.

[Ian Clelland]

Yes, I do think this is orthogonal to the concerns of FP, sandbox, et al. The closest thing on the web platform that I can think of would be <iframe seamless>, but that has been deprecated, as far as I can tell. (And that isn't as fine-grained as this propsal in any case).

[Becca Hughes]

For autoplay, I think we are going to go down the road of adding this to feature policy instead. Apple wants to implement it too so the current plan is to add an "autoplay" feature that will be specific to controlling autoplay.

We have opened a PR to add this to the feature policy spec.

--

•  Becca Hughes   •  Software Engineer   •  Google Inc.   •  becca...@google.com

This email may be confidential and privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

[Philip Jägenstedt]

I see that https://github.com/WICG/feature-policy/pull/93 is merged now, is there anything else blocking this? (No hurry, just wary of things sitting around blocked on API owners without it being obvious.)

[Becca Hughes]

No, we are going to abandon this in favor of feature policy.

[moss.m...@gmail.com]

Does the intent to use a feature policy completely invalidate the iframe/DOM-related API that was described when the Autoplay Policy changes were announced here: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#iframe ? Is there going to be any way for a web application to programmatically allow autoplay in an iframe serving a page with media from the same shared domain?