WebAPI Security Discussion: Browser API

22 views
Skip to first unread message

Lucas Adamski

unread,
Apr 16, 2012, 2:14:27 AM4/16/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-b2g mailing list, dev-se...@lists.mozilla.org
Please reply-to dev-w...@lists.mozilla.org

Name of API: Browser API
Reference: https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI

Brief purpose of API: Provide an iframe that acts as a web browser
General Use Cases: None

Inherent threats:
* browser can see all data from all websites, and perform all actions

Threat severity: moderate (phishing) per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including OAuth, OpenID, PayPal, Facebook Connect, etc. etc.
Authorization model: implicit
Potential mitigations: container should not be able to script into browser iframe

Google's recommendations about how to do this:
http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-approval

Consider also the iOS-Twitter authorization flow described here:
http://code.google.com/p/twitter-api/issues/detail?id=1560
and the threat, described here:
http://www.zdnet.co.uk/blogs/tech-tech-boom-10017860/ios-url-handler-poses-significant-risk-10021042/

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Replacement Browser
Authorization model: Implicit
Potential mitigations: Explicit process to add a new browser to the system?

[Given that the browser is built in to b2g, what would a replacement browser actually be?]

popup windows in b2g:
https://bugzilla.mozilla.org/show_bug.cgi?id=716664

window.open in iframe mozbrowser:
https://bugzilla.mozilla.org/show_bug.cgi?id=742944

window.open in iframe mozapp:
https://bugzilla.mozilla.org/show_bug.cgi?id=744451


Justin Lebar

unread,
Apr 16, 2012, 3:15:31 AM4/16/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
> 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. It even displays a lock icon. You type in your
username and password. Evil.com records it.

I think it is a mistake to talk about things like preventing the
container from injecting script into the iframe. That is only useful
for preventing a tiny class of attacks out of many, many possible
attacks.

> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including OAuth, OpenID,
> PayPal, Facebook Connect, etc. etc.

<iframe mozbrowser> is explicitly not for this. We need to be able to
run the mozbrowser in a separate process, and that precludes any
interaction of this sort between the parent and the child.

> [Given that the browser is built in to b2g, what would a replacement browser actually be?]

The browser is built in just like the calculator app. A user could
download another calculator app. They could also download another
browser app (modulo security constraints).
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

Ben Francis

unread,
Apr 17, 2012, 7:09:02 AM4/17/12
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
On Mon, Apr 16, 2012 at 7:14 AM, Lucas Adamski <lada...@mozilla.com> wrote:

>
> == Regular web content (unauthenticated) ==
>
> == Trusted (authenticated by publisher) ==
>
> == Certified (vouched for by trusted 3rd party) ==
>

I don't understand these categories, could you explain them a bit further?

What is the difference between trusted and certified and what process and
limitations do they require?

Is there a difference in security model between regular web content and
installed apps?

If the app is installed directly from a web app's own server (not via a
third party app store), can it never get access to this API, even with the
user's explicit permission?

Ben

--
Ben Francis
http://tola.me.uk

Justin Lebar

unread,
Apr 17, 2012, 9:32:58 AM4/17/12
to Ben Francis, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
> I don't understand these categories, could you explain them a bit further?

Lucas can correct me, but AIUI this is a model that Lucas has
developed for thinking about trust and apps. These categories may not
have concrete analogs in B2G.

There was previously a lot of talk about somehow requiring that
"certified" apps be somehow restricted from executing arbitrary code,
so we could verify that they're doing what they say they're doing.
But that discussion has been put on hold afaict.

> What is the difference between trusted and certified and what process and
> limitations do they require?
>
> Is there a difference in security model between regular web content and
> installed apps?
>
> If the app is installed directly from a web app's own server (not via a
> third party app store), can it never get access to this API, even with the
> user's explicit permission?

In other words, these are good questions, but they're general
questions about this way of thinking about web app security, and
aren't specific to the browser API and this thread. If we're going to
have this discussion, I'd appreciate if we did so separately.

-Justin

Lucas Adamski

unread,
Apr 26, 2012, 11:06:19 AM4/26/12
to Ben Francis, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, dev-b2g mailing list
Sorry I didn't catch this earlier. The following discussion is still accurate, though I will refine these descriptions and post them to the wiki by Friday: https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/2dd02277ab8b41ba?pli=1
Lucas.

