一什么不什么四字成语

3.1. Optionally-blockable Content

A resource or request is optionally-blockable when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web. This could be because mixed usage of the resource type is sufficiently high, and because the resource is low-risk in and of itself. The fact that these resource types are optionally-blockable does not mean that they are safe, simply that they’re less catastrophically dangerous than other resource types. For example, images and icons are often the central UI elements in an application’s interface. If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact to users.

This category of content includes:

• Images loaded via img or CSS (background-image, border-image, etc)

  Note: This includes SVG documents loaded as images, as they are banned from executing script or loading subresources. It does not include images loaded via picture.

• Video loaded via video and source
• Audio loaded via audio and source

Note: We further limit this category in §5.3 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled request. This means that mixed content images loaded via <img crossorigin ...> will be blocked. This is a good example of the general principle that content falls into this category only when it is too widely used to be blocked outright. The Working Group intends to carve out more blockable subsets as time goes on.

3.2. Blockable Content

Any resource or request that isn’t optionally-blockable is blockable. Typical examples of this kind of content include scripts, plugin data, data requested via XMLHttpRequest, and so on.

Note: Navigation requests might target top-level browsing contexts; these are not considered mixed content. See §5.3 Should fetching request be blocked as mixed content? for details.

Note: Note that requests made on behalf of a plugin are blockable. We recognize, however, that user agents aren’t always in a position to mediate these requests. NPAPI plugins, for instance, often have direct network access, and can generally bypass the user agent entirely. We recommend that plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.

5.1. Does settings prohibit mixed security contexts?

Both documents and workers have environment settings objects which may be examined according to the following algorithm in order to determine whether they restrict mixed content. This algorithm returns "Prohibits Mixed Security Contexts" or "Does Not Prohibit Mixed Security Contexts", as appropriate.

Given an environment settings object (settings):

1. If settings’ HTTPS state is not "none", then return "Prohibits Mixed Security Contexts".

2. If settings has a responsible document document, then:

   1. While document has an embedding document:

      1. Set document to document’s embedding document.

      2. Let embedder settings be document’s global object’s relevant settings object.

      3. If embedder settings’ HTTPS state is not "None", then return "Prohibits Mixed Security Contexts".

3. Return "Does Not Restrict Mixed Security Contexts".

5.2. Is request a passthrough request?

A passthrough request is a request (request) which is created in a browsing context (e.g. via an img tag in a document), but serviced by a Service Worker (e.g. by calling fetch(e.request) from within an onfetch event handler). As described in §7.5 Service Workers, we special-case these kinds of requests in order to allow web developers to layer service workers on top of an existing site which relies on requesting optionally-blockable mixed content.

More formally, request is a passthrough request if the following conditions hold [FETCH]:

1. request’s initiator is fetch

   Note: When a request is copied (as in the fetch(e.response) example above), the original context is lost. Here, we ensure that we’re dealing with such a request, but we implicitly rely on §5.3 Should fetching request be blocked as mixed content? preventing blockable requests from entering a Service Worker in the first place.

2. request’s window is an environment settings object (and, therefore, not no-window)

   Note: We rely on the window property being properly set by [FETCH] to the environment settings object responsible for the request in order to ensure that we can render some sort of warning to the user (as described in §7.3 UI Requirements).

3. request’s client’s global object is a ServiceWorkerGlobalScope object.

   Note: We rely on the client property to reflect the origin of the request. Importantly, request is only a passthrough request if it originated inside a Service Worker.

5.3. Should fetching request be blocked as mixed content?

Note: The Fetch specification hooks into this algorithm to determine whether a request should be entirely blocked (e.g. because the request is for blockable content, and we can assume that it won’t be loaded over a secure connection).

Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:

1. Return allowed if one or more of the following conditions are met:
   1. §5.1 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contexts" when applied to request’s client.
   2. request’s url is a priori authenticated.
   3. The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
   4. request’s destination is "document", and request’s target browsing context has no parent browsing context.

      Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see §7.6 Further Action).

2. For each policy in request’s client’s CSP list:

   1. If policy’s directive set contains a directive whose name is "block-all-mixed-content":

      1. Let violation be the result of executing the algorithm defined in Content Security Policy §2.3.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and "block-all-mixed-content".

      2. Set violation’s resource to request’s url.

      3. Execute the algorithm defined in Content Security Policy §5.3 Report a violation on violation.

3. Return blocked if one or more of the following conditions are met:
   1. The user agent is configured to block optionally-blockable mixed content, as described in §7.4 User Controls.
   2. request’s client’s strict mixed content checking flag is true.
   3. request’s mode is CORS or CORS-with-forced-preflight.
4. Return allowed if one or more of the following conditions are met:
   1. request’s initiator is "fetch" and destination is "subresource", and request is a passthrough request.
   2. request’s type is "image", and initiator is not "imageset".
   3. request’s type is "video".
   4. request’s type is "audio".
5. Return blocked.

