Hacker News new | ask | show | jobs
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.

1 comments

I feel like the right solution to using the modern web is a allow-list based approach. Let the user be in control of the details of every request and response and action taken by the browser. Then everyone can choose their own way to interact with the web.