ShouldEnableClassifier checks two things:
1. If AddOn can load the channel
2. If the classified channel is top-level.
For the first point, we added the check in Bug 1308640, and I think the
idea is only for tracking protection to not block channels when
extensions have permission on the channels' domain.
For annotation features, we should always annotate a channel regardless of whether
it is controlled by extensions (also for ETP).
And since we use first-party classification flag in channels, so we
should also annotate channel no matter it is top-level, first-party or
third-party.
So this patch removes calling ShouldEnableClassifier in annotation
features and also rename ShouldEnableClassifier to
ShouldEnableProtectionForChannel to make the idea more clear.
Differential Revision: https://phabricator.services.mozilla.com/D82504
Channels loaded by service worker don't have loadcontext, so we don't
apply tracking protection on them.
Depends on D80183
Differential Revision: https://phabricator.services.mozilla.com/D80184
When a channel is initiated from sharedworker or service worker, we use
worker's origin as the top-level uri.
Depends on D80182
Differential Revision: https://phabricator.services.mozilla.com/D80183
We use whether channel->GetTopWindowURI returns a failure to determin
if the channel is a top-level load. However, channels loaded by service
worker or appcache don't have top-level window.
This patch use TYPE_DOCUMENT to determin whether it is a top-level load.
This patch also adds UrlClassifierCommon::GetTopWindowURI to print debug message
because nsIChannel::GetTopWindowURI is not fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D80182
Channels loaded by service worker don't have loadcontext, so we don't
apply tracking protection on them.
Depends on D80183
Differential Revision: https://phabricator.services.mozilla.com/D80184
When a channel is initiated from sharedworker or service worker, we use
worker's origin as the top-level uri.
Depends on D80182
Differential Revision: https://phabricator.services.mozilla.com/D80183
We use whether channel->GetTopWindowURI returns a failure to determin
if the channel is a top-level load. However, channels loaded by service
worker or appcache don't have top-level window.
This patch use TYPE_DOCUMENT to determin whether it is a top-level load.
This patch also adds UrlClassifierCommon::GetTopWindowURI to print debug message
because nsIChannel::GetTopWindowURI is not fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D80182
The argument aEventTarget is actually never used by any caller; nullptr is always passed for it.
But the code is there in case it isn't null which would call into IProtocol::SetEventTargetFor
Depends on D80419
Differential Revision: https://phabricator.services.mozilla.com/D80421
ChannelClassifierService notifies "urlclassifier-before-block-channel"
event when a channel is going to be blocked by protection features.
It also provides an API for receivers to "unblock" the channel.
Sample usage:
this.service = Cc["@mozilla.org/url-classifier/channel-classifier-service;1"].getService(
Ci.nsIChannelClassifierService
);
if (this.service) {
this.service.addListener({
observe(aSubject, aTopic, aData) {
switch (aTopic) {
case "urlclassifier-before-block-channel":
let channel = aSubject.QueryInterface(Ci.nsIUrlClassifierBlockedChannel);
channel.unblock();
break;
}
},
})
}
Differential Revision: https://phabricator.services.mozilla.com/D76836
We used to use nsContentUtils::IsThirdPartyWindowOrChannel() to
determine the third-party channel when annotate the channel in
UrlClassifierCommon. Howeverm This is fission-incompatible. So, we
change it to use AntiTrackingUtils::IsThirdPartyChannel() which is
fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D75187
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
In this patch, we make the UrlClassifierCommon::IsAllowListed() to get
the ContentBlockingAllowListPrincipal from the WindowGlobalParent
instead of from the channel.
Differential Revision: https://phabricator.services.mozilla.com/D66213
--HG--
extra : moz-landing-system : lando
Dimi Lee
Andrea Marchesini
Noemi Erli
Simon Giesecke
Jean-Yves Avenard
Kashav Madan
Narcis Beleuzu
Taegeon Lee
Tim Huang
Csoregi Natalia
Andreea Pavel
Stefan Hindli
Andreas Farre
Emilio Cobos Álvarez
Cosmin Sabou
Gijs Kruitbosch
Steven Englehardt
Sebastian Streich
Ehsan Akhgari