Re: Manifest format MIME type

On Tuesday, 26 February 2013 at 17:40, Fabrice Desre wrote:

> Hi Marcos,
> 
> On 02/26/2013 06:05 AM, Marcos Caceres wrote:
> > For the application manifest, the runtime spec currently defines a MIME type and an API for installing applications. Is it envisioned that a user agent can will acquire an install URL from an external source (and thus not rely on the API, but instead depend purely the MIME type)? 
> > 
> > If no, meaning that only the API (install() method) must be used to install an application, then it seems unlikely we will need the MIME type. 
> 
> In Gecko we check the mime type for cross-origin installs, and there's
> also a bug open to trigger an install() call when we fetch a resource
> from this type: https://bugzilla.mozilla.org/show_bug.cgi?id=756976
> 

Ok, it's good to have confirmation that this is more or less implemented. 

Next part of then is settling on a MIME type name (yay! bikeshed time:). The current one is not suitable for registration. 

Can I propose: webapp-manifest+json

Here is the complete registration text (I'll send as a pull request once we sort out the editorial process):

[[
This section contains the required text for MIME media type registration with IANA. 

The MIME media type for Web App Manifests text is application/webapp-manifest+json.

Type name:
application

Subtype name:
webapp-manifest+json

Required parameters:
n/a

Optional parameters:
n/a

Encoding considerations:
8bit if UTF-8; binary if UTF-16 or UTF-32

Security considerations:
As the application manifest format is JSON and will commonly be encoded using [[!!Unicode]], the security considerations described in [[!JSON]] and [[!UTR36]] apply. In addition, implementers need to impose their own implementation-specific limits on the values of otherwise unconstrained member types, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

The manifest document allows authors, through the permissions and required_features, to request permission to enable security sensitive APIs. As these APIs are outside the scope of this specification, significant caution needs to be taken when granting an application the capability to use a feature. Features themselves define their own security considerations.

Web applications will generally contain ECMAscript, HTML, CSS files, and other media, which are executed in a sand-boxed environment. As such, implementers need to be aware of the security implications for the types they support. Specifically, implementers need to consider the security implications outlined in the [[!CSS-MIME]] specification, the [[!ECMAScript-MIME]] specification, and the [[!HTML-MIME]] specification.

As web applications can contain content that is able to simultaneously interact with the local device and a remote host, implementers need to consider the privacy implications resulting from exposing private information to a remote host. Mitigation and in-depth defensive measures are an implementation responsibility and not prescribed by this specification. However, in designing these measures, implementers are advised to enable user awareness of information sharing, and to provide easy access to interfaces that enable revocation of permissions.

As this specification relies on the standardized heuristics for determining the content type of files defined in the [[!SNIFF]] specification, implementers need to consider the security considerations discussed in the [[!SNIFF]] specification.

As this specification allows for the declaration of IRIs within certain members of a the application manifest, implementers need to consider the security considerations discussed in the [IRI] specification. Implementations intending to display IRIs and IDNA addresses found in the application manifest are strongly encouraged to follow the security advice given in [[!UTR36]]. 

In addition, user agents need to be careful about trusting path components found in the manifest. Such path components might be interpreted by operating systems as pointing at security critical files outside the browsing environment proper, and naive unpacking of zip packages into the file system might lead to undesirable and security relevant effects, such as overwriting of system files.


Applications that use this media type:
FireFox OS, ?? 

Additional information:

Magic number(s):
n/a

File extension(s):
.webapp

Macintosh file type code(s):
TEXT

Person & email address to contact for further information:
....

Intended usage:
Common

Restrictions on usage:
none

Author:
W3C's System Application Working Group.

Change controller:
W3C's System Application Working Group.



]]

-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 26 February 2013 17:54:45 UTC