<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Sebastian,<br>
<br>
Thanks for stating a thread for this. Let's see what we can do...<br>
<br>
Did you already file radars for the issues? If you did, can you give
the radar numbers? I'll link them with the meta radars tracking the
features requests we are getting for content blockers. If you did
not file radars, I'll do that.<br>
<br>
<div class="moz-cite-prefix">On 6/14/15 7:07 AM, Sebastian Noack
wrote:<br>
</div>
<blockquote
cite="mid:CAJvBVaJrLSa-xwA83n6EtXLwrsDheTPwWEjjNCgvGwWmtNqejg@mail.gmail.com"
type="cite">
<div dir="ltr">I'm from Adblock Plus, and just read the articleon
the WebKit website [1] about the new content blocking mechanism,
introduced with Safari 9. Thanks for providing some details. But
I identified following shortcomings that would effectively make
the new mechanism insufficient for us, or anybody supporting our
filters [2], which are used by popular filter lists, including
EasyList:</div>
</blockquote>
From the list, it seems to me that we should discuss concrete cases
instead of concrete solution.<br>
<br>
The content blockers in WebKit are vastly different from what
extensions do today. As such, a solution that works well for classic
extensions may not be the best way to solve the same problem in
content blockers. If you tell us about the actual problems (for
example an example of a website were you can't filter a resource),
it would be easier for us to identify what we can do.<br>
<blockquote
cite="mid:CAJvBVaJrLSa-xwA83n6EtXLwrsDheTPwWEjjNCgvGwWmtNqejg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>1. Most importantly, our exception rules are recursive. For
example ||<a moz-do-not-send="true" href="http://example.com">example.com</a>$document
prevents not only documents loaded from <a
moz-do-not-send="true" href="http://example.com">example.com</a>
being blocked. But also resources loaded as part of that
document or in any of it's subframes or their subframes
wouldn't be blocked either. However, this logic doesn't seem
to be possible with the ignore-previous-rules action. A
recursive flag would come handy here.</div>
</div>
</blockquote>
That seems feasible. I have a couple of ideas on how to best achieve
this.<br>
<br>
Including the subframes is a bit worrying to me. A subframe of a
trusted source is typically not to be trusted. Do you have examples
where that is useful?<br>
<blockquote
cite="mid:CAJvBVaJrLSa-xwA83n6EtXLwrsDheTPwWEjjNCgvGwWmtNqejg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>2. There doesn't seem to be a way to distinguish between
document and subdocument requests. While Adblock Plus blocks
frames, it never blocks the top level document, so that users
can still access the resource that is blocked, when entering
its URL in the address bar.</div>
</div>
</blockquote>
This sounds like a good idea for your use case.<br>
<br>
Any suggestion on the format? What would be the best way to specify
this in your opinion?<br>
<blockquote
cite="mid:CAJvBVaJrLSa-xwA83n6EtXLwrsDheTPwWEjjNCgvGwWmtNqejg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>3. A dedicated resource-type for XMLHttpRequests, objects
(requests loading a Flash element) and object subrequests
(subsequent requests issued by a Flash object) would certainly
be useful as well. EasyList has quite some filters
specifically checking for those.</div>
</div>
</blockquote>
Targeting XHR specifically seems very easy to counter to me.
Couldn't one just use the Fetch API or Sockets to work around the
rule?<br>
Do you have an example where the distinction matters?<br>
<br>
Regarding the object subrequest, that seems like a valuable thing to
do.<br>
<blockquote
cite="mid:CAJvBVaJrLSa-xwA83n6EtXLwrsDheTPwWEjjNCgvGwWmtNqejg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>4. Adblock Plus uses filters subscriptions (periodically
downloaded filter lists, like EasyList) as well as filters
added by the user, to decide what to block. So we'd need a way
to dynamically configure block lists. I saw the pre-release
announcements mentioning the new setContentBlocker API for
this purpose. I couldn't find any details on that, but I
assume that you can simply pass in a block list as JavaScript
object? But note that we'd need a way to invalidate previously
set blocking rules when filters in Adblock Plus changed.
However, a way to add new rules without flushing the
previously set block list would be extremely useful in some
cases as well. So ideally, this API should let you modify the
block list in place.</div>
</div>
</blockquote>
You can pass the rules as a JavaScript object, or as a serialized
JSON string.<br>
<br>
When you set a new content blocker, it replaces the old one.
Strictly speaking, the old one remains active until the new one is
compiled and then it is replaced.<br>
<br>
There is a technical reason why you cannot modify/add/delete
individual rules. In the engine, the rules are combined into giant
state machines. The concept of rule does not exist past the
compiler, after that all we have is a very simple bytecode
(<a class="moz-txt-link-freetext" href="http://trac.webkit.org/browser/trunk/Source/WebCore/contentextensions/DFABytecode.h">http://trac.webkit.org/browser/trunk/Source/WebCore/contentextensions/DFABytecode.h</a>)
that executes several thousands triggers at once.<br>
<br>
Note that compiling is not cheap. We are paying compile time when
loading rules in exchange for faster runtime and lower memory
footprint. How often do you need to update the rules?<br>
<br>
Cheers,<br>
Benjamin<br>
</body>
</html>