Add `ORB_BLOCK_REASON` to learn more about the reasoning of orb blocking in the wild.
Add ORB_BLOCK_INITIATOR to learn about the initiators. We can add more probes in the future if we want to target a specific initiator.
Differential Revision: https://phabricator.services.mozilla.com/D178102
nsHttpChannel::OnAuthCancelled calls nsHttpChannel::CallOnStartRequest
directly, effectively bypassing
HttpBaseChannel::ProcessCrossOriginSecurityHeaders, which is needed to
get CORP handling right.
Differential Revision: https://phabricator.services.mozilla.com/D177778
Add a separate check for spec breaking allows of certain MIME
types. Having this separated out means that we can make the rest of
the implementation behave exactly like spec.
Some tradeoffs that we need in the current state are:
* Allowing "application/dash+xml"
* Allowing "application/vnd.apple.mpegurl"
* Allowing "text/vtt"
* Allow all MIME types beginning with "audio/mpeg"
* Allow "text/plain" when there is a no-sniff header.
Differential Revision: https://phabricator.services.mozilla.com/D176821
We make sure to not send any data to the content process in case of
fetching an opaque resource. This is way to remain more web
compatible, but is also in conflict with the ORB specification.
Differential Revision: https://phabricator.services.mozilla.com/D173454
Content processes can do nothing to the responses of nsIContentPolicy::TYPE_BEACON,
nsIContentPolicy::TYPE_PING and nsIContentPolicy::TYPE_CSP_REPORT requests, so filter
them out of the ORB_DID_EVER_BLOCK_RESPONSE probe to not worry them for
web compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D173292
With HTTPS-First top-level loads can have a loading principal, so we
need to explicitly check the load info if we're doing a top-level
load.
Differential Revision: https://phabricator.services.mozilla.com/D171315
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
Since Bug 1802086, we strip authentication headers when redirected to a cross-origin page. However, the api ReferrerInfo::IsCrossOriginRequest used for determining whether a request is cross-origin cannot be used as it compares the triggering principal's uri with the redirected channel's uri. This comparison might sometimes yield to false positives.
For e.g consider the following scenario:
1. Load `https://example.org/` and send the following fetch request from browser console
```
fetch("https://test.com/some_location", {
"headers": {
"Authorization": "Token foo"
}
});
```
2. Server responds with a redirect to https://test.com/another_location
In the above scenario, the api ReferrerInfo::IsCrossOriginRequest will yield the above request as cross origin since the triggering principal uri here is example.com. Hence, this will be treated as cross-origin redirect resulting in removal of auth headers.
Thus ReferrerInfo::IsCrossOriginRequest has been replaced with nsScriptSecurityManager::CheckSameOriginURI where we directly compare the origins for the two requests.
Differential Revision: https://phabricator.services.mozilla.com/D170868
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
This particular request is used to identify the potential timeout issue
for HTTPS only requests. ORB doesn't need to block this request.
Differential Revision: https://phabricator.services.mozilla.com/D170251
Devtools use its own mainThreadFetch to fetch resources when it's
needed. For example, fetching the content of a source file. Importantly,
these request use `TYPE_OTHER` which could be blocked by ORB. Having
ORB block requests coming from devtools break some of it
functionalities.
Differential Revision: https://phabricator.services.mozilla.com/D170250
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
We should only need to start nsCompressedAudioVideoImageDetector when
nsUnknownDecoder is not going to be started. Generally, they are not
designed to be working together.
Differential Revision: https://phabricator.services.mozilla.com/D163063
With this patch we also try to align a bit more with the current in
development spec at: https://whatpr.org/fetch/1442.html#orb-algorithm
The tests:
* fetch/orb/tentative/known-mime-type.sub.any.js
* fetch/orb/tentative/unknown-mime-type.sub.any.js
specifically tests the case of UNKNOWN_CONTENT_TYPE, i.e. the case
where the `orb-algorithm` fails to extract a MIME type from the
response headers.
Differential Revision: https://phabricator.services.mozilla.com/D161142
Devtools can generate fetch request on behalf of the content document,
reporting these requests in PerformanceObserver would cause confusion,
so we should ignore them.
Differential Revision: https://phabricator.services.mozilla.com/D162582
Our current code uses PeekStream to get the data and pass them
over to the sniffer, however it doesn't count the case where the
contents are compressed, so the sniffer would fail to determine
the type of contents.
This patch we creates a child class of nsUnknowDecoder to utilize
its ability to hold off of calling the next OnStartRequest until
the contentType is determined, we also overrides DetermineContentType
method to make it focuses on decoding the compressed contents only.
Credit goes to farre since he pointed out this solution.
Differential Revision: https://phabricator.services.mozilla.com/D161167
There's no point of blocking requests that users want to download,
and these requests are only being handled the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D160845
This patch starts to actually blocking opaque responses
for most type of the resources that are defined in the spec.
There are still pieces missing such as blocking JSON responses,
and this is why it's called partially implemented.
This patch was originally written by farre, and I made some
modifications based on it.
Depends on D155128
Differential Revision: https://phabricator.services.mozilla.com/D155129
Currently, if users enabled COEP:Credentialless by Origin-Trial,
it won't put the document into an isolated process, this patch
fixes.
Though the caveat is this only works for enabling Origin-Trial
in the response header, setting it via <meta> still won't work.
Differential Revision: https://phabricator.services.mozilla.com/D158684
UserAgent() needs a parameter because it previously was
calling the non-fine-grained RFP check. It can't call the
fine-grained check, so it needs to be told what to do.
AddStandardRequestHeaders calls UserAgent() and needs to
know what to pass it.
Differential Revision: https://phabricator.services.mozilla.com/D144582
Everywhere except one loadInfo is supplied to an HTTPChannel
right after it is Init()-ed. Inside of Init we would like to
use the loadInfo so we'll put it in there.
Differential Revision: https://phabricator.services.mozilla.com/D144580
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Given the Fetch spec, the TAO check algorithm has been updated to
be more restricted. This patch updates the algorithm to match the
spec.
Differential Revision: https://phabricator.services.mozilla.com/D146737
According to the latest Fetch spec, we should generate a opaque
PerformanceResourceTiming entry for cross origin redirects, rather than
not generating it at all.
Plus the timings for cross-origin redirects won't be leaked unless all
redirects pass the TAO check.
Differential Revision: https://phabricator.services.mozilla.com/D146580
This patch is more conservative for requests initiated by add-on and prefers
to send no Origin header instead of Origin: null.
Differential Revision: https://phabricator.services.mozilla.com/D147091
