This changes the way that the principal for a Blob URL is inferred to instead
be based on the URL within the BlobURL, unless the URL's origin part is
"null".
In order to continue to support system-principal Blobs without needing to
broadcast the principal around, they are given a special origin part of
"system". This changes some tests which were specifically looking for the
"blob:null" prefix.
Differential Revision: https://phabricator.services.mozilla.com/D276055
This reverts commit 47367770c3.
Revert "Bug 2005247 - Part 3: Always read BlobURL info over IPC, r=asuth"
This reverts commit df37ac38f8.
Revert "Bug 2005247 - Part 2: Validate BlobURL ContentLength header during channel fetch, r=asuth,necko-reviewers,valentin"
This reverts commit 45e63e6920.
Revert "Bug 2005247 - Part 1: Get the BlobImpl from the BlobURLChannel, r=asuth,media-playback-reviewers,padenot"
This reverts commit 440a33211b.
Revert "Bug 2005002 - Part 5: sec-fetch-storage-access not implemented for workers, r=manuel"
This reverts commit 5654faf8a0.
Revert "Bug 2005002 - Part 4: Fix devtools tests for blob: URL dedicated worker changes, r=devtools-reviewers,ochameau"
This reverts commit 9c9c197990.
Revert "Bug 2005002 - Part 3: Extension content scripts for Blob URLs no longer match with full paths, r=extension-reviewers,robwu"
This reverts commit 55f399175f.
Revert "Bug 2005002 - Part 2: Infer Blob URL principal from URL when possible, r=asuth,extension-reviewers,necko-reviewers,home-newtab-reviewers,robwu,mconley,kershaw,bvandersloot"
This reverts commit d3022ec470.
Revert "Bug 2005002 - Part 1: Support do_QueryObject for nsSimpleURI and subclasses, r=necko-reviewers,valentin,asuth"
This reverts commit 3d1199b4d4.
This changes the way that the principal for a Blob URL is inferred to instead
be based on the URL within the BlobURL, unless the URL's origin part is
"null".
In order to continue to support system-principal Blobs without needing to
broadcast the principal around, they are given a special origin part of
"system". This changes some tests which were specifically looking for the
"blob:null" prefix.
Differential Revision: https://phabricator.services.mozilla.com/D276055
This is a large number of largely mechanical changes. When possible, the code
was called to directly call `.get()` instead, performing the assertions
manually. In many places PromiseFlatCString() calls were added to dynamically
copy the strings into null terminated buffers if the string was not null
terminated.
Differential Revision: https://phabricator.services.mozilla.com/D286158
If otherHost.Length() is not larger than ourHost.Length() calling
GetNextSubDomain(otherHost) will never end up returning a string that equals
ourHost, so we can exit the loop early.
Differential Revision: https://phabricator.services.mozilla.com/D278546
This ensures that the instantiation of the service always returns the
same singleton. I also changed calls to nsEffectiveTLDService::GetInstance
to use mozilla::components::EffectiveTLD::Service() instead.
Differential Revision: https://phabricator.services.mozilla.com/D235288
GetURI can succeed, but still return null. In that case, BasePrincipal::IsL10nAllowed
will pass null into NS_URIChainHasFlags, causing it to fail, which will produce three
separate warnings, and then return NS_OK. A recent change caused this function to be
call much more frequently, so this is now the top source of log spam in debug builds.
This change should not affect the behavior, aside from the lack of warnings.
Differential Revision: https://phabricator.services.mozilla.com/D219065
Previously, the WebExtension protocol used dynamic protocol flags which
were based on the WebExtension policy in order to enforce things such as
availability in private browsing and the accessibility of certain
resources.
Since the shift to MV3, these checks have required more complex checks
than what was possible to specify with protocol flags, which required
the addition of WEBEXT_URI_WEB_ACCESSIBLE - a security flag which would
trigger further checks with the EPS to determine if the URI can be
loaded.
This was somewhat inefficient, as fetching the URI flags would require
looking up the policy each time dynamic flags were looked up, as well as
when policy specifics were being checked after loading flags. In
addition, it lead to a number of flags which were very specific to
extension protocols.
This patch changes extensions to no longer have dynamic flags, instead
specifying the static `URI_IS_WEBEXTENSION_RESOURCE` security flag. When
this flag is specified, security checks are made by querying the
ExtensionPolicyService to ask if the load should be permitted, combining
the specific security checks for Extension resources into a simpler
code-path, and avoids redundant checks.
Differential Revision: https://phabricator.services.mozilla.com/D216076
This method was previously non-threadsafe due to it needing to access dynamic
URI flags. These flags were used to check the WEbExtensionPolicy to see if the
webextension resource being loaded should be accessible.
Making dynamic URI flags available off-main-thread in general would
unfortunately be quite difficult, due to some of them depending on things like
JS `nsIAboutModule` implementations, so that was not the approach taken.
Instead, all information required is already available in the threadsafe
WebExtensionPolicyCore, which is now directly queried, instead of being queried
indirectly through protocol flags.
Differential Revision: https://phabricator.services.mozilla.com/D215026
Just starting up a debug build you will get 40 copies of this printed.
The uri that we fail to get host of is about:newtab. One stack looks like this
#02: mozilla::BasePrincipal::GetIsLoopbackHost(bool*)
#03: mozilla::net::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, nsIContentPolicy::nsContentPolicyType, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, bool
#04: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool)
#05: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16
#06: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool,
#07: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&)
#08: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*)
#09: nsStyleImageLayers::ResolveImages(mozilla::dom::Document&, nsStyleImageLayers const*)
#10: mozilla::ComputedStyle::StartImageLoads(mozilla::dom::Document&, mozilla::ComputedStyle const*)
Differential Revision: https://phabricator.services.mozilla.com/D193349
This patch has three parts to it:
1) Use NS_IsContentAccessibleAboutURI to ensure that only safe
about: documents get exempted.
With this change, we will no longer allow about:blank or
about:srcdoc to be exempted base on URI. If they are to be
exempted, it will need to be base on other information.
2) In Document::RecomputeResistFingerprinting we previously
deferred to a Parent Document if we had one, and either the
principals matched or we were a null principal.
We will do the same thing, except we will also defer to our
opener as well as the parent document. Now about:blank
documents can be exempted.
However, this deferral only works if the opener is
same-process. For cross-process openers, we make the decision
ourselves.
We can make the wrong decision though. CookieJarSettings is
inherited through iframes but it is _not_ inherited through popups.
(Yet. There's some discussion there, but it's not implemented.)
Conceptually; however, we do want CJS to inherit, and we do want
RFP to inherit as well. Because a popup can collude with its
opener to bypass RFP and Storage restrictions, we should propagate
the CJS information.
This does lead to an unusual situation: if you have exempted
b.com, and a.com (which is not exempted) creates a popup for b.com
then that popup will not be exempted. But an open tab for b.com
would be. And it might be hard to tell those two apart, or why
they behave differently.
The third part of the patch:
3) In LoadInfo we want to populate information down from the
opener to the popup. This is needed because otherwise a
cross-origin popup will not defer to its opener (because in
Fission they're in different processes) and will decide if
it should be exempted itself. It's the CookieJarSettings
object that prevents the cross-origin document from thinking
it should be exempted - CJS tells it 'No, you're a child
(either a subdocument or a popup) and if I say you don't get
an exemption, you don't.'
Finally, there is one more caveat: we can only defer to a parent
document or opener if it still exists. A popup may outlive its
opener. If that happens, and something induces a call to
RecomputeResistFingerprinting, then (e.g.) an about:blank popup
may lose an RFP exemption that it had received from its parent.
This isn't expected to happen in practice -
RecomputeResistFingerprinting is only called on document creation
and pref changes I believe.
It is not possible for a popup to _gain_ an exemption though,
because even if the parent document is gone, the CJS lives on and
restricts it.
Differential Revision: https://phabricator.services.mozilla.com/D178866
This patch has three parts to it:
1) Use NS_IsContentAccessibleAboutURI to ensure that only safe
about: documents get exempted.
With this change, we will no longer allow about:blank or
about:srcdoc to be exempted base on URI. If they are to be
exempted, it will need to be base on other information.
2) In Document::RecomputeResistFingerprinting we previously
deferred to a Parent Document if we had one, and either the
principals matched or we were a null principal.
We will do the same thing, except we will also defer to our
opener as well as the parent document. Now about:blank
documents can be exempted.
However, this deferral only works if the opener is
same-process. For cross-process openers, we make the decision
ourselves.
We can make the wrong decision though. CookieJarSettings is
inherited through iframes but it is _not_ inherited through popups.
(Yet. There's some discussion there, but it's not implemented.)
Conceptually; however, we do want CJS to inherit, and we do want
RFP to inherit as well. Because a popup can collude with its
opener to bypass RFP and Storage restrictions, we should propagate
the CJS information.
This does lead to an unusual situation: if you have exempted
b.com, and a.com (which is not exempted) creates a popup for b.com
then that popup will not be exempted. But an open tab for b.com
would be. And it might be hard to tell those two apart, or why
they behave differently.
The third part of the patch:
3) In LoadInfo we want to populate information down from the
opener to the popup. This is needed because otherwise a
cross-origin popup will not defer to its opener (because in
Fission they're in different processes) and will decide if
it should be exempted itself. It's the CookieJarSettings
object that prevents the cross-origin document from thinking
it should be exempted - CJS tells it 'No, you're a child
(either a subdocument or a popup) and if I say you don't get
an exemption, you don't.'
Finally, there is one more caveat: we can only defer to a parent
document or opener if it still exists. A popup may outlive its
opener. If that happens, and something induces a call to
RecomputeResistFingerprinting, then (e.g.) an about:blank popup
may lose an RFP exemption that it had received from its parent.
This isn't expected to happen in practice -
RecomputeResistFingerprinting is only called on document creation
and pref changes I believe.
It is not possible for a popup to _gain_ an exemption though,
because even if the parent document is gone, the CJS lives on and
restricts it.
Differential Revision: https://phabricator.services.mozilla.com/D178866
This patch has three parts to it:
1) Use NS_IsContentAccessibleAboutURI to ensure that only safe
about: documents get exempted.
With this change, we will no longer allow about:blank or
about:srcdoc to be exempted base on URI. If they are to be
exempted, it will need to be base on other information.
2) In Document::RecomputeResistFingerprinting we previously
deferred to a Parent Document if we had one, and either the
principals matched or we were a null principal.
We will do the same thing, except we will also defer to our
opener as well as the parent document. Now about:blank
documents can be exempted.
However, this deferral only works if the opener is
same-process. For cross-process openers, we make the decision
ourselves.
We can make the wrong decision though. CookieJarSettings is
inherited through iframes but it is _not_ inherited through popups.
(Yet. There's some discussion there, but it's not implemented.)
Conceptually; however, we do want CJS to inherit, and we do want
RFP to inherit as well. Because a popup can collude with its
opener to bypass RFP and Storage restrictions, we should propagate
the CJS information.
This does lead to an unusual situation: if you have exempted
b.com, and a.com (which is not exempted) creates a popup for b.com
then that popup will not be exempted. But an open tab for b.com
would be. And it might be hard to tell those two apart, or why
they behave differently.
The third part of the patch:
3) In LoadInfo we want to populate information down from the
opener to the popup. This is needed because otherwise a
cross-origin popup will not defer to its opener (because in
Fission they're in different processes) and will decide if
it should be exempted itself. It's the CookieJarSettings
object that prevents the cross-origin document from thinking
it should be exempted - CJS tells it 'No, you're a child
(either a subdocument or a popup) and if I say you don't get
an exemption, you don't.'
Finally, there is one more caveat: we can only defer to a parent
document or opener if it still exists. A popup may outlive its
opener. If that happens, and something induces a call to
RecomputeResistFingerprinting, then (e.g.) an about:blank popup
may lose an RFP exemption that it had received from its parent.
This isn't expected to happen in practice -
RecomputeResistFingerprinting is only called on document creation
and pref changes I believe.
It is not possible for a popup to _gain_ an exemption though,
because even if the parent document is gone, the CJS lives on and
restricts it.
Differential Revision: https://phabricator.services.mozilla.com/D178866
Base64 encoding is done to top-level principal and the sub-principals
of expanded principals. Getting rid of the Base64 encoding entirely
also lets us use jsoncpp consider expanded principals to be entirely
serialized as JSON.
Differential Revision: https://phabricator.services.mozilla.com/D166783
Base64 encoding is done to top-level principal and the sub-principals
of expanded principals. Getting rid of the Base64 encoding entirely
also lets us use jsoncpp consider expanded principals to be entirely
serialized as JSON.
Differential Revision: https://phabricator.services.mozilla.com/D166783
In order to handle the content script case correctly we must expose the
contentScriptAddonPolicy to JavaScript. With that we can always see what
extension is trying to perform an action and use its name rather than internal
ID in the dialog.
Differential Revision: https://phabricator.services.mozilla.com/D161282
Sylvestre Ledru