[whatwg] Small ddition to 7.4.2.1, postMessage's security considerations for authors
The spec should mention that even after MessageEvent.origin's value has been checked, MessageEvent.data should also be checked for structural correctness, because if the target window contains an XSS hole, improper validation of incoming messages could result in the target window's XSS hole being propagated into the sender's window as well. For example, consider a site A which requests a particular string of JSON data from site B, which it then parses into an object using eval(). If site B is subvertible, the response JSON string may instead be arbitrary script which would be executed by site A *as* site A's code. Proper validation by site A would mean checking that the sent string actually is JSON and not arbitrary syntactically-correct JavaScript. (Ignore the fact that the site shouldn't be unserializing JSON data using eval(), and further ignore that structured data-passing makes this particular use obsolescent. Other instances of contamination may be possible depending on the sent data and its structure, and this was just the simplest example to explain.) Jeff
Re: [whatwg] The iframe element and sandboxing ideas
On Mon, 26 May 2008, Ojan Vafai wrote: What happens if an iframe is loaded with sandbox set and then the property it is unset? What security origin is it in? I've clarified the spec to ensure that the flag only takes effect when the browsing context is navigated and the Document is created. Similiarly, what happens when seamless is set/removed on an iframe already in the page? Does it start inheriting CSS and resize to fit it's content? I don't feel strongly about what should happen in these cases, seems worth being explicit though. I've added a note saying that it is dynamic, yes. 1. When seamless is set, the compatMode of the iframe should be the same as that of the parent browsing context, even if the doctype of the iframe would put it in a different compatmode than its parent. I thought about this some more and this seems like a bad idea. If you actualy link to a page that expects to be quirks from a standards parent, then this could be break things. I'll modify this to the following: Iframes with an empty src (or no src property) should inherit their parent's compatmode iff seamless is set, otherwise they should be in backcompat unless a standards doctype is document.write'ed in. Again the latter part of that is for compatibility with current browsers. I think making the compat mode inherit only in the case of seamless being set and the document being about:blank and there not being a DOCTYPE is somewhat too weird to be worth it. I can just imagine people running into this and being all confused. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The iframe element and sandboxing ideas
(Please only cc one mailing list when replying, to reduce cross-posting.) On Sun, 25 May 2008, Jon Ferraiolo wrote: Olaf suggested that there might be another attribute to propagate events. This is definitely highly desirable in some scenarios. Note that the CDF WG has done some work that relates at least partially, although I wouldn't be surprised if Ian isn't all that positive on CDF. Nevertheless, here is the spec: http://www.w3.org/TR/WICD/. The WICD spec focuses on various aspects of not just event propagation, but also hyperlink propagation and focus management. All of these topics seem worthy of consideration in terms of bridging between the host web page and any of the iframes it embeds. I think this would be an interesting area to extend into, but I think we should wait until we have more experiense with iframe sandbox and iframe seamless before going there. I have, however, noted this proposal with the WICD link in the spec. 3) It seems to me that for some of the propagation areas (e.g., CSS propagation, event propagation, focus-model integration) you would want both the container and the component to opt-in before the propagation occurred. For example, with CSS propagation, there may be cases where the component only wants certain of its own characteristics to be stylable by the parent. If you look at typical Ajax widgets, which use CSS for controlling the visual rendering, there are some aspects which are meant to be stylable by the developer, some aspects that are meant to be themable (i.e., stylable via a shared theme), and other aspects which the widget needs to control exclusively and should not be overridden. For widgets, XBL2 is probably the better way of dealing with this. I would assume that there are also security issues with allowing the parent to override the styling of an embedded iframe because conceivably someone could invoke a bank website within an iframe and it wouldn't be good if the parent could override some of the CSS for the bank's website. Similarly, you probably wouldn't want the parent frame to be able to listen to keystrokes that happen within the child iframe (e.g., your password). For some of the information passing between parent and child, it might be best to somehow use a publish/subscribe mechanism like how postMessage() works, where both both parent and child have to opt-in before the propagation occurs. Since seamless= only works for same-origin resources anyway, I don't think there's any new problem here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] defer on style, depends
On Thu, Feb 12, 2009 at 8:41 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Garrett Smith wrote:
In Shiretoko, a script, even a deferred script, will not run until the
stylesheet is loaded.
Correct.
Can we make an improvement on that, or to make that improvement
configurable to the page author?
I think we can, sure. In fact I'm proposing flagging scripts that don't
depend on stylesheets, no?
I agree, and am optimistic that improvements can be made.
Defer is not widely implemented. Opera and Webkit today will run a
script before a stylesheet loads. Allowing the author to provide
information about what a script depends on (or doesn't) would not
break functionality in those cases (where such functionality is
already broken).
script depends= ...
when depends is empty string, the script depends on nothing else.
Ah, that is one thing that Gecko does do: we don't start _layout_ (as
opposed to parsing) until all the stylesheets in head have loaded.
For Firefox 3.0, IMG and SCRIPT that are part of the body are fetched
around this time. They are not fetched prior. Why not?
Because you have scripts after your stylesheets, not just stylesheets.
Really, controlled experiments are hard. You have to hold all but one
variable constant.
OK, I modified the example:
http://localhost/jstest/block/link-img-noscript.html
The bottom script will not load ('load' as opposed to 'run') in
Firefox/3.0.6 until after 5 seconds.
+-+---+
| req | HTTP date |
+-+---+
| link-img-noscript.html | Sun, 15 Feb 2009 05:08:52 GMT |
| rgmetal.jpg | Sun, 15 Feb 2009 05:08:52 GMT |
| delay.jsp?ct=text...| Sun, 15 Feb 2009 05:08:52 GMT
|
| example.js | Sun, 15 Feb 2009 05:08:57 GMT |
+-+---+
(table to be viewed in a monospace font)
The result shows that example.js loads 5 seconds after the initial
page load. example.js waits for the stylesheet to load.
Not the case in 3.1; what you are arguing is true there.
In that case, the link would not block layout.
Yes, which is why you get a performance hit when it loads. But I thought we
were talking about stylesheets that don't really affect layout
(late-loading stylesheets, which you wanted).
Late-loading stylesheets would improve load time.
My concern is with the recomputation you mentioned. Can you elaborate
on that, or point me to a webpage that explains it?
In Shiretoko 1.9.1b3pre, a deferred script waits for all stylesheets
to load before running. However, this is not guaranteed behavior in
any standard.
True. At least not yet. I suspect it's pretty much required for web
compat, though, which is why it's implemented that way. Or at the very
least the scripts need to wait for the stylesheets that came before them.
I would disagree with that on the basis that defer is not widely supported.
Question: What does IE do?
Question: When the stylesheet is eventually applied, could the reflow
be optimized for performance?
Not easily, no. Or rather, the reflow already is; the style data
recomputation is the hard part.
What would make it easier? I'd really like to know how to design my
pages so that they are faster and more responsive.
Well, one option is to stop worrying about micromanaging the load order and
assume that speculative parsing will solve your problems will it?
Possibly. If the author could declare what a script depends on and let
the implementation determine what to load and when, would that be too
complicated?
A deferred stylesheet being requested by the browser would not be a
problem. Mozilla already makes predictive fetches for links. However,
if a deferred stylesheet is fetched during loading, should that
stylesheet (and rules.length, etc) be accessible via script in that
time? Should the deferred link fire a load event after the request
completes?
In my opinion, prefetching should have no effect on what the DOM sees. It
should just make it look like the network load took a lot less time than it
would otherwise.
In other words, you load the stylesheet, parse it, whatever, but don't hook
it up to the document until you really parse the link tag.
That makes sense.
-Boris
Garrett
