So for RFP we need to change behavior based on the following conditions: 1. Is it the System Principal asking for something? 2. Are you PBM? 3. Is this a WebExtension asking for something? (Not counting content scripts, I believe those run in the context of the page and if they get spoofed data, that's fine. It's possible for the content script to communicate with a non-content script if it needs real data 4. Is it a non-content about: page? This would include privileged about pages like about:preferences, but also unprivileged ones like about:rights. It would not include ones that content can act on or interact with like about:srcdoc or about:blank 5. Is the site exempted via the ETP toggle? This exemption propogates down the iframe stack - if the top level document is exempted in this way, all iframes are exempted. 6. Is the site exempted via 'the other' mechanism? Right now 'the other' mechanism is a list of domains in a pref, in the future it will be something nicer. This exemption _does not_ propagate down the iframe stack - if the top level document is exempted this way, an iframe is only exempted if its domain is _also_ exempted. And if the top level document is _not_ exempted this way, the iframe is _not_ exempted even if its domain _is_ on the list. To accomplish (6) we need to look at CookieJarSettings. (5) is done via [ContentBlockingAllowList.h](https://searchfox.org/mozilla-central/source/toolkit/components/antitracking/ContentBlockingAllowList.h), all of which kind of cascade into checking the top-level document's principal and the pbm bit. I am not sure about URI_SAFE_FOR_UNTRUSTED_CONTENT - it looks like pages without URI_SAFE_FOR_UNTRUSTED_CONTENT are System Principal pages. But pages with URI_SAFE_FOR_UNTRUSTED_CONTENT we still want to exempt RFP on, for example about:welcome, about:pocket-home, and about:reader*. * I have an email out to verify that about:reader is safe to disable RFP on. I am trying to find a way to reliably enforce RFP on about:blank when appropriate in Bug 1805101 - that attempt at the moment is focusing on either finding a reference from the about:black document up the document chain so I can accurately query RFP on the parent (this is in the comments on the phab revision and I'm trying to test it) or pushing the correct RFP bit down into the about:blank document at creation (which is what the current patch does.) I'll need to look at BrowserContextGroup a bit more to figure out if replacing the Channel/Principal APIs is accurate for it. emilio recently refactored the RFP behavior on documents to cache the bit and a lot of stuff uses that to be both fast and accurate, so I'm not sure how that would behave in a switch to BrowserContextGroup also.
Bug 1830070 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So for RFP we need to change behavior based on the following conditions: 1. Is it the System Principal asking for something? 2. Are you PBM? 3. Is this a WebExtension asking for something? (Not counting content scripts, I believe those run in the context of the page and if they get spoofed data, that's fine. It's possible for the content script to communicate with a non-content script if it needs real data 4. Is it a non-content about: page? This would include privileged about pages like about:preferences, but also unprivileged ones like about:rights. It would not include ones that content can act on or interact with like about:srcdoc or about:blank 5. Is the site exempted via the ETP toggle? This exemption propogates down the iframe stack - if the top level document is exempted in this way, all iframes are exempted. 6. Is the site exempted via 'the other' mechanism? Right now 'the other' mechanism is a list of domains in a pref, in the future it will be something nicer. This exemption _does not_ propagate down the iframe stack - if the top level document is exempted this way, an iframe is only exempted if its domain is _also_ exempted. And if the top level document is _not_ exempted this way, the iframe is _not_ exempted even if its domain _is_ on the list. To accomplish (6) we need to look at CookieJarSettings. (5) is done via [ContentBlockingAllowList.h](https://searchfox.org/mozilla-central/source/toolkit/components/antitracking/ContentBlockingAllowList.h), all of which kind of cascade into checking the top-level document's principal and the pbm bit. I am not sure about URI_SAFE_FOR_UNTRUSTED_CONTENT - it looks like pages without URI_SAFE_FOR_UNTRUSTED_CONTENT are System Principal pages. But pages with URI_SAFE_FOR_UNTRUSTED_CONTENT we still want to exempt RFP on, for example about:welcome, about:pocket-home, and about:reader*. \* I have an email out to verify that about:reader is safe to disable RFP on. I am trying to find a way to reliably enforce RFP on about:blank when appropriate in Bug 1805101 - that attempt at the moment is focusing on either finding a reference from the about:black document up the document chain so I can accurately query RFP on the parent (this is in the comments on the phab revision and I'm trying to test it) or pushing the correct RFP bit down into the about:blank document at creation (which is what the current patch does.) I'll need to look at BrowserContextGroup a bit more to figure out if replacing the Channel/Principal APIs is accurate for it. emilio recently refactored the RFP behavior on documents to cache the bit and a lot of stuff uses that to be both fast and accurate, so I'm not sure how that would behave in a switch to BrowserContextGroup also.