== 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

Re: WebAPI Security Discussion: Browser API

> 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.

Re: [b2g] WebAPI Security Discussion: Browser API

> 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.

Re: [b2g] WebAPI Security Discussion: Browser API

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).

Re: WebAPI Security Discussion: Browser API

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

> 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.
>
>