- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 15 Nov 2010 21:46:48 +0000 (UTC)
On Mon, 9 Aug 2010, Justin Schuh wrote: > > I'm working on implementing iframe.srcdoc in WebKit, and section 2.5.1 > states: > > "This specification defines the URL about:srcdoc as a reserved, though > unresolvable, about: URI, that is used as the document's address of > iframe srcdoc documents." > > It seems like it would make more sense for the address to be the data > URL of the frame's document. This would be easier to implement in > WebKit, and I expect other data URL supporting browsers as well. Is > there some reasoning I'm missing for the decision to use about:srcdoc? My concern is that using data: would be too easy for implementors, leading to some subtle yet very hard to fix bugs. :-) For example, the origin handling for data: URLs and srcdoc="" is not intended to be identical (though it might be currently, I haven't checked). Yet if we reuse data:, it's likely that implementations will make it identical regardless of what the spec says. There's also the DOCTYPE/quirks issue, where a data: document might act differently if opened in its own tab than if put in using srcdoc="". On Thu, 26 Aug 2010, Justin Schuh wrote: > > What should the baseURL and referrer be for a @srcdoc nested browsing > context? The base URL was "about:srcdoc". Oops. Fixed to be the base URL of the parent document, like about:blank. (Be careful when implementing this to follow the chain all the way up in the case of nested srcdoc iframes.) > The referrer seems trickier. I couldn't find the about:blank referrer > behavior specified anywhere, and in my testing it does not inherit the > creator document's referrer. However, it seems to me that maybe > about:srcdoc should, even if about:blank does not. When the srcdoc="" is used with sandbox="" set without allow-same-origin, the Referer header is omitted. At other times, you are correct that it wasn't well-defined (it was theoretically required to be "about:srcdoc"). I've updated the fetching algorithm to make about:srcdoc documents use the parent document's URL in such situations (again going up the iframe chain until it hits a non-srcdoc document). On Mon, 30 Aug 2010, Tab Atkins Jr. wrote: > > While talking with the implementor of @srcdoc in Webkit, it came up > that, though @srcdoc is *designed* for use with @sandbox, the author > still has to explicitly add @sandbox to the <iframe> or else they don't > get the sandbox security model. > > Can we make this automatic? Specifically, when <iframe > srcdoc=foo></iframe> is specified (without @sandbox), it drops into the > sandbox security model as if <iframe sandbox srcdoc=foo></iframe> was > used. If @sandbox is explicitly added, its value is instead used, so > the author can set the sandbox security flags if desired. > > This would mean that there is no way for an author to use @srcdoc > *without* sandboxing. This appears to be a minority use-case in the > first place (as far as I can tell, it's pretty much just useful for > testing purposes), but the author can always use a data: url in that > case. On Mon, 30 Aug 2010, Maciej Stachowiak wrote: > > I think it's better to let these remain orthogonal features. In general > I think it is a net negative to usability when Feature A implicitly > turns on Feature B. Implicit relationships like this make the Web > platform more confusing. On Mon, 30 Aug 2010, Tab Atkins Jr. wrote: > > While I agree with you in general, in this particular case I cannot. > @srcdoc wasn't designed as an orthogonal feature - it was explicitly > built with @sandbox in mind, to allow authors to shove generic content > into the sandbox without incurring a network request. It has only niche > technical use outside the context of @sandbox. > > Further, omitting @sandbox seems like an easy mistake to make, and one > that you won't realize is a mistake until an attack gets through. > Avoiding that sort of security model was precisely why @srcdoc was > designed the way it was - we want to make it hard to fail, and obvious > when you do. On Mon, 30 Aug 2010, Maciej Stachowiak wrote: > > Should @seamless imply @sandbox too, then? On Mon, 30 Aug 2010, Adam Barth wrote: > > I think there lots of use cases for seamless that don't require sandbox. > For example, suppose a site wants to show a login form on many pages by > only wants to implement the login logic once. It's entirely reasonable > to wish to place the login form in a seamless iframe. If we required > @sandbox for seamless, that would interfere with the login form working > properly with password managers. On Mon, 30 Aug 2010, Ojan Vafai wrote: > > I'm not convinced this is that small of a use-case even if it's not the > primary one. We should provide a way to turn off sandboxing if we're > going to make it the default for anything. On Mon, 30 Aug 2010, Tab Atkins Jr. wrote: > > Precisely; @seamless was *not* designed with the intention of always > being used with @sandbox. It's just a nice feature to have for > <iframe>s in general. So there's no real connection between @seamless > and @sandbox like there is between @srcdoc and @sandbox. On Mon, 30 Aug 2010, Maciej Stachowiak wrote: > > @seamless was in fact designed to help @sandbox meet more use cases (in > particular ones where embedding untrusted content in a fixed rect is not > sufficient). But it can be used without @sandbox, and has some plausible > uses along those lines, though they were not the initial use cases > considered. LIkewise for @srcdoc. Indeed, many use cases are well-served > by using all three in tandem. > > My point being, don't mix up orthogonal features in arbitrary ways. If > @srcdoc implies @sandbox, but @seamless does not, someone reviewing for > security has to remember exactly which set of similar-sounding > attributes cause sandboxing, instead of following the simple rule "just > look for @sandbox". Things are clearer when security policy is explicit, > and not implied by non-security behaviors. On Tue, 31 Aug 2010, Justin Schuh wrote: > > As someone who spends the majority of his time doing security > assessments and code audits, I disagree. I'd happily accept an easily > reducible false positive over a feature that simply fails open with no > security whatsoever. My reasoning here is that the vast majority of > software doesn't get security reviews, which is why secure defaults are > generally far more effective. This is particularly true when you > consider that misuse of @seamless or @srcdoc will fail obviously and > quickly in nearly all applications. However, a missing @sandbox is just > the kind of thing that's very likely to go undetected. On Mon, 30 Aug 2010, Justin Schuh wrote: > > Security features are typically effective only when deployed in concert > and when they default to their most restrictive state. As I understand, > srcdoc is intended primarily as a security feature (because non-security > use cases already have solutions). So, srcdoc should behave like a > well-spec'd security feature and provide it's strongest level of > protection by default, requiring the author to scale it back if needed. > Otherwise we'll end up with common vulnerable cases because many people > will expect secure default behavior, regardless of whether or not we > spec it. I considered this, but I'm not a fan of "silent" features like this -- I find that while they initially make sense, it's easy to end up in a situation where all the "magic" interacts in very confusing ways. Also, IMHO it's easier to review <iframe> for security now than it would be if we made sandbox="" silently apply sometimes: If sandbox="" is specified, you have a sandbox, otherwise you don't. So anytime you see <iframe>, look for sandbox="". On Mon, 30 Aug 2010, Justin Schuh wrote: > > Data URLs already provide this. And if convenience is the primary goal, > it seems like there are much better ways to implement the same feature. Such as what? On Mon, 30 Aug 2010, Justin Schuh wrote: > > However, maybe I'm missing something. Could you give a scenario where > the convenience factor is significant, and not already served by another > feature? On Tue, 31 Aug 2010, Maciej Stachowiak wrote: > > You can use sandboxing with a data: URI by also specifying the "sandbox" > attribute. As currently specified, srcdoc is almost entirely syntactic > sugar. On Tue, 31 Aug 2010, Tab Atkins Jr. wrote: > > What use-case are you trying to address that you think the suggestion in > this thread (make @srcdoc imply @sandbox) is incompatible with? At the > moment it appears that you're confused about the goal of the change I'm > suggesting, but I could just be missing something. Another use case for <iframe srcdoc=""> is the kind of thing where today you have to have a blank.html file to provide the initial contents of a frame that you'll be populating with other pages (e.g. help contents in a help viewer). With srcdoc="" you can now conveniently put the original document in the same file as the <iframe>: <iframe seamless srcdoc="<p>Select a topic from the list."></iframe> It's very convenient because you can then use either a script setting src="" directly or regular <a href="" target=""> to update the iframe. The latter is useful if you want the back/forward button to work, the former is best if you want to handle that yourself or if you ever want to be able to go back to the default (just remove the 'src' attribute and it'll flip back to the default). On Mon, 30 Aug 2010, Tab Atkins Jr. wrote: > > As a seperate issue, a @srcdoc <iframe> should be able to receive > @seamless as well Done. > even when it's officially unique-origin (that is, when the author > doesn't go out of their way to set @sandbox=allow-same-origin). There is > precedent for this in the spec - a text/html-sandboxed resource loaded > into an iframe (which is required to be unique-origin) can receive > @seamless, because it's not "actually" cross-origin; it only acts that > way for particular security purposes which don't apply to the use of > @seamless here. There's nothing special about text/html-sandboxed here -- anything whose URL is from the same origin is allowed to be seamless, even if it is sandboxed with sandbox="". On Sun, 12 Sep 2010, Justin Schuh wrote: > > Currently, section 2.5.1 states that about:srcdoc should not be navigable: > > "This specification defines the URL about:srcdoc as a reserved, though > unresolvable, about: URI, that is used as the document's address of iframe > srcdoc documents." That's not quite what that means, technically. The about: spec basically says that the above results in about:srcdoc doing the same as about:foobar, where "foobar" is some value the UA made up but didn't publicly define (e.g. about:mozilla, about:config, about:cache...). > In working on the WebKit implementation I've found that this requirement > would necessitate major changes to the navigation and document loading > implementation. Additionally, I do think there should be a simple method > of navigating to the iframe's srcdoc browsing context. (As currently > described, this can be triggered only by modifying @srcdoc from an > outer, same origin browsing context.) I don't quite follow what you mean. > So, I propose making about:srcdoc resolvable when the srcdoc attribute > is present on the iframe. It should be unresolvable only when navigated > to on a browsing context that is not an iframe with @srcdoc set. I don't know what you mean. On Sun, 12 Sep 2010, Anne van Kesteren wrote: > > Resolvable is a term the about URL scheme draft uses to determine > whether a given about URL returns a resource or not when used somewhere. > E.g. about:blank resolves to a text/html resource consisting of the > empty string. That about:srcdoc does not resolve does not mean its > browsing context cannot be navigated. On Sun, 12 Sep 2010, Justin Schuh wrote: > > Sorry, that was a dumb terminology error in my original email; it should > have read "the iframe's srcdoc *document*" and not "browsing context." > > However, I believe the proposal as I originally framed it is still > accurate. I'm suggesting that navigating to the about:srcdoc on an > iframe with a @srdoc attribute should resolve to the srcdoc document. > Whereas, as I read the current spec, it would be unresolvable. I don't understand. Do you mean that if the user clicks on a link like <a href="about:srcdoc">this</a> inside an <iframe srcdoc='like <a href="about:srcdoc">this</a>'>, the page should reload? That seems weird. Why would we do that? If you mean just that location.reload() should work in a srcdoc iframe, then that's a different matter... I agree that that would make sense. I've updated the spec accordingly. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 15 November 2010 13:46:48 UTC