On Apr 17, 2012, at 4:09 AM, Ben Francis wrote:

> On Mon, Apr 16, 2012 at 7:14 AM, Lucas Adamski <lada...@mozilla.com> wrote:
>
>>
>> == Regular web content (unauthenticated) ==
>>
>> == Trusted (authenticated by publisher) ==
>>
>> == Certified (vouched for by trusted 3rd party) ==
>>
>
> I don't understand these categories, could you explain them a bit further?
>
> What is the difference between trusted and certified and what process and
> limitations do they require?
>
> Is there a difference in security model between regular web content and
> installed apps?
>
> If the app is installed directly from a web app's own server (not via a
> third party app store), can it never get access to this API, even with the
> user's explicit permission?
>
> Ben
>
> --
> Ben Francis
> http://tola.me.uk
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

Lucas Adamski

unread,
Apr 27, 2012, 2:53:34 PM4/27/12
to Justin Lebar, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-se...@lists.mozilla.org, Ben Francis, dev-b2g mailing list
On Apr 26, 2012, at 8:21 AM, Justin Lebar wrote:

> (cc only dev-b2g, per Mounir's plea that we stop mass cross-posting.)

I realize Mounir doesn't like cross-posting because doesn't want to be on all those lists, but I'm not sure why he thinks in turn everyone else should subscribe to his list just to participate in the API discussions. If there's a single list these discussions should be happening on its dev-webapps not b2g.

This is different from most typical Mozilla discussions as it requires the participation of a broad set of stakeholders, all of whom should not be expected to subscribe to dev-b2g to participate. I realize that sucks, but it sucks less than having a minority of people participating then having to restart the conversation when all of the other stakeholders are added.

>> The following discussion is still accurate
>
> No, it has a number of basic problems, which I pointed out in an
> earlier post. Perhaps you missed it?

Huh? My link was to the discussion of the types of applications per Ben's previous question, not directly related to browser API. Sorry for the confusion.

> Here's what I'd written:
>
> ======
>
>> 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. It even displays a lock icon. You type in your
> username and password. Evil.com records it.
>
> I think it is a mistake to talk about things like preventing the
> container from injecting script into the iframe. That is only useful
> for preventing a tiny class of attacks out of many, many possible
> attacks.

In this model the untrusted browser has access to the shared cookie and password stores, right? This allows an app to load arbitrary website content and script into it, becoming a mass XSS and password stealing vector. Not something I'd want every app to have access to, and the permission dialog would have to be carefully worded to communicate the risk. Quite likely this would be unavailable to unauthenticated apps, and authenticated apps would have a pretty scary warning.

>> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including OAuth, OpenID,
>> PayPal, Facebook Connect, etc. etc.
>
> <iframe mozbrowser> is explicitly not for this. We need to be able to
> run the mozbrowser in a separate process, and that precludes any
> interaction of this sort between the parent and the child.

So is this really intended just for implementing browsers rather than interacting with content, and we can live with a fairly scary permission dialog (i.e. "has access to passwords and your private online data")?

>> [Given that the browser is built in to b2g, what would a replacement browser actually be?]
>
> The browser is built in just like the calculator app. A user could
> download another calculator app. They could also download another
> browser app (modulo security constraints).

Not as worried about calculator apps. :)
Lucas.

Justin Lebar

unread,
Apr 27, 2012, 3:13:01 PM4/27/12
to Lucas Adamski, dev-w...@lists.mozilla.org, Mounir Lamouri
If you think this discussion belongs on dev-webapps, then let's have
it there. (Personally, I think this belongs on dev-webapi, if
anywhere, but I really don't care.) All I'm asking is for us to
please pick a newsgroup, instead of continuing to send mail to four
separate lists. I think the consensus on Mounir's plea was pretty
clear, but please feel free to re-visit his thread if you still
disagree.

>> 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.  It even displays a lock icon.  You type in your
>> username and password.  Evil.com records it.
>>
>> I think it is a mistake to talk about things like preventing the
>> container from injecting script into the iframe.  That is only useful
>> for preventing a tiny class of attacks out of many, many possible
>> attacks.
>
> In this model the untrusted browser has access to the shared cookie and password stores, right?  This allows an app to load arbitrary website content and script into it, becoming a mass XSS and password stealing vector.  Not something I'd want every app to have access to, and the permission dialog would have to be carefully worded to communicate the risk.  Quite likely this would be unavailable to unauthenticated apps, and authenticated apps would have a pretty scary warning.

What I'm saying is, even if we restrict an "untrusted browser" (that
should be a contradiction in terms) from injecting script into a page,
the browser is *still* able to execute a large variety of attacks.

