Re: [whatwg/dom] What is the "security policy" for adding new events and elements to the Web Platform? (#913)

IMO, it will be hard to have this discussion without more/better examples.

The policy being discussed, and which I attempted to articulate in the other thread about declarative shadow DOM, is simply stated: "ensure 100% backwards compatibility with any sanitizer that works today or could work today in principle, no matter how oddly constructed."

I think it's clearer when we give these things names, and **I would propose to call this policy "No Sanitizer Left Behind," NSLB.**

NSLB stands in contrast with another rule which I think is much closer to the rule we actually follow on the web: "ensure 100% backwards compatibility with any _reasonable_ sanitizer, and certainly with any sanitizer in widespread use today." Let's call that **"No Good Sanitizer Left Behind," NGSLB,** in opposition to NSLB.

In the declarative shadow DOM thread, I argued that `<template shadowroot>` runs afoul of NSLB and that `<template onshadowroot>` would/does, too.

On the other hand, NGSLB would probably allow `<template onshadowroot>`, and `<template shadowroot>` would probably be allowed, too.

I say "probably" because NGSLB requires us to look at actual _data_. What do real sanitizers actually _do?S _Do_ they refuse to sanitize templates? _Do_ they strip all attributes starting with `on`, just to be safe, or is there a widespread sanitizer with a deny list? etc.

### NSLB doesn't forbid as much as you'd think

In your statement at the top of this thread, you give three other examples of what you thought NSLB would forbid:

1. Declarative custom elements
2. Any new HTML element
3. Any new HTML events

I don't think I agree with two of these examples. I think 2 would actually be _allowed_ under NSLB, and 1 might be as well; 3 would be forbidden, but that's probably good, actually.

#### New HTML Elements would be allowed under NSLB

I think new HTML elements are not strictly forbidden by NSLB, because `HTMLUnknownElement` exists. No sanitizer can be said to "work" today if it sanitizes only known, defined HTML elements, because it would be vulnerable on all modern browsers to attackers who made up a tag and attached an HTML event handler to it, e.g. `<foo onmouseover="alert('xss')">foo</foo>`. If the traditional behavior of browsers had been to leave unknown elements inert, _then_ a deny-list approach to sanitizing elements would work, but it absolutely doesn't work today, and so, at least in principle, we're allowed to introduce new HTML elements without violating NSLB, as long as it doesn't provide any _new_ vector for running scripts.

#### Declarative custom elements might be allowed, too… _without shadow DOM_

If you look at the explainer for declarative custom elements, it's basically just declarative shadow DOM wrapped in a new `<definition>` element. I see no way to use the `<definition>` element to run scripts except by virtue of the fact that the declarative shadow DOM _inside_ the `<definition>` element might be forbidden under NSLB.

Which is to say, declarative custom elements might well depend on declarative shadow DOM, and declarative shadow DOM in its currently spec'd implementation (`<template shadowroot="open"><script>alert('ohai'')</script></template>`) does seem to run afoul of NSLB, but that's just restating the original problem: declarative shadow DOM violates NSLB.

Declarative _custom elements_ don't violate NSLB except by using declarative shadow DOM, and if for some reason we thought it made sense to ship declarative custom elements _without_ declarative shadow DOM, I can foresee no _NSLB_ problems with that.

#### New HTML events (`onBlah` attributes) would be forbidden, and that's good, actually

As for forbidding any _new_ HTML events (`onBlah` attributes)… I think that might well be right. But, truth be told, I think _that_ is actually extremely reasonable. I think we should at the very least _hesitate_ before introducing any new HTML attribute (`onBlah` or otherwise) where the value of the attribute contains JavaScript that the browser will run.

If NSLB were officially the law of the land, and as a result there were a moratorium on new `onBlah` HTML attributes, I don't think we'd miss much, as long as it remained legal to use the _existing_ HTML attributes (`onclick` ,`onkeydown`, `onpointermove`, etc.)

As for Open UI specifically, it's hard to know in advance what specs Open UI will generate, but the only two proposals linked off of https://open-ui.org/ mention no _new_ event attribute names. `<checkbox>` would have `change` and `input` events… those both already exist. `<select>` includes `change`, `click`, and `keydown` events. Those all already exist, too. Those would all be legal under NSLB as a result.

Indeed, I'm not aware of anything on the Open UI list of form controls (breadcrumb, card, datepicker, slider, switch, table, tabs) that _would_ need a new `onBlah` attribute. I think we probably could forbid new `onBlah` attributes forever-ish, as long as the web continues to have the traditional keyboard + pointer interaction model it has today. (Maybe if/when it becomes possible to create and define VR objects in HTML, we can reopen this discussion…?)

### But maybe HTML events prove that NSLB is wrong and NGSLB is right

NSLB asks us to "ensure 100% backwards compatibility with any sanitizer that works today or could work today in principle, no matter how oddly constructed."

But the web _has_ added new HTML events in recent years without a major international XSS incident. I believe (without proof) that no sanitizer in common use today uses a deny list for HTML events precisely _because_ it's just so obvious that new ones come along every day. Anyone who started with a deny list for HTML attributes and got screwed when we added `onpointermove` learned their lesson years ago!

In the declarative shadow DOM thread, it was suggested that perhaps `<template onshadowroot>` would/should be allowed, even if `<template shadowroot>` isn't. IMO, if anyone thinks creating new `onBlah` HTML attributes should be allowed, then they have, wittingly or not, left the path of NSLB and accepted NGSLB into their hearts.

I think we can probably live with NSLB. But maybe we shouldn't.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/913#issuecomment-719825801