Intent to Implement and Ship: Block navigator.vibrate in cross-origin iframes

[Bin Lu]

Contact emails

bi...@googe.com, oj...@chromium.org, kenji...@chromium.org, aemi...@google.com

Spec

Public standards discussion: https://github.com/WICG/interventions/issues/25

Summary

Block navigator.vibrate in cross-origin iframes, and so that the call of navigator.vibrate will be no-op inside cross-origin iframes.

Motivation

Vibrate is being abused by unsafe third-party content (eg., malicious ads), and some users have complained about it (e.g., this reddit thread). To better protect user, we would like to block vibrate if it is called in cross-origin iframes (eg., a lot of ads are rendered inside iframes). 

Interoperability and Compatibility Risk

The measurement from Chrome shows that vibrate in (same-origin+cross-origin) iframes is being used by ~0.00025% of pages (See the metrics link), and so it is considered a low risk removal.

Meanwhile, if needed, we could provide a permission API to re-enable it, since the permissions/feature-policy work is moving forward and will probably ship by the end of the year.

Ongoing technical constraints

None.

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

Yes, although vibrate works only on mobile (Android and Android WebView).

OWP launch tracking bug

https://crbug.com/625044

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5682658461876224

Requesting approval to ship?

Yes.

Thanks,

- Bin

[Chris Harrelson]

LGTM1

--
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.

[Philip Rogers]

I've seen these ads as well and I'm not sure this mitigation will help because the ads are in new windows/tabs, not iframes. The reddit thread seems to mention this as well.

Why don't we put navigator.vibrate behind a permission prompt instead?

[Darin Fisher]

