st use the must have app
focus to have prompts appear (keyboard services never get app focus, so if
they tried to use an API it would always be deferred).
-Jim Straus
On May 4, 2012, at 2:36 PM, Lucas Adamski wrote:
> On May 2, 2012, at 8:34 AM, Jim Straus wrote:
>
>> Lucas -
>
viewed app.
-Jim Straus
On May 1, 2012, at 11:23 PM, Lucas Adamski wrote:
> Please reply-to dev-webapps.
>
> There's been much discussion lately of the different types of applications
> and so I figured this would be a good time to
> summarize the current state of discussion
ied" dialer.
Particularly for emergency calls which really, really need to work.
-Jim Straus
On Apr 30, 2012, at 6:14 PM, Lucas Adamski wrote:
> So I'm a bit confused as to the purpose of the dialer API with trusted apps.
> The stated use case is "fun dialer" but if
I believe that the user should not be able to replace their built-in telephone
app except with a certified telephony app (though they can have multiple
telephony apps installed) so that we know emergency calls can always be made.
And that whatever mechanism is used to make emergency calls (tho
s indicate an app has
become less stable (I'll wait for a follow on update) or has lost some portion
of functionality.
-Jim Straus
On Apr 30, 2012, at 12:46 AM, Lucas Adamski wrote:
> On Apr 21, 2012, at 10:35 PM, Thinker K.F. Li wrote:
>
>> Hi,
>>
>> Although we do
tooth, usb icon button for usb, etc. I'm not
sure about things like storage, permissions API, settings API, etc. Maybe
those are handled more at the install/first launch stage and not at runtime.
And background apps or services are a whole different question.
-Jim Straus
On Apr 13, 20
Thanks for pulling this together. Some comments inline below.
On Apr 19, 2012, at 1:41 AM, Lucas Adamski wrote:
> Much anticipated, here is a high-level overview of the B2G runtime security
> model. We are calling this the "runtime" B2G security model to avoid
> confusion with the underlying
Comments in line below
On Apr 17, 2012, at 4:08 PM, Adrienne Porter Felt wrote:
>
>
> On Mon, Apr 16, 2012 at 7:42 PM, Jim Straus wrote:
> On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:
>
> > -- Changing the wallpaper or ringtone: Let all apps do it, but
I like the original thinking that is going into trying to avoid specific
permission prompts and use implied consent. I have some questions and
concerns, so I'm going to go through a scenario and see if I'm understanding
correctly and solicit thoughts on some issues.
Scenario: A camera that ta
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()
Actually, a lot of apps need access to the preview before starting to capture
(an image or video). Any app that wants to do realtime transformations or
effects will need the preview stream and then display it themselves. Also,
there are a class of apps that do "pre-cording" so that you can cap
I think it has been said before that the extra security being discussed is only
required for apps that have been granted privileges (permissions). I'm not
sure if it should be only "super sensitive permissions" or any permissions
granted automatically. As I've said, if a permission isn't a ris
Comments in line below:
On Mar 21, 2012, at 6:05 PM, Ian Bicking wrote:
> On Wed, Mar 21, 2012 at 3:32 PM, Jim Straus wrote:
> As I've been reading, there are two divergent proposals for privileged app
> deployment. The primary concern is that the code that has been granted
&
As I've been reading, there are two divergent proposals for privileged app
deployment. The primary concern is that the code that has been granted
privileges is not changed so that malicious code can't get privileges. I think
we want protection for any privileges that are granted to an applicat
. I suspect that if it is too easy to rip off developers they won't
participate.
On Mar 19, 2012, at 4:17 PM, Anant Narayanan wrote:
> On Mar 19, 2012, at 12:19 PM, Jim Straus wrote:
>> I don't see how this helps with someone copying an app and
>> modifying/removi
Does this mean that the store has to host all the backend data and services?
Since the standard model is that web sites are generally restricted to
connecting to their origination domain, the would mean that an app would be
restricted to connecting to app5472.mozilla.org. Even if app5472.mozil
rtificate) have to be involved.
-Jim Straus
On Mar 16, 2012, at 5:55 PM, Justin Lebar wrote:
>> Anything that is granted permissions needs to be the same thing every time.
>
> I think we're going down a really dangerous path with this thinking.
>
> It's one thing t
e user
will have to re-grant the permissions.
On Mar 16, 2012, at 3:39 PM, Jonas Sicking wrote:
> On Sun, Mar 11, 2012 at 6:51 PM, Jim Straus wrote:
>> Hello Jonas -
>> The problem I'm trying to solve is knowing that the app I think I'm getting
>> is the app that I
I would like to propose that we can get the equivalent of a packaged web-app
without actually packaging all the content. If the manifest includes a list of
components of the web app (the javascript, html, css, possibly more if needed),
and a signed hash for those pieces (either in aggregate or
ot;Deny Always".
Otherwise you could be locked out of your device.
On Mar 15, 2012, at 6:21 PM, lkcl luke wrote:
> On Thu, Mar 15, 2012 at 10:00 PM, Jim Straus wrote:
>> I'm not sure an app can effectively bully the user.
>
> []
>
>> An app COULD complain to t
mplain
to the user if they are denied access and try to get them to go to the
Permissions Manager app, but I suspect any app that was so abusive wo
uld be deleted very quickly.
-Jim Straus
On Mar 15, 2012, at 5:53 PM, lkcl luke wrote:
> On Thu, Mar 15, 2012 at 9:31 PM, Justin Lebar wro
permission a priori, the reviewer could look at that reason directly. But the
reason would always be there on the device, and looked at through whatever
Permissions Management app is supplied.
-Jim Straus
On Mar 14, 2012, at 8:51 PM, David Chan wrote:
> The review process seems to work for
Yup, bug 707625
-Jim Straus
On Mar 14, 2012, at 4:03 PM, Vivien wrote:
> On 13/03/2012 21:09, Jim Straus wrote:
>> Hello all -
>> I've been sketching out an implementation of permissions. I've laid out
>> some code framework, but wanted to through tis out f
se for testing permissions and enumerate the database without
having to call the permissions API. The master process would still be used to
update the permissions, signal that something changed, and invoke the UI .
-Jim Straus
On Mar 13, 2012, at 1:10 PM, phillip...@gmail.com wrote:
>
ld want to allow the user to
control that, not the developer unilaterally.
Just for fun, see
http://www.youtube.com/watch?feature=player_embedded&v=k4EbCkotKPU It is has
some relevance to the discussion.
-Jim Straus
On Mar 11, 2012, at 9:11 PM, David Barrera wrote:
> I've been fo
. But there will definitely be
apps that we want to completely disable (eg. if we find an app is hijacking
information, I don't want it running at all.)
-Jim Straus
On Mar 11, 2012, at 7:46 PM, Jonas Sicking wrote:
> On Sat, Mar 10, 2012 at 1:00 PM, Jim Straus wrote:
>> Jonas, Pau
vers, leaks contacts, etc.) so that the
user can make an informed choice such as to allow an app that consumes excess
resources, but not allow an app that leaks personal information or incurs
excessive costs.
-Jim Straus
On Mar 9, 2012, at 11:01 PM, Jonas Sicking wrote:
> On Thu, Mar 8, 2012 a
yet.
I like the idea of auditing. I'm not sure what you mean by when a specific
permission is actually used, but the idea of giving the user a sense of how
often an application is using the permission is certainly possible and could be
shown in a permissions manager.
-Jim Straus
On Mar
ep their permissions until they are
re-installed.
-Jim Straus
On 3/5/12 1:25 PM, Lucas Adamski wrote:
I like this proposal at a high level, it provides for a lot of flexibility.
What I like about a permission model that can prompt at runtime is that is
makes some permissions optional. On An
30 matches
Mail list logo
