Re: AdBlock Plus as a ServiceWorker?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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, t...@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-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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 wrote: > 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 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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? On 08/05/15 11:21, Francois Marier wrote: > On 08/05/15 19:42, Frederik Braun wrote: >> 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. > > 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 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
On 08/05/15 19:42, Frederik Braun wrote: > 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. 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
AdBlock Plus as a ServiceWorker?
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 signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
