Use <iframe> contents if srcdoc is present but empty


#21

It’s probably wrong to assume that the main purpose intended by a spec editor is the only purpose that real-world authors would actually use the feature. For example, I would like to be able to put example documents with isolated styling into single article file without the need for using any escaping (or, all the more, juggling with separate files) and with proper highlighting in code editor. This has nothing to do with sandboxing hostile content.


#22

That’s literally everyone. Give people a secure and insecure way of doing something and some people will choose the insecure one and get rekt. Particularly when the insecure one looks more “natural”.

Then it is their choice. Forcing people to do things the “right way” (for some definition of that which resonates with you) is patronizing and against the spirit of the Web. But this is devolving into a philosophical argument at this point, which I’m not sure is particularly productive for this discussion.

In any case, if someone has zero concern for security, they won’t escape quotes either, making srcdoc just as insecure.

What are you doing that needs hand-authored iframe contents? The entire point of srcdoc is to help sandboxing; that’s why it was designed and implemented.

As MT pointed out, there are many use cases of iframes beyond sandboxing. Styling isolation, documents that can be saved individually, and many others that escape me right now. Don’t restrict a useful feature to one use case because that’s all that was all the WG could see at the time.


#23

So “hostile text” cannot be put into the attribute as is anyway, and there is no difference in terms of security between attribute and element contents.

Your quote omitted the rest of my post, which explicitly described what the security difference is between the two. It’s significant and real - experienced people commonly get HTML escaping wrong. A string-replace for a single character, on the other hand, is trivial.

@leaverou

As MT pointed out, there are many use cases of iframes beyond sandboxing. Styling isolation, documents that can be saved individually, and many others that escape me right now. Don’t restrict a useful feature to one use case because that’s all that was all the WG could see at the time.

Sure, you can come up with more uses. But it was designed to aid in security. Adding a minor usability affordance for non-core use-cases would be a major hole for non-expert users (the group this is designed to help) to accidentally do things wrong and get major XSS problems for non-obvious reasons. srcdoc is a security feature; whatever else you do with it is your business, but mixing it in with non-security use-cases and weakening its usability for security purposes is an extremely bad move. Security works only when it is simple enough to be ubiquitous; adding more ways for people to fail weakens that.


#24

// Unlike mailing lists, in a forum like this, quoting is used just to show a basic part of the replied message, that does not mean that the rest part of the original message has not been taken into account.

Could you provide a real-world example (non just pure theory as so far) demonstrating that the attribute is crucially more secure and better in general?


#25

Sure, you can come up with more uses. But it was designed to aid in security. Adding a minor usability affordance for non-core use-cases would be a major hole for non-expert users (the group this is designed to help) to accidentally do things wrong and get major XSS problems for non-obvious reasons. srcdoc is a security feature; whatever else you do with it is your business, but mixing it in with non-security use-cases and weakening its usability for security purposes is an extremely bad move. Security works only when it is simple enough to be ubiquitous; adding more ways for people to fail weakens that.

Fighting against an easier way to do something because you think it makes the existing way look unusable and unnatural in comparison is like trying to become taller by chopping off other people’s heads.

And btw, is escaping really that much harder? The contents of the <iframe> are not parsed as markup, they’re parsed as text until the first closing tag, as can be seen here. Therefore, the closing tag can be escaped. There are ways around this, but perhaps there could be a sandbox permission for that. Or require the contents to be wrapped in a <template> for extra inertness.

Also, it’s not just weird use cases (though the argument “this feature was not designed for that so we don’t care about your use cases” has failed many times in the Web’s history, as I’m sure you know). Authoring environments have not been designed for shoving HTML inside attributes. There is no code completion, no syntax highlighting etc. It breaks fundamental assumptions about what attributes are, and makes HTML harder to teach. I’d argue it’s not a “minor” usability improvement but that putting HTML in an attribute is a major usability impediment.


#26

Fighting against an easier way to do something because you think it makes the existing way look unusable and unnatural in comparison is like trying to become taller by chopping off other people’s heads.

There is no easier way to do the thing srcdoc is designed to do. You’re trying to get an easier way to do something quite different, but your suggestion if adopted will make it much easier to misuse srcdoc for its primary designed use-case and thus lose all the security benefits, particularly for the non-expert devs that srcdoc was explicitly designed to help.

What you want isn’t any easier for the cases srcdoc was designed for.

And btw, is escaping really that much harder?

Yes. Can you provide a full account of all the markup patterns that will be recognized as being a closing tag? No looking at the HTML spec’s parser section, that’s cheating - the point is that closing tags are definitely non-trivial to recognize, as they’re far wider than just a single search-and-replace can find. (If you do cheat, this is not a correct answer - those are the authoring requirements for valid HTML. What’s actually recognized as an end-tag is much wider.)

Or require the contents to be wrapped in a for extra inertness.

If you can trick the sanitizer into letting your </iframe> thru (thus escaping the sandbox and yielding a full-blown XSS), you can trick it into letting your </template> thru.

Authoring environments have not been designed for shoving HTML inside attributes.

