Tests for implementation on manifest v3

[mneunomne]

Tests for implementation on manifest v3.

Some things we need to understand before attempting an implementation of "AdNauseam Lite":

1. Is it possible to implement ad-collection on UBOLite?
2. Is it possible to implement ad-clicking on UBOLite?
3. If we implement our own service worker for it, would it cause major performance issues as stated here https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-1253893421
4. Would the current interface be possible (or even make sense) for the v3, if not, should we make a specific "lite" design?
5. What is the impact of the change of source filters to AdNauseam, do we need to make a specific "lite" adnauseam-filters?

We should somehow attempt to test these things on the UBOLite build, even though it is rather at an early stage at the moment.

---

Links:

• AdNauseam v3 Discussion https://github.com/dhowe/AdNauseam/discussions/2188
• uBlock v3 Discussion https://github.com/uBlockOrigin/uBlock-issues/issues/338
• uBlock Lite description https://github.com/gorhill/uBlock/blob/master/platform/mv3/description/en.md
• Manifest v3 In-progress design doc: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#
• "Migrating to Manifest V3" (timeline) - https://developer.chrome.com/extensions/migrating_to_manifest_v3

[mneunomne]

Timeline

https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

January 2023	Manifest V3 will become a prerequisite for the Featured badge.	Enterprise policy can let Manifest V2 extensions run on Chrome deployments within an organization.Staring in Chrome 112, Chrome may run experiments to turn off support for Manifest V2 extensions in Canary, Dev, and Beta channels.
June 2023	All existing Manifest V2 items with visibility set to Public at that time will have their visibility changed to Unlisted.	Starting in June in Chrome 115, Chrome may run experiments to turn off support for Manifest V2 extensions in all channels, including stable channel.

---

AdNauseam timeline

The fact that AdNauseam is not on chrome store gives us more time than uBlock Origin for sure, but still means that we should have a ready stable solution as soon as possible after June 2023.

[mneunomne]

It seems that we would have to implement ad-detection around this function (among others)

https://github.com/gorhill/uBlock/blob/c7715d56bde427063bde6d916ba45a1a41e88751/platform/mv3/extension/js/scripting/css-generic.js#L128-L165

const uBOL_processNodes = ( ) => {
    const t0 = Date.now();
    const hashes = [];
    const nodes = [];
    const deadline = t0 + maxSurveyTimeSlice;
    for (;;) {
        pendingNodes.next(nodes);
        if ( nodes.length === 0 ) { break; }
        for ( const node of nodes ) {
            uBOL_idFromNode(node, hashes);
            uBOL_classesFromNode(node, hashes);
        }
        nodes.length = 0;
        if ( performance.now() >= deadline ) { break; }
    }
    for ( const hash of hashes ) {
        const selectorList = genericSelectorMap.get(hash);
        if ( selectorList === undefined ) { continue; }
        styleSheetSelectors.push(selectorList);
        genericSelectorMap.delete(hash);
    }
    surveyCount += 1;
    if ( styleSheetSelectors.length === 0 ) {
        surveyMissCount += 1;
        if (
            surveyCount >= 100 &&
            (surveyMissCount / surveyCount) >= stopAllRatio
        ) {
            stopAll(`too many misses in surveyor (${surveyMissCount}/${surveyCount})`);
        }
        return;
    }
    if ( styleSheetTimer !== undefined ) { return; }
    styleSheetTimer = self.requestAnimationFrame(( ) => {
        styleSheetTimer = undefined;
        uBOL_injectStyleSheet();
    });
};

[mneunomne]

Popup

The popup menu in theory could simply be substituted by ours again, and have the button to the "UBOLite Menu" like we have now with uBlock Origin

[mneunomne]

Dashboard

Not sure yet how much will uBlock still change their dashboard options, currently it looks like this:

It seems that we have to take a similar approach of avoiding to create a service worker from scratch to manage all our options current options.

[mneunomne]

AdVault

https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#state

It seems that on v3 there is no persistent state for the Service Workers (read above).

The stored data would need to be stored in using the Chrome Storage API, e.g.:

// background.js
chrome.runtime.onMessage.addListener(({ type, name }) => {
  if (type === "set-name") {
    chrome.storage.local.set({ name });
  }
});

