DNR: Add excludedTopFrameDomains (and topFrameDomains)

[ghostwords]

In addition to excludedInitiatorDomains (and initiatorDomains). Having excludedTopFrameDomains (and topFrameDomains) would solve the problem of excluding (or including) requests based specifically on the top-level document's domain, not the initiator's (immediate parent frame's) domain.

excludedTopFrameDomains will work just like excludedInitiatorDomains with the one difference being that excludedTopFrameDomains compares against the top-level frame's domain instead of the immediate parent frame's domain.

Developers should be able to feature detect the availability of excludedTopFrameDomains, so that they can use it when it is available and fall back on excludedInitiatorDomains otherwise.

For a real world example of what this would solve, see EFForg/privacybadger#3048 (comment)

[oliverdunk]

Chrome is supportive of this. It seems like a compelling use case and a good proposal to achieve the desired behavior.

[Rob--W]

What is the expected behavior if the top level is about:blank, e.g. a popup opened by https://example.com ?

[ghostwords]

We should fall back on the initiator in this edge case? Maybe we also want matchAboutBlank and matchOriginAsFallback properties? #673 seems related.

[kzar]

@oliverdunk FWIW I created a Chromium issue for this a while back (though calling it tabDomains/excludedTabDomains), and I drafted a patch too. It didn't get merged in the end, because Devlin (fairly) requested a design document and I never got a chance to write one. I'd be happy to update my patch to get this in Chromium once we're agreed about how it should work. Just let me know if that would help.

In case it helps, some notes from the discussions in that earlier issue:

• I agree with the approach proposed here as I understand it - adding support for new domain conditions (e.g. topFrameDomains/excludedTopFrameDomains or tabDomains/excludedTabDomains), that work in a similar way to the existing domain conditions (e.g. requestDomains/excludedRequestDomains). But for completeness, woxxom on the old Chromium issue proposed we should instead consider a new syntax instead that covers other use cases too.
• "For requests where there is no tab (e.g. requests made by ServiceWorkers), the rule condition is matched against an opaque origin instead."
• Fenced frames complicated matters in the implementation, but IMO these new domain conditions should ignore those. So in other words, the conditions should match the "logical domain of the entire page itself" instead of just the closest main frame parent of a request.

[ghostwords]

"For requests where there is no tab (e.g. requests made by ServiceWorkers), the rule condition is matched against an opaque origin instead."

Let's say we want to block example.net globally, except on example.com. What happens when an example.com service worker makes requests for example.net? Will having example.com in excludedTopFrameDomains of the block rule that targets example.net correctly allow those requests, or? Should we fall back on the initiator in such cases?

[ghostwords]

By the way, here is another real-world problem caused by "domainType": "thirdParty" not working as expected and/or excludedInitiatorDomains being the wrong tool for the job: EFForg/privacybadger#3066

[kzar]

@ghostwords with your example, I figure the excludedTopFrameDomains condition would not allow the ServiceWorker initiated requests. I figure adding an excludedInitiatorDomains condition would do the job there like you say, and hopefully give extension developers more flexibility. But it's been a while since I dug into this stuff, would the initiator domain be set as needed for such requests?

[oliverdunk]

Thanks @kzar - exciting to hear that you might be interested in contributing a patch for this. I hadn't seen the Chromium issue before today, but when I last spoke to Devlin about this he didn't feel as strongly about having a more flexible syntax. Let me check in with him, likely next week as I'm OOO from tomorrow. I'd then be happy to help with opening a proposal given there is interest in implementing this.

[ghostwords]

I figure adding an excludedInitiatorDomains condition would do the job there like you say, and hopefully give extension developers more flexibility. But it's been a while since I dug into this stuff, would the initiator domain be set as needed for such requests?

Yeah, I think service worker-initiated requests have the service worker domain as the initiator.

The problem with specifying example.com in both excludedTopFrameDomains and excludedInitiatorDomains is that we want to allow example.net to load when loaded in the context of the example.com website (whether via a service worker or not), but not when loaded on some other website from an example.com frame. We don't always want to look at the initiator, only when we don't have a top frame domain ("tabless" service worker-initiated requests). Does that make sense?

[kzar]

Yea, I see what you mean. I think you're right that it makes sense for topFrameDomains/excludedTopFrameDomains conditions to fall back to matching against initiator domain where there's no associated tab for the request. (I was going to say you could have a second rule, with a initiator domain condition and a tabIds: [-1] condition, but that would potentially require a bunch more rules + tabIds conditions are limited to session rules.)

[kzar]

@oliverdunk I've had a go at drafting the API proposal document this afternoon. Any chance you and Devlin can take a pass?

(I went with the name tabDomains/excludedTabDomains so far, but I don't feel too strongly - happy to go with what folks prefer. I initially went with topFrameDomains/excludedTopFrameDomains, but I was finding the API docs kind of hard to word, e.g. to explain the distinction between URL of the request, request initiator, and the request's associated tab.)