This reverts commit efd9a5ba48fc380ea38ca827657e6f3fc1a865b5.
Revert "Bug 1968644 - Part 9: Add more tests for loads triggered by tracking scripts. r=valentin,anti-tracking-reviewers,emz"
This reverts commit 7d5c3e1c1ce9e5e41f3054ba7245dda936d14787.
Revert "Bug 1968644 - Part 8: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for WebSocket requests. r=valentin,necko-reviewers"
This reverts commit 53a783a51e5e2db3f695150bc85b7af2a34b78a3.
Revert "Bug 1968644 - Part 7: Add tests. r=necko-reviewers,anti-tracking-reviewers,emz,valentin"
This reverts commit e52f034955e34d4c6ad841278894974c615a123f.
Revert "Bug 1968644 - Part 6: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags during channel creation. r=necko-reviewers,kershaw"
This reverts commit f564c21b371c60b240c79a8b56906a9175d58ec3.
Revert "Bug 1968644 - Part 5: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for CSS loads. r=emilio"
This reverts commit 8a8fd7bacc029c91337718e31f7f5911c5afd9a8.
Revert "Bug 1968644 - Part 4: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for loads. r=smaug,necko-reviewers"
This reverts commit 7b3ba3b6689a802718fef2023f9691400611c285.
Revert "Bug 1968644 - Part 3: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for fetch requests. r=valentin,smaug"
This reverts commit 08f090244fbab71a14c5e30f740ffcb9cb6f3d31.
Revert "Bug 1968644 - Part 2: Intorduce the ClassificationFlags to nsIClassifiedChannel.idl. r=dimi,necko-reviewers,valentin"
This reverts commit b8c01cd77c4e180b5983dd6a7515b7438676a897.
Revert "Bug 1968644 - Part 1: Introduce triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags to LoadInfo. r=necko-reviewers,kershaw"
This reverts commit a7619a72b4c02e1ff2fa11ce70c954e3313058e1.
This patch introduces `UserNavigationInvolvement`
as an IPDL type, and adds the user navigation
involvement flag to `nsDocShellLoadState` and
`nsILoadInfo`.
Differential Revision: https://phabricator.services.mozilla.com/D234851
Modify the frame recursion check to only happen when a load is triggered
from a src or data attribute (depending on if it's an iframe, embed or
an object element). This prevents recursion checks from blocking
ordinary navigations and navigations with a target.
Differential Revision: https://phabricator.services.mozilla.com/D229503
This commit is a prerequisite for part 5 of this patch set
and introduces the `text directive user activation` flag
as well as the necessary boilerplate to transport the value
through process boundaries in `nsDocShellLoadState` and `LoadInfo`.
There is no changed behavior in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D212816
This commit is a prerequisite for part 5 of this patch set
and introduces the `text directive user activation` flag
as well as the necessary boilerplate to transport the value
through process boundaries in `nsDocShellLoadState` and `LoadInfo`.
There is no changed behavior in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D212816
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
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
`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
The goal of this change is to detect content-initiated file URI loads
earlier such that crash stacks give us a better idea of what is
responsible for starting these loads.
These assertions explicitly only fire for system-principal triggered
loads of file URIs, as those should never be happening from within a web
content process.
Differential Revision: https://phabricator.services.mozilla.com/D182223
This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.
For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.
For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:
1. The "Triggering Process" is the process which provided the URI to load.
This is also the process which provides the Triggering Principal. This is
the process being tracked in this patch.
2. The "Loading Process" is the process which actually creates the channel and
starts the load. This may be the same as the triggering process, or may be
a different process starting the navigation on behalf of the triggering
process. In general this is the process hosting the current docshell,
though it may be the parent process in the case of parent-initiated loads.
3. The "Final Process" is the process which receives the response and renders
the final document. This isn't known at channel creation time, and is
determined by the result principal and process isolation policy.
This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.
The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D161198
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
Previously, we tracked UnstrippedURI on the nsDocShellLoadState and LoadInfo,
and manually filled it in to match the previous load when doing a
LOAD_CMD_RELOAD in nsDocShell. It is more consistent with other load types to
instead store the information in the load state, allowing it to be handled
consistently for reloads and other history operations.
Unfortunately, this patch has some extra complexity right now, as it needs to
support both SHIP and non-SHIP session history. This should disappear in the
future when we switch to using exclusively SHIP.
Differential Revision: https://phabricator.services.mozilla.com/D161196
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
When we navigate in history to the same entry that we're current at then we
actually do a reload. The problem is in the way we detect whether to do a reload
in the parent process.
If a page does a back and a forward one after the other in a script, then the
parent will calculate the index for the back and tell the child to load the
entry at that index. While the child is processing the load of that entry, the
BC in the parent process still has the same entry as its active entry (until the
child commits the load of the entry over IPC). The parent then processes the
forward, calculates the index for the forward and finds the entry at that index.
This is the same entry that we were at before doing anything, and so the same
entry as the active entry in the BC in the parent process. We used to compare
the entry that we're going to load with the active entry in the BC to determine
whether we're doing a reload, and so in this situation we would assume the
forward navigation was actually doing a reload. The child would reload the page,
and we'd run the script again and we'd end up in a reload loop.
Comparing the offset with 0 to determine whether we're doing a reload fixes this
issue.
Differential Revision: https://phabricator.services.mozilla.com/D126585
Using requestedIndex on the child side is hard, because there are race conditions when a session history load is triggered
and at the same time a non-session history load commits a new active entry.
Differential Revision: https://phabricator.services.mozilla.com/D126619