Note: We special-case fetch to allow it as optionally-blockable in the event that a Service Worker is making a no-cors request in response to a Fetch event generated from a Document. In that case, the request’s client property will be an environment settings object whose global object is a Window object (the Service Worker’s request’s client, on the other hand, will be a WorkerGlobalScope object.

5.4. Should response to request be blocked as mixed content?

Note: If a request proceeds, we still might want to block the response based on the state of the connection that generated the response (e.g. because the request is blockable, but the connection is unauthenticated), and we also need to ensure that a Service Worker doesn’t accidentally return an unauthenticated response for a blockable request. This algorithm is used to make that determination.

Given a request request and response response, the user agent determines what response should be returned via the following algorithm:

1. Return allowed if one or more of the following conditions are met:
   1. §5.1 Does settings prohibit mixed security contexts? returns Does Not Restrict Mixed Content when applied to request’s client.
   2. response’s HTTPS state is modern.
   3. The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
   4. request’s destination is "document", and request’s target browsing context has no parent browsing context.

      Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see §7.6 Further Action).

2. Return blocked if one or more of the following conditions are met:
   1. The user agent is configured to block optionally-blockable mixed content, as described in §7.4 User Controls.
   2. request’s client’s strict mixed content checking flag is true.
3. Return allowed if response is an opaque filtered response and one or more of the following conditions are met:
   1. request’s initiator is "fetch", and request is a passthrough request.
   2. request’s type is "image", and initiator is not "imageset".
   3. request’s type is "video".
   4. request’s type is "audio".
4. Return blocked.

7.1. Limitations

Blocking mixed content allows us to ensure that the guarantees discussed in §1 Introduction are upheld. Note, however, that those guarantees only protect developers and users against active network attackers who would otherwise be able to replace critical bits of code or content on the wire as it flows past. They do not protect against a compromised server that itself is coerced into sending corrupted resources.

Mechanisms such as Subresource Integrity [SRI] are designed to deal with this kind of threat, and we recommend that web developers make use of them whenever possible.

7.2. Form Submission

If §5.1 Does settings prohibit mixed security contexts? returns Restricts Mixed Content when applied to a Document's relevant settings object, then a user agent MAY choose to warn users of the presence of one or more form elements with action attributes whose values are not a priori authenticated URLs.

Note: Chrome, for example, currently gives the same UI treatment to a page with an insecure form action as it does for a page that displays an insecure image.

Further, a user agent MAY treat form submissions from such a Document as a blockable request, even if the submission occurs in the top-level browsing context.

7.3. UI Requirements

If a user agent would normally indicate to the user that the top-level browsing context is secure, then:

• When the user agent downgrades a context to a mixed security context by returning a resource in response to a mixed content request (either because the request is optionally-blockable, or because the user agent is configured to allow blockable requests), the user agent MUST NOT provide the user with that same indication.

  The user agent SHOULD instead give an indication that mixed content is present.

If a mixed content indication is present, it MUST be made available through accessibility APIs for users of assistive technologies.

Note: This requirement holds even in the context of an EV status [CAB]. An EV certificate’s indicator does not override the necessity to notify users of mixed content violations.

7.4. User Controls

A user agent MAY offer users the ability to directly decide whether or not to treat all mixed content as blockable (meaning that even optionally-blockable mixed content would be blocked).

Note: It is strongly recommended that users take advantage of such an option if provided.

A user agent MAY offer users the ability to override its decision to block blockable mixed content on a particular page.

Note: Practically, a user agent probably can’t get away with not offering such a back door. That said, allowing mixed script is in particular a very dangerous option, and each user agent REALLY SHOULD NOT [RFC6919] present such a choice to users without careful consideration and communication of the risk involved.

Any such controls offered by a user agent MUST also be offered through accessibility APIs for users of assistive technologies.

7.5. Service Workers

The fact that Service Workers sit inbetween a document and the network means that we need to special-case requests made in those contexts. In particular, they should be able to cache the results of insecure requests, provided that those requests were triggered from a document (which, presumably, ensures that they’ll be used in an optionally-blockable context). Those insecure results, however, cannot be exposed to the Service Worker, nor should the Service Worker be allowed to launder responses to optionally-blockable requests into responses to blockable requests.

To that end:

1. §5.3 Should fetching request be blocked as mixed content? has some carve-outs for the fetch request initiator, with the intent of allowing a Service Worker to copy a request as part of its response to a Fetch event (e.g. fetch(event.response) should be executable inside the event handler.

   fetch will continue to be treated as blockable when executed outside the context of a Fetch event, which of course includes document contexts.

2. §5.4 Should response to request be blocked as mixed content? verifies that the incoming response has the same security characteristics that were allowed for the request. That is, a Service Worker will not be able to replace a request for a secure script with a cached response for an insecure resource.

7.6. Further Action

A user agent is encouraged to take further action above and beyond the requirements this document outlines in order to discourage developers from embedding mixed content.

For instance, a user agent could:

1. Interpret the presence of a Strict-Transport-Security header field as forcing all content into the blockable category [RFC6797], or as a signal to enable strict mode for mixed content checking.
2. Modify requests for optionally-blockable resources which are mixed content in order to reduce the risk to users: cookies and other authentication tokens could be stripped from the requests, automatic scheme upgrades could be attempted, and so on.
3. Treat optionally-blockable resources inside nested browsing contexts as blockable, to allow sites to embed resources without fear of introducing mixed content.