This section is not normative.
When a user successfully loads a webpage from
example.com over a
secure channel (HTTPS, for example), the user is guaranteed that no entity
between the user agent and
example.com eavesdropped on or
tampered with the data transmitted between them. However, this guarantee is
weakened if the webpage loads subresources such as script or images over an
insecure connection. For example, an insecurely-loaded script can allow an
attacker to read or modify data on behalf of the user. An insecurely-loaded
image can allow an attacker to communicate incorrect information to the user
(e.g., a fabricated stock chart), mutate client-side state (e.g., set a
cookie), or induce the user to take an unintended action (e.g., changing the
label on a button). These requests are known as mixed content.
[MIXED-CONTENT] details how a user agent can mitigate these risks by blocking certain types of mixed content, and behaving more strictly in some contexts.
However, as implemented in today’s web browsers, [MIXED-CONTENT] does not fully protect the confidentiality and integrity of users' data. Insecure content such as images, audio, and video can currently be loaded by default in secure contexts.
Moreover, users do not have a clear security indicator when mixed content is loaded. When a webpage loads mixed content, browsers display an "in-between" security indicator (such as removing the padlock icon), which does not give users a clear indication of whether they should trust the page. This UX has also not proved a sufficient incentive for developers to avoid mixed content, since it is still common for webpages to load mixed content. Blocking all mixed content would provide the user with a simpler mental model -- the webpage is either loaded over a secure transport or it isn’t -- and encourage developers to securely load any mixed content that is necessary for their webpage to function properly.
Mixed Content Level 2 therefore updates and extends [MIXED-CONTENT] to provide users with better security and privacy guarantees and a better security UX, while minimizing breakage. Instead of advising browsers to simply strictly block all mixed content, the core idea of Level 2 is mixed content autoupgrading. That is, mixed content that user agents are not already blocking should be autoupgraded to a secure transport. If the request cannot be autoupgraded, it will be blocked. Autoupgrading avoids loading insecure resources on secure webpages, while minimizing the amount of developer effort needed to avoid breakage.
This specification (Level 2) only recommends autoupgrading types of mixed content that are not currently blocked by default, and does not recommend autougprading types of content that are already blocked. This is to minimize the amount of web-visible change; we only want to autoupgrade content if it advances us towards the goal of blocking all mixed content by default.
2. Key Concepts and Terminology
3.1. Upgrade request to an a priori authenticated URL as mixed content, if appropriate
Note: The Fetch specification will hook into this algorithm to upgrade optionally-blockable mixed content to HTTPS.
Given a Request request, this algorithm will rewrite its url if the request is deemed to be optionally-blockable mixed content, via the following algorithm:
If one or more of the following conditions is met, return without modifying request:
- request’s url is an Mixed Content §a-priori-authenticated-url.
- Mixed Content §categorize-settings-object returns "
Does Not Restrict Mixed Security Contents" when applied to request’s client.
- request’s mode is
- request’s destination is not "
audio", or "
- request’s destination is "
image" and request’s initiator is "
If request’s url’s scheme is
http, set request’s url’s scheme to
https, and return.
Note: Per [url], we do not modify the port because it will be set to null when the scheme is
http, and interpreted as 443 once the scheme is changed to
3.2. Modifications to existing algorithms
Note: This section specifies modifications to existing mixed content algorithms to ignore the distinction between optionally-blockable and blockable mixed content, since all optionally-blockable mixed content will now be autoupgraded.
Mixed Content §should-block-fetch should be modified to remove Steps 3, 4, and 5, replacing them with a single step "Return blocked".
Mixed Content §should-block-response should be modified to remove Steps 2, 3, and 4, replacing them with a single step "Return blocked".
4.1. Modifications to Fetch
Fetch Standard §4.1 Main fetch should be modified to call § 3.1 Upgrade request to an a priori authenticated URL as mixed content, if appropriate on request between steps 3 and 4. That is, optionally-blockable mixed content should be autoupgraded to HTTPS before applying mixed content blocking.
This specification renders the Mixed Content §block-all-mixed-content CSP directive obsolete, because all mixed content is now blocked if it can’t be autoupgraded.
upgrade-insecure-requests ([upgrade-insecure-requests]) directive is not
obsolete because it allows developers to upgrade blockable content. This specification only
upgrades optionally-blockable content by default.
6. Security and Privacy Considerations
Overall, autoupgrading optionally-blockable mixed content is expected to be security- and privacy-positive, by protecting more user traffic from network eavesdropping and tampering.
There is a risk of introducing a security or privacy issue in a webpage by loading a resource that
the developer did not intend. For example, suppose that a website includes an innocuous image
http://www.example.com/image.jpg, and for some
https://www.example.com/image.jpg redirects to a tracking site. The browser
will now have introduced a privacy issue without the developer’s or user’s explicit
consent. However, these cases are expected to be exceedingly rare. The risk is mitigated by
autoupgrading only optionally-blockable content, not blockable content as well. Blockable content