WebAPI Security Discussion: Vibration API

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Vibration API

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" <[hidden email]>
To: "Justin Lebar" <[hidden email]>
Cc: [hidden email], [hidden email], [hidden email], "Adrienne Porter Felt" <[hidden email]>, "dev-b2g mailing list" <[hidden email]>
Sent: Wednesday, April 18, 2012 10:43:41 PM
Subject: Re: [b2g] WebAPI Security Discussion: Vibration API

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.
_______________________________________________
dev-webapps mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Vibration API

Paul Theriault
In reply to this post by Justin Lebar-3
Fair enough - I suppose it is up to the app developer to use vibration
in a way that is not annoying, and provide an interface to configure
options etc.

Just fyi: Testing this on my b2g phone right now, maximum vibration time
is 9999 millis and it doesnt vibrate while the phone is asleep.

On 4/20/12 11:10 AM, Justin Lebar wrote:

> On Fri, Apr 20, 2012 at 10:18 AM, Paul Theriault<[hidden email]>  wrote:
>> So long as this is easily user configurable, then I don't see this as a huge
>> risk. Rather than heuristics, how about just giving the user an easily
>> accessible interface to disable vibration for a given domain (maybe show the
>> vibrate icon in the status bar, tapping brings up a dialog that allows
>> disable vibration for this domain).
>>
>> Which makes me think we do actually need a permission for vibration, even if
>> it is granted by default.
> We don't currently give users the ability to disallow audio from a
> given domain.  Maybe you'd argue we should!  (You might be right.  :)
> But until we do that, I don't think there's any need to give users an
> "easily-configurable" way to disable vibration by domain, especially
> since audio will play in background tabs, but vibration won't.
>
> Just close the tab/app if it's vibrating like heck.  I feel like
> anything else may be over-engineering this.
>
>> On 4/20/12 9:47 AM, Adrienne Porter Felt wrote:
>>> I wasn't suggesting that the threshold is 20 minutes. Instead, my comment
>>> is that 20 minutes is clearly above the threshold, so this is evidence
>>> that
>>> there must be *some* reasonable threshold that won't break many games.
>>>   30sec? 20sec?  10sec?  3sec?  This could probably be resolved with a
>>> rather fun short survey of games.
>>>
>>> On Fri, Apr 20, 2012 at 1:44 AM, Justin
>>> Lebar<[hidden email]>wrote:
>>>
>>>> On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt<[hidden email]>
>>>> wrote:
>>>>> Surely there are limits as to what even a game wants to do with a
>>>> vibrator
>>>>> -- I doubt a game is going to want to constantly vibrate the phone for
>>>>> 20
>>>>> solid minutes.  Since that is the case, there must be a threshold.
>>>> Sure, but if we set the threshold at 20 minutes of continuous
>>>> vibration, we haven't accomplished very much in terms of avoiding user
>>>> annoyance.
>>>>
>>>>> On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar<[hidden email]>
>>>>> wrote:
>>>>>>> Maybe the API implementation itself can limit the number of vibration
>>>>>>> requests made by a page in a period of time ...
>>>>>> I don't know how to do this in a way which wouldn't mess up e.g. a
>>>>>> game which uses the vibrator all the time.  In general, heuristics
>>>>>> like this are hard.  :-/
>>>>>>
>>>>>>>> On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA<[hidden email]>
>>>> wrote:
>>>>>>>>> Is there any special risk on allowing any kind of unauthenticated
>>>>>>>>> content
>>>>>>>>> to request vibration without any permission request?
>>>>>>>>>
>>>>>>>>> Thanks, best
>>>>>>>>>
>>>>>>>>> El 16/04/12 07:55, "Lucas Adamski"<[hidden email]>    escribió:
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> On Apr 11, 2012, at 10:36 PM, Lucas Adamski wrote:
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> dev-webapps mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://lists.mozilla.org/listinfo/dev-webapps
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede
>>>>>>>>> consultar nuestra política de envío y recepción de correo
>>>>>>>>> electrónico
>>>>>>>>> en
>>>>>>>>> el enlace situado más abajo.
>>>>>>>>> This message is intended exclusively for its addressee. We only send
>>>>>>>>> and receive email on the basis of the terms set out at
>>>>>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>>>>>>> _______________________________________________
>>>>>>>>> dev-security mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.mozilla.org/listinfo/dev-security
>>>>>>>
>>>>>>>
>>>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede
>>>> consultar
>>>>>>> nuestra política de envío y recepción de correo electrónico en el
>>>> enlace
>>>>>>> situado más abajo.
>>>>>>> This message is intended exclusively for its addressee. We only send
>>>> and
>>>>>>> receive email on the basis of the terms set out at
>>>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>>>>>> _______________________________________________
>>>>>>> dev-webapi mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.mozilla.org/listinfo/dev-webapi
>>>>>> _______________________________________________
>>>>>> dev-webapi mailing list
>>>>>> [hidden email]
>>>>>> https://lists.mozilla.org/listinfo/dev-webapi
>>>>>
>>> _______________________________________________
>>> dev-security mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Vibration API