Thus only trusted content should be able to create browsers.

>>> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including  OAuth, OpenID,
>>> PayPal, Facebook Connect, etc. etc.
>>
>> <iframe mozbrowser> is explicitly not for this.  We need to be able to
>> run the mozbrowser in a separate process, and that precludes any
>> interaction of this sort between the parent and the child.
>
> So is this really intended just for implementing browsers rather than interacting with content, and we can live with a fairly scary permission dialog (i.e. "has access to passwords and your private online data")?

Yes.

>>> [Given that the browser is built in to b2g, what would a replacement browser actually be?]
>>
>> The browser is built in just like the calculator app.  A user could
>> download another calculator app.  They could also download another
>> browser app (modulo security constraints).
>
> Not as worried about calculator apps. :)

I was trying to explain that the browser app is not "built in to b2g"
any more than any other app is "built in to b2g". Did I answer your
question "what would a replacement browser would actually be?", or
would you like further clarification?

Lucas Adamski

unread,
Apr 27, 2012, 10:12:26 PM4/27/12
to Justin Lebar, dev-w...@lists.mozilla.org
On Apr 27, 2012, at 12:13 PM, Justin Lebar wrote:

> If you think this discussion belongs on dev-webapps, then let's have
> it there. (Personally, I think this belongs on dev-webapi, if
> anywhere, but I really don't care.) All I'm asking is for us to
> please pick a newsgroup, instead of continuing to send mail to four
> separate lists. I think the consensus on Mounir's plea was pretty
> clear, but please feel free to re-visit his thread if you still
> disagree.

dev-webapps is what we'd decided on earlier as a compromise and it splits the difference in detail level I guess. I set that as the reply-to but people ignore that and post to whatever list they're actually on. I'll try this as I simply care that we maximize the number of qualified participants, and I'm personally incurring the cost of being on all 4 lists, but means I'll still be cross-posting periodic updates to those lists as people need to be informed of progress.

> What I'm saying is, even if we restrict an "untrusted browser" (that
> should be a contradiction in terms) from injecting script into a page,
> the browser is *still* able to execute a large variety of attacks.
>
> Thus only trusted content should be able to create browsers.

Sure, that clarifies the intent, thanks. I'll update the template to reflect that this is a high threat level API and to restrict access only to trusted and certified apps.

>
>>>> [Given that the browser is built in to b2g, what would a replacement browser actually be?]
>>>
>>> The browser is built in just like the calculator app. A user could
>>> download another calculator app. They could also download another
>>> browser app (modulo security constraints).
>>
>> Not as worried about calculator apps. :)
>
> I was trying to explain that the browser app is not "built in to b2g"
> any more than any other app is "built in to b2g". Did I answer your
> question "what would a replacement browser would actually be?", or
> would you like further clarification?

Nope I'm good. That question was actually there from when we put together the template so I'm not sure who asked that originally. Thanks!
Lucas.

Lucas Adamski

unread,
Apr 27, 2012, 10:29:14 PM4/27/12
to dev-w...@lists.mozilla.org
Updated proposal. The biggest difference has been to drop a number of use cases and focus this API just on apps intent on implementing a full browser.

Please reply-to dev-w...@lists.mozilla.org

Name of API: Browser API
References:
https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
Brief purpose of API: Provide an iframe that acts as a web browser
General Use Cases: A browser app.

Inherent threats:
* browser can see all data from all websites, and perform all actions
* can steal passwords (user-entered; enumerate all saved passwords)
* can steal cookies (by enumerating websites)
* NOT a use case: OAuth or other app-content or content-content interactions

