|
|
|
|
|
by mintplant
1674 days ago
|
|
Hey, author here! Kinda shocked to see this on HN. Regarding anti-tampering: this work is in a "taking the Web as we found it" kind of model. We focused on improving the existing state of the art for content blocking and resource replacements rather than adversarial environments deliberately trying to get around SugarCoat. There are already other ways that sites try and circumvent URL-based blocking anyway—bypassing SugarCoat won't be the low-hanging fruit. We touch on this in the discussion section of the paper, but if a script is making itself too much of a problem, filter list authors can always opt to block it entirely. Regarding patching the runtime environment: other systems have done this, but they haven't been adopted. Deep engine modifications are hard to get upstreamed and, absent an actual standard, don't give you cross-browser compatibility. SugarCoat-generated scripts can be (and are!) deployed in existing content blocking systems today, and aren't locked to one particular browser. |
|