AdBlock Plus as a ServiceWorker?

[David Rajchenbach-Teller]

From what I gather, ServiceWorkers are now The Right Thing To Do if a
webpage needs some off main thread pre/post processing on server-sent
data. This got me thinking that pre/post processing is exactly what
AdBlock Plus is doing.

So, I wonder: could AdBlock Plus be reimplemented using a slightly
beefed up browser-wide ServiceWorker? Could add-on authors similarly
implement, say, image-blocking for slow-connections using a similar
mechanism? What about anti-viruses, which could possibly perform scans
on e.g. swf before it is executed, using js-ctypes and ServiceWorkers?

Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[Ehsan Akhgari]

On 2015-05-07 7:07 AM, David Rajchenbach-Teller wrote:
> From what I gather, ServiceWorkers are now The Right Thing To Do if a
> webpage needs some off main thread pre/post processing on server-sent
> data. This got me thinking that pre/post processing is exactly what
> AdBlock Plus is doing.
>
> So, I wonder: could AdBlock Plus be reimplemented using a slightly
> beefed up browser-wide ServiceWorker? Could add-on authors similarly
> implement, say, image-blocking for slow-connections using a similar
> mechanism? What about anti-viruses, which could possibly perform scans
> on e.g. swf before it is executed, using js-ctypes and ServiceWorkers?

These types of add-ons are usually implemented by registering a content
policy implementation which is a service that we call into from the main
thread to determine whether or not to load content. Service workers
however are full fledged workers that are currently installed for a URL
scope under one origin, and they intercept the network fetch and have a
lot of power over what to do with it. They can just log the request,
and let it go to the network, synthesize an error response, send back a
cached response, or generate a dynamic response that may be fully
generated. IOW, they can do a *lot* more than a content policy
implementation.

There are two problems which make what you're suggesting not a great idea:

1. Because service workers run on their own thread, they add some
latency for determining what to do for each network request. Therefore
running them for all network requests across the entire browser is
probably impractical.

2. As they are currently implemented, they can only intercept the
requests that are coming from a specific scope under a specific origin.
Currently it's not possible to register a global service worker for
intercepting all network requests no matter where they are coming from.
Also, they cannot see the insides of a response for a cross-origin
request (which will essentially be all requests for a service worker
similar to what you have in mind) which makes them unsuitable for things
such as anti-virus scanners.

I think that service workers are probably too big of a hammer for
supporting use cases such as adblock, image blocking, etc. They are
probably the right level of abstraction for something like a swf virus
scanner but they're restricted in what they can do with those as I
mentioned above. And I suspect that as a mechanism for intercepting all
network requests, they will be too slow.

It's probably much better to come up with specific APIs for these use
cases where are current solutions are insufficient.

[Frederik Braun]

I thought that the APIs we brought into Firefox by implementing Tracking
Protection were supposed to provide a better (canonical?) way to hook
your own blocker into Firefox.

[Francois Marier]

Yes, as long as they're willing to stand up a server [1] that serves
their lists in a different format [2].

Francois

[1] https://github.com/mozilla-services/shavar
[2] https://developers.google.com/safe-browsing/developers_guide_v2

[David Rajchenbach-Teller]

So is there something that ABP developers can do at the moment to
reimplement their code without CPOWs & co? And is it documented anywhere
on MDN?

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Francois Marier]

On 21/05/15 07:01, David Rajchenbach-Teller wrote:
> So is there something that ABP developers can do at the moment to
> reimplement their code without CPOWs & co? And is it documented anywhere
> on MDN?

There's nothing like that at the moment, but I'd be happy to work with a
blocklist add-on developer to try and make it work.

Francois

[Bill McCloskey]

The only way to do this now is to register a content policy in the content
process using a frame script. That's how the shim stuff works internally.
There's some reference to this at [1].

I'm working on an API that should make this easier in bug 1157561. It's not
finished yet though.

-Bill

[1]
https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts

On Wed, May 20, 2015 at 7:10 PM, Francois Marier <fran...@mozilla.com>
wrote:

[tr...@adblockplus.org]

On Thursday, May 7, 2015 at 2:51:39 PM UTC+2, Ehsan Akhgari wrote:
> 1. Because service workers run on their own thread, they add some
> latency for determining what to do for each network request. Therefore
> running them for all network requests across the entire browser is
> probably impractical.

That latency will be there either way with E10S. We attempted to decentralize the decision making for Fennec back when it was using E10S - that didn't work well, lots of complexity but also latencies were introduced due to state syncing, and the memory usage exploded. So an E10S compatible implementation would still have all the decisions being made in one process - and content processes using synchronous messaging to contact it.

Still, I'm not entirely sure what the advantage of a ServiceWorker would be here. Would that make our processing merely delay the network request but not everything else that happens on the UI thread? That might offload the UI thread a bit, but I can imagine that the API would require significant changes in order to work for us. I see that there is Request.context but I cannot immediately see whether it is possible to deduce the frame structure somehow (i.e. which document made this request, what is the URL of its parent frame etc). Plus of course the issues already mentioned - running a separate ServiceWorker for each tab sounds wasteful.

[David Rajchenbach-Teller]

I'm willing to admit that ServiceWorker was something of a wild idea.
But yes, the original idea was to let a thread perform all
interceptions. It was my hope that we could extend ServiceWorker to have
one shared KindOfServiceWorker per process, which would avoid most of
the waste.

Now, if ServiceWorker is not the right API, what would be?

On 21/05/15 15:19, tr...@adblockplus.org wrote:
> That latency will be there either way with E10S. We attempted to decentralize the decision making for Fennec back when it was using E10S - that didn't work well, lots of complexity but also latencies were introduced due to state syncing, and the memory usage exploded. So an E10S compatible implementation would still have all the decisions being made in one process - and content processes using synchronous messaging to contact it.
>
> Still, I'm not entirely sure what the advantage of a ServiceWorker would be here. Would that make our processing merely delay the network request but not everything else that happens on the UI thread? That might offload the UI thread a bit, but I can imagine that the API would require significant changes in order to work for us. I see that there is Request.context but I cannot immediately see whether it is possible to deduce the frame structure somehow (i.e. which document made this request, what is the URL of its parent frame etc). Plus of course the issues already mentioned - running a separate ServiceWorker for each tab sounds wasteful.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Ehsan Akhgari]

On 2015-05-21 10:47 AM, David Rajchenbach-Teller wrote:
> I'm willing to admit that ServiceWorker was something of a wild idea.
> But yes, the original idea was to let a thread perform all
> interceptions. It was my hope that we could extend ServiceWorker to have
> one shared KindOfServiceWorker per process, which would avoid most of
> the waste.
>
> Now, if ServiceWorker is not the right API, what would be?

It depends on the specific use cases, and that is not something that I'm
closely aware of...

[tr...@adblockplus.org]

On Thursday, May 21, 2015 at 4:47:42 PM UTC+2, David Rajchenbach-Teller wrote:
> Now, if ServiceWorker is not the right API, what would be?

The webRequest-like API from bug 1157561 sounds pretty good, especially if it provides access to headers (Tom Schuster says that it does). However, we also need to get back from the request to the element that triggered it (this part can happen in a frame script). For some elements we simply need to hide them, for others we need to associate the request data with them so that it can be looked up later (and won't leak if the document is frequently adding and removing nodes). I'm not sure whether any general-purpose API can give us that - I suspect that a better strategy would be implementing both the chrome and the content parts of this ourselves.