We are making changes to many files. Very huge chunk of the changes are just renaming CSP -> PolicyContainer. Part 1 and part 2 are solely separated as frontend and backend. The unfortunate thing is, I mistakenly placed IDL changes in part 1, and many of those IDL changes affect frontend code too. I'm sorry for this inconvinience and hard to review patch(es).
(FWIW before this rewrite we had another patch stack. It is 25 patches and I believe isn't as comprehensive as this one. It also didn't replace CSP's inheritance but was copied alongside with CSP, but we decided to change our method and make policy conttainer contain CSP and copy it around after some discussion and reviews)
Differential Revision: https://phabricator.services.mozilla.com/D249248
This reverts commit efd9a5ba48.
Revert "Bug 1968644 - Part 9: Add more tests for loads triggered by tracking scripts. r=valentin,anti-tracking-reviewers,emz"
This reverts commit 7d5c3e1c1c.
Revert "Bug 1968644 - Part 8: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for WebSocket requests. r=valentin,necko-reviewers"
This reverts commit 53a783a51e.
Revert "Bug 1968644 - Part 7: Add tests. r=necko-reviewers,anti-tracking-reviewers,emz,valentin"
This reverts commit e52f034955.
Revert "Bug 1968644 - Part 6: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags during channel creation. r=necko-reviewers,kershaw"
This reverts commit f564c21b37.
Revert "Bug 1968644 - Part 5: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for CSS loads. r=emilio"
This reverts commit 8a8fd7bacc.
Revert "Bug 1968644 - Part 4: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for loads. r=smaug,necko-reviewers"
This reverts commit 7b3ba3b668.
Revert "Bug 1968644 - Part 3: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for fetch requests. r=valentin,smaug"
This reverts commit 08f090244f.
Revert "Bug 1968644 - Part 2: Intorduce the ClassificationFlags to nsIClassifiedChannel.idl. r=dimi,necko-reviewers,valentin"
This reverts commit b8c01cd77c.
Revert "Bug 1968644 - Part 1: Introduce triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags to LoadInfo. r=necko-reviewers,kershaw"
This reverts commit a7619a72b4.
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
The code path that was used for loading a document
with fission disabled did not take user activation into account.
This made almost all WPTs for Text Fragments fail,
since they depend on this flag to decide if
a text directive is allowed to be scrolled to.
This patch makes sure that the user activation is
also available for code paths that run through
`CanonicalBrowsingContext::FixupAndLoadURIString()`
to load a document.
This is done by adding a flag `hasValidUserGestureActivation`
to the `nsIOpenWindowInfo`, which carries it through
the JS stack for loading a document.
Differential Revision: https://phabricator.services.mozilla.com/D213401
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
The code path that was used for loading a document
with fission disabled did not take user activation into account.
This made almost all WPTs for Text Fragments fail,
since they depend on this flag to decide if
a text directive is allowed to be scrolled to.
This patch makes sure that the user activation is
also available for code paths that run through
`CanonicalBrowsingContext::FixupAndLoadURIString()`
to load a document.
This is done by adding a flag `hasValidUserGestureActivation`
to the `nsIOpenWindowInfo`, which carries it through
the JS stack for loading a document.
Differential Revision: https://phabricator.services.mozilla.com/D213401
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
`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
Propagate the ability to pass triggeringRemoteType through the desktop frontend
in various places, such that it is set when using the context menu or content
click handler.
Differential Revision: https://phabricator.services.mozilla.com/D161834
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
Fatih Kilic