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
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
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
`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
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
Now that we've simplified the startup process somewhat, it is easier to clean
up IPC channel creation for NodeChannel connections. This stops having
GeckoChildProcessHost inherit from IPC::Channel::Listener, as it would never
receive most of the relevant callbacks, and instead implements the one callback
it would receive directly as a method on that type.
Differential Revision: https://phabricator.services.mozilla.com/D181282
The problem that the image element not being removed is that the tabId is missing.
To make tabId available for the web extensions, we need to provide nsILoadContext to hinted requests.
Differential Revision: https://phabricator.services.mozilla.com/D179924
