[whatwg] Behavior when <script> is removed from DOM
jonas at sicking.cc
Thu Dec 8 15:20:43 PST 2011
On Thu, Dec 8, 2011 at 3:15 PM, Mark S. Miller <erights at google.com> wrote:
> On Thursday, December 8, 2011, Yehuda Katz wrote:
>> Yehuda Katz
>> (ph) 718.877.1325
>> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller <erights at google.com> wrote:
>>> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
>>> header, the API you suggest below can be fully implemented as a library.
>>> protection anyway, rather than carve out a special case for JSONP, should we
>>> waive the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse
>>> out a special case for JSONP?
> The legacy content we're concerned with is written to work on ES3 browsers.
> By overriding "Object" and "Array", or by other subterfuge, you can corrupt
> an ES3 environment adequately to violate the confidentiality of scripts
> loaded later into the same frame. Anne Van Kesteren pointed out the only
> form of confidentiality we can be confident of in this context: comments
> (and whitespace and choice of internal variable names). Are these secrets
> worth giving up on the safety that could result from loading these scripts
> as data, so that we could then run them in a restricted manner (whether by
> translation, verification, or other tricks, e.g., SES)?
Yet browsers jump through hoops to not expose the contents of
cross-origin scripts in error messages and the like.
I would personally not be happy with Firefox exposing the contents of
any cross-origin resource just because it happened to parse as
to load data from a same-origin server. I don't know how other browser
This is why I used the strict definition of JSONP since such data can
irrefutably be loaded cross-origin in all versions of all popular
More information about the whatwg