ianG-2
In reply to this post by Justin Lebar-3

> someone  wrote:
>> So long as this is easily user configurable, then I don't see this as a huge
>> risk.


Right - low risk.  At this stage, we're into idle speculation as to
finding some weirdo threat.

Don't be tempted by movie plot threats.  What you want to do now is
declare it low risk, refer to the conversation, and make the judgement
call:  "this risk is accepted.  I say it again.  The risk of vibration
abuse is not mitigated.  So there!"

Then, you go out there into the marketplace, *accepting the risk* and if
there is any reason why you got it wrong, the market will find the
reason and tell you.  Say sorry, update, move on.

In all risk modelling, you must accept some risks.

The common trap with trivial risks is that because we can mitigate them,
we do so, instead of accepting them.  Meanwhile, by wasting time
mitigating unimportant risks, we distract from other more important
risks...... which require more brain power to deal with.

The common trap with hard risks is that we declare them /out of scope/
because we haven't figured out how to mitigate them.



iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Vibration API

Devdatta Akhawe
Yes; but we like permissions just because they allow app to run least
privilege. Measurements indicate less than 20% of apps use the API
anways.

Further, responding to ianG's phrasing, if all apps in the market that
use vibration can be easily discovered through a manifest grep, it
might be easier to update and fix a risk discovered late.
---
We might later discuss APIs that are medium risk, but we decide are
not worthy of a UX prompt. In that case, for least privilege (i.e., in
case app gets pwned), it still makes sense to declare such a
permission.

In general, lets disassociate permissions with UI dialogs. Permissions
are a useful security mechanism that the developer can opt in to. I
don't really see much argument for *not* having this permission: is
the burden on developers really that high?



=dev

On 19 April 2012 19:31, ianG <[hidden email]> wrote:

>
>> someone  wrote:
>>
>>> So long as this is easily user configurable, then I don't see this as a
>>> huge
>>> risk.
>
>
>
> Right - low risk.  At this stage, we're into idle speculation as to finding
> some weirdo threat.
>
> Don't be tempted by movie plot threats.  What you want to do now is declare
> it low risk, refer to the conversation, and make the judgement call:  "this
> risk is accepted.  I say it again.  The risk of vibration abuse is not
> mitigated.  So there!"
>
> Then, you go out there into the marketplace, *accepting the risk* and if
> there is any reason why you got it wrong, the market will find the reason
> and tell you.  Say sorry, update, move on.
>
> In all risk modelling, you must accept some risks.
>
> The common trap with trivial risks is that because we can mitigate them, we
> do so, instead of accepting them.  Meanwhile, by wasting time mitigating
> unimportant risks, we distract from other more important risks...... which
> require more brain power to deal with.
>
> The common trap with hard risks is that we declare them /out of scope/
> because we haven't figured out how to mitigate them.
>
>
>
> iang
>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Vibration API

Jonas Sicking-2
In reply to this post by Adrienne Porter Felt
On Wed, Apr 18, 2012 at 9:32 PM, Adrienne Porter Felt <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Vibration API

Ian Melven


----- Original Message -----
From: "Jonas Sicking" <[hidden email]>
To: "Adrienne Porter Felt" <[hidden email]>
Cc: [hidden email], [hidden email], [hidden email], "Lucas Adamski" <[hidden email]>, "dev-b2g mailing list" <[hidden email]>
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
12