Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
105th opened this issue Dec 4, 2024 · 3 comments
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time

Comments

@105th
Copy link

105th commented Dec 4, 2024

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'],
  },
}
  1. Open a new tab in a browser with address 'iana.org'.
  2. 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)
@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Dec 4, 2024
carlosjeurissen referenced this issue in carlosjeurissen/webext-tech-demo-extensions Dec 5, 2024
@105th
Copy link
Author

105th commented Dec 5, 2024

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
Copy link

maximtop commented Dec 5, 2024

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
Copy link
Member

Rob--W commented Dec 5, 2024

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:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time
Projects
None yet
Development

No branches or pull requests

3 participants