Running DOMPurify in a Web Worker

[fabiospampinato]

This issue discusses a performance issue deriving from DOMPurify's dependance on the DOM.

Background & Context

I work on a note-taking app which renders user-provided HTML documents, essentially. Those HTML documents must be sanitized, my goal is to do that as efficiently as possible. The problem is that given how DOMPurify works it's impossible for me to implement this well enough.

Initially I was just doing the following:

1. Turn the HTML into a DOM with DOMParser.
2. Sanitize the DOM with DOMPurify.

But there are multiple problems with that approach:

1. First of all sanitization time scales with the input, and it's synchronous so it blocks the thread, it follows immediately that I just can't run sanitization on the main thread if I want to provide great performance to my users under pretty much all scenarios.
2. Secondly when the HTML document is being edited by the user I probably don't actually need to sanitize it fully again, I can just split the HTML into top-level tags and sanitize each of them individually, with some caching this means only the top-level tags that changed will be sanitized again, which will be a massive speed up.

I can address the second problem pretty easily, but the first problem just can't be addressed because DOMPurify relies on the DOM, the DOM APIs aren't available in a worker context, userland implementations of DOM APIs like jsdom come with their own major issues (jsdom in particular in my experience is slow and massive), and alternative non-DOM-based HTML sanitization libraries like js-xss I just don't trust, if they work at all.

So assuming it's in DOMPurify's interest to be able to be used efficiently, what should be done to fix this?

Feature

I think the best way to address the issue is the following: DOMPurify already accepts a raw Node as input, if it "only" accepted a relatively simple NodeLike object too, which would be an object implementing a very restricted set of DOM-like APIs, then I as a user could parse my HTML string with a third-party HTML parser, and then provide a simple adaptor to it for DOMPurify. Basically DOMPurify would work largely the same way with potentially little change to its code, and users could run it in workers with relatively little work.

Essentially I think it's fine that DOMPurify needs a DOM-like API, but if it requires the entirety of the DOM APIs then it becomes a problem from a performance perspective, because it just can't be run in a worker.

Additionally it may be a good idea to provide an asynchronous version of the API which yields to the event loop every 5ms or so, so that no matter how big the input string is the thread will never just freeze indefinitely.

I hope these potential improvements will be implemented, as currently I don't see a way to use DOMPurify with predictable and acceptable performance.

[cure53]

Heya, I doubt we can easily implement that and we have no intention to provide support to work inside a worker.

We need the DOM to sanitize properly - and there are libraries already that offer exactly what you need, DOM-free HTML sanitization that should be fully compatible with workers.

[fabiospampinato]

we have no intention to provide support to work inside a worker.

Why not? Is being able to use DOMPurify performantly, i.e. without blocking the main thread for too long, not a goal of the project?

We need the DOM to sanitize properly - and there are libraries already that offer exactly what you need, DOM-free HTML sanitization that should be fully compatible with workers.

I'm not sure those two statements are compatible with each other, either one needs to use the DOM to sanitize properly and no proper non-DOM library exist, or one doesn't need the DOM, in which case a non-DOM library that works properly with it may exist, right?

I'm sure DOMPurify would work in a WebWorker context if I use something like jsdom to provide it with all the APIs it needs, and surely DOMPurify doesn't actually depend on all the ~10MB that make jsdom up. So could you keep this issue open to keep the discussion open on exploring defining a DOM-like interface for use with DOMPurify in a worker? I might be personally interested in working on that in the future, I don't think DOMPurify actually needs to change all that much.

Also I was also suggesting adding an asynchronous API that yields to the main thread every few ms, that has nothing to do with WebWorker.

[cure53]

Hmm, I can imagine that this is a major change and we don't have the capacity to plan, develop, test and release it. But, if you are interested in having a closer look yourself, I won't mind reviewing your PRs.

If the outcome is that we can get rid of jsdom, which is an incredible mess, then this would have actual benefits for everyone. But, as mentioned, right now we cannot take this task on ourselves - but are happy to review any incoming contributions.

[fabiospampinato]

Thank you 👍 I certainly plan to try to address this issue somehow in the future, I can't make any promises about how long it would take me though, most probably I won't be able to allocate time to this in the immediate future.

[cure53]

Aye, thanks! Closing this one for now then :)

[fabiospampinato]

Wonderful reference snippet combining LinkeDOM and DOMPurify and achieving sanitization in a worker context without all the bloat that comes with jsdom: preactjs/preact#3278 (comment)

It's probably not worth to spend time trying to improve on this, I'd say that pretty much addresses the issue I was reporting.

[cure53]

Oh, nice, thanks!

[CyberAP]

@fabiospampinato thanks for the link, I have tried it and must say that LinkeDOM probably is missing something that DOMPurify heavily relies on, since I basically get no sanitization whatsoever from the demo in jsfiddle (even with markdown step removed).

Screenshot

[Nantris]

@cure53 @CyberAP - I'm late to the party, and I make no claim to the correctness or safety of this approach (just spitballing with ChatGPT while investigating the code), and unfortunately it still doesn't work, but it does get us closer to the root cause of incompatibility, and whether it might be overcome.

Based on how linkedom works, I feel quite certain it cannot, but I fell down a rabbit hole and here we are.

import { DOMParser, parseHTML } from 'linkedom';

const dp = require('dompurify');

const output = parseHTML('<!DOCTYPE html>');
const makeCompatibleWithDOMPurify = abstraction => {
  const polyfill = (title = '') => {
    const { document: doc } = parseHTML(
      `<!doctype html><html><head><title>${title}</title></head><body></body></html>`
    );
    return doc;
  };
  abstraction.document.implementation = {
    createHTMLDocument: true,
    createDocument: polyfill,
  };

  function NodeFilter() {}

  // FILTER_* constants for acceptNode()
  NodeFilter.FILTER_ACCEPT = 1;
  NodeFilter.FILTER_REJECT = 2;
  NodeFilter.FILTER_SKIP = 3;

  // SHOW_* bitmask flags for whatToShow
  NodeFilter.SHOW_ALL = 0xff_ff_ff_ff;
  NodeFilter.SHOW_ELEMENT = 0x1;
  NodeFilter.SHOW_ATTRIBUTE = 0x2;
  NodeFilter.SHOW_TEXT = 0x4;
  NodeFilter.SHOW_CDATA_SECTION = 0x8;
  NodeFilter.SHOW_ENTITY_REFERENCE = 0x10;
  NodeFilter.SHOW_ENTITY = 0x20;
  NodeFilter.SHOW_PROCESSING_INSTRUCTION = 0x40;
  NodeFilter.SHOW_COMMENT = 0x80;
  NodeFilter.SHOW_DOCUMENT = 0x1_00;
  NodeFilter.SHOW_DOCUMENT_TYPE = 0x2_00;
  NodeFilter.SHOW_DOCUMENT_FRAGMENT = 0x4_00;
  NodeFilter.SHOW_NOTATION = 0x8_00;

  abstraction.NodeFilter = NodeFilter;
};

makeCompatibleWithDOMPurify(windowAbstraction);
const DOMPurify = dp(windowAbstraction)

I noted that with IN_PLACE: false the output is returned unchanged, but with IN_PLACE: true the return value is ''