Sanitizer built-ins document

[otherdaniel]

This is meant as a starting point for our built-ins. It's a "mostly free-form" document, in that it's just text with one line per element, plus markdown-style headings. The idea is to classify elements and attributes into groups.

I started out putting everything into "other", and then moving them into better defined groups. The idea is to work down the "other" list until it's empty.

I copied all the elements from the "proposed allow lists" doc into the "harmless" category. Will do the same for attributes.

Source(s):

• Elements & attributes lists from Chrome. (Which may include legacy elements no longer supported.)
• "Proposed allow lists -- Sanitizer API - 2024-03" document prepared by Frederik.

[mozfreddyb]

FYI, this PR is still called "Not ready yet". Let me know when you are seeking review.

[otherdaniel]

FYI, this PR is still called "Not ready yet". Let me know when you are seeking review.

About now would be good, so I renamed it. :)

I added more "sections" with spec links, also for attributes. I think that should cover all of HTML; while SVG + MathML coverage is still a bit of a mess. There are a lot more leftover ("other") attributes than there were with elements.

Changes so far are:

• I copied the per-element attributes from the HTML spec, for any element that I expect to be default-allowed. (It's a manual process, so I was trying to save myself some time.)
• I also copied global HTML attributes + aria attributes from the spec(s), including spec links.
• I removed all attributes that are used locally somewhere from the global list. I'm not sure this is quite correct.
• All of this was manual, so I wouldn't be surprised if there are some omissions somewhere. I'm unsure how to do QA here.

[annevk]

Thanks for making this list. Very useful to have something based on the HTML standard. Here's an initial very conservative safelist for "default":

• html
• head
• title
• All of Sections (body, article, ...)
• All of Grouping Content (p, hr, ...)
• Most of Text-level Semantics:
  • a attributes target, referrerpolicy, download, and ping I would omit
• All of Edits (ins, del)
• All of Tabular Data
• SVG & MathML: TBD
• Global attributes:
  • dir
  • lang
  • title

[mozfreddyb]

👍 to what @annevk says, that we should build upon the HTML spec rather than casting the widest net.

As written in #245, I could see us being a bit more iterative by using his relatively small list for now and discussing additions individually as they come up (which they are bound to anyway).

[otherdaniel]

• Updated list according to Anne's suggestion.
• Changed the list format a little, and added a python script that turns it into JSON.
• Included this and baseline config from the spec.
• Moved the builtin files (json, text, script) to a builtins/ directory.

[mozfreddyb]

What should we do here? In spec purity terms, I believe we should stick to those in the HTML standard and make a big note that many engines support non-standardized and add them as a hint or such?
But In reality, I can see this going wrong.

@evilpie: How would we best identify the list of supported event handler attributes in Gecko?

[annevk]

We should probably just check if an attribute is a https://html.spec.whatwg.org/#event-handler-content-attributes. We could then maybe non-normatively list all of them (they're also in an index in HTML). Implementations can do roughly the same thing they do for Trusted Types.

[evilpie]

In Gecko, Trusted Types currently uses the EventNameList.h.