WebAPI Security Discussion: Vibration API

[Lucas Adamski]

Name of API: Vibration
Reference: http://dev.w3.org/2009/dap/vibration/

Brief purpose of API: Let content activate the vibration motor

Inherent threats: Obnoxious if mis-used, consume extra battery
Threat severity: low

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Vibrate when hit in a game
Authorization model for uninstalled web content: Explicit
Authorization model for installed web content: Implicit
Potential mitigations: Limit how long vibrations can run

== Trusted (authenticated by publisher) ==
Use cases for authenticated code:[Same]
Authorization model: Implicit
Potential mitigations:

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code:
Authorization model: implicit
Potential mitigations:

Notes: This API may be implicitly granted. User can deny from Permission Manager to over-ride an abusive app.

[Lucas Adamski]

Last call for comments! So far the only feedback I have received is that it would be good to have a UI mechanism for determine which app is triggering the vibration, which sounds like a reasonable idea to me. Thanks!
Lucas.

[Justin Lebar]

> So far the only feedback I have received is that it would be good to have a UI mechanism for determine which app is triggering the vibration, which sounds like a reasonable idea to me. Thanks!

Only foreground pages / apps can trigger vibrations via the vibrator
API. So there is no need to expose in the UI which app is responsible
for a vibration.

Background apps will have to go through a separate notifications API
in order to frob the vibrator.

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Devdatta Akhawe]

> Background apps will have to go through a separate notifications API
> in order to frob the vibrator.

And for those, a UI mechanism for determining which app is causing the
vibration would be useful.

-dev

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

[Mike Habicher]

----- Original Message -----
> From: "Devdatta Akhawe" <dev.a...@gmail.com>
> To: "Justin Lebar" <justin...@gmail.com>
> Cc: dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, "Lucas Adamski"
> <lada...@mozilla.com>, "dev-b2g mailing list" <dev...@lists.mozilla.org>
> Sent: Monday, 16 April, 2012 10:36:52 AM
> Subject: Re: [b2g] WebAPI Security Discussion: Vibration API
>
> > Background apps will have to go through a separate notifications
> > API
> > in order to frob the vibrator.
>
> And for those, a UI mechanism for determining which app is causing
> the
> vibration would be useful.

And whenever the notifications API comes up for discussion, it would be good to keep in mind that just because an app requests a notification doesn't mean it will get it. The user preference (audible, vibrate, none) should (must?) always take precedence. Note that 'vibrate' is not the opposite of 'audible'--sometimes you want no notifications at all.

--m.

[Lucas Adamski]

Updated proposal. Note that since only foreground content can trigger vibrator, this seems equivalent to other potentially annoying feedback mechanisms and should be implicit for uninstalled web content… thoughts?

Name of API: Vibration
Reference: http://dev.w3.org/2009/dap/vibration/

Brief purpose of API: Let content activate the vibration motor

Inherent threats: Obnoxious if mis-used, consume extra battery
Threat severity: low

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Vibrate when hit in a game

Authorization model for uninstalled web content: Implicit

Authorization model for installed web content: Implicit

Potential mitigations: Limit how long vibrations can run. Only foreground content can trigger vibration.

== Trusted (authenticated by publisher) ==
Use cases for authenticated code:[Same]
Authorization model: Implicit
Potential mitigations:

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code:

Authorization model: Implicit

[Chris Lee]

On Apr 18, 2012, at 6:44 PM, Lucas Adamski wrote:

> Updated proposal. Note that since only foreground content can trigger vibrator, this seems equivalent to other potentially annoying feedback mechanisms and should be implicit for uninstalled web content… thoughts?

I didn't see this called out, but how do we think about vibration triggers for the notification use case from SMS/3rd party apps?

Chris

[Adrienne Porter Felt]

Could it be limited to both foreground content that is the top level
window? That way ads in iframes won't be able to annoy the user as much
(and websites can ensure that ads won't be annoying by putting them in
frames).

On Thu, Apr 19, 2012 at 3:44 AM, Lucas Adamski <lada...@mozilla.com> wrote:

> Updated proposal. Note that since only foreground content can trigger
> vibrator, this seems equivalent to other potentially annoying feedback
> mechanisms and should be implicit for uninstalled web content… thoughts?
>

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Justin Lebar]

