Mailto links handled by Gmail fail with ERR_TOO_MANY_REDIRECTS

[ghostwords]

If you set up Gmail to handle mailto links in Chrome, clicking mailto links in Chrome with Privacy Badger installed will probably produce the following error page:

This page isn’t working mail.google.com redirected you too many times.

Try deleting your cookies. ERR_TOO_MANY_REDIRECTS

One workaround is to re-navigate to the URL you are already on. To do so, click on the address bar and press Enter.

A more permanent workaround is to set the toggle for mail.google.com to the rightmost, green ("fully allow") position. To do so, open Privacy Badger's options page, select the Tracking Domains tab, search for mail.google.com, and set the toggle to green.

Clicking the Reload button does not help.

[ghostwords]

At first glance, the problem is that our "remove cookies" DNR rule for mail.google.com, despite being scoped to domainType: 'thirdParty', is applied to mail.google.com requests in a new, mail.google.com browser tab.

This seems to be happening because these requests are technically initiated by the page you clicked the mailto link on. This then appears to be another argument for excludedTopFrameDomains (https://github.com/w3c/webextensions/issues/762).

It also seems like "domainType": "thirdParty" is buggy / does not work the way one would reasonably expect it to work.

[ghostwords]

Here is what the relevant DNR rule looks like (minus a million google.com country code domains in excludedInitiatorDomains):

{
    "action": {
        "requestHeaders": [
            { "header": "cookie", "operation": "remove" }
        ],
        "responseHeaders": [
            { "header": "set-cookie", "operation": "remove" }
        ],
        "type": "modifyHeaders"
    },
    "condition": {
        "domainType": "thirdParty",
        "excludedInitiatorDomains": [
            "google.com",
            "android.com",
            "blogger.com",
            "chromium.org",
            "gmail.com",
            "googleblog.com",
            "youtube.com",
            "ggpht.com",
            "googleusercontent.com",
            "googlevideo.com",
            "gstatic.com",
            "youtube-nocookie.com",
            "ytimg.com",
            "google.ac",
            "google.ws",
            "fonts.googleapis.com",
            "storage.googleapis.com",
            "www.googleapis.com"
        ],
        "requestDomains": [
            "mail.google.com"
        ]
    },
    "id": 1580,
    "priority": 3
}

[ghostwords]

This is not a problem in MV2 / with blocking webRequest because we keep our own tab state, and we compare the tab's (top frame's) host to request hosts when determining party-ness.

In MV3 / DNR, if I add the initiator domain of the page with the mailto link to excludedInitiatorDomains, the problem is resolved. This is obviously not a tenable workaround[^1], just evidence of what exactly we're running into.

[^1]: We cannot enumerate all domains that host pages with mailto links.

[Rob--W]

At first glance, the problem is that our "remove cookies" DNR rule for mail.google.com, despite being scoped to domainType: 'thirdParty', is applied to mail.google.com requests in a new, mail.google.com browser tab.

For truly new tabs opened by the user, the issue is tracked at:

• WECG: https://github.com/w3c/webextensions/issues/731
• Firefox: Bug 1961350 - [DNR] main_frame request without initiator should be firstParty, not thirdParty

[ghostwords]

I wasn't able to reproduce this problem in Firefox, only Chrome.

[ghostwords]

To reproduce in Chrome:

1. Download and unzip chrome-gmail-mailto.zip somewhere
2. Visit chrome://extensions, enable Developer mode, click Load unpacked, select the unpacked folder from previous step
3. Log into Gmail
4. Click on the crossed diamonds on the right of the address bar and allow Gmail to handle all mailto links
5. Visit a page with a mailto link, click it, and observe the "This site can’t be reached" error
6. Disable the demo extension in chrome://extensions
7. Click the mailto link again and observe that Gmail successfully opens
8. Re-enable the demo extension, click the mailto link again, and re-observe the breakage

The demo extension consists of a single DNR rule:

[
    {
        "action": {
            "type": "block"
        },
        "condition": {
            "domainType": "thirdParty",
            "excludedInitiatorDomains": [
                "google.com",
                "gmail.com"
            ],
            "requestDomains": [
                "mail.google.com"
            ]
        },
        "id": 1,
        "priority": 1
    }
]

Here is a screenshot of the blocked requests:

[ghostwords]

Opened crbug at https://issues.chromium.org/issues/413413551