- Original Message -
> From: "ptheriault"
> To: cjo...@mozilla.com, "Jonas Sicking"
> Cc: dev-weba...@lists.mozilla.org, dev-security@lists.mozilla.org, "Mozilla
> B2G mailing list"
>
> Sent: Thursday, March 8, 2012 1:48:46 PM
> Subject: Re: [b2g] OpenWebApps/B2G Security model
>
> - P
That's right: the ideal model is one process per "app" and one process per
(arbitrary web content).
In practice, OS processes aren't free, and memory is a finite resource, so
we'll need to multiplex apps/tabs onto OS processes. Gecko is quite flexible
on how this can be done. The allocation
Actually, the suggestion was to have the reason included in the code/manifest.
Then when the dialog asking the user for to grant/deny permission was
displayed, the developer could tell the user why they want the permission
granted. Of course, if the application is being reviewed for granting
I think the idea is the opposite: to make it easy and common. Not saying its
risk-free. :)
In other news, we have started a feature page for the B2G app security model.
The idea is to work through the current
list of open issues in a (somewhat) structured process and capture the
resulting dec
https://developer.mozilla.org/en/OpenWebApps has some good info.
But in terms of business objectives, I'll do a terrible job of paraphrasing the
mission: maximize participation in the
open web. This means breaking up the app silos by maximizing the number of
possible devices, developers, app
On Thu, Mar 15, 2012 at 1:36 AM, ptheriault wrote:
>
> On Mar 15, 2012, at 12:16 PM, lkcl luke wrote:
>
>> Some time ago, Paul wrote this:
>>
>>> How do domains which install themselves as Web Apps fit into this model? Is
>>> there perhaps a default lower set of permissions that websites can inst
On Mar 15, 2012, at 12:16 PM, lkcl luke wrote:
> Some time ago, Paul wrote this:
>
>> How do domains which install themselves as Web Apps fit into this model? Is
>> there perhaps a default lower set of permissions that websites can install
>> themselves with - basically the same types as websit
Some time ago, Paul wrote this:
> How do domains which install themselves as Web Apps fit into this model? Is
> there perhaps a default lower set of permissions that websites can install
> themselves with - basically the same types as websites, except that with
> apps permissions might be able t
On 15/03/12 08:43 AM, lkcl luke wrote:
it is even absolute madness to even expect the actual people who have
been following this right from the beginning to be able to hold
everything in their heads.
+1. This is what I know:
"I'm way over due to write a proposal for the Open Web Apps and
B
On Thu, Mar 15, 2012 at 12:51 AM, David Chan wrote:
> Ignore my other email. I sent too early
*eyes shut*
>> > The
>> > selfhost issue Jonas brought up doesn't seem to apply if the
>> > packages
>> > are signed.
>>
>> self-host... selfhost... i'm lost. sorry. do you have a reference
>> (
On Thu, Mar 15, 2012 at 12:45 AM, David Chan wrote:
>> > The
>> > selfhost issue Jonas brought up doesn't seem to apply if the
>> > packages
>> > are signed.
>>
>> self-host... selfhost... i'm lost. sorry. do you have a reference
>> (wiki URL) which explains?
>>
>
> The scenario is more complic
Ignore my other email. I sent too early
> > The
> > selfhost issue Jonas brought up doesn't seem to apply if the
> > packages
> > are signed.
>
> self-host... selfhost... i'm lost. sorry. do you have a reference
> (wiki URL) which explains?
>
The situation is more complicated than I remember.
[re-sending, whoops i forgot to send this to all recipients. good job
i decided to review it and update the wiki eh, else i wouldn't have
known that i'd made the mistake of sending it only to lucas]
On Thu, Mar 15, 2012 at 12:05 AM, Lucas Adamski wrote:
> In fairness, its worth considering that
> > The
> > selfhost issue Jonas brought up doesn't seem to apply if the
> > packages
> > are signed.
>
> self-host... selfhost... i'm lost. sorry. do you have a reference
> (wiki URL) which explains?
>
The scenario is more complicated than I remember.
> > I could host my own app and have i
On Thu, Mar 15, 2012 at 12:09 AM, David Chan wrote:
> Thanks for reviewing the wiki. I'll add your concerns to that section. If I'm
> understanding correctly, you are arguing for a flat "hierarchy", peers in the
> debian sense.
absolutely. the analogy is "entries in /etc/apt/sources.list".
>Th
I've added the debconf shim information to the wiki
https://wiki.mozilla.org/Apps/Security#debconf_shim_for_B2G_native_apps
It also does seem that there is some misunderstanding in the terminology
being used so I added a section trying to define a "webapp", "native app".
However, I believe there
Thanks for reviewing the wiki. I'll add your concerns to that section. If I'm
understanding correctly, you are arguing for a flat "hierarchy", peers in the
debian sense. The analogous idea in the B2G world would be that Mozilla,
telcos, company foo could all run their own stores. If a user doesn
review requested:
https://wiki.mozilla.org/Apps/Security#FLASK_for_enforcing_permissions
i've thought about this some more and have updated it for accuracy as
well. the basic position is that the present model which implements
WebAPIs within the same threads/processes (fork, pthread) is
fundament
In fairness, its worth considering that a better overall user experience could
be obtained by having dynamically web
hosted without an explicit update process, because
a) it maximizes the community that can participate in building really great
apps (without having to figure out code
signing, vers
review:
https://wiki.mozilla.org/Apps/Security#Trusted_store_with_permissions_delegation
(thank you to david for documenting this stuff, yeah!)
"A store (parent) may permit a trusted store (child) to grant a subset
of parent's permissions"
no. this is a very bad idea. ok. maybe it is, maybe
On Wed, Mar 14, 2012 at 11:02 PM, ptheriault wrote:
>
> I actually liked the idea of "more privilege for "installed" apps, less for
> "remote" apps" - the number of apps that will need elevated permissions are a
> very small percentage (and I think that was B2G's original plan?) . As I
> unders
On Wed, Mar 14, 2012 at 10:44 PM, David Chan wrote:
> I've updated the wiki page with the information presented in e-mails today
> - definition of app instance / version
> - link to B2G/App security model feature page
> - benefits of mirroring Debian package management system
> - link to Jim's per
@whoever is maintaining the wiki page: information is contained about
1/2 way down which is critical to put onto the wiki page. thanks.
On Wed, Mar 14, 2012 at 9:50 PM, Fabrice Desré wrote:
> Lucas,
>
> Are you considering signing the html/js/css/other-content from apps?
ys. nooow you'r
I actually liked the idea of "more privilege for "installed" apps, less for
"remote" apps" - the number of apps that will need elevated permissions are a
very small percentage (and I think that was B2G's original plan?) . As I
understand it, Gaia apps are already static HTML apps (i.e. it would
I've updated the wiki page with the information presented in e-mails today
- definition of app instance / version
- link to B2G/App security model feature page
- benefits of mirroring Debian package management system
- link to Jim's permission manager bug
- complications of using SSL as authenticat
Paul and I are putting together a feature page to capture some of the
discussion so far, and to provide a foundation
going forward. We'll have someone out for review shortly. Thanks!
Lucas.
On 3/14/2012 2:35 PM, lkcl luke wrote:
> On Wed, Mar 14, 2012 at 6:30 PM, Justin Lebar wrote:
>> On We
At this point I'm just raising possibilities. If we go with something close to
option b), then we have to figure out
how to deal with a set of threats not really present in other app stores. It
doesn't preclude us from doing so, but we
might for example have to require a relatively strict CSP p
On Wed, Mar 14, 2012 at 9:35 PM, Lucas Adamski wrote:
> My understanding is that there will be multiple app stores. But code signing
> has another benefit: reducing systemic risk.
>
> This assume code signing and sane key management, but lets say there's a very
> popular app with significant pr
Lucas,
Are you considering signing the html/js/css/other-content from apps?
I can understand the nice properties that would give us, but that looks
extremely impractical in real life. Web sites change all the time, which
is not the case of native apps distributed from a store.
Fabri
On Wed, Mar 14, 2012 at 8:20 PM, Lucas Adamski wrote:
> I don't think the feature page should be the place for discussion, but it
> should track the discussion. As issues are
> raised, discussed & resolved, those would be mirrored in the feature page.
> Otherwise, important issues will be lost
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 for validation.
>> Assumptions: th
On Wed, Mar 14, 2012 at 6:30 PM, Justin Lebar wrote:
> On Wed, Mar 14, 2012 at 2:16 PM, Lucas Adamski wrote:
>> P.S. If that sounds a lot like a Feature Page, that's probably because it
>> wouldn't be a bad starting point.
>> Lucas.
>
> IME, developers have been traditionally hesitant to desig
My understanding is that there will be multiple app stores. But code signing
has another benefit: reducing systemic risk.
This assume code signing and sane key management, but lets say there's a very
popular app with significant privileges.
To compromise a large number of people, you'd need t
I don't think the feature page should be the place for discussion, but it
should track the discussion. As issues are
raised, discussed & resolved, those would be mirrored in the feature page.
Otherwise, important issues will be lost,
and new participants will cannot synthesize a design from a h
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 for validation.
Assumptions: that B2G/Firefox will have separate processes for each app/tab.
This is already decl
It feels a bit like we are really trying to define what a given "instance" or
"version" of an app means. Is it:
a) a static bundle of code authenticated by manifest + signature (or
equivalent)
b) a dynamic stream of code authenticated by a specific origin (same origin
applied, all assets must
On Wed, Mar 14, 2012 at 2:16 PM, Lucas Adamski wrote:
> P.S. If that sounds a lot like a Feature Page, that's probably because it
> wouldn't be a bad starting point.
> Lucas.
IME, developers have been traditionally hesitant to design using
feature pages, because there's no means for collaborat
P.S. If that sounds a lot like a Feature Page, that's probably because it
wouldn't be a bad starting point.
Lucas.
On 3/11/2012 4:48 PM, Jonas Sicking wrote:
> On Sat, Mar 10, 2012 at 1:41 PM, lkcl luke wrote:
>> this is all really good stuff, jim. but i have to reiterate: WHERE
>> IS IT BEI
I have to agree with my namesake here. This is too complicated to design in a
ML, without having some sort of reference
point. It also makes is unrealistic to add new participants without the cliche
"go read every post about this subject
first". If nothing else we should have a wiki that conta
39 matches
Mail list logo
