Incorrect application of "domainType: thirdParty" in DNR - blocking direct access to iana.org when opening a new tab

[105th]

Description:

I have encountered an issue where the DNR incorrectly applies rule with domainType: thirdParty, leading to the blocking of direct access to iana.org when opening it in a new tab, when this is a first-party request. As well as opening this site from example.org, when it is a true third-party request.

Steps to Reproduce:

1. Add test rule (you can do it from test extension)
   dummy-extension-chrome.zip
   dummy-extension-firefox.zip

{
  id: 1,
  action: {
    type: 'block',
  },
  condition: {
    domainType: 'thirdParty',
    urlFilter: 'iana.org',
    resourceTypes: ['main_frame', 'sub_frame'],
  },
}

2. Open a new tab in a browser with address 'iana.org'.
3. Observe that the page is blocked.

Expected Behavior:

iana.org should not be classified as a third-party domain when the user directly accesses it via the address bar.

Actual Behavior:

When accessing iana.org from address bar, it is being blocked as well as opening it from 'example.com'

Browser Details:

Tested on

• Chrome 131.0.6778.86 (Official Build) (arm64)
• Firefox 133.0 (aarch64)

[105th]

Also, there is another case, when we trying to convert our rule

# block all requests to facebook.com, but not block requests originated from facebook.com to directly visit it.
||facebook.com^$all,domain=~facebook.com

to DNR format:

{
    "action": {
        "type": "block"
    },
    "condition": {
        "excludedInitiatorDomains": [
            "facebook.com"
        ],
        "resourceTypes": [
            "main_frame",
            "sub_frame",
            "stylesheet",
            "script",
            "image",
            "font",
            "object",
            "xmlhttprequest",
            "ping",
            "media",
            "websocket",
            "other"
        ],
        "urlFilter": "||facebook.com^"
    },
    "id": 220,
    "priority": 56
}

And in this example i also cannot open facebook.com from address bar.

[maximtop]

I don’t know the actual implementation, but it seems that when a user enters a URL into the address bar, the origin of the request is considered about:blank. As a result, iana.org is treated as a third-party site in this context.

I believe it would be better if the URL were considered as originating from itself in such cases, if possible. This would resolve issues related to thirdParty determination and the handling of excludedInitiatorDomains.

[Rob--W]

If extensions are not already relying on the current behavior for "domainType", Firefox would be willing to change it. For example, we could consider a different domainType other than "firstParty" and "thirdParty" for (main_frame) requests without initiator.

Additional context:
Firefox has recently implemented support for domainType. The implementation was delayed due to unclarity over what "third-party" semantics we should implement, as highlighted at https://bugzilla.mozilla.org/show_bug.cgi?id=1797408#c1

Firefox ultimately chose to follow Chrome's implementation, described at https://bugzilla.mozilla.org/show_bug.cgi?id=1797408#c6 , fully quoted below:

For future reference, the domainType that we're going to implement here matches Chrome's behavior, mentioned at https://phabricator.services.mozilla.com/D212267?id=870402#inline-1177146

For reference, Chrome's behavior is as follows:

• first_party_origin = initiator or no origin
• document requests: sub_frame = parent origin, main frame = no origin
• ^ https://source.chromium.org/chromium/chromium/src/+/main:extensions/browser/api/declarative_net_request/request_params.cc;l=181-221;drc=ac83a5a2d3c04763d86ce16d92f3904cc9566d3a
• opaque origin (=no origin, null origin including sandboxed domain) = third party
• same base domain = first party, otherwise third-party
• ^ https://source.chromium.org/chromium/chromium/src/+/main:extensions/browser/api/declarative_net_request/request_params.cc;l=38;drc=ac83a5a2d3c04763d86ce16d92f3904cc9566d3a

This behavior in its turn is based on the meaning of "third-party" option in adblocker filters (aka 3p in uBlock Origin).
uBlock Origin also has a strict3p option (https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#strict3p), which is currently not supported in DNR. If you feel that this feature is necessary, consider filing a feature request in the WECG.

Note: I'm aware that DNR does currently not have the ability to filter by absent or opaque/null origin. I have written about the issue before at https://bugzilla.mozilla.org/show_bug.cgi?id=1798225

[oliverdunk]

Similar to Rob's comment at #731 (comment), we would be supportive of changing the behavior in Chrome if we could align on the desired behavior.

A simple fix may be to consider a request first-party if there is no initiator origin. That would be similar to what @maximtop suggested. Can anyone think of an issue with that?

It would be really nice if we could find an algorithm specified elsewhere that we can reference in our specification. I'm not sure what would be appropriate, but perhaps something related to strict same-site handling?