Adapt to the WebRequest API in MV3

[chunyuema]

The GPC signals are not updated for the extension as we still rely on the API that has been phased out since MV3. This issue attempts to address the upgrade of the WebRequest API to correctly append the GPC signal.

[ekuller]

I am looking into this now, working on migrating the backend to use declarativeNetRequest API. I think I have a good idea of how to do this and can give an update at the meeting tomorrow.

[chunyuema]

@ekuller, thank you for looking into this. We also need to update the logic, which we depend on when updating the GPC signals. For example, the following caching mechanism is unlikely to work since the service worker does not maintain these global variables. I can look more into this.

[ekuller]

1. In order to track third party requests I had to make the service worker persistent. This is due to a bug that prevents the service worker from waking up when the webRequest listener should be called. I used a solution from stack overflow. If we decide we do not want to use this work around we will have to get rid of tracking third party web requests.
2. I have migrated the gpc backend for scheme 6 to use the declarativeNetRequest API, and suggest how we should migrate the backend for the other schemes below:
   • [ ] Scheme 0- use updateDynamicRules API to create and manage the urls/domains on which we want to enable/disable gpc
   • [x] Scheme 1 - similar to scheme 0, but if gpc is enabled on all future domains we add a universal rule as in scheme 6 and add domains whose requests we don't want to enable gpc on to the "excludedDomains" property
   • [x] Scheme 2 - I think the gpc backend would be handled in the implementation of scheme 1's backend, if not, it would require the same features
   • [x] Scheme 3 - after the profile is selected, we would dynamically need to add a rule that is applied to all urls and customize the "domains" property to the profile; the rule we need to be removed and updated if the profile is updated in the options page
   • [x] Scheme 4 - similar to scheme 3, aside from how domains are selected
   • [x] Scheme 5 - similar to scheme 1 and 3
   • [x] Scheme 6 - static rule that sets gpc universally and is enabled and disabled dependent on setting (already implemented)

[SebastianZimmeck]

This is also of interest to @kalicki1 and @OliverWang13.

[ekuller]

@bella-tassone, @chunyuema, and I met on Saturday and discussed delegation of webRequest/GPC migration. These are the tasks I have come up with for the coming week:

1. @chunyuema -- update dynamic rule (I think only one rule really needs to exist at a time for this purpose) when user profile changes in schemes 3-5, setting the domains condition equal to an array of the appropriate domains dictated by the disconnect list; something like:

   chrome.declarativeNetRequest.updateDynamicRules({addRules:[{
   "id" : 1,
   "action" : { "type" : "modifyHeaders",
     "requestHeaders": [
         { "header": "Sec-GPC", "operation": "set", "value": "1" },
         { "header": "DNT", "operation": "set", "value": "1" }
       ]},
   "condition" : {
     "urlFilter" : "|*"
     "domains": [LIST_OF_DOMAINS_TO_SEND_GPC_TO]
   }
   }], removeRuleIds:[1]
   })

2. @bella-tassone -- add and remove rules that set GPC for individual urls for schemes 0-2 and learning phase of 5; use {chrome.runtime.sendMessage({greeting: "NEW RULE", d: currentDomain, id: domains[currentDomain].id})} and {chrome.runtime.sendMessage({greeting: "RM RULE", id: domains[currentDomain].id})} . When adding domains to the domain list they should now contain two properties: domains[currentDomain].id=Object.keys(domains).length+1 and domains[currentDomain].id set to true or false dependent on whether we are sending GPC. Code that uses the values of domains[currentDomain] currently should be updated to use the values of domains[currentDomain].id (decent amount of refactoring). I can definitely help you with this.
3. @ekuller -- help with Bella's large task if/when needed and implement logic/rules for when there is customized domain list, but universal setting for all future urls being visited.

declarativeNetRequest Documentation

[SebastianZimmeck]

Nice plan and teamwork!

[chunyuema]

Note from the discussion yesterday

1. Below is a conceptual overview of how our extension is currently working. This might be a good reference to have a quick overview of everything we have changed so far @SebastianZimmeck

2. The plan moving forward:
   • Banner UI Layer: @bella-tassone
   • Options page UI Layer: @ekuller
   • Rule Set Layer: @chunyuema

[SebastianZimmeck]

Very nice, @chunyuema! (Maybe, even put this, or a final version, in the readme as an architectural overview.)