Threat severity: high per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Implement a 3rd party browser application
Authorization model: explicit
Potential mitigations: Suitably scary privilege description like "access to internet passwords and data". Could maybe maintain separate cookie and password stores from system browser, but that would be a poor experience for multi-browser users.

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Replacement Browser
Authorization model: Implicit
Potential mitigations: Explicit process to add a new browser to the system?

On Apr 15, 2012, at 11:14 PM, Lucas Adamski wrote:

> Please reply-to dev-w...@lists.mozilla.org
>
> Name of API: Browser API
> Reference: https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
>
> Brief purpose of API: Provide an iframe that acts as a web browser
> General Use Cases: None
>
> Inherent threats:
> * browser can see all data from all websites, and perform all actions
>
> Threat severity: moderate (phishing) per https://wiki.mozilla.org/Security_Severity_Ratings
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: None
> Authorization model for normal content: None
> Authorization model for installed content:None
> Potential mitigations:
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including OAuth, OpenID, PayPal, Facebook Connect, etc. etc.
> Authorization model: implicit
> Potential mitigations: container should not be able to script into browser iframe
>
> Google's recommendations about how to do this:
> http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-approval
>
> Consider also the iOS-Twitter authorization flow described here:
> http://code.google.com/p/twitter-api/issues/detail?id=1560
> and the threat, described here:
> http://www.zdnet.co.uk/blogs/tech-tech-boom-10017860/ios-url-handler-poses-significant-risk-10021042/
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Replacement Browser
> Authorization model: Implicit
> Potential mitigations: Explicit process to add a new browser to the system?
>
> [Given that the browser is built in to b2g, what would a replacement browser actually be?]
>

Ben Francis

unread,
Apr 30, 2012, 8:42:39 AM4/30/12
to Lucas Adamski, dev-w...@lists.mozilla.org
Hi Lucas,

On Sat, Apr 28, 2012 at 3:29 AM, Lucas Adamski <lada...@mozilla.com> wrote:

> Updated proposal. The biggest difference has been to drop a number of use
> cases and focus this API just on apps intent on implementing a full browser.
>
> Please reply-to dev-w...@lists.mozilla.org
>
> Name of API: Browser API
> References:
> https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
> popup windows in b2g: https://bugzilla.mozilla.org/show_bug.cgi?id=716664
> window.open in iframe mozbrowser:
> https://bugzilla.mozilla.org/show_bug.cgi?id=742944
> window.open in iframe mozapp:
> https://bugzilla.mozilla.org/show_bug.cgi?id=744451
>

Have you seen this wiki page
https://wiki.mozilla.org/WebAPI/BrowserAPIwhich supersedes
https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI ? Does your review still
apply to this proposal? It's really the same, just a bit more explicit
about scope and design. Note that there is no mention of allowing browser
apps to inject JavaScript into iframes.

I previously posted this link to dev-webapi which seemed like the right
place to discuss it ;)


>
> Brief purpose of API: Provide an iframe that acts as a web browser
> General Use Cases: A browser app.
>
> Inherent threats:
> * browser can see all data from all websites, and perform all actions
> * can steal passwords (user-entered; enumerate all saved passwords)
> * can steal cookies (by enumerating websites)
>

I don't understand how any of these things are possible with the proposed
API, but perhaps this is just due to my limited understanding of the
implementation.


> * NOT a use case: OAuth or other app-content or content-content
> interactions
>
> Threat severity: high per
> https://wiki.mozilla.org/Security_Severity_Ratings
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: None
> Authorization model for normal content: None
> Authorization model for installed content:None
> Potential mitigations:
>

I've asked this before, but does "regular web content" include apps
installed directly from the app developer's web site as opposed to through
an app directory or store, or can the user "trust" an app's origin directly
without the involvement of a third party store?

>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Implement a 3rd party browser application
> Authorization model: explicit
> Potential mitigations: Suitably scary privilege description like "access
> to internet passwords and data". Could maybe maintain separate cookie and
> password stores from system browser, but that would be a poor experience
> for multi-browser users.
>

Again, as far as I know the only information the browser will have access
to is the URLs and titles of the web pages the user visits, not passwords
and cookies.

