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 Wed, Apr 18, 2012 at 9:32 PM, Adrienne Porter Felt 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
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
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, refe
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 millis and it doesnt vibrate while the phone is asleep.
On
stin Lebar"
Cc: dev-weba...@lists.mozilla.org, dev-web...@lists.mozilla.org,
dev-security@lists.mozilla.org, "Adrienne Porter Felt" ,
"dev-b2g mailing list"
Sent: Wednesday, April 18, 2012 10:43:41 PM
Subject: Re: [b2g] WebAPI Security Discussion: Vibration API
On Apr 18, 201
On Fri, Apr 20, 2012 at 10:18 AM, Paul Theriault 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 i
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
On Fri, Apr 20, 2012 at 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?
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 f
On Fri, Apr 20, 2012 at 9:33 AM, Adrienne Porter Felt 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 w
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.
On Fri, Apr 20, 2012 at 1:12 AM, Justin Lebar wrote:
> > Maybe the API implementa
> 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 20
El 19/04/12 23:21, "Devdatta Akhawe" escribió:
>On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA wrote:
>> Is there any special risk on allowing any kind of unauthenticated
>>content
>> to request vibration without any permission request?
>>
>
>It will be an annoyance yes, but I don't see any
On 19 April 2012 11:31, JOSE MANUEL CANTERA FONSECA wrote:
> Is there any special risk on allowing any kind of unauthenticated content
> to request vibration without any permission request?
>
It will be an annoyance yes, but I don't see any security risk other
than Denial of Service. I think of
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" escribió:
>Last call for comments! So far the only feedback I have received is that
>it would be good to have a UI mech
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 th
> 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
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 wrote:
> Updated proposal.
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 calle
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 pu
ay, 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
> 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
On 16 April 2012 00:05, Justin Lebar wrote:
> > So far the only feedback I have receive
> 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 t
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: V
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 cod
26 matches
Mail list logo
