> > If the user picks 'no', a well-written app should allow other
> > functionality to work, but won't be able to use the camera.
Too many developers fall into this trap: If a user installs a camera
application (some basic alternative camera), but denies it camera access -
why would the OS even
Hi,
As far as I know, you can do an uninstall now. Regarding the update
functionality I guess it will work a bit different, each time you visit a
new web app, if the cache manifest changes, or even if you don't have an
offline version and you are always using the online one, the system will
automa
+1 to the permissions model.
A responsive permissions model could help build any kind of app, and
giving the user total control over what it installs.
On 16/04/2012 16:27, "Mike Habicher" wrote:
>
>* Permission 1: Allow this app to use the camera to take pictures/video?
>yes/no
>
>If the user p
> It would be great if the spec also specified that the phone needs to
> provide a resource consumption manager.
Perhaps "should" rather than "needs to". This is a non-trivial thing
to do, in general. Not that we shouldn't do it, but I don't think we
should say that we're in violation of the spe
On Mon, 16 Apr 2012 13:02:32 -0700
Tanvi Vyas wrote:
> Invisible Flash is often used as an audio
> > fall-back when a particular codec isn't supported natively by the
> > browser.
Maybe there's other invisible flash. I wouldn't really know as I only
use it occasionally, except on my tvs and there
Hi Mark,
Thanks for your comments! In the current proposal, the plugin will work
automatically as long as it is up-to-date and the user hasn't requested
"click to play". If the user has set the preference to click to play
all plugins (or click to play certain plugins), they will be familiar
Comments inline below
On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:
> I'm not sure all Settings should be treated as either one of two levels
> (accessible with no user involvement, or not accessible at all). I think
> different Settings should be handled individually. Here are some
How about un-install an app, update an app (assuming that the app has a cached
component and we can distinguish when cached components change, and also that
we desire that the user can control when an app is updated).
I also think that the risks for some of the APIs vary. For example, getSelf()
Hi there - I was encouraged to comment here by Ian Melven.
I just wanted to better understand the proposal for dealing with
'invisible' pieces of Flash. Invisible Flash is often used as an audio
fall-back when a particular codec isn't supported natively by the
browser. As co-author of jPlayer (jPl
- Original Message -
> From: "Devdatta Akhawe"
> To: "Justin Lebar"
> Cc: dev-weba...@lists.mozilla.org, dev-web...@lists.mozilla.org,
> dev-security@lists.mozilla.org, "Lucas Adamski"
> , "dev-b2g mailing list"
> Sent: Monday, 16 April, 2012 10:36:52 AM
> Subject: Re: [b2g] WebAPI Sec
- Original Message -
> From: "Adrienne Porter Felt"
> To: "Lucas Adamski"
> Cc: dev-weba...@lists.mozilla.org, dev-web...@lists.mozilla.org, "Zack
> Weinberg" , "dev-b2g list"
> , mozilla-dev-secur...@lists.mozilla.org
> Sent: Sunday, 15 April, 2012 4:32:06 PM
> Subject: Re: [b2g] WebA
That is one area where one could trust the app - the only way for it to
gain access to the camera would be to insert the button's DOM node facade
(this is a secure mechanism, because the DOM node is not the button itself,
it is only a placement indicator). The OS then observes the positioning,
det
I like this proposal.
For some apps (like the Yahoo Messenger app), it might be annoying to see a
full-screen preview of the text message every time. For this, I'd propose
a magic button for sending SMS messages. In this proposal, the OS takes
the target number as input and includes either the t
> 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
It would be great if the spec also specified that the phone needs to
provide a resource consumption manager. That way concerned users could see
which trusted/certified apps are responsible for a short battery life, if
the phone is being drained too fast.
On Sun, Apr 15, 2012 at 11:18 PM, Lucas Ad
I'm not sure all Settings should be treated as either one of two levels
(accessible with no user involvement, or not accessible at all). I think
different Settings should be handled individually. Here are some
suggestions for a few possible Settings parameters:
-- Vibrating the phone and changin
>
>
> but yes, adrienne - perhaps unintentionally - did actually say that
> it should be userspace. allow me to quote again the relevant part of
> what adrienne (hello adrienne) said:
>
> On Sun, Apr 15, 2012 at 9:32 PM, Adrienne Porter Felt
> wrote:
> > Would the following suggestion solve the
> Potential mitigations: container should not be able to script into browser
> iframe
In general, you cannot mitigate risk from an untrusted browser.
An untrusted browser can arbitrarily phish you. You type in
"bank.com", the browser takes you to evil.com and displays "bank.com"
in its URL bar.
> 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
19 matches
Mail list logo