And srcdoc wasn’t designed for authoring environments. It was designed to allow embedding presumed-hostile text into a webpage, with an absolute minimum amount of escaping needed to be absolutely safe. Anything you’re doing beyond that is exceeding what it was meant for, and diluting the security strength of the feature to accommodate non-core use-cases is not a good idea.

What I’m saying is that your request should be for something to directly support whatever stuff you want, not modifying srcdoc to become what you want. The latter is not going to happen because it defeats the entire point. The former, if I read between the lines of your request for an actual use-case, sounds like it’s just shadow DOM + some usability improvements for literal-HTML authoring, which is a reasonable v2 feature request.


#27

It is NOT Shadow DOM. Shadow DOM requires JS, whereas what I’m proposing is completely declarative*. Also, many use cases (e.g. separate saveable documents) require a separate document. Another use case is sandboxing, but not of hostile content (often needed in testing). Regarding the attribute name, it can be called flugelhorn for all I care. I just suggested srcdoc because it’s much more elegant to say that if it has a value, that value is used and if it doesn’t then its value is the element’s contents, than to define an entirely new attribute that someone has to learn as a separate thing. And for what? To protect authors from themselves? Most authors would find this rather insulting.

*FWIW, I would totally advocate for a declarative custom elements & shadow DOM spec, but that’s a topic for another thread.


#28

It is NOT Shadow DOM. Shadow DOM requires JS, whereas what I’m proposing is completely declarative*.

That’s why I explicitly said “shadow DOM + some usability improvements for literal-HTML authoring, which is a reasonable v2 feature request.”

And for what? To protect authors from themselves? Most authors would find this rather insulting.

This sort of attitude toward security features is terrifying. Yes, security features protect authors from themselves. That is literally their entire point. Nobody can write perfect code, so the less mistakes we allow to happen when trying to use a security primitive, the more likely the code will actually be secure.

*FWIW, I would totally advocate for a declarative custom elements & shadow DOM spec, but that’s a topic for another thread.

You opened this thread with a request for a spec change, rather than presenting an actual use-case you’re having trouble with. Once you elaborated on an actual use-case, it became clear that this is precisely Shadow DOM, it’s just missing some usability enhancements to handle the actual usage you’re trying to do. So, discussing Shadow DOM is the topic for this thread, unless you (reasonably) feel it’s too polluted with cross-talk and would like to restart the conversation fresh.


#29

Hell is paved with good intentions. You’ve still not provided a real-world example of why attribute is much better.


#30

This sort of attitude toward security features is terrifying. Yes, security features protect authors from themselves. That is literally their entire point. Nobody can write perfect code, so the less mistakes we allow to happen when trying to use a security primitive, the more likely the code will actually be secure.

Oh, please. That would apply if I was arguing to drop srcdoc as it is currently specced and only use the element’s contents. If the author has to put enough effort in this to escape something (quotes vs closing tag), they will most likely find out that the attribute approach is preferable for security. If the author doesn’t care about any of this, they won’t escape their quotes either. It’s not like one of the two offers magic security out of the box. Your point is like saying that CORS shouldn’t exist, because some authors could send CORS headers when that is not appropriate.

You opened this thread with a request for a spec change, rather than presenting an actual use-case you’re having trouble with. Once you elaborated on an actual use-case, it became clear that this is precisely Shadow DOM, it’s just missing some usability enhancements to handle the actual usage you’re trying to do. So, discussing Shadow DOM is the topic for this thread, unless you (reasonably) feel it’s too polluted with cross-talk and would like to restart the conversation fresh.

Nope. You’re seeing Shadow DOM because that’s your hammer. Style encapsulation was only ONE of the use cases mentioned. Others were sandboxing of non-hostile content (e.g. for testing), presenting individually saveable documents, and links to other pages that only affect an area of the page. Iframes have a ton of properties, style encapsulation is only one of them. I really don’t understand why you want to limit the potential and usability of such a useful feature for some theoretical security worry. The reason the feature was originally specced is irrelevant, what matters is how authors want to use it. Isn’t finding out what authors want the whole point of WICG? A few people have commented here about wanting this feature, and your attitude is rather dismissive.


#31

I think both sides have valid arguments here:

  • On the one hand having srcdoc be the only way to inline child documents today is a limitation, and there are decent use-cases for lifting that limitation.
  • On the other hand, srcdoc's security-enhancing characteristics seem to be an integral part of the feature. We shouldn’t corrode them in order to support non-security use-cases.

Maybe a separate attribute called something like unsafeinline would be a better fit, making it clear that it should only be used for non-hostile content?


#32

@leaverou also hinted at the possibility …

… it just got lost in the discussion.


#33

A string-replace for a single character, on the other hand, is trivial.

Actually, we need to replace at least two characters, the quoting character and the ampersand, and we need to do that in right order (ampersand first, quoting character second).

When using the XHTML syntax, we need to escape even more characters.

https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-srcdoc


#34

What are the implications when working with nested iframes?


#35

As I said, you don’t need to replace the ampersand; leaving it as-is has no security implications. It just might cause rendering issues as some text is accidentally interpreted as an escape, so you should replace it. But the quoting character is the only thing that’s required to replace for security guarantees.

Yeah, XML has its own set of stupid escaping requirements. It’ll fuck you up real good if you’re not careful. We couldn’t change that, unfortunately. :confused: