This patch addresses the problem that we currently collect HTTPS-First telemetry
for sites that are not reachable at all, be it through always causing a error or
through always timing out.
- On a downgrade, do not collect telemetry instantly, but instead save the
telemetry data in the load state for the downgraded request
- That telemetry data will then be copied over into the document load listener
of the new request
- On a successful request, if we have downgrade data in the load listener, we
collect the downgrade telemetry, as the downgrade seems to have been
successful
- Similar to the downgrade case, we only count the upgrade metric once we
encounter a successful request annotated with the information that it was
upgraded by HTTPS-First, instead of counting it instantly on the decision to
upgrade. This also means the upgrade metric will not include loads that are
downgraded again anymore
- Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and
ensure no telemetry is collected
Differential Revision: https://phabricator.services.mozilla.com/D210792
Without this patch we potentially create the reserved client principal
based on a stale cookie jar because we add the ClientChannelHelper
before the cookie jar's partition key is mutated in
nsHttpChannel::AsyncOpen.
Differential Revision: https://phabricator.services.mozilla.com/D211148
This was causing object loads which aren't handled by a document to not
enter the content process, meaning that repsonse timing tests would
fail.
NS_ERROR_WONT_HANDLE_CONTENT returned from this method is not a real
error condition, as it just indicates that we decided to not handle the
response in nsDocShell explicitly, much like returning `NS_OK` and not
specifying `m_targetStreamListener`.
Depends on D201645
Differential Revision: https://phabricator.services.mozilla.com/D204056
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
- Add new glean metrics.yaml for dom/security
- Add 8 new metrics for (schemeless) HTTPS-First, see metrics.yaml for
explanation
- Add getter for timing on document load listener
- Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with
complete document load listener so that it is able to access the timing
- Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check
for correct telemetry values
Differential Revision: https://phabricator.services.mozilla.com/D196072
- Add new glean metrics.yaml for dom/security
- Add 5 new metrics for (schemeless) HTTPS-First, see metrics.yaml for
explanation
- Add getter for timing on document load listener
- Provide `nsHTTPSOnlyUtils::PotentiallyDowngradeHttpsFirstRequest` with
complete document load listener so that it is able to access the timing
- Adapt browser_httpsfirst.js and browser_schemeless.js tests to also check
for correct telemetry values
Differential Revision: https://phabricator.services.mozilla.com/D196072
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
Given meta/ctrl key should use browser.tabs.loadInBackground pref instead of
browser.tabs.loadDivertedInBackground pref, the existing
nsIBrowserDOMWindow.OPEN_NEWTAB behavior doesn't match the requirement.
Add dedicate flag for "open in foreground tab" to make it controllable from
nsWindowWatcher::IsWindowOpenLocationModified.
Differential Revision: https://phabricator.services.mozilla.com/D201929
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
In order to achieve "load in a new background tab" operation in `window.open`,
add OPEN_NEWTAB_BACKGROUND which is equivalent to OPEN_NEWTAB except for
not selecting the tab.
Differential Revision: https://phabricator.services.mozilla.com/D197859
It has never shipped after being implemented years ago,
and was removed from spec in September 2022:
https://github.com/w3c/webappsec-csp/pull/564
Now skipping navigate-to WPT tests. Filed issue upstream for their future removal:
https://github.com/w3c/webappsec-csp/issues/608
Consensus seems to agree to remove, will do in follow up bug once landed.
Also removed our own tests.
Added a hack in StartDocumentLoad as just removing the navigate-to check call
breaks some inhertiance, see comment for more info.
Differential Revision: https://phabricator.services.mozilla.com/D181630
This will impact all resource types which are loaded as documents within
object/embed elements, which should roughly correspond to the behaviour
prior to Fission.
The major exception here which is a behaviour change is around image
loading. In bug 1595491, the way these were loaded to be using an image
document under the hood. At the time, this meant that image loads with
CD: attachment specified would fail to load, but this change will mean
that they will instead are downloaded.
Additional changes would need to be made to preserve the older behaviour
of ignoring Content-Disposition when loading images in object/embed
elements, if it turns out to be a web-compat issue.
Differential Revision: https://phabricator.services.mozilla.com/D196363
We populate the OverriddenFingerprintingSettings to the loadInfo when updating
AntiTracking Info for the channel. This happens when we open the channel
in the parent process, so we have every info we need to get the
granular overrides for the channel.
Differential Revision: https://phabricator.services.mozilla.com/D185013
`nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is currently only used by HTTPS-First. It is used for fixing upgrade-downgrade loops and when loading history entries, as when we already know if HTTPS-First succeeded there or not, we have no need for trying to upgrade again and can disable HTTPS-First. With the changes introduced by Bug 1839612, `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` also applies to HTTPS-Only, which is a problem because disabling HTTPS-Only for history entries will result in them potentially being loaded insecurely without the user setting an exception. As a solution this patch just applies `nsILoadInfo::HTTPS_ONLY_EXEMPT_NEXT_LOAD`, the flag being set when `nsDocShellLoadState::IsExemptFromHTTPSOnlyMode` is set, when HTTPS-First is enabled, and renames both flags to reflect that behavior.
Differential Revision: https://phabricator.services.mozilla.com/D185829
In the Storage Access API's latest draft, a few items were added to the user-agent state. Relevant here,
the source snapshot params gained two fields that are initialized from the sourceDocument during
snapshotting source params while navigating: "has storage access" and "environment id".
https://privacycg.github.io/storage-access/#ua-state
These are used to identify self-initiated navigations that come from documents that have obtained storage access.
Combined with a same-origin check, this determines if the destination document of the navigation should start
with storage access.
This is stricter than the current behavior, where if the permission is available, all documents start with storage access.
Instead, now a document will only have storage access if it requests it explicitly or if a same-origin document that has
storage access navigates itself to that document. This is seen as a security win.
Security discussion of this change was here: https://github.com/privacycg/storage-access/issues/113
Artur at Google wrote up a great summary here: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
Differential Revision: https://phabricator.services.mozilla.com/D184821
In the Storage Access API's latest draft, a few items were added to the user-agent state. Relevant here,
the source snapshot params gained two fields that are initialized from the sourceDocument during
snapshotting source params while navigating: "has storage access" and "environment id".
https://privacycg.github.io/storage-access/#ua-state
These are used to identify self-initiated navigations that come from documents that have obtained storage access.
Combined with a same-origin check, this determines if the destination document of the navigation should start
with storage access.
This is stricter than the current behavior, where if the permission is available, all documents start with storage access.
Instead, now a document will only have storage access if it requests it explicitly or if a same-origin document that has
storage access navigates itself to that document. This is seen as a security win.
Security discussion of this change was here: https://github.com/privacycg/storage-access/issues/113
Artur at Google wrote up a great summary here: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
Differential Revision: https://phabricator.services.mozilla.com/D184821
Nobody uses it and currently not super useful as the possible return value is limited to primitives. It could be extended to support DOM objects, but I don't know there's actual use cases for that as in many cases the promise is resolved with non-DOM values.
Differential Revision: https://phabricator.services.mozilla.com/D183026
- Also clear HTTPS_ONLY_EXEMPT for HTTPS-First in TestSitePermissionAndPotentiallyAddExemption
- Remove PotentiallyClearExemptFlag as we are now clearing the exemption every time
- Introduce new flag HTTPS_ONLY_EXEMPT_NEXT_LOAD which will set the exemption again after it being (potentially) cleared
- Set that flag when nsDocShellLoadState::IsExemptFromHTTPSOnlyMode is set, since that happens before the exemption is cleared
Differential Revision: https://phabricator.services.mozilla.com/D182322
