[imports]: <link rel=import> shouldn't be active when added by innerHTML (bugzilla: 26898)

[hayatoito]

Title: [imports]: shouldn't be active when added by innerHTML (bugzilla: 26898)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26898

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26898#c0
Morrita Hajime wrote on 2014-09-24 20:07:27 +0000.

Reported at https://code.google.com/p/chromium/issues/detail?id=416036
As <script>, it should be disabled when injected by innerHTML.
cf. http://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml0

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26898#c1
Jonas Sicking wrote on 2014-09-24 20:51:51 +0000.

Why?

The <script> thing was mostly done in order to get compatibility with existing content. Specifically there was a lot of content out there that did things like:

<script>...</script> lots of content here

document.getElementById('elem').innerHTML += "hello world";

This code did not expect the script elements to execute again because back in those days dynamically inserted <script> elements almost never executed.

I don't think any of those reasons apply here.

First of all "reimporting" the same URL is a no-op since we de-duplicate imports, right?

Second, there's no existing content that we need to be compatible with since imports are a new feature.

The reason I'd rather not make exceptions for innerHTML is that it creates arbitrary and hard-to-learn inconsistencies. Why innerHTML but not outerHTML or insertAdjecentHTML? What about the jQuery provided $("markup here") and parseHTML?

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26898#c2
Morrita Hajime wrote on 2014-09-24 22:24:07 +0000.

Good question. Your points are valid.

I heard that the <script> blacklisting is a safeguard for reducing XSS.
Is it misunderstanding the intention of the spec?

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26898#c3
Jonas Sicking wrote on 2014-09-24 22:35:34 +0000.

The current limitation was mainly added in order to be compatible with the web. It was originally not added for any security reasons.

I don't think that blocking <script> in innerHTML is a meaningful XSS-prevention mechanism. But others might disagree.

[mikewest]

This is one of the few ways to directly execute script from innerHTML (other injection mechanisms require user input/events).

I agree with @sicking that this won't prevent XSS, but I disagree that it's not meaningful. Anecdotal, Google folks tell me that innerHTML is significantly more likely to contain XSS vectors than appendChild or document.write. I'd like to close this hole by treating <link> in the same way that we treat <script>.

+@annevk, how would you feel about adding the "already started" bit to a section of https://html.spec.whatwg.org/#parsing-main-inhead:already-started for <link>? It's only useful for imports at the moment, so... I have a patch up to make this change for Chrome, regardless: https://codereview.chromium.org/1670203002

[annevk]

I'm pretty sure that imports will go away. Last time the WG met we discussed a concept called "HTML modules" and the couple times before that nobody other than Google was interested in HTML imports. Although it has a specification, it isn't really part of the platform I think.

[rniwa]

I agree. I don't really care what happens to the HTML imports in its current form as that's not something we would be interested in implementing.

[devingfx]

Any teaser on future HTML modules ? :)

[TakayoshiKochi]

Let me close this issue as we do not spend time on HTML Imports moving forward.