How vibrate will work with Feature Policy given the user gesture requirement?

[lubin2010]

Given the interventions of gating vibrate with user gesture, the semantics of using Feature Policy for vibrate might change, eg.,

• Giving the permission of vibrate from the top-level page to subframe (something like "allow='vibrate'") may not make sense any more since vibrate is currently allowed after user gesture in cross-origin iframes;
• It might make sense to only disallow vibrate with Feature Policy (something like "disallow='vibrate'");

/cc @ojanvafai @RByers @clelland @raymeskhoury @VicenteDiaz

See the two interventions below for context:

• Require user gesture for navigator.vibrate in cross-origin iframes (shipped)

• Require user activation for navigator.vibrate (ongoing),

[raymeskhoury]

My preference would still be that we disallow vibrate in subframes by default, requiring embedders to say "allow='vibrate'" to enable. But my understanding is that other folks are keen to have it enabled by default in subframes with a user-gesture requirement for having it work. @benfredwells

In either case, I think disabling via feature policy should definitely turn the feature off.

[ojanvafai]

I think annoyance/abuse mitigations are different from permissions. Potentially annoying APIs like vibrate, autoplay, window.open, should be gated on a gesture by default and enabled in any frames that have had a gesture. Whereas APIs that need permissions should be off by default in subframes because, in general, the user doesn't understand that it's a subframe asking for the permission. As far as the user is concerned, they're only interacting with the top-page.

Am I missing something significant we gain by defaulting to requiring the top-page to grant vibrate to subframes instead of just requiring that the subframe has had a user gesture?

[VicenteDiaz]

I agree with @raymeskhoury in the sense that a "global" allowance should still be available and complementary to make it possible for publishers, interested in vibration content, to allow it by default without gesture. For instance a page based on haptic content for impaired people to enjoy different content without the need of gestures. Take into account that a blind person is unable to press the iframe so he/she will never activate it. Also old people has problems to control hands movements so this kind of global allowance will easy these possibilities.

Further, In advertising content sometimes we can sign a private agreement with a publisher (let's say BBC site), then they provide of a special iframe in their website only for our format to be displayed without the need of a gesture (just as it worked before Chrome modification), so BBC allows vibration by default (using policy) and only our format will be displayed in such iframe, this way they receive more money from marketers by selling Haptter advertising spaces creating a higher engagement with users.

As a conclusion, I think that both possibilities Allow and Disallow policies should be available. This way no one will be harmed in the future.

What do you think @lubin2010 ?

[ojanvafai]

Using user gestures should work fine with accessibility APIs. Users don't physically click, but they do actions that the browser interprets as a click.

Context

Chrome plans to limit vibrate on top-level pages to mitigate rampant abuse of vibrate for phishing. So, top frames will also require having had a user gesture before they can vibrate. We can talk about ways we might loosen those restrictions in the future, but should discuss that in a separate forum since it's not related to FeaturePolicy.

As a general FeaturePolicy principle, the top page cannot delegate permissions to subframes that it doesn't have access to. So, given the above, if the top frame hasn't had a gesture, then it can't delegate it to a subframe.

New Proposal

allow="vibrate" should allow the subframe to vibrate in the case that the top-frame has had a user gesture, regardless of whether the subframe has. That keeps the top page in charge of what it's subfames can do. Of course, the top-level page would still be able to use the vibrate FeaturePolicy to fully disable vibrate in subframes as they can with any other FeaturePolicy directive.

In this world, subframes that don't have allow="vibrate" but have had a user gesture would still be allowed to vibrate as they can today.

[clelland]

In this world, subframes that don't have allow="vibrate" but have had a user gesture would still be allowed to vibrate as they can today.

@ojanvafai, do you mean that even if not enabled by FP, a user gesture in a subframe would enable vibrate in that frame?

If the behaviour for vibrate is "allowed top-level and same-origin frames" (after gesture), then you'd still need to use allow="vibrate" to delegate to cross-origin subframes. -- I think this is acceptable.

On the other hand, if the behaviour for vibrate is "allowed at top-level and in all frames -- even cross-origin" (still after gesture), then the only way to disable vibrate completely would be through an HTTP header, at least until we sort out some kind of <iframe disallow> syntax.

[ojanvafai]

@ojanvafai, do you mean that even if not enabled by FP, a user gesture in a subframe would enable vibrate in that frame?

Right.

If the behaviour for vibrate is "allowed top-level and same-origin frames" (after gesture), then you'd still need to use allow="vibrate" to delegate to cross-origin subframes. -- I think this is acceptable.

I don't see what we gain by being this restrictive for this feature.

On the other hand, if the behaviour for vibrate is "allowed at top-level and in all frames -- even cross-origin" (still after gesture), then the only way to disable vibrate completely would be through an HTTP header, at least until we sort out some kind of <iframe disallow> syntax.

I think that's fine. People aren't clamoring to disable vibrate. I think the attribute disabling of it can easily wait until we've figured out attribute disabling for feature policy.

To be clear, my last proposal was that it's allowed in all frames after a gesture (in that frame), but that allow="vibrate" would also let a subframe vibrate after the parent page has had a gesture.

[raymeskhoury]

To be clear, my last proposal was that it's allowed in all frames after a gesture (in that frame), but that allow="vibrate" would also let a subframe vibrate after the parent page has had a gesture.

Hmm, but doesn't that get us back to a tri-state feature policy situation that we were trying to avoid?

I think I'm ok with allowing vibrate everywhere by default, as long as there is a gesture requirement, but I don't think specifying allow="vibrate" should do anything extra or else it complicates the FP mechanism (the default is "allow everywhere" so allow="vibrate" should be a no-op).

I know you've talked about the idea of passing around user gestures to subframes in the past. I think that might be an interesting direction to think more about that fits in with your suggestion though.

[jyasskin]

There are at least four different features here:

1. Vibrate after receiving a gesture
2. Vibrate without a gesture
3. Spend the parent's gestures
4. Spend the parent's gestures on vibrating

If it's ambiguous which one "vibrate" refers to, we can/should use a longer name.

[clelland]

There's been little movement on this in the last year or so -- I'm wondering whether this is still something we want to pursue. I'd propose that we drop this, unless people feel strongly that the current behaviour (no use without activation, Chrome's behaviour since version 60) is insufficient for vibration.

The other options I see are:

• We can add a vibrate-without-activation feature, off by default, which needs to be enabled in all frames from the top-level to any frame which wants to use it.
• We implement something like gesture delegation to allow fine-grained control of which frames receive activation after a gesture, and try to spec something that works to allow the no-vibrate, vibrate-only-after-activation, and vibrate-without-activation scenarios.

[clelland]

Closing this out; vibrate is currently implemented without any FP integration. If it comes up again, we can re-open this or file a new issue for the semantics.