Upstream sanitizer api

[noamr]

Convert the incubated spec in https://wicg.github.io/sanitizer-api/ to the HTML format and make it part of the HTML standard.

• At least two implementers are interested (and none opposed):
  • Gecko/Chromium already shipping
• Tests are written and can be reviewed and commented upon at:
  • Remove "tentative" from sanitizer API tests. web-platform-tests/wpt#59400
• Implementation bugs are filed:
  • Chromium: already supported
  • Gecko: already supported
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=303808
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: already there: https://developer.mozilla.org/en-US/docs/Web/API/Sanitizer
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/canvas.html ( diff )
/comms.html ( diff )
/dom.html ( diff )
/dynamic-markup-insertion.html ( diff )
/edits.html ( diff )
/embedded-content-other.html ( diff )
/form-elements.html ( diff )
/forms.html ( diff )
/grouping-content.html ( diff )
/iframe-embed-object.html ( diff )
/image-maps.html ( diff )
/imagebitmap-and-animations.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/microdata.html ( diff )
/parsing.html ( diff )
/references.html ( diff )
/rendering.html ( diff )
/scripting.html ( diff )
/sections.html ( diff )
/semantics.html ( diff )
/system-state.html ( diff )
/tables.html ( diff )
/text-level-semantics.html ( diff )
/timers-and-user-prompts.html ( diff )
/web-messaging.html ( diff )
/webstorage.html ( diff )
/workers.html ( diff )

[noamr]

@zcorpan @evilpie @mozfreddyb @otherdaniel
initial review? :)
this is quite a big PR...

[evilpie]

Amazing, thanks for working on this.

The built-in safe default configuration is pretty integral to the API, where did I go?

For anyone else looking at this, the gist of the changes are in dynamic-markup-insertion.html.

[noamr]

Amazing, thanks for working on this.

The built-in safe default configuration is pretty integral to the API, where did I go?

Oh you're right I had it on my todo list and forgot. Getting to it. Thanks!

[noamr]

Amazing, thanks for working on this.
The built-in safe default configuration is pretty integral to the API, where did I go?

Oh you're right I had it on my todo list and forgot. Getting to it. Thanks!

Done.

[annevk]

I thought as part of moving this into the HTML standard we'd also address the parser integration issue?

[noamr]

I thought as part of moving this into the HTML standard we'd also address the parser integration issue?

This is a huge PR so I thought doing it in two stages, the first one being a purely technical upstream, would be easier to review?

Open and happy to incorporate the stream-while-parsing changes in this PR if you and @zcorpan are ok to review that in one go.

[noamr]

@zcorpan @annevk can we align on whether we upstream the sanitizer as is and then change it to stream-while-parsing, or do it in one go? I'm perfectly happy with both options.

[zcorpan]

I prefer doing the parser integration in a follow-up PR.

[evilpie]

I think these three PRs would be good to merge before merging into the HTML standard:

• Remove custom element state when is attribute is blocked WICG/sanitizer-api#396
• Refactor "is attribute allowed" WICG/sanitizer-api#385
• Replace replace all with steps from replaceWith. WICG/sanitizer-api#375

[noamr]

I think these three PRs would be good to merge before merging into the HTML standard:

• Remove custom element state when is attribute is blocked WICG/sanitizer-api#396
• Clarify condition by splitting it up into explicitly named bools. WICG/sanitizer-api#385
• Replace replace all with steps from replaceWith. WICG/sanitizer-api#375

Since some security sensitive changes rely on "sanitizing while parsing", and that in turn relies on the current post-processing sanitizer being upstreamed, I don't think we should delay upstreaming any further.

Can we race it? If any of these go in before the upstream PR is in I'll incorporate them into the HTML PR.

[noamr]

These algorithms look like they belong in infra... would people be open to adding an optional comparator predicate to those, or to the definition of list/order set?

@annevk @zcorpan

[zcorpan]

Moving this to Infra SGTM.

[noamr]

Opened whatwg/infra#709 for now.
I'm not sure about the comparator thing - infra doesn't really say what it means that two items in a list are the same. Would it be enough to mention here whaht makes items of attributes/elements/... lists "equal"

[otherdaniel]

Thank you, and I'm super happy to see this happening!

---

I wonder if we can link to the "Security Considerations" section in the current spec; or have them in a supplementary document somewhere?

[otherdaniel]

Thank you, and I'm super happy to see this happening!

---

I wonder if we can link to the "Security Considerations" section in the current spec; or have them in a supplementary document somewhere?

[noamr]

Thank you, and I'm super happy to see this happening!

I wonder if we can link to the "Security Considerations" section in the current spec; or have them in a supplementary document somewhere?

I've upstreamed them instead into a security consideration subsection

[noamr]

I've refactored some of the sanitization constants to go into each element's definition instead of being in one huge table. I think that makes it less error prone when we add new elements in the future. If that's undesirable I'm happy to revert.

[zcorpan]

Moving this to Infra SGTM.