> I didn't see this called out, but how do we think about vibration triggers for the notification use case from SMS/3rd party apps?

We think about this as a completely separate "notifications" API.

This API is separate because it may not directly let pages frob the
vibrator -- if I've globally disabled sound and vibrating
notifications, then a background SMS app shouldn't be able to ring or
vibrate the phone.

> Could it be limited to both foreground content that is the top level
> window? That way ads in iframes won't be able to annoy the user as much
> (and websites can ensure that ads won't be annoying by putting them in
> frames).

I can't think of a precedent for this kind of thing. If there is a
precedent, then I might be OK applying it here.

[Lucas Adamski]

On Apr 18, 2012, at 10:29 PM, Justin Lebar wrote:
>> Could it be limited to both foreground content that is the top level
>> window? That way ads in iframes won't be able to annoy the user as much
>> (and websites can ensure that ads won't be annoying by putting them in
>> frames).
>

> I can't think of a precedent for this kind of thing. If there is a
> precedent, then I might be OK applying it here.

I think the precedent is being set in the orientation API, which has faced a similar set of (annoyance) concerns and come to a similar conclusion.
Lucas.

[Ian Melven]

there's also discussion along these lines about the DeviceMotion API but we haven't decided
to actually add that restriction yet. See https://bugzilla.mozilla.org/show_bug.cgi?id=686401

thanks,
ian

----- Original Message -----
From: "Lucas Adamski" <lada...@mozilla.com>
To: "Justin Lebar" <justin...@gmail.com>
Cc: dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, "Adrienne Porter Felt" <a...@berkeley.edu>, "dev-b2g mailing list" <dev...@lists.mozilla.org>
Sent: Wednesday, April 18, 2012 10:43:41 PM
Subject: Re: [b2g] WebAPI Security Discussion: Vibration API

_______________________________________________
dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

[Jonas Sicking]

On Wed, Apr 18, 2012 at 9:32 PM, Adrienne Porter Felt <a...@berkeley.edu> wrote:
> Could it be limited to both foreground content that is the top level
> window?  That way ads in iframes won't be able to annoy the user as much
> (and websites can ensure that ads won't be annoying by putting them in
> frames).

I feel like vibration is very similar to audio. I'm fairly sure there
are websites that have a policy that none of the ads that they are
showing are allowed to play audio. Unfortunately this can't be
enforced through technical means right now, with the result being that
sometimes ad agencies break the policies.

I see the desire to disable vibration for cross-origin iframes, but I
think it would also disable useful usecases if we do it as a blanket
policy. For example many games on facebook run inside an iframe. What
would be really cool is if we had the ability for a site to create an
iframe for an ad and say that the contents of the iframe wasn't
allowed to play audio or enable the vibrator.

Alternatively we could do it the other way around and say that
cross-origin iframes by default disable vibration, but can then be
explicitly re-enable the vibrator.

We could implement a "allow by default but allow parent website to
disable vibration" by extending the sandbox attribute. We could
probably do audio that way too since sandboxes disable plugins.

/ Jonas

[Ian Melven]

----- Original Message -----
From: "Jonas Sicking" <jo...@sicking.cc>
To: "Adrienne Porter Felt" <a...@berkeley.edu>
Cc: dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, "Lucas Adamski" <lada...@mozilla.com>, "dev-b2g mailing list" <dev...@lists.mozilla.org>
Sent: Thursday, May 3, 2012 4:05:38 AM
Subject: Re: [b2g] WebAPI Security Discussion: Vibration API

> We could implement a "allow by default but allow parent website to
> disable vibration" by extending the sandbox attribute. We could
> probably do audio that way too since sandboxes disable plugins.

when working on a previous user agent, when pitching what is essentially the sandbox attribute's 'allow-same-origin' functionality
to various people, a common request that came up was 'site authors want a way to stop hosted, possibly user generated, content being annoying'

so, FWIW i'm in favor of exploring extending the sandbox attribute to deal with cases like
restricting vibration or audio - the existing 'sandboxing automatic features' flag which is set if
'allow-scripts' isn't specified is a start along these lines already and has a somewhat 'up to the reader' interpretation
beyond the mentioned example use cases (stopping video autoplay and autofocus).

thanks,
ian