Or limit it to only being usable when showing a notification (that's presumably a primary use case, right?) and in other cases require a user gesture?

-Darin

[Bin Lu]

See my inline comments below. Ojan and Kenji, please correct me if I miss something.

 

I've seen these ads as well and I'm not sure this mitigation will help because the ads are in new windows/tabs, not iframes. The reddit thread seems to mention this as well.

Why don't we put navigator.vibrate behind a permission prompt instead?

Based on the internal data, we have seen ads vibrating both in new tabs and ad iframes.

This blocking in cross-origin iframes is just a part of the plan which helps only the iframe cases. 

The other part of plan is to use the engagement service to decide whether the site will be allowed to vibrate users, which will help the new tab case.

On the other, we don't want to prompt users before any vibrate which might annoy and confuse users.

There were a lot of Google internal discussion about this here in case you'd like to know more.

Or limit it to only being usable when showing a notification (that's presumably a primary use case, right?) and in other cases require a user gesture?

Other legit use cases include game web apps, alarm web apps, web messengers, etc. So we don't want to all completely.

As said above and discussed in the above internal thread, we'd like to try the engagement service to guard the use of vibrate which is the next step.

WDYT?

Thanks,

Bin

On Wed, Jul 6, 2016 at 5:36 PM, Darin Fisher <da...@chromium.org> wrote:

Or limit it to only being usable when showing a notification (that's presumably a primary use case, right?) and in other cases require a user gesture?

-Darin

 

[Rick Byers]

Regardless of the bigger picture discussion here, disabling in cross-origin iframes seems valuable and very low risk.  Also (since Chrome Android only appears to permit vibrate from the foreground tab) I assume this is the scenario that causes the most user confusion - since there may be no indication to the user of who to blame for the annoyance.  So LGTM2 for that.

I'm, of course, very interested to see how the larger issue plays out.  Finding a good compromise between user annoyance and application richness is always challenging...

Rick

[Darin Fisher]

+1, agreed this seems like a low risk & positive change.

-Darin

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[Mounir Lamouri]

To give a user angle to the data, 0.2-0.3% of Chrome Android users end
up hitting cross origin iframe vibrations. The number of users
encountering vibrations is an order of magnitude higher.

As Philip pointed, anecdotally, every time I had ads started to vibrate,
it was a full page ads, not an iframe. The ad would open via a pop up or
even sometimes with top frame highjacking. I've seen this recently on
mainstream French newspapers.

Blocking cross origin iframes vibrations is definitely a low hanging
fruit worth tackling but I think the real issue will be quite harder to
fix :(

-- Mounir

> >>> <https://groups.google.com/a/google.com/forum/#!msg/web-malware-eng/CyMt5H2YE2M/2I65MWS8DAAJ>

> >>>>>>> <https://www.reddit.com/r/chrome/comments/3cce4y/android_under_no_imaginable_circumstance_should_a/>).

> >>>>>>> To better protect user, we would like to block vibrate if it is
> >>>>>>> called in
> >>>>>>> cross-origin iframes (eg., a lot of ads are rendered inside
> >>>>>>> iframes).
>
> >>>>>>> Interoperability and Compatibility Risk
>
> >>>>>>> The measurement from Chrome shows that vibrate in (same-origin+
> >>>>>>> cross-origin) iframes is being used by ~0.00025% of pages (See the
> >>>>>>> metrics link

> >>>>>>> <https://www.chromestatus.com/metrics/feature/timeline/popularity/851>),

> >>>>>>> and so it is considered a low risk removal.
>
> >>>>>>> Meanwhile, if needed, we could provide a permission API to re-enable
> >>>>>>> it, since the permissions/feature-policy work is moving forward and
> >>>>>>> will probably ship by the end of the year.
>
> >>>>>>> Ongoing technical constraints
>
> >>>>>>> None.
>
> >>>>>>> Will this feature be supported on all six Blink platforms (Windows,
> >>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> >>>>>>> Yes, although vibrate works only on mobile (Android and Android
> >>>>>>> WebView).
>
> >>>>>>> OWP launch tracking bug
>
> >>>>>>> https://crbug.com/625044
>

[PhistucK]

What about game aggregators (games on Facebook, for example)? Blocking cross origin vibrations will cripple the user experience of those games a bit and make them less immersive or compelling...

I think maybe a sandbox token to re-enable vibration should be added in conjunction with this removal.

☆PhistucK

[Philip Jägenstedt]

Sandbox tokens are for things that are enabled by default in iframes but are disabled by the sandbox and thus need a way to opt back in. This would be a feature that's disabled by default and thus needs an opt-in separate from sandbox.

Fullscreen is like this with the allowfullscreen attribute, and getUserMedia might get an allowusermedia attribute, but a growing list of allow* attributes doesn't seem great.

What should the story be here? Vibration doesn't need a permission at all, but maybe one could pretend that it is and delegate it?

[Philip Jägenstedt]

See also https://github.com/noncombatant/permission-delegation-api/issues/21 to see the distinction between allowing an iframe to use an API at all (what allow* does) and delegating a permission so that it can use the API without further prompting. (Having both mechanisms for a single API would be pretty weird.)

[Bin Lu]

Thanks all for the feedback. 

So far, it seems that:

• It's agreed that blocking cross-origin iframe vibrations is a low risk & positive change.
  
• It's suggested to add a way to re-enable vibrate for cross-origin iframe for some use cases:
  

The original plan (as mentioned in the intent email) was to use the iframe permission delegate API to re-enable it, which will probably ship by the end of the year. 

On the other hand, an iframe attribute called allowvibrate  (similar to allowfullscreen) sounds also a good option to me. 

I'll chat with Ojan and the delegation API owners about it, and will get back when there is more info.

• There are concerns on how to block top-frame vibrate from e.g., annoying ads, which is the next step of this ship.
  

For the bigger picture, we are looking at different options:

- Blocking vibrate on sites with low engagement with the engagement service which will be ready to be used in Chromium soon.

- Blocking auto-redirect without user gesture (here as part of web interventions), which will help since many of such vibrating sites are from auto-redirecting ads.

Please let us know if there are further questions.

Thanks,

Bin

[Bin Lu]

An update on the status: This was already shipped in Chrome 55+, and some team members are working on allowing re-enabling vibrate for cross-origin iframe via feature policy (please see https://github.com/WICG/feature-policy/), e.g.,

- For now, the vibrate function could be turned on via HTTP headers for feature policy (See https://bugs.chromium.org/p/chromium/issues/detail?id=623682):

For example, if you have an iframe (src=B.com) that you'd like to enable vibrate for it, you will have to include a header: "Feature-Policy: {"vibrate": [B.com]}". Alternatively you can enable vibrate for all iframes by "Feature-Policy: {"vibrate": [*]}" or all same-origin iframes by "Feature-Policy: {"vibrate": [self]}". If you want to disable it, you can do "Feature-Policy: {"vibrate": []}".

By default vibrate is enabled for self, which means current frame and same-origin iframes have permission to vibrate.

- Also we are working on implementing iframe attribute for feature policy (please see crbug.com/682258). So you will be able to enable vibrate for any iframe in a couple of months by something like: <iframe src=... enable="vibrate"></iframe>.

> >>>>>>> send an email to blink-dev+unsubscribe@chromium.org.

>
>
>
>
>
>
>
>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
> --
> 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+unsubscribe@chromium.org.

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

[Rick Byers]

Also for the record, we should mention that Chrome 57 re-enabled vibration in iframes after a user gesture had occurred.

[bi...@google.com]

For the record again, Chrome 60 is removing navigator.vibrate without user gesture for all frames, including top-level pages.

> >>>>>>> send an email to blink-dev+...@chromium.org.

>
>
>
>
>
>
>
>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
> --
> 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.

--
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.