Well met.

I wrote a WebKit content filter for surf. It is over a hundred lines of ugly 
and slow, so no patch is included, but surf is now in my future. I'd be happy 
to continue kludging along with my own podge of content-mining tools, but I'd 
also be pleased to put on a spit of polish and share it with others. So:

Is anyone interested in using surf with WebKit content filtering?

If so, I'd like to see your must-have features and can't-have excesses. But a 
mere yea or nay would also be informative, if perhaps more suitable for direct 
contact.

My thought, at the moment: this idea is good, but both launch delays and 
time-to-fix need to be minimized.

Launch delays might be a problem as WebKit seems to want to compile the 
filtering binary from a json rules file upon  each and every launch. But I 
believe that is an optimization issue which I can address later. (Short term, 
I'll do what I can and you can opt out. Perhaps, medium-term, mimic 
emacs-server. Long term, maybe help develop an API that abstracts the renderer 
from the interface -- I suspect one imperative of "suck less" is "pipe more".)

Time-to-fix is a fascinating design challenge. I'm assuming a 
deny-globally/allow-exceptionally approach, so every page is broken and many 
will need to be unbroken to the user's satisfaction -- with minimal 
interruption to flow. I see a two-tier solution: (1) a surf patch that 
escalates permissions along a compile-time configurable continuum, and (2) a 
distinct utility that facilitates request auditing and rule authoring (which 
I'm tempted to name 'turf'), as if uMatrix meets the web inspector pane and has 
a baby which is raised by curl. But it might be more suckless to determine 
rules at compile time and leave authoring and such to a completely independent 
utility.

I'm open to -- I'm asking for -- criticism and guidance.

Would a translator to/from uBlock dynamic rules facilitate interest? (I'm 
thinking about doing this anyhow.) How about apps that apply the same rules to 
iOS/macOS Safari? (Already part of my daily kit.) Or expanding the 
request-auditing utility to include overlapping webdev tools? (I've little clue 
what you do, but I'd benefit from learning more. Yeah, I over-sold you in 
paragraph seven. Sorry. I'm incurably optimistic, both an under- and 
over-achiever. As will happen here.)

Your feedback is truly welcome, even if entirely negative. Questions are 
encouraged; accessibility concerns will be given particular attention.

I salute you who make such projects possible. One cheer for those who can; two 
cheers for those who do; three cheers for who came before and made it 
tried-and-true.

Sincerely,
Jon

Reply via email to