[webkit-help] Feedback and questions regarding Content Blocking Extensions

Thu Aug 13 16:22:10 PDT 2015

By doing some "refactoring" of the rules, if-domain and unless-domain seem sufficient for my use cases.

There is just one case that can’t be elegantly fulfilled right now: when a user navigates to a given webpage (either through an hyperlink or by typing the webpage’s URL in the address field) and that webpage is in the user’s whitelist for an active content blocker.

First, since the URL won’t always be just a valid domain, there is no easy way to ignore the rules for the given webpage and all its content.
Second, even when the URL is a valid domain, it might be inefficient to use ignore-previous-rules in this case. Please note that I insist on the “might” since I’m quite ignorant about the content blocking implementation.

In both cases, it may be a good idea to have a new action type: “whitelist” (or “ignore-all-rules”). Please note that this wouldn’t be the exact opposite of “ignore-previous-rules” (the exact opposite would be “ignore-next-rules”).

This would be something like this:

    {
        "action": {
            "type": “whitelist"
        },
        "trigger": {
            "url-filter": "apple\\.com/mac"
        }
    }

or for a full website:

    {
        "action": {
            "type": “whitelist"
        },
        "trigger": {
            "url-filter": “.*”,
	    “if-domain": “*apple.com”
        }
    }

When the user opens a new webpage, the engine should first evaluate the whitelist rules. If the rule activates for the current URL, all the other rules of the current content blocker should be ignored.

It is actually possible to go even further. Indeed, the whitelist rules are frequently updated since they are mostly user-generated — the user decides which websites or webpages he/she doesn’t want to block — and, as stated above, they should always be the first rules to be evaluated and are therefore completely independent from the other rules. Therefore it may be better to create a separate whitelist JSON file for the content blocker. This way, it is no longer necessary to recompile the whole blocker list every time a user adds or remove an URL from the whitelist.

> On Aug 13, 2015, at 11:58 PM, Alex Christensen <achristensen at apple.com> wrote:
> 
> Right now, if-domain and unless-domain are the only features that query the main document URL.  This is a known limitation, and something we’ve been thinking about.  If you have suggestions of ways to do this that are elegant and perform well with thousands of such rules, we would welcome such input.
>> On Aug 13, 2015, at 2:54 PM, Romain Jacquinot <rjacquinot at me.com <mailto:rjacquinot at me.com>> wrote:
>> 
>> Thank you for your quick reply.
>> 
>> The if-domain only solves half the issue. For instance, if I want to whitelist all pages under the apple.com <http://apple.com/> domain, it works with something like this:
>> 
>>     {
>>         "action": {
>>             "type": "ignore-previous-rules"
>>         },
>>         "trigger": {
>>             "url-filter": ".*",
>>             "if-domain": ["*apple.com <http://apple.com/>"]
>>         }
>>     }
>> 
>> It also works with subdomains, like appleid.apple.com <http://appleid.apple.com/>:
>> 
>>     {
>>         "action": {
>>             "type": "ignore-previous-rules"
>>         },
>>         "trigger": {
>>             "url-filter": ".*",
>>             "if-domain": [“*appleid.apple.com <http://appleid.apple.com/>"]
>>         }
>>     }
>> 
>> However, if I only want to whitelist a given webpage like apple.com/mac <http://apple.com/mac>, this doesn’t work:
>> 
>>     {
>>         "action": {
>>             "type": "ignore-previous-rules"
>>         },
>>         "trigger": {
>>             "url-filter": "apple\\.com/mac",
>>             "if-domain": ["*apple.com <http://apple.com/>"]
>>         }
>>     }
>> 
>> This also doesn’t work since this is not a valid domain:
>> 
>>     {
>>         "action": {
>>             "type": "ignore-previous-rules"
>>         },
>>         "trigger": {
>>             "url-filter": ".*",
>>             "if-domain": ["*apple.com/mac <http://apple.com/mac>"]
>>         }
>>     }
>> 
>> Is there currently some way to only whitelist a given webpage and have all its resources loaded?
>> 
>>> On Aug 13, 2015, at 11:24 PM, Alex Christensen <achristensen at apple.com <mailto:achristensen at apple.com>> wrote:
>>> 
>>> Thank you for your bug reports.  Feedback like this helps improve our development.
>>>> On Aug 13, 2015, at 9:49 AM, Romain Jacquinot <rjacquinot at me.com <mailto:rjacquinot at me.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> After a few days experimenting with Content Blocking in Safari, I have a few questions / some feedback:
>>>> 
>>>> 1) There are currently no recursive exception rules. It is therefore not possible to whitelist a full website or webpage, i.e. ignoring all rules regardless of where the content comes from. I've filed a bug report at bugreport.apple.com <http://bugreport.apple.com/>: #22268224. Are there any plans to add this feature before the release of iOS 9.0 and OS X 10.11?
>>> This is what if-domain and unless-domain are for.  Sometimes a website needs a very specific rule that would break other websites, or a common rule would break a certain website.  Try something like this:
>>> {"action": {"type": "ignore-previous-rules"},"trigger": {"url-filter": ".*","if-domain”:”*example.com <http://example.com/>”}}
>>>> 
>>>> 2) Enabling content blockers from Safari Settings may be complicated for some non-tech-savvy users. It would be great to be able to open Safari Settings directly (or even better Content Blockers' Settings) from a third-party app using URL-schemes. Bug report: #22217664
>>>> 
>>>> 3) With iOS 9.0 (13A4325c), content blocking doesn’t work on iPad, only in the simulator. I've filed a bug report at bugreport.apple.com <http://bugreport.apple.com/>: #22217578. Is it a known bug?
>>>> 
>>>> 4) There doesn’t seem to be a way to programmatically enable/disable a previously-enabled content blocker without having to go through the compiler again when re-enabling it. I’ve filed a bug report at bugreport.apple.com <http://bugreport.apple.com/> (#22270848) with an example of use case.
>>>> Thanks.
>>>> 
>>>> Romain
>>>> _______________________________________________
>>>> webkit-help mailing list
>>>> webkit-help at lists.webkit.org <mailto:webkit-help at lists.webkit.org>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-help <https://lists.webkit.org/mailman/listinfo/webkit-help>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-help/attachments/20150814/291c7bab/attachment-0001.html>