Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
The benefit of doing this client-side instead of server-side is that you can stay up to date with any changes that the client may make to how it's processing HTML that may have security implications. Additionally, you get to use the exact same code that the browser is ultimately using to parse the HTML, so a browser parsing bug, spec nuance, or un-specced legacy behavior that your backend developer didn't consider don't turn into serious security flaws.
Additionally, the Sanitize API does a much better job of handling contextual parsing then many other similar backend APIs. What happens when you parse an HTML fragment assuming it will live in a `div`, and then it actually get inserted into a `table` cell? The spec goes into this is more detail here: https://wicg.github.io/sanitizer-api/#strings
The downsides, of course, are those associated with any thick-client/thin-server API design—more logic on the front-end means more logic to reimplement for different consumers.
Personally, I would probably still stick with Nokogiri for my own applications, but I can see both sides of the trade-off.
>I have yet to see where Chrome is explicitly telling anyone they plan to phase out support for adblockers, nor where they are making it clear that is their intention.
That was never their intention, not what the uproar was about, so it's to be expected that you're not seeing any evidence of it. The problem with Manifest V3 is not that it disables adblockers; not sure where you got that idea from.
The problem is that it severely restricts how effective they can be. Many of the things uBO does cannot be done in v3. That's what the uproar is about.
https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...