Re: [whatwg/dom] Declarative Shadow DOM (#831)

> XSS is not just added magically as far as I understand - it is added either though bad programming or modifyiable user generated content on web apps. And for latter you want to have opt-in security models stripping away everything a santizier does not know about even if it is an unknown attribute. For the first you want to focus on security over other concerns when developing web apps.

Right. In ideal world, every sanitizer will strip away anything it doesn't understand. I don't think that's the case today. 

> So when adding this to the html standard, we are not introducing XSS. Either bad programmers are or bad concepts about user generated content. Wrong?

I'm not certain that this will capture the full nuance of the situation. The Web platform strives to be forever forward compatible, meaning that any future addition to the platform is compatible with the existing Web content. If an existing web site currently doesn't have an XSS vulnerability, introducing new XSS vulnerability would be considered as a breaking change. This is why we've historically avoided introducing a new way of executing to avoid introducing XSS vulnerabilities on websites where such a mechanism isn't properly handled yet.

> > > > One way to mitigate this issue is to punt the parser behavior and just go with shadow element.
> 
> > > Using the  element wouldn't mitigate this at all. The concern is fundamental - any declarative shadow dom mechanism of any kind will suffer from this issue, by design. Why do you think  mitigates things?
> 
> > It would because any sanitizer won't consider scripts etc... inside a template element to be inert. This is because  will be parsed as a HTMLUnknownElement right now.
> 
> So what I understood from the sidebench, adding declarative shadow dom through the template-tag is of an issue here _because_ sanitizers are not strictly following an opt-in paradigm (as in: includes attributes), correct? So isn't the first issue here a fire-and-forget mind-set/security-model regarding sanitizers that shouldn't be trusted in the first place?

There is certainly a merit to making such an argument. However, this is not the approach we've taken historically. We would need some broader discussion and extraordinarily good reasons if we're fundamentally changing the way we add new API to the Web platform.

> **If the answer is no**, and the issue boils down to fundamentally changing the behavior of a 9-year-old tag, why go with the tag in the first place?
> 
> Instead where `<shadow>` may be what technical people (here) would make sense of a simple **`<component>`**-tag could be used instead of `<template>`. This would IMHO also perfectly match with what every-day authors would expect a component to be called like, wouldn't it?

Right.

The trouble lies in if we want to allow `<shadow>` to be parsed like `<template>`, which can basically appear anywhere. For example, you can't place `<shadow>` as a child of `<table>` because of the HTML parsing behavior. There are a few other odd behaviors in HTML which forbid `<shadow>` to appear as a child or a parent of certain elements. I've started to think this isn't so bad because our primary use case is custom element, and custom element can't appear wherever template appears either. Note that making `<shadow>` to behave like `<template>` will pose some serious XSS vulnesrabitliy risk (more so than re-using `<template>`) because it would necessarily affect the HTML parsing behavior.

Another potential issue is that `<shadow>` would display its contents like any other element and we probably don't want that prior to being moved into a shadow tree. So even though `<shadow>` can't appear everywhere `<template>` appears, we may still need to hide its contents in a special fragment like we do with `<template>`. Again, this at least poses a serious implementation complexity & cost, and may pose new kinds of XSS possibilities. I need to think about it more.

> So what's the answer? Is it the sanitizers basic design flaw, or not?

If I speak as someone who works on the Web security, then yes such a sanitizer design is flawed (or at least not forward compatible). As someone who works on a web browser, I can't break all such sanitizers even if I didn't necessarily think their design is great.

I emphasize with people getting frustrated here. This must be such an easy feature for browsers to add, you might think. In reality, there is a lot of nuances and issues we have to consider and take care of. So please don't be discouraged that this isn't going anywhere. If I thought this isn't going anywhere or a totally bad idea, I wouldn't be actively engaging in the discussion like this over weekends :)

-- 
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/831#issuecomment-716068028