[Webkit-unassigned] [Bug 206924] Content blocker: add an option to replace response with static content

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=206924

--- Comment #5 from Sam Sneddon [:gsnedders] <gsnedders at apple.com> ---
(In reply to Andrey Meshkov from comment #3)
> (In reply to Sam Sneddon [:gsnedders] from comment #2)
> > Are empty ("empty") resources sufficient for the vast majority of cases here?
> > 
> > (I'm aware there are some cases, like Google Analytics, where stub
> > implementations of the API might be necessary, c.f. bug 199173 and bug
> > 199704, but these seem to be exceptionally rare in comparison to just
> > wanting the load to succeed.)
> 
> In AdGuard filters there're over 1000 "redirect" rules.
> ~800 of them are different kinds of "noop" rules.
> 
> There's an important thing about them, though. About ~100of them are
> different versions of "noopvast" and "noopvmap" - special "stubs" for
> replacing VAST/VPAID XML files (files with video ads metadata).
> 
> I haven't checked exact numbers, but I am pretty sure the situation with
> uBlock Origin filters is similar to ours. 
> 
> Here're the full sources for static non-JS "stubs" we're using:
> https://github.com/AdguardTeam/Scriptlets/blob/master/src/redirects/static-
> redirects.yml

Right; realistically if WebKit owns the set of possible replacement files then it doesn't matter if they are "empty" or not, but the real desire is to keep them static to avoid a malicious content blocker from being able to load different replacement resources per-user and therefore add a trivial fingerprinting mechanism (e.g., imagine generating different window.uniqueUser = 2314321 JS files as replacements).

Yes, this makes it slightly more costly in terms of adding new files to the set, especially given you're blocked on the next release of the framework rather than being able to modify it within the extension, but hopefully adding a new file would be of comparable difficulty to modifying your YAML file and something other WebKit contributors (yourself or others!) could write patches for.

I guess there'd be some concern about the set of files becoming massive, but it doesn't look like the current set in that repo is very large.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210520/644a853b/attachment.htm>