From f50f638cc0eef0020e9df47ea4c515aa5b3f7c58 Mon Sep 17 00:00:00 2001
From: Marcos Caceres
+ This section contains the required text for MIME media type + registration with IANA. +
+
+ The media type for an application manifests is
+ application/webapp-manifest+json
.
+
+ If the protocol over which the manifest is transferred supports the + [[!MIME]] specification (e.g. [[!HTTP11]]), it is RECOMMENDED that + the application manifest be labeled with the media type for an + application manifests. +
++ 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. +
+
From 250aa293c2e99456d89fd7d6bf6a1a6018c5f9bb Mon Sep 17 00:00:00 2001
From: Marcos Caceres
- Inside an application package, the valid application manifest
+ Inside a packaged application, the valid application manifest
filename is
Manifest
manifest.webapp
.