diff --git a/index.html b/index.html index c976201..d5876ad 100644 --- a/index.html +++ b/index.html @@ -70,9 +70,9 @@ The figure shows the overlap between traditional web applications, hosted web applications, and packaged applications. Web applications make use of standard Web technologies but don't make use of an - application manifest. On the other hand, hosted applications make use - of an application manifest, while packaged applications have both an - application manifest and are packaged using [[!ZIP]]. + application manifest. On the other hand, hosted web applications make + use of an application manifest, while packaged applications have both + an application manifest and are packaged using [[!ZIP]].

@@ -600,8 +600,8 @@

  • If present is true:
    1. Let value be the result of calling the - [[\GetOwnProperty]] internal method of manifest passing - key as the argument. + [[\GetOwnProperty]] internal method of manifest + passing key as the argument.
    2. Let tag be ToString(value).
      3. @@ -1106,6 +1106,189 @@

      +
      +

      + Media Type +

      +

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

      +
      +
      + Type name: +
      +
      + application +
      +
      + Subtype name: +
      +
      + webapp-manifest+json +
      +
      + Required parameters: +
      +
      + N/A +
      +
      + Optional parameters: +
      +
      + N/A +
      +
      + Encoding considerations: +
      +
      + Same as for application/json +
      +
      + 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: +
      +
      + Web browsers +
      +
      + 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: +
      +
      + The System + Applications Working Group can be contacted at public-sysapps@w3.org. +
      +
      + Intended usage: +
      +
      + COMMON +
      +
      + Restrictions on usage: +
      +
      + none +
      +
      + Author: +
      +
      + W3C's System Application Working Group. +
      +
      + Change controller: +
      +
      + W3C. +
      +
      +

      @@ -1867,7 +2050,7 @@

      Manifest

      - Inside an application package, the valid application manifest + Inside a packaged application, the valid application manifest filename is manifest.webapp.