chrome.action.onClicked.addListener((tab) => {
  chrome.storage.local.get(["name"], ({ name }) => {
    chrome.tabs.sendMessage(tab.id, { name });
  });
});
[#](https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#alarms)

[dhowe]

My feeling is that if it is easy to do, then we can consider the changes listed above. But I don't think we have the bandwidth for major changes, especially as we are not in the Chrome store anyhow. Not to mention the maintenance resources to support multiple versions (lite and regular). AdNauseam will work, as is, until at least June 2023, when Google may or may not start disabling MV2 extensions. Between then and now it might be a better use of our time to focus on support for other chromium-based browsers

[mneunomne]

Brave

It seems that Brave intends to support v2 manifest version, and perhaps even have their own web extension store seprate from Chrome:

https://github.com/brave/brave-browser/issues/20059#issuecomment-992720832

Yes - manifest v2 extensions will be supported by Brave 👍 We'll be taking steps as V2 is sunset by Chromium team (https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/)

During the deprecation period, we can keep this functionality via patch (since it's there for Enterprise). After V2 is pulled from store, we'll need to stand up our own extension store for manifest v2

[Coolguy3289]

Just discovered this, think it's a great project! I'm also curious now that we're at the end of June 2023 if there's been any progress or updates on the status of moving to mv3? Based on the reading I've done it seems like it will create a lot of limitations/reworking of the extension, but was just wondering if any work has been done to prep for this change as of yet?

[dnet890]

I understand that new Adnauseam Lite will be developed and it is quite different from the original one. Will this addon appear on chrome store?

[mneunomne]

Ok I finally was able to run some tests based on the UBOLite. I parsed altered some code here https://github.com/dhowe/AdNauseam/blob/master/platform/mv3/extension/js/scripting/css-generic.js.

Results

Is it possible to implement ad-collection on UBOLite?

Yes.

From the Content Script we can access the dom and run the queries on it, and instead using the vAPI to communicate between the content script and the "background script" (which is now the service worker), we use something like this:

chrome.runtime.sendMessage({ what: 'adDetected', data: data)

For the storage we use the chrome.storage API https://developer.chrome.com/docs/extensions/reference/api/storage.

Is it possible to implement ad-clicking on UBOLite?

Yes.

I tested a test ad visit on the background script, and it indeed occurred:

const sendFetchRequest = async function(ad) {
    const target = ad.targetUrl;

    console.log('[TRYING] ', ad, ad.targetUrl);

    try {
        const response = await fetch(target, {
            method: 'GET',
            credentials: 'include', // equivalent to xhr.withCredentials = true
            timeout: 5000
        });

        // Handle response
        if (response.ok) {
            const data = await response.text(); // or response.json() if expecting JSON data
            // Process data
            console.log(data);
        } else {
            throw new Error('Network response was not ok.');
        }
    } catch (error) {
        console.error('Error fetching data:', error);
    }
}

For the storage we use the chrome.storage API https://developer.chrome.com/docs/extensions/reference/api/storage.

Next tests

• Would Adn-Allow still be necessary? Since lists are not dinamically loaded anymore, we could soimply change the content of the list when they are constructed, needs more research.
• How to load AdNauseam filter list? Seems that there are new limitations for the ammount of filters available, also the manner in which they are loaded.
• Are there limitations for the storage capacity?
• Service Workers are not persistent, what is the impact of this in Ad-Visits? (we take intervals between them currently in AdNauseam, not sure if this is possible)

Feasibility

It would still depend on the points I have just listed above. But it seems like if we can get the ad-collection working on the content-scripts, and the ad-visit working in the background (perhaps not as smartly as we currently have implemented), we could possibly still have the AdVault and our Menu working basically the same, needing "only" to addapt it to the new vAPI, and storage system.

The Dashboard would need to be completely reduced, since there would be only "trusted domain list". Strict-blocking only makes sense if "adn-allow" is at all needed, which I am still unsure about.

So for me now, it seems realistic if we can keep our mv3 reduced like uBlock Origin did.

[dnet890]

For next Adnauseam that complies with Manifest v3. Will it support custom filter and block custom element same like previous version?