Re: The global object in browsers
Maciej Stachowiak wrote: On Feb 19, 2009, at 1:39 AM, David-Sarah Hopwood wrote: Ian Hickson wrote: On Tue, 17 Feb 2009, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch wrote: Indeed, I noted this earlier. The behavior HTML5 codifies is the behavior that the majority of browser vendors have asked me to codify. Majority, huh? Which vendors? How does the behavior they ask for correlate with what their browsers do? Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE does, namely throw an exception when running code whose global object doesn't match the current Window object, but Opera, Apple, and Mozilla rejected this on the grounds that it could not be implemented in a high-performance manner. That is clearly false. It would be a single pointer comparison when entering a new context. I make no comment here on whether this behaviour would be a good idea on other criteria, just that rejecting it on performance grounds is absurd. In modern JITing implementations, adding (at least) two memory reads and a conditional branch to every function call would be a significant performance hit. It is not every function call; only function calls that are not known to be same-context (in a particular copy of the generated code). The majority (by call frequency) of function calls can be inferred to be same-context by analyses that a high-performance implementation should be doing already. Furthermore, the context check can be hoisted to the first point in a function body where the target function is known (so calls to the same function in a loop will require only one check). There are most sophisticated optimizations that could be done, but they're probably not needed. In JavaScriptCore for instance, the hot path at the machine code level is optimized down to essentially just one memory read, one conditional branch, and a jump to the callee's code (also some memory writes but those don't stall the pipeline so they don't matter as much). The next hottest path has three branches and a few extra memory reads. Adding an extra branch (and associated memory reads) to that would be a big hit. We know because we have measured the benefit of reducing the number of branches. It makes a huge difference in call-heavy code. In general, I would advise against making performance claims in absolute terms (like clearly false) without testing or studying the relevant implementation internals. I see no point in equivocating on points that I am quite sure about, having studied similar issues in implementations of other languages. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
parseInt and implicit octal constants
15.1.2.2 says: When radix is 0 or undefined and the string's number begins with a 0 digit not followed by an x or X, then the implementation may, at its discretion, interpret the number either as being octal or as being decimal. Implementations are encouraged to interpret numbers in this case as being decimal. This is item 3.10 in the JScript Deviations document and my notes from when we reviewed the deviations document for ES3.1 changes says we decided to disallow the octal interpretation in ES3.1. However that change has never been made in the ES3.1 draft. Does anyone remember if there was a subsequent explicit decision to keep the ES3 status quo or is this just an editing oversight? Note that IE, FF, and Safari all interpret leading 0 strings as octal while Opera does not. So, arguably ,the de facto standard is to support such octal strings. The argument for removing the option and mandating either one of the alternatives is improved interoperability across all browsers over the long term. The argument for disallowing such implicit octal strings is that they are an error hazard. The argument of requiring support of implicit octal strings is that it is the de facto standard of the web and that disallowing them may break existing webapps. The cop-out is to just leave it as it is. The safe decision is to mandate the current de facto standard. The brave (ie, risky) decision for a better long term language is to disallow octal. Thoughts? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: parseInt and implicit octal constants
On Feb 20, 2009, at 3:26 PM, Mark S. Miller wrote: 2009/2/20 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com: The cop-out is to just leave it as it is. The safe decision is to mandate the current de facto standard. The brave (ie, risky) decision for a better long term language is to disallow octal. Given that Opera has survived the decision not to use octal, doesn't this establish that this decision is adequately compatible with the web? Opera folk, do you have any data (anecdotal would be fine) of how much breakage you encounter because of this decision? If the Opera experience says the risk is acceptably low, I vote to disallow octal. I wouldn't assume that an Opera-only behavior is safe for the Web; there are a number of Opera-specific behaviors that for instance Firefox or Safari would not accept as meeting our threshold of Web compatibility. I would be interested in hearing what, if any, bugs they have run into. I think the wise thing to do here is specify a requirement for octal support. The potential improvement in overall usability of the language seems small and not worth taking a compatibility risk. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: parseInt and implicit octal constants
On Feb 20, 2009, at 3:26 PM, Mark S. Miller wrote: 2009/2/20 Allen Wirfs-Brock allen.wirfs-br...@microsoft.com: The cop-out is to just leave it as it is. The safe decision is to mandate the current de facto standard. The brave (ie, risky) decision for a better long term language is to disallow octal. Given that Opera has survived the decision not to use octal, doesn't this establish that this decision is adequately compatible with the web? Opera folk, do you have any data (anecdotal would be fine) of how much breakage you encounter because of this decision? If the Opera experience says the risk is acceptably low, I vote to disallow octal. I wouldn't assume that an Opera-only behavior is safe for the Web; there are a number of Opera-specific behaviors that for instance Firefox or Safari would not accept as meeting our threshold of Web compatibility. I would be interested in hearing what, if any, bugs they have run into. I think the wise thing to do here is specify a requirement for octal support. The potential improvement in overall usability of the language seems small and not worth taking a compatibility risk. I agree. The octal thing is problematic, but I don't think Opera's example is compelling. If we didn't have the radix parameter, which nicely corrects the problem, then I would be willing to accept the breakage that fixing this would cause. But we do, so we should play it safe. The smart kids are using the radix parameter. The other kids have already written code which may be depending on the bad behavior. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: parseInt and implicit octal constants
On Fri, Feb 20, 2009 at 3:45 PM, Maciej Stachowiak m...@apple.com wrote: [...] Opera folk, do you have any data (anecdotal would be fine) of how much breakage you encounter because of this decision? If the Opera experience says the risk is acceptably low, I vote to disallow octal. I wouldn't assume that an Opera-only behavior is safe for the Web; there are a number of Opera-specific behaviors that for instance Firefox or Safari would not accept as meeting our threshold of Web compatibility. I would be interested in hearing what, if any, bugs they have run into. I think the wise thing to do here is specify a requirement for octal support. The potential improvement in overall usability of the language seems small and not worth taking a compatibility risk. Absent further information from the Opera folks, I agree. But if we can, we should postpone committing to a decision until we hear about their experience with this. Opera folks? -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Am I paranoid enough?
What are you trying to do? Exclude all scripts that use the operator?
Waldemar
David-Sarah Hopwood wrote:
Suppose that S is a Unicode string in which each character matches
ValidChar below, not containing the subsequences !, / or ]], and
not containing ( followed by a character not matching AmpFollower).
S encodes a syntactically correct ES3 or ES3.1 source text chosen by
an attacker.
ValidChar :: one of
'\u0009' '\u000A' '\u000D' // TAB, LF, CR
[\u0020-\u007E]
[\u00A0-\u00AC]
[\u00AE-\u05FF]
[\u0604-\u06DC]
[\u06DE-\u070E]
[\u0710-\u17B3]
[\u17B6-\u200A]
[\u2010-\u2027]
[\u202F-\u205F]
[\u2070-\uD7FF]
[\uE000-\uFDCF]
[\uFDF0-\uFEFE]
[\uFF00-\uFFEF]
AmpFollower :: one of
'=' '(' '+' '-' '!' '~' '' '/' [0-9]
'\u0027' '\u005C' '\u0020' '\u0009' '\u000A' \u000D'
// single quote, backslash, space, TAB, LF, CR
(ValidChar excludes format control characters, and some other
characters known to be mishandled by browsers. AmpFollower is
intended to exclude characters that can start an entity reference.)
S is inserted between script and /script in a place where a
script tag is allowed in an otherwise valid HTML document, or
between script![CDATA[ and ]]/script in a place where a
script tag is allowed in an otherwise valid XHTML document.
The HTML or XHTML document starts with a correct !DOCTYPE or
?xml declaration respectively, and is encoded as well-formed
UTF-8.
Are these restrictions sufficient to ensure that the embedded
script is interpreted as it would have been if referenced from
an external file, foiling any attempts of browsers to collude
with the attacker in misparsing it?
Are some of the restrictions unnecessary?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