>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Replacement Browser
> Authorization model: Implicit
> Potential mitigations: Explicit process to add a new browser to the system?
>


Paul Theriault

unread,
Apr 30, 2012, 5:33:11 PM4/30/12
to Ben Francis, dev-w...@lists.mozilla.org, Lucas Adamski
Ben,

The risks I think haven't been updated from the previous template which
was from a while ago. This approach will mitigate some of these threats,
but obviously will limit browser functionality.

On 4/30/12 10:42 PM, Ben Francis wrote:
>
> Have you seen this wiki page
> https://wiki.mozilla.org/WebAPI/BrowserAPIwhich supersedes
> https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI ? Does your review still
> apply to this proposal? It's really the same, just a bit more explicit
> about scope and design. Note that there is no mention of allowing browser
> apps to inject JavaScript into iframes.
>
> I previously posted this link to dev-webapi which seemed like the right
> place to discuss it ;)
>
Sorry, yes I did read it but didn't get a chance to review the use cases
before Lucas sent the updated version.
>> Brief purpose of API: Provide an iframe that acts as a web browser
>> General Use Cases: A browser app.
>>
>> Inherent threats:
>> * browser can see all data from all websites, and perform all actions
>> * can steal passwords (user-entered; enumerate all saved passwords)
>> * can steal cookies (by enumerating websites)
>>
> I don't understand how any of these things are possible with the proposed
> API, but perhaps this is just due to my limited understanding of the
> implementation.
>
I think you are right - the risks are probably reduced with this
approach. So does this mean no password managers and no cookie
management in b2g browsers? As for content - the "find" feature would
rely on access to at least all "findable" content wouldn't it? (even if
not directly, it could be extracted I think?)
>> * NOT a use case: OAuth or other app-content or content-content
>> interactions
>>
>> Threat severity: high per
>> https://wiki.mozilla.org/Security_Severity_Ratings
>>
>> == Regular web content (unauthenticated) ==
>> Use cases for unauthenticated code: None
>> Authorization model for normal content: None
>> Authorization model for installed content:None
>> Potential mitigations:
>>
> I've asked this before, but does "regular web content" include apps
> installed directly from the app developer's web site as opposed to through
> an app directory or store, or can the user "trust" an app's origin directly
> without the involvement of a third party store?
I asked this previously and the answer I got was that self-installed
websites wouldn't be able to get higher level permissions.
But if this is desired, then I think the answer is that there is some
process for granting trust to a self-installed web app, such that it is
considered Trusted. Not sure what this process would be though
(something stronger than just a permissions dialog I would expect)

Ben Francis

unread,
May 2, 2012, 6:45:53 AM5/2/12
to Paul Theriault, dev-w...@lists.mozilla.org, Lucas Adamski
On Mon, Apr 30, 2012 at 10:33 PM, Paul Theriault <pther...@mozilla.com>wrote:

> I think you are right - the risks are probably reduced with this approach.
> So does this mean no password managers and no cookie management in b2g
> browsers?


These features are not currently scheduled for v1 of the browser app. There
is a requirement to be able to "clear private
data<https://github.com/andreasgal/gaia/issues/1234>"
including cookies, cache and offline data, but this will be system-wide and
not specific to the browser app. I don't think this should be part of the
browser API because it isn't browser-specific (all apps can have cookies)
but I don't know where it should live.


> As for content - the "find" feature would rely on access to at least all
> "findable" content wouldn't it? (even if not directly, it could be
> extracted I think?)


This also isn't a requirement, yet. This is definitely a tricky feature to
implement and we've discussed it before but I would prefer to focus on the
confirmed use cases first to make sure we don't build something that isn't
needed (this could turn out to be part of the platform rather than the
responsibility of any app for example, as many apps could benefit from this
feature).


> I asked this previously and the answer I got was that self-installed
> websites wouldn't be able to get higher level permissions.
> But if this is desired, then I think the answer is that there is some
> process for granting trust to a self-installed web app, such that it is
> considered Trusted. Not sure what this process would be though (something
> stronger than just a permissions dialog I would expect)


My understanding of Open Web Apps is that anyone should be able to host
their own app, without the involvement of a third party, the user can
simply grant trust to the origin the app is being served from. Given that
anyone can run their own app directory or app store, requiring that a
"trusted" app be installed via a directory or store doesn't seem to add any
extra protection in terms of security, just added complication for
independent app developers.

