`dir` member

The [=manifest's=] dir member specifies the default direction for the [=localizable members=] of the [=manifest=]. The [=manifest/dir=] member's value can be set to a [=text-direction=].

The text-directions are the following, implying that the value of the [=localizable members=] is by default:

"ltr"

Left-to-right text.

"rtl"

Right-to-left text.

"auto" (default)

Text direction is unknown. The user agent should use heuristics to estimate the display of the text, for example the first-strong algorithm as described in [[UAX9]].

The text-direction list is the [=list=] « "[=text-direction/ltr=]", "[=text-direction/rtl=]", "[=text-direction/auto=]" ».

To process the `dir` member, given [=ordered map=] |json:ordered map| and [=ordered map=] |manifest:ordered map|:

1. Set |manifest|["dir"] to "auto".
2. If |json|["dir"] doesn't [=map/exist=] or if |json|["dir"] is not a [=string=], return.
3. [=Strip leading and trailing ASCII whitespace=] from |json|["dir"].
4. [=ASCII lowercase=] |json|["dir"].
5. If [=text-direction list=] doesn't [=list/contain=] |json|["dir"], return.
6. Set |manifest|["dir"] to |json|["dir"].

`lang` member

The [=manifest's=] lang member is a [=string=] in the form of a [=language tag=] that specifies the language for the values of the manifest's [=localizable members=]. If the `lang` member is not specified, the language is treated as unknown.

Specifying the language improves the user experience by helping user agents select the most appropriate processing or resources, such as fonts, styling, hyphenation, or text-to-speech voices for accessibility.

A language tag is a [=string=] that matches the production of a well-formed `Language-Tag` defined in [[BCP47]].

Language tags are case-insensitive. Examples of language tags include '`fr`' (French), '`en-AU`' (English as spoken in Australia), or '`zh-Hans-CN`' (Chinese as written in the Simplified Han script as spoken in China).

To process the `lang` member, given [=ordered map=] |json:ordered map| and [=ordered map=] |manifest:ordered map|:

1. If |json|["lang"] doesn't [=map/exist=] or if |json|["lang"] is not a [=string=], return.
2. [=Strip leading and trailing ASCII whitespace=] from |json|["lang"].
3. If calling IsStructurallyValidLanguageTag with |json|["lang"] returns `false`, return.
4. [=Map/Set=] |manifest|["lang"] to the result of calling the CanonicalizeUnicodeLocaleId abstract operation with |json|["lang"].

`name` member

The [=manifest's=] name member is a string that represents the name of the web application as it is usually displayed to the user (e.g., amongst a list of other applications, or as a label for an icon).

The [=manifest/name=] member is a [=localizable member=].

The [=manifest/name=] member serves as the accessible name of an [=installed web application=].

When [=processing a manifest=], the [=process a text member=] algorithm is used to process the [=manifest/name=] member.

`short_name` member

The [=manifest's=] short_name member is a string that represents a short version of the name of the web application. It is intended to be used where there is insufficient space to display the full name of the web application.

The [=manifest/short_name=] member is a [=localizable member=].

When [=processing a manifest=], the [=process a text member=] algorithm is used to process the [=manifest/short_name=] member.

`scope` member

The [=manifest's=] scope member is a string that represents the [=manifest/navigation scope=] of this web application's application context.

To process the `scope` member, given [=ordered map=] |json:ordered map| and [=ordered map=] |manifest:ordered map|:

1. Set |manifest|["scope"] to the result of [=URL Parser|parsing=] "." with |manifest|["start_url"] as the base URL.
2. If |json|["scope"] is the empty string, then return.
3. Let |scope:URL| be the result of [=URL Parser|parsing=] |json|["scope"] with |manifest URL| as the base URL.
4. If |scope| is failure, return.
5. Set |scope|'s [=URL/query=] and [=URL/fragment=] to null.
6. If |manifest|["start_url"] is not [=URL/within scope=] of |scope|, return.
7. Otherwise, set |manifest|["scope"] to |scope|.

`icons` member

The [=manifest's=] icons member are images that serve as iconic representations of the web application in various contexts. For example, they can be used to represent the web application amongst a list of other applications, or to integrate the web application with an OS's task switcher and/or system preferences.

The [=manifest/icons=] member is a [=localizable member=].

`display` member

The [=manifest's=] display member represents the developer's preferred display mode for the web application. Its value is a [=display mode=].

To process the `display` member, given [=ordered map=] |json:ordered map| and [=ordered map=] |manifest:ordered map|:

1. Set |manifest|["display"] to "browser".
2. If |json|["display"] doesn't [=map/exist=] or |json|["display"] is not a a [=string=], return.
3. [=Strip leading and trailing ASCII whitespace=] from |json|["display"].
4. [=ASCII lowercase=] |json|["display"].
5. If [=display modes list=] doesn't [=list/contain=] |json|["display"], return.
6. Set |manifest|["display"] to |json|["display"].

`orientation` member

The [=manifest's=] orientation member is a string that serves as the default screen orientation for all top-level browsing contexts of the web application. The possible values are those of the {{OrientationLockType}} enum, which in this specification are referred to as the orientation values (i.e., "any", "natural", "landscape", "portrait", "portrait-primary", "portrait-secondary", "landscape-primary", or "landscape-secondary").

If the user agent supports the value of the [=manifest/orientation=] member as the default screen orientation, then that serves as the default screen orientation for the life of the web application (unless overridden by some other means at runtime). This means that the user agent MUST return the orientation to the default screen orientation any time the orientation is unlocked [[SCREEN-ORIENTATION]] or the top-level browsing context is navigated.

Although the specification relies on the [[SCREEN-ORIENTATION]]'s {{OrientationLockType}}, it is OPTIONAL for a user agent to implement the [[SCREEN-ORIENTATION]] API. Supporting the [[SCREEN-ORIENTATION]] API is, of course, encouraged.

Certain UI/UX concerns and/or platform conventions will mean that some screen orientations and cannot be used together. Which orientations and display modes cannot be used together is left to the discretion of implementers. For example, for some user agents, it might not make sense to change the default screen orientation of an application while in `browser` display mode.

Once the web application is running, other means can change the orientation of a top-level browsing context (such as via [[SCREEN-ORIENTATION]] API).

To process the `orientation` member, given [=ordered map=] |json:ordered map| and [=ordered map=] |manifest:ordered map|:

1. If |json|["orientation"] doesn't [=map/exist=] or |json|["orientation"] is not a [=string=], return.
2. [=Strip leading and trailing ASCII whitespace=] from |json|["orientation"].
3. [=ASCII lowercase=] |json|["orientation"].
4. If |json|["orientation"] doesn't [=list/contain=] any of the [=orientation values=], return.
5. Set |manifest|["orientation"] to |json|["orientation"].

`start_url` member

The [=manifest's=] start_url member is a string that represents the start URL , which is URL that the developer would prefer the user agent load when the user launches the web application (e.g., when the user clicks on the icon of the web application from a device's application menu or homescreen).

The [=manifest/start_url=] member is purely advisory, and a user agent MAY ignore it or provide the end-user the choice not to make use of it. A user agent MAY also allow the end-user to modify the URL when, for instance, a bookmark for the web application is being created or any time thereafter.

To process the `start_url` member, given [=ordered map=] |json:ordered map|, [=ordered map=] |manifest:ordered map|, [=URL=] |manifest URL:URL|, and [=URL=] |document URL:URL|:

1. Set |manifest|["start_url"] to |document URL|.
2. If |json|["start_url"] doesn't [=map/exist=] or |json|["start_url"] is not a [=string=], return.
3. If the type of |json|["start_url"] is not [=string=], or if |json|["start_url"] is the empty string, return.
4. Let |start URL:URL| be the result of [=URL Parser|parsing=] |json|["start_url"], using |manifest URL| as the base URL.
5. If |start URL| is failure, return.
6. If |start URL| is not same origin as |document URL|, return.
7. Otherwise, set |manifest|["start_url"] to |start URL|.

`id` member

The [=manifest's=] id member is a string that represents the identity for the application. The [=identity=] takes the form of a URL, which is same origin as the [=start URL=].

The [=identity=] is used by user agents to uniquely identify the application universally. When the user agent sees a manifest with an [=identity=] that does not correspond to an already-installed application, it SHOULD treat that manifest as a description of a distinct application, even if it is served from the same URL as that of another application. When the user agent sees a manifest where |manifest|["id"] is [=url/equal=] (with [=URL/equals/exclude fragments=] OPTIONALLY set to true) to the [=identity=] of an already-installed application, it SHOULD be used as a signal that this manifest is a replacement for the already-installed application's manifest, and not a distinct application, even if it is served from a different URL than the one seen previously.

The [=identity=] can be used by a service that collects lists of web applications to uniquely identify applications.

The [=identity=] is processed like a URL but it doesn't point to a resource that can be navigated to, so it's not required to be [=URL/within scope=].

To process the `id` member, given [=ordered map=] |json:JSON|, [=ordered map=] |manifest:ordered map|:

1. Set |manifest|["id"] to |manifest|["start_url"].
2. If the type of |json|["id"] is not [=string=], return.
3. If |json|["id"] is the empty string, return.
4. Let |base origin| be |manifest|["start_url"]'s [=url/origin=].
5. Let |id:URL| be the result of [=URL Parser|parsing=] |json|["id"] with |base origin| as the base URL.
6. If |id| is failure, return.
7. If |id| is not [=same origin=] as |manifest|["start_url"], return.
8. Set |id|'s [=URL/fragment=] to null.
9. Set |manifest|["id"] to |id|.

`theme_color` member

The [=manifest's=] theme_color member serves as the default theme color for an application context. What constitutes a theme color is defined in [[HTML]].

If the user agent honors the value of the [=manifest/theme_color=] member as the [=default theme color=], then that color serves as the [=theme color=] for all [=browsing contexts=] to which the manifest is [=applied=]. However, the user agent MAY override the [=default theme color=] if a [=document=] whose [=Document/URL=] is [=URL/within scope=] of the [=application context=]'s [=manifest=] includes a [^meta^] element whose [^meta/name^] attribute is "[^meta/name/theme-color^]". However, the user agent SHOULD NOT override the [=default theme color=] via a [^meta^] element whose [^meta/name^] attribute is "theme-color" for [=documents=]' [=Document/URL=] are not [=URL/within scope=], since the application has no control over these documents.

The user agent MAY ignore the theme color's [=alpha component=] based on the context. For example, in most environments, the theme color cannot be transparent.

Implementors MAY override the value defined by the [=manifest/theme_color=] member to support prefers-color-scheme.

When [=processing a manifest=], the [=process a color member=] algorithm is used to process the [=manifest/theme_color=] member.

`background_color` member

The [=manifest's=] `background_color` member describes the expected background color of the web application. It repeats what is already available in the application stylesheet but can be used by the user agent to draw the background color of a web application for which the manifest is known before the files are actually available, whether they are fetched from the network or retrieved from disk.

The [=manifest/background_color=] member is only meant to improve the user experience while a web application is loading and MUST NOT be used by the user agent as the background color when the web application's stylesheet is available.

Implementors MAY override the value defined by the [=manifest/background_color=] member to support prefers-color-scheme.

When [=processing a manifest=], the [=process a color member=] algorithm is used to process [=manifest/background_color=] member.

`shortcuts` member

The [=manifest's=] shortcuts member is an [=list=] of shortcut items that provide access to key tasks within a web application.

How shortcuts are presented, and how many of them are shown to the user, is at the discretion of the user agent and/or operating system.

To process the `shortcuts` member, given [=ordered map=] |json:ordered map|, [=ordered map=] |manifest:ordered map|, and [=URL=] |manifest URL:URL|:

1. Let |processedShortcuts:list| be a new [=list=].
2. [=Map/Set=] |manifest|["shortcuts"] to |processedShortcuts|.
3. If |json|["shortcuts"] doesn't [=map/exist=] or |json|["shortcuts"] is not a [=list=], return.
4. [=list/For each=] |entry:ordered map| of |json|["shortcuts"]:
   1. Let |shortcut:ordered map| be [=process a shortcut=] with |entry|, |manifest URL|, |manifest|["scope"], and |manifest|["dir"].
   2. If |shortcut| is failure, continue.
   3. [=list/Append=] |shortcut| to |processedShortcuts|.

A user agent SHOULD expose shortcuts via interactions that are consistent with exposure of an application icon's context menu in the host operating system (e.g., right click, long press). A user agent SHOULD render the shortcuts in the same order as they are provided in the manifest. A user agent SHOULD represent the shortcuts in a manner consistent with exposure of an application icon's context menu in the host operating system. A user agent MAY truncate the list of shortcuts presented in order to remain consistent with the conventions or limitations of the host operating system.

`*_localized` members

A localizable member is a [=manifest=] member that can be localized. Each [=localizable member=] of the [=manifest=] has a corresponding *_localized member, where `*` represents the member name.

A language map is an [=ordered map=] whose key is a [=language tag=] and whose value is a [=localized value=]. The localized value is content localized in the language given by the key.

The value assigned to the [=localizable member=] is the default representation. [=manifest/*_localized=] members contain a [=language map=] that defines [=localized values=] for the given [=localizable member=] in the application. The user agent SHOULD use the user's localization settings to select the [=localized value=] whose [=language tag=] key best matches the user's preference. When no such [=localized value=] is available, the [=localizable member/default representation=] is used.

Manifest life-cycle

This section defines algorithms for [=processing a manifest=], and applying a manifest.

A user agent MUST support the link type "manifest" and the associated steps for how to fetch and process the linked resource.

`purpose` member

The purpose member is an unordered set of unique space-separated tokens. The allowed values are the icon purposes.

When a [=manifest image resource=] is used as an icon, a developer can hint that the image is intended to serve some special purpose in the context of the host OS (i.e., for better integration). User agents SHOULD NOT use an icon other than for its stated icon purpose.

For example, an icon with purpose "[=icon purpose/monochrome=]" could be used as a badge or pinned icon with a solid fill, visually distinct from an application's full color launch icon. The user agent uses the value of the [=manifest image resource/purpose=] member as a hint to determine where and how an [=manifest image resource/purpose=] is displayed. Unless declared otherwise by the developer, a user agent can use an icon for [=icon purpose/any|any purpose=].

The icon purposes are as follows:

monochrome

A user agent can present this icon where a monochrome icon with a solid fill is needed. The color information in the icon is discarded and only the alpha data is used. The icon can then be used by the user agent like a mask over any solid fill.

maskable

The image is designed with icon masks and safe zone in mind, such that any part of the image that is outside the safe zone can safely be ignored and masked away by the user agent.

any (default)

The user agent is free to display the icon where no [=manifest image resource/purpose=] is required. For example, a [=manifest image resource=] with a "any" purpose wouldn't be used in a context where "[=icon purpose/monochrome=]" is required.

The icon purposes list is the [=list=] « "[=icon purpose/monochrome=]", "[=icon purpose/maskable=]", "[=icon purpose/any=]" ».

If an icon contains multiple purposes, it could be used for any of those purposes. If none of the stated purposes are recognized, the icon is totally ignored. For example, if an icon has purpose `"monochrome fizzbuzz"`, then it could be used as a monochrome icon, as `"monochrome"` is a valid purpose. However, if an icon just has the purpose `"fizzbuzz"`, then it will be ignored.

To determine the purpose of an image, given [=ordered map=] |json:image|:

1. If |json|["purpose"] doesn't [=map/exist=] or if |json|["purpose"] is not a [=string=]:
   1. Return [=set=] « "any" ».
2. Let |keywords:list<string>| be the result of [=split on ASCII whitespace=] |json|["purpose"].
3. Let |purposes:set| be new [=set=].
4. [=set/For each=] |keyword:string| of |keywords|:
   1. If [=icon purposes list=] doesn't [=list/contain=] |keyword|, then [=iteration/continue=].
   2. Otherwise, [=set/append=] |keyword| to |purposes|.
5. If |purposes| [=list/is empty=], then return failure.
6. Return |purposes|.

Content security policy

The security policy that governs whether a user agent can fetch an icon image is governed by the `img-src` directive [[CSP3]] associated with the manifest's owner {{Document}}.

Icon masks and safe zone

Some platforms have their own preferred icon shape, but as web applications should work across multiple platforms, it is possible to indicate that an icon can have a user-agent-specified mask applied by adding the [=icon purpose/maskable=] purpose. This allows the platform to ensure that the icon looks well integrated with the platform, and even apply different masks and background colors in different places throughout the platform.

The safe zone is the area within a [=icon purpose/maskable=] icon which is guaranteed to always be visible, regardless of user agent preferences. It is defined as a circle with center point in the center of the icon and with a radius of 2/5 (40%) of the icon size, which means the smaller of the icon width and height, in case the icon is not square.

Designers of [=icon purpose/maskable=] icons will want to make sure that all important parts are within the safe zone.

All pixels in this zone are guaranteed to be seen in all masks. Pixels outside the safe zone are not guaranteed to (but can) be visible depending on the applied mask.

The user agent MAY apply a mask of any size, making any pixels that are more than 2/5ths of the image size (minimum of width and height if non-square) away from the center (the safe zone) transparent.

The user agent MUST NOT make any pixel within the safe zone transparent.

The user agent MAY enlarge the icon by adding additional padding.

If the icon contains transparent pixels, the user agent MUST composite the icon onto a solid fill (e.g., white) of the user agent's choice.

It is suggested that designers avoid using transparent pixels in maskable icons.

Examples of masks

By staying inside the safe zone, most icons will have around 10% padding on the top, bottom, right and left with no content or non-essential content, such as an icon background. It is suggested that developers check their icon when all but the safe zone is masked out.

Icons with "maskable" purpose

Mask examples

Monochrome icons and solid fills

Some platforms enforce that icons be displayed with a solid fill such as a single color, where only the transparency of the icon can be declared in a [=manifest=]. As web applications need to work across multiple platforms, it is possible to indicate that an icon can have an user-agent-specified color applied by adding the [=icon purpose/monochrome=] purpose. This allows the platform to ensure that the icon looks well integrated with the platform, and even apply different colors and padding in different places throughout the platform.

When presenting a [=icon purpose/monochrome=] icon, the user agent MUST NOT independently display the red component, green component, or blue component of a pixel. The user agent SHOULD display each pixel with its original alpha value, but with a red, green, and blue value of the user agent's choosing. It is RECOMMENDED that the user agent use the same color value for all pixels.

Designers of [=icon purpose/monochrome=] icons could set all pixels to black and only use transparency to create a silhouette of their icon.

The user agent MAY enlarge the icon by adding additional padding.

The user agent MAY add a background of any color behind transparent pixels, and SHOULD ensure that the background has sufficient contrast with the icon.

Example usage of monochrome icons

Usage examples

Processing image resources

To process image resources, given [=list=] |images:list|, [=ordered map=] |map:ordered map|, |manifest URL:URL| and [=string=] |member:string|:

1. Let |imageResources:List<Image Resources>| be a new [=list=].
2. Set |map|[member] to |imageResources|.
3. If |images| is not [=list=], return.
4. [=list/For each=] |potential image:Manifest image resource| of |images|:
   1. Let |image:ordered map| be the result of running [=process an image resource from JSON=] given |potential image| and |manifest URL|.
   2. If |image| is failure, [=iteration/continue=].
   3. Let |purposes:set| be [=determine the purpose of an image=] passing |potential image|.
   4. If |purposes| is failure, [=iteration/continue=].
   5. Set |image|["purpose"] to |purposes|.
   6. [=list/Append=] |image| to |imageResources|.

`name` member

The [=shortcut item's=] name member is a string that represents the name of the shortcut as it is usually displayed to the user in a context menu.

The [=shortcut item/name=] member is a [=localizable member=].

`short_name` member

The [=shortcut item's=] short_name member is a string that represents a short version of the name of the shortcut. It is intended to be used where there is insufficient space to display the full name of the shortcut.

The [=shortcut item/short_name=] member is a [=localizable member=].

`description` member

The [=shortcut item's=] description member is a string that allows the developer to describe the purpose of the shortcut. User agents MAY expose this information to assistive technology.

The [=shortcut item/description=] member is a [=localizable member=].

`url` member

The [=shortcut item's=] url member is a URL [=manifest/within scope=] of a [=Document/processed manifest=] that opens when the associated shortcut is activated.

`icons` member

The shortcut item's icons member lists images that serve as iconic representations of the shortcut in various contexts.

The [=shortcut item/icons=] member is a [=localizable member=].

Launching a shortcut

When shortcut item shortcut having manifest is invoked, run the steps to [=launch a web application=] with manifest and shortcut.url.

Processing shortcut items

To process a shortcut, given [=ordered map=] |item:ordered map|, [=URL=] |manifest URL:URL|, [=URL=] |scope:URL|, and [=text-direction=] |defaultDirection:string|:

1. Return failure if it's the case that:
   • |item| is not [=ordered map=].
   • |item|["name"] doesn't [=map/exist=].
   • |item|["name"] is the empty string.
   • |item|["url"] doesn't [=map/exist=].
   • |item|["url"] is not a [=string=].
2. Let |url:URL| be the result of [=URL Parser|parsing=] |item|["url"] with |manifest URL| as the base URL.
3. If |url| is failure, return failure.
4. If |url| is not [=manifest/within scope=] of |scope|, return failure.
5. Let |shortcut:ordered map| be |ordered map| «[ "url" → |url|, "name" → |item|["name"] ]».
6. [=Process a `*_localized` text member=] passing |item|, |shortcut|, "name_localized", and |defaultDirection|.
7. If "short_name" [=map/exists=] in |item|, and |item|["short_name"] is a [=string=], [=map/set=] |shortcut|["short_name"] to |item|["short_name"].
8. [=Process a `*_localized` text member=] passing |item|, |shortcut|, "short_name_localized", and |defaultDirection|.
9. If "description" [=map/exists=] in |item|, and |item|["description"] is a [=string=], [=map/set=] |shortcut|["description"] to |item|["description"].
10. [=Process a `*_localized` text member=] passing |item|, |shortcut|, "description_localized", and |defaultDirection|.
11. [=Process image resources=] passing |item|["icons"], |shortcut|, |manifest URL|, and "icons".
12. [=Process a `*_localized` image resource member=] passing |item|, |shortcut|, "icons_localized", and |manifest URL|.
13. Return |shortcut|.

Application's name

The application's name is derived from either the [=manifest/name=] member or [=manifest/short_name=] member. The user agent SHOULD first resolve the localized values from their corresponding [=manifest/`*_localized`=] members.

When either the [=manifest/name=] member or the [=manifest/short_name=] member is missing, empty, or the wrong type, a user agent MAY use the [=manifest/name=] member as a fallback for the [=manifest/short_name=] member or [=manifest/short_name=] member as the fallback for the [=manifest/name=] member.

If the [=manifest/name=] and [=manifest/short_name=] members are missing, empty, or the wrong type, a user agent MAY fallback to the {{Document}} to find suitable replacements for missing manifest members (e.g., using `application-name` in place of [=manifest/name=] or [=manifest/short_name=]). Alternatively, the user agent SHOULD assign a default name (e.g., "Untitled") that follows platform conventions. Alternatively, a user agent MAY allow the end-user to input some text that can serve as the application's name.

When both the [=manifest/name=] and [=manifest/short_name=] members are present, it is left up to implementations to decide which member is best suited for the space available (e.g., the [=manifest/short_name=] member might be better suited for the space available underneath an icon).

Launching a web application

At the discretion of the operating system or user agent, run the steps to [=launch a web application=] with a [=Document/processed manifest=].

This would typically take place when the user selects an [=installed=] web app from an app launching UI surface e.g., a home screen, launcher or start menu.

The steps to launch a web application is given by the following algorithm. The algorithm takes a [=Document/processed manifest=] |manifest:processed manifest|, an optional [=URL=] |target URL:URL|, an optional [=POST resource=] |POST resource| and returns an [=application context=].

|target URL|, if given, MUST be [=manifest/within scope=] of |manifest|.

Other specifications MAY replace this algorithm's steps with their own steps. This replacement will take effect for all invocations of [=launch a web application=].

This algorithm is replaceable to allow an experimental launch_handler manifest field to configure the behavior of all web application launches. The replacement algorithm invokes [=create a new application context=] by default but under certain conditions behaves differently.

1. Return the result of running the steps to [=create a new application context=] passing |manifest|, |target URL| and |POST resource|.

The steps to create a new application context is given by the following algorithm. The algorithm takes a [=Document/processed manifest=] |manifest:processed manifest|, an optional [=URL=] |target URL:URL|, an optional [=POST resource=] |POST resource| and returns an [=application context=].

1. If |target URL| was not given, set |target URL| to [=start URL=].
2. Let |traversable| be the result of running the steps to [=create a fresh top-level traversable=] with |target URL| and |POST resource|.
3. Let |browsing context| be the |traversable|'s active browsing context.
4. [=Apply=] |manifest| to |browsing context|.
5. Return |browsing context|.

Privacy and security considerations

It is RECOMMENDED that UI that affords the end user the ability to install a web application also allows inspecting the icon, name, start URL, origin, etc. pertaining to a web application. This is to give an end-user an opportunity to make a conscious decision to approve, and possibly modify, the information pertaining to the web application before installing it. This also gives the end-user an opportunity to discern if the web application is spoofing another web application, by, for example, using an unexpected icon or name.

It is RECOMMENDED that user agents prevent other applications from determining which applications are installed on the system (e.g., via a timing attack on the user agent's cache). This could be done by, for example, invalidating from the user agent's cache the resources linked to from the manifest (for example, icons) after a web application is installed - or by using an entirely different cache from that used for regular web browsing.

Uninstallation

User agents SHOULD provide a mechanism for the user to remove an installed web application application.

It is RECOMMENDED that at the time of removal, the user agent also present the user with an opportunity to revoke other persistent data and settings associated with the application, such as permissions and persistent storage.

Deep links

A deep link is a URL that is [=manifest/within scope=] of an [=installed web application=]'s [=Document/processed manifest=].

An application context can be instantiated through a deep link, in which case, the manifest is applied and the deep link is loaded within the context of a web application.