declarativeWebRequest: detecting which rule was matched

[Michael Gundlach]

AdBlock lets advanced users see all the resources requested by a tab, and which ad blocking filters matched which ones.  I'm thinking about how to do this using declarativeWebRequest as it currently stands, and came up with:

1. Every RequestMatcher's actions includes a SendMessageToTab whose message specifies the original ad blocking filter that created the RequestMatcher.

2. There's a super-low-priority catch-all RequestMatcher whose SendMessageToTab specifies that the resource was not blocked.

3. Every tab runs an onMessage handler storing the map from resource to filter (or lack of filter).

4. If the user requests to see the map, show-requested-resources.html fetches it using sendMessage() to the current tab, and displays it.

Is there an easier way than that?  I don't like having to run an onMessage handler for every requested resource; that's part of what declarativeWebRequest was designed to eliminate.

A couple API changes that could make this less painful:

1. Let the extension request that Chrome start logging all resources and which RequestMatchers they matched, if any, on a specific tab.  Then the extension can stop logging and retrieve the log.  (The log could truncate after N entries so a broken extension won't eat memory wildly.)  AdBlock would then require that the user reload the current tab in order to generate and view the log.

2. Add an asynchronous declarativeWebRequest.whichRuleWouldBeTriggeredBy(request_details),  letting the rule engine be queried without attempting to fetch a resource.  Then extensions can just log all requested resources, and feed them one at a time to declarativeWebRequest if needed.

Chrome team, do either of those sound plausible?  Any better ideas?

Michael

[Dominic Battre]

Hi Michael,

On Tue, Nov 13, 2012 at 7:03 PM, Michael Gundlach <adblockf...@gmail.com> wrote:

AdBlock lets advanced users see all the resources requested by a tab, and which ad blocking filters matched which ones.  I'm thinking about how to do this using declarativeWebRequest as it currently stands, and came up with:

1. Every RequestMatcher's actions includes a SendMessageToTab whose message specifies the original ad blocking filter that created the RequestMatcher.

2. There's a super-low-priority catch-all RequestMatcher whose SendMessageToTab specifies that the resource was not blocked.

3. Every tab runs an onMessage handler storing the map from resource to filter (or lack of filter).

4. If the user requests to see the map, show-requested-resources.html fetches it using sendMessage() to the current tab, and displays it.

Is there an easier way than that?  I don't like having to run an onMessage handler for every requested resource; that's part of what declarativeWebRequest was designed to eliminate.

A couple API changes that could make this less painful:

1. Let the extension request that Chrome start logging all resources and which RequestMatchers they matched, if any, on a specific tab.  Then the extension can stop logging and retrieve the log.  (The log could truncate after N entries so a broken extension won't eat memory wildly.)  AdBlock would then require that the user reload the current tab in order to generate and view the log.

If we require the user to reload the current tab in order to generate and view the log, we can use also your steps 1.-4., where 0. would be "Replace all rules with rules that generate logs" and 5. would be "Restore the original rules". I think this would work.

It would require an onMessage handler for each requested resource. Even with your original proposal the situation should be better than for the current WebRequest API because these onMessage events are asynchronous and don't block the resource loading.

 

2. Add an asynchronous declarativeWebRequest.whichRuleWouldBeTriggeredBy(request_details),  letting the rule engine be queried without attempting to fetch a resource.  Then extensions can just log all requested resources, and feed them one at a time to declarativeWebRequest if needed.

I see three concerns:

- code duplication (every condition need to be checkable on the internal URLRequest and the details object), or

- limitations on the expressiveness of filters (they can only process what is shown to the extension, which may be a subset of information available) and

- possibly a slowdown (because every internal URLRequest needs to be mapped into a details object for each request).

The first proposal sounds better in my opinion.

Best regards,

Dominic

 

Chrome team, do either of those sound plausible?  Any better ideas?

Michael

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.