[Webkit-unassigned] [Bug 225861] Content Blocker: add a new action type - "scriptlet"

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Michael Catanzaro <mcatanzaro at gnome.org> ---
I'm going to try to nudge discussion along a bit.

> 3. "abort-current-inline-script" - https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#abort-current-inline-script
> 4. "abort-on-property-read" - https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#abort-on-property-read
> 5. "abort-on-property-write" - https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#abort-on-property-write

These three might be a reasonable starting point. One could argue that these are unlikely to cause worse privacy or security problems than simply blocking scripts from executing in the first place. Of course, that may not actually be true for a reasonably-complex website, but we could claim that the content blockers are designed to be "secure" provided that websites don't do something "insecure" when a script execution gets terminated early.

Of course, there's going to be some performance cost to implementing this, but I assume it could be done way faster if implemented as a feature of JSC relative to implementing it via a user script.

> 1. "set-constant" - https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#set-constant
> 2. "json-prune" - https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#json-prune

If the content blockers are really meant to be seriously untrusted, then these both seem *really* unlikely. At least I wouldn't want untrusted code messing with constants or JSON on my bank's website.

(In reply to Maciej Stachowiak from comment #1)
> Unlimited versions of these actions would defeat the security and privacy
> goals of Content Blockers, so we'd want to think about whether there are
> ways to achieve the same goal with narrower actions.

How untrusted are content blockers really intended to be?

I'm a little skeptical that it makes sense to consider the content blockers to be completely untrusted, since most users will use just one or two popular filters, like EasyList or whatever. And if developers who use content blockers are reporting that they're not flexible enough to block the content they want to block, that probably indicates we need a design rethink.

-- 
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/20210810/66b0b5a5/attachment.htm>