(Final proposal, please reply to dev-weba...@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)
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
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:
On 5/5/12 11:28 AM, Lucas Adamski wrote:
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.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
