Previously, this was passed around using the nsHashPropertyBag base
class on HTTP channels. In bug 1907269, this base was added to
nsExtProtocolChannel to support reading this property for external
protocols.
This unfortunately ended up not working when a HTTP channel redirects to
an external protocol, as the hash property propagation logic in
nsHttpChannel happens after the check that the target channel is a HTTP
channel, so the property was lost when redirecting to an external
protocol.
Rather than refactoring HTTP redirect logic, this patch simplifies by
moving the property onto the LoadInfo where it will be trivially
preserved across redirects, and available in the places which need it.
Because the nsHashPropertyBag base is no longer required for
nsExtProtocolChannel, it is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D220744
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 adds a new attribute called OverriddenFingerprintingSettings to
nsILoadInfo. The field will be used to decide the granular fingerprinting
protection override of the corresponding channel.
The OverriddenFingerprintingSettings will only get populated if
there is one defined for the context of the channel. Otherwise, a value
of Nothing indicates no granular overrides are present for the channel..
Differential Revision: https://phabricator.services.mozilla.com/D185011
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
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.
In P1, https://phabricator.services.mozilla.com/D174249, we propagate the BrowsingContext ID through PFetch.
In this patch, we need to save it in channel's LoadInfo for netmonitor.
In order not to confuse with nsILoadInfo's BrowsingContextID, we create a new attribute WorkerAssociatedBrowsingContextID in nsILoadInfo.
Depends on D174249
Differential Revision: https://phabricator.services.mozilla.com/D174441
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.
In P1, https://phabricator.services.mozilla.com/D174249, we propagate the BrowsingContext ID through PFetch.
In this patch, we need to save it in channel's LoadInfo for netmonitor.
In order not to confuse with nsILoadInfo's BrowsingContextID, we create a new attribute WorkerAssociatedBrowsingContextID in nsILoadInfo.
Depends on D174249
Differential Revision: https://phabricator.services.mozilla.com/D174441
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
When a network load needs to be intercepted by ServiceWorker, we extract the Request from the InterceptedHttpChannel, and propagate the Request through FetchEvent.request.
However, some needed information is not extracted or is modified during the Request propagation, so getting the wrong result when using the Request to fetch resources in the ServiceWorker script.
Differential Revision: https://phabricator.services.mozilla.com/D145969
If we enable pref browser.tabs.documentchannel.parent-controlled and remove the
requirement for needing SHIP for parent-initiated loads, test
NavigationDelegateTest#redirectIntentLoad times out. It times out because when
redirecting in Document Channel, we were using the URI of the redirect that
failed.
Differential Revision: https://phabricator.services.mozilla.com/D132093
To differentiate the storage permission is granted by either the
permission or the allowList, we need to change the hasStoragePermission
to an enum to represent the storage permission state.
This patch also changes the name of the attribute to make it reasonable
with respect to this change.
Differential Revision: https://phabricator.services.mozilla.com/D126276
This change stores a generated nsID directly on the LoadInfo, rather
than the full SandboxedLoadingPrincipal. This allows for the sandboxed
principal to be constructed from GetChannelResultPrincipal using the
unsandboxed result principal as a precursor, rather than the loading
principal.
The nsID is reset by HttpChannelBase whenever a non-internal redirect
occurs to reduce the chance of multiple null result principals during a
redirect with the same nsID, but different precursors.
Depends on D119692
Differential Revision: https://phabricator.services.mozilla.com/D119693
This patch adds a UnstrippedURI into the LoadInfo. This attribute
represents the channel's URI has been stripped if this attributes is not
a nullptr.
Having this attribute allows us to be able to revert the query stripping
in the case where the loading channel is in the content blocking allow
list in the parent process.
In addition, this patch removes the main thread assertion in URIUtils
given that we've made the URL construction thread-safe. This will allow
us to be able to use nsIURI directly in ParentLoadInfoForwarderArgs.
Differential Revision: https://phabricator.services.mozilla.com/D116108
This patch adds a flag 'needForCheckingAntiTrackingHeuristic' in
loadInfo. This flag will be used for deciding if we need to check the
AntiTracking heuristic after the channel has been classified.
Differential Revision: https://phabricator.services.mozilla.com/D107047
Nika Layzell
Jan-Niklas Jaeschke
Christoph Kerschbaumer
Sebastian Hengst
Andreas Farre
Stanca Serban
Cristian Tuns
Butkovits Atila
Tim Huang
Frederik Braun
Benjamin VanderSloot
Cosmin Sabou
Tom Schuster
Norisz Fay
Hannah Peuckmann
Eden Chuang
Iulian Moraru
Paul Zuehlcke
Sean Feng
Marian-Vasile Laza
Tooru Fujisawa
Neil Deakin
Anny Gakhokidze
Gijs Kruitbosch
Niklas Gögge
Masatoshi Kimura
Narcis Beleuzu