A third party app store can "vouch" for an app, or provide an indication of
quality through user ratings which can help users to make a decision, but
ultimately the user is expressing trust in the origin the app is served
from, right?

So, shouldn't I be able to install a browser app directly from
www.trustedbrowser.com if I trust the owners of that origin, without the
involvement of www.someappstore.com ?

Jim Straus

unread,
May 2, 2012, 12:05:32 PM5/2/12
to Ben Francis, dev-w...@lists.mozilla.org, Paul Theriault, Lucas Adamski
I think the idea is that the runtime (B2G, Fennec) will have public keys for a set of stores that are "trusted", just like browsers have a set of trusted certs for SSL. Other stores or sites wil be able to offer "untrusted" apps. The user can explicitly grant trust to "untrusted" apps, as Lucas outlines in his email of app types. I don't know if there is a way to add the public key for a new store, but it should be a non-trivial process (not just click an "ok" button on a dialog) so we can make sure the user knows the risks they take by adding in the key. On the other hand, it should be possible so that a store or site can test the process. I also figure that we will expand the list of installed keys over time in updates to Gecko.
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps

Lucas Adamski

unread,
May 4, 2012, 9:28:15 PM5/4/12
to Ben Francis, dev-w...@lists.mozilla.org, Paul Theriault
On May 2, 2012, at 3:45 AM, Ben Francis wrote:

> This also isn't a requirement, yet. This is definitely a tricky feature to implement and we've discussed it before but I would prefer to focus on the confirmed use cases first to make sure we don't build something that isn't needed (this could turn out to be part of the platform rather than the responsibility of any app for example, as many apps could benefit from this feature).

Not allowing the container to have access to the content inside the browser definitely reduces the risk tremendously but also limits a lot of potential use cases. Find is one of them but also typical browser features like adblocking, content blocking, content augmentation, etc. Basically means no add-ons for 3rd party browsers. I'm ok with that, but I suspect we'll come under a lot of pressure to permit this. Happy to keep this out of 1.0 though.

> My understanding of Open Web Apps is that anyone should be able to host their own app, without the involvement of a third party, the user can simply grant trust to the origin the app is being served from. Given that anyone can run their own app directory or app store, requiring that a "trusted" app be installed via a directory or store doesn't seem to add any extra protection in terms of security, just added complication for independent app developers.

Trusted apps are different in a number of respects as documented in the "types of applications thread" (I'm also going to post this to the wiki to capture this more thoroughly). Trusted apps have an explicit list of assets that is code reviewed and approved by an app store. Only code enumerated in the manifest has access to granted privileges, etc. Untrusted and trusted apps differ significantly beyond whether they went though an app store or not.

> A third party app store can "vouch" for an app, or provide an indication of quality through user ratings which can help users to make a decision, but ultimately the user is expressing trust in the origin the app is served from, right?

Or in the app store and review process. That said I think you can still build very rich apps with untrusted apps, so I don't think we should frame this as an app store being required to build a great app.
Lucas.


Paul Theriault

unread,
Jun 4, 2012, 1:51:51 AM6/4/12
to dev-se...@lists.mozilla.org, dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, Mozilla B2G mailing list
(Final proposal, please reply to dev-w...@lists.mozilla.org by COB
Jun 04)

Only change here was to change trusted apps from explicit to implicit,
acknowledging that trusted and certified apps will now have separate
profile based resources (cookie jars, localstorage, app-cache etc)
Brief purpose of API: Provide an iframe that acts as a web browser
General Use Cases: A browser app.

Inherent threats:
* browser can see all data from all websites, and perform all actions
* can steal passwords (user-entered; enumerate all saved passwords)
* can steal cookies (by enumerating websites)
* NOT a use case: OAuth or other app-content or content-content interactions

Threat severity: high per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Implement a 3rd party browser application
Authorization model: Implicit
Potential mitigations: Each app has separate cookie and password stores
from other apps (including system browser app)

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Replacement Browser
Authorization model: Implicit
Potential mitigations:


Reply all
Reply to author
Forward
0 new messages