Apps/Security/Definitions

Definitions

• WebApp - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content (i.e. may make use of eval, script injection as in body.appendChild(createNode("script")) etc.)
• Native App - A WebApp consisting solely of static content (no script injection or use of eval) and run on a B2G capable device
• Gaia App - DEFINITION REQUIRED
• B2G App - DEFINITION REQUIRED which is meaningful in the context of the above app definitions
• "bookmarked website" - DEFINITION REQUIRED
• Store - A marketplace where a user may download/purchase WebApps for their device
• above definition are up for discussion
• Extended Validation (EV) Certificate - A SSL certificate that undergoes additional authentication / verification steps before issuance.
  • Explanation
  • Verification process
• Content Security Policy (CSP) - A mechanism by which website administrators can define a policy which restricts what domains a website can load resources from
  • Specification
• XPCOM - a Common Object Model that is 'inspired by' Microsoft's COM. It is reasonably feature-complete but does not contain co-classes. The implementation is also entirely missing a marshalling / unmarshalling (serialisation) layer.
• ncalrpc - a local networking protocol that is used in Microsoft's COM to efficiently communicate (marshalled and unmarshalled) function call parameters between COM clients and COM servers that are on the same machine. http://msdn.microsoft.com/en-us/library/windows/desktop/aa378665%28v=vs.85%29.aspx

Important reading! B2G applications are Open Web Apps, you can read about them here: https://developer.mozilla.org/en-US/apps

Concepts to be given Official Definitions

There is no real easy way to distinguish the following, all of which are iframes (!) in the B2G environment. There is some considerable confusion as a result, especially due to the fact that the required security context and especially the interactions between parent and child iframes are different depending on the type of iframe.

Names really therefore need to be given to the following:

• the root frame (top-level one into which the top gaia HTML is loaded)
• individual gaia apps (sub-iframes, one per app)
• any gaia app that opens up a public-facing (URL-based) iframe in which the contents of a URI are displayed: the browser app is one such
• iframes *within* that iframe - as in "iframes that you normally think of iframes being used for as an ordinary web developer".

Discussion which raises the issue of confused definitions, helps clarify them: https://groups.google.com/d/msg/mozilla.dev.b2g/AQYPkIjKxjE/WYy0LPta9cMJ

Another discussion which mentions "bookmarked website": https://groups.google.com/d/msg/mozilla.dev.b2g/PFaN9HjGkmY/cXTAkRPaGecJ

App instance / version

(Note: this section is very much in an informal style that includes definitions, discussion as well as functional analysis. it should be analysed and split up appropriately.)

• Possible definitions of what an app instance / version is
  1. a static bundle of code authenticated by manifest + signature (or equivalent)
  2. a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)
  3. an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants
  4. unauthenticated code loaded over any channel, from any origin
• loosely ordered from best to worst (descending) security wise
• 1) and 2) could work with additional security controls
• attacker can use option 2) as a proxy for malicious content
• attacker can use option 2) as proxy to paid app (buy once, share with world)
  • mitigation for this may be responsibility of app developer
• CSP can secure 1) and 2) to an extent
  • define baseline CSP policy that apps have to adopt
• See Intro to AIR security