[gruez]

In section 3.2.2 they mention being able to handle obfuscated/minified scripts, but based on the description it doesn't look very robust. Any sort of anti-debug/tampering would break this, eg. storing the value of window.localstorage somewhere, then comparing it against the value of window.localstorage when you try to access it. If the values differ, there's probably some debugging/tampering going on, and the site can hold the content hostage and demand you turn off the protections. I'm not sure why they don't just patch the javascript runtime environment (ie. the implementation of window.localstorage itself). That would be much more robust and harder to detect. Plus, you don't have to mess around with rewriting scripts.

[mintplant]

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.

[pabs3]

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.

[NiekvdMaas]

Looking at the source code [1], I have to agree with you. This is very easily detectable by anti-tampering scripts. Using JS Proxies would have been a better approach, although that is detectable as well (see e.g. [2]). To be really undetectable, the mocks should have been done on V8-level.

1. https://github.com/brave-experiments/sugarcoat/blob/master/m...

2. https://github.com/abrahamjuliot/creepjs

[mintplant]

You can't turn existing global objects into proxies, unfortunately.