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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Thank you for your bug reports. Feedback like this helps improve our
>>> development.
>>>> On Aug 13, 2015, at 9:49 AM, Romain Jacquinot <[email protected]
>>>> <mailto:[email protected]>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-help
>>>> <https://lists.webkit.org/mailman/listinfo/webkit-help>
>>>
>>
>
_______________________________________________
webkit-help mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-help
