[webkit-help] blacklist limit and callback question
sign up
signup_mail2002 at yahoo.com
Sun Dec 13 11:42:22 PST 2015
Hi,
First of all is there a limit on how many URLs we can load for blocking (i.e.: blacklist) ? I read somewhere there was a near 50k whitelist rule limit in the mailing thread. So I am assuming similar limitation is available. The problem I have is that rules needs to be pre-loaded on the device. For hostname blocking I believe it should allow callback into the extension so we can do lookup locally (cached data) or remotely (cloud lookup). This allows more flexibility and memory efficient (less than 1Gb to work with). This would make blocking of URL by category (ex: adult content; violent/illegal content) filtering very simple. I wish Apple allowed this from their native parental control but this is the closest (and easiest) thing we have right now.
I wish URL blocking can be made smarter by only calling the extension when the address bar's URL is loading so there is no argument for performance. Right now the only argument is that loading every resource on a page triggers a callback to the extension can cause delay so pre-loading rules (and optimizing it is good). So doing the filtering of main URL before anything can clean cut the whole processing flow by terminating the analysis right away if it matches a blacklist (basically alot of companies would like to bring URL filtering to iOS).
Ideal flow:
1) main page loading - callback on main URL request - if blocked no further resources are loaded - callback to block logic; this is URL filtering logic2) callback to extension for each resource loading - this is content filtering logic (i.e.: ad blocking; tracking blocking, etc)
If we don't differentiate main page's URL loading with every other URLs on the page then we will end up treating everything as being equal which is feature limiting (i.e.: serials.ws is illegal so further filtering of every single resources of that page is irrelevant since you could block the page from the first URL request - same issue with proxy filtering, lack of context introduces inefficiency and higher network traffic cost). I hope webkit has enough context to make URL filtering a reality for iOS (without the cost of proxy).
Feedback welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-help/attachments/20151213/05d7c3b5/attachment.html>
More information about the webkit-help
mailing list