Re: [whatwg] Video with MIME type application/octet-stream
I think we should always sniff or never sniff, for simplicity. Philip On Wed, 08 Sep 2010 19:14:48 +0200, David Singer sin...@apple.com wrote: what about don't sniff if the HTML gave you a mime type (i.e. a source element with a type attribute), or at least don't sniff for the purposes of determining CanPlay, dispatch, if the HTML source gave you a mime type? On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote: On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 9/7/10 3:29 PM, Aryeh Gregor wrote: * Sniff only if Content-Type is typical of what popular browsers serve for unrecognized filetypes. E.g., only for no Content-Type, text/plain, or application/octet-stream, and only if the encoding is either not present or is UTF-8 or ISO-8859-1. Or whatever web servers do here. * Sniff the same both for video tags and top-level browsing contexts, so open video in new tab doesn't mysteriously fail on some setups. I could probably live with those, actually. * If a file in a top-level browsing context is sniffed as video but then some kind of error is returned before the video plays the first frame, fall back to allowing the user to download it, or whatever the usual action would be if no sniffing had occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. I agree with Boris, the first two points are OK but the third I'd rather not implement, it's too much work for something that ought to happen very, very rarely. -- Philip Jägenstedt Core Developer Opera Software David Singer Multimedia and Software Standards, Apple Inc. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] The choice of script global object to use when the script element is moved
On Sep 9, 2010, at 00:47, Ian Hickson wrote: On Fri, 3 Sep 2010, Henri Sivonen wrote: When evaluating a parser-inserted script, there are three potential script global objects to use: 1) The script global object of the document whose active parser the parser that inserted the script is. 2) The script global object of the document that owned the script element at the time of invoking the run algorithm. 3) The script global object of the document that owns the script element at the time of script evaluation. #1 and #2 are dodgy because the documents in question might have been GC'ed by that point. This problem doesn't arise in Gecko, because if a document gets GC'ed, the pending external script loads that have started while the script was in that document never get evaluated. That is, the document (via its script loader) owns the pending loads--not the script node. I could see theoretical merit in an argument that this is itself dodgy for script-inserted external scripts. However, I think the parser or the document whose active parser the parser is should own the loads for parser-inserted external script, because things become weird if defer script handling doesn't stay with the inserter parser and things get weird if the parser-blocking script doesn't stay with the inserter parser. While it would be *possible* to decouple various aspects of script loading from each other, I think it's not really worthwhile to go through that exercise just for an edge case that's currently broken in more severe ways in the current release versions every one of the top 4 engines. That is, I'd really like to see http://www.w3.org/Bugs/Public/show_bug.cgi?id=10540 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=10542 become FIXED rather than WONTFIX. Furthermore (to avoid major changes to Gecko's script loading), I'd like the pending load of script-inserted external scripts to be owned by the owner doc at the time of the run algorithm. The spec says the answer is #3. WebKit (with HTML5 parser or without) says the answer is #1. Firefox 3.6 says the answer is #2. I doubt that there are Web compat considerations forcing this choice, because IE8 doesn't get as far as running the script in this case. IE9 tries to do either #2 or #3 (not sure which) succeeding for inline scripts and failing for external ones. (IIRC, the text in the spec that explains the distinction between 1 and the other (without explaining the distinction between 2 and 3) was added specifically for the benefit of the IE team.) I'm not sure exactly which sentence you mean here, but I'm happy to clarify text if anything is ambiguous. The example http://www.whatwg.org/specs/web-apps/current-work/#scripts-that-modify-the-page-as-it-is-being-parsed doesn't cover the script moving to a third document between the first parser-performed insertion and the external script finishing loading. So in conclusion, I really don't see a new attack vector regardless of what we do here. OK. One advantage of doing #3 is that, as Adam pointed out, the implementation is required to get the security context at the last minute, where it's most likely to be up to date (e.g. with document.domain changes, etc) even in the case of the script element not being moved around. For last-minute security context grabbing to have an extra benefit, wouldn't the security checks have to be re-performed at last-minute? #3 is simpler to understand, IMHO. However, #1 is not particularly hard to spec, and I guess does decrease the odds of scripts being made to run accidentally by a bug in a script using sandboxed or CSP context. If everyone is ok with #1, I'm happy to change the spec accordingly. In case we don't end up doing #1, I have a follow-up question: Is there a good reason to perform the run algorithm against the then-current owner doc as opposed to the parser's doc for parser-inserted scripts? (Performing it against the parser's doc would require fewer changes to Gecko but implementing the checks against the owner doc would be doable.) Suppose there are two docs from one Origin. The document that the parser is associated with doesn't have a CSP. A script in it moves a node in such a way that the parser ends up inserting subsequent scripts into another document. That document has a CSP that bans scripts. Would you consider it a bug if a script ran in the context of the script global object of the document whose CSP says no scripts? If the CSP applied then the script would not run, if it didn't then it would run in the context of the doc without the CSP. I'm sure we wouldn't want to define the CSP as applying to nodes in a different way than the global scope is picked. Currently, CSP is evaluated at the run algorithm time. This seems a natural extension to the scripting disabled check that happens at run algorithm time. -- Henri Sivonen hsivo...@iki.fi
[whatwg] Partial HTML5 documents
Hello, I'm looking for a way to define valid partial HTML fragments that can be included into other documents using a server-side language or injected using AJAX. The current specification doesn't have any major restrictions in this area but it always require the presence of a TITLE tag which in this specific case is not needed. Does anybody have an idea if the TITLE can be skipped somehow or how this whole thing can be implemented properly? Do you think it should be specified? Best, Rostislav Asual - Open software that pushes the limits http://www.asual.com
Re: [whatwg] Partial HTML5 documents
On Thu, Sep 9, 2010 at 6:06 PM, Rostislav Hristov rostislav.hris...@gmail.com wrote: Hello, I'm looking for a way to define valid partial HTML fragments that can be included into other documents using a server-side language or injected using AJAX. The current specification doesn't have any major restrictions in this area but it always require the presence of a TITLE tag which in this specific case is not needed. Does anybody have an idea if the TITLE can be skipped somehow or how this whole thing can be implemented properly? Do you think it should be specified? Isn't it already, in the Parsing HTML fragments section? http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#parsing-html-fragments -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [whatwg] Partial HTML5 documents
On Thu, Sep 9, 2010 at 9:06 AM, Rostislav Hristov rostislav.hris...@gmail.com wrote: Hello, I'm looking for a way to define valid partial HTML fragments that can be included into other documents using a server-side language or injected using AJAX. The current specification doesn't have any major restrictions in this area but it always require the presence of a TITLE tag which in this specific case is not needed. Does anybody have an idea if the TITLE can be skipped somehow or how this whole thing can be implemented properly? Do you think it should be specified? If you're just passing around fragments in javascript or server-side code, then there's no need whatsoever to have a valid document at all times. You just need to ensure that the final page is valid. So, you don't need a title at all on some fragment you're fetching via ajax. ~TJ
Re: [whatwg] Partial HTML5 documents
I'm actually looking into manually editing these in an authoring environment and this is why I want them to be valid. The parsing section looks fine but it doesn't help in this case. Best, Rostislav Asual - Open software that pushes the limits http://www.asual.com On Thu, Sep 9, 2010 at 7:12 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Sep 9, 2010 at 9:06 AM, Rostislav Hristov rostislav.hris...@gmail.com wrote: Hello, I'm looking for a way to define valid partial HTML fragments that can be included into other documents using a server-side language or injected using AJAX. The current specification doesn't have any major restrictions in this area but it always require the presence of a TITLE tag which in this specific case is not needed. Does anybody have an idea if the TITLE can be skipped somehow or how this whole thing can be implemented properly? Do you think it should be specified? If you're just passing around fragments in javascript or server-side code, then there's no need whatsoever to have a valid document at all times. You just need to ensure that the final page is valid. So, you don't need a title at all on some fragment you're fetching via ajax. ~TJ
Re: [whatwg] Partial HTML5 documents
On Thu, Sep 9, 2010 at 6:37 PM, Rostislav Hristov wrote: I'm actually looking into manually editing these in an authoring environment and this is why I want them to be valid. The parsing section looks fine but it doesn't help in this case. Yes, sorry, I was thinking in terms of parse errors. I think there's no answer to your question, as validity of a DOM subtree depends on where you attach it: for instance, spanfoo/span would be valid if put inside a p (in an already valid document), but not if put inside, say, a tr. And it's a simple example. You'd have to provide a context for validating your HTML fragment, just like when parsing the fragment. I think the best you can do is to parse the fragment using the spec'd algorithm (if you're not already dealing with a DOM tree) and then attach the result to a simple HTML document (containing a title and providing the context you want to validate the fragment in); but even that would not cover all cases and your fragment could very well turn into something invalid when put in some documents (duplicate IDs, footer inside a footer, sectionning content inside an address, something not an hN inside an hgroup, etc.) -- Thomas Broyer /tɔ.ma.bʁwa.je/
[whatwg] Which vulnerabilities in HTML4 are (partially) solved in HTML5
I saw the iframe element adds the attribute 'sandbox' in HTML5, which can better protect users from malicious content. so I want to know whether or not there are other changes, HTML5 can (partially) solve some vulnerabilities in HTML4 ? thanks.
Re: [whatwg] Video with MIME type application/octet-stream
I can't think why always sniffing is simple, or cheap, or desirable. I'd love to get to never-sniff, but am not sanguine. On Sep 9, 2010, at 0:07 , Philip Jägenstedt wrote: I think we should always sniff or never sniff, for simplicity. Philip On Wed, 08 Sep 2010 19:14:48 +0200, David Singer sin...@apple.com wrote: what about don't sniff if the HTML gave you a mime type (i.e. a source element with a type attribute), or at least don't sniff for the purposes of determining CanPlay, dispatch, if the HTML source gave you a mime type? On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote: On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 9/7/10 3:29 PM, Aryeh Gregor wrote: * Sniff only if Content-Type is typical of what popular browsers serve for unrecognized filetypes. E.g., only for no Content-Type, text/plain, or application/octet-stream, and only if the encoding is either not present or is UTF-8 or ISO-8859-1. Or whatever web servers do here. * Sniff the same both for video tags and top-level browsing contexts, so open video in new tab doesn't mysteriously fail on some setups. I could probably live with those, actually. * If a file in a top-level browsing context is sniffed as video but then some kind of error is returned before the video plays the first frame, fall back to allowing the user to download it, or whatever the usual action would be if no sniffing had occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. I agree with Boris, the first two points are OK but the third I'd rather not implement, it's too much work for something that ought to happen very, very rarely. -- Philip Jägenstedt Core Developer Opera Software David Singer Multimedia and Software Standards, Apple Inc. -- Philip Jägenstedt Core Developer Opera Software David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Video with MIME type application/octet-stream
Much of this discussion has focused on the careless server operator. What about the careful ones? Given the past history of content sniffing and security warts, it is useful - or at least comforting - to have a path for the careful server to indicate I know this file really is intended to be handled as this type, please don't sniff it. This is particularly true for a server handling sanitized files from unknown sources, as no sanitizer will be perfect. Today we approximate this through accurate use of Content-Type and a recent addition of X-Content-Type-Options: nosniff. Never sniffing sounds idyllic and always sniffing makes life a bit riskier for careful server operators. The proposals of limiting video/audio sniffing to a few troublesome Content-Types are quite reasonable. -Andy On Thu, Sep 9, 2010 at 3:07 AM, Philip Jägenstedt phil...@opera.com wrote: I think we should always sniff or never sniff, for simplicity. Philip On Wed, 08 Sep 2010 19:14:48 +0200, David Singer sin...@apple.com wrote: what about don't sniff if the HTML gave you a mime type (i.e. a source element with a type attribute), or at least don't sniff for the purposes of determining CanPlay, dispatch, if the HTML source gave you a mime type? On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote: On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 9/7/10 3:29 PM, Aryeh Gregor wrote: * Sniff only if Content-Type is typical of what popular browsers serve for unrecognized filetypes. E.g., only for no Content-Type, text/plain, or application/octet-stream, and only if the encoding is either not present or is UTF-8 or ISO-8859-1. Or whatever web servers do here. * Sniff the same both for video tags and top-level browsing contexts, so open video in new tab doesn't mysteriously fail on some setups. I could probably live with those, actually. * If a file in a top-level browsing context is sniffed as video but then some kind of error is returned before the video plays the first frame, fall back to allowing the user to download it, or whatever the usual action would be if no sniffing had occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. I agree with Boris, the first two points are OK but the third I'd rather not implement, it's too much work for something that ought to happen very, very rarely. -- Philip Jägenstedt Core Developer Opera Software David Singer Multimedia and Software Standards, Apple Inc. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Video with MIME type application/octet-stream
On Sep 9, 2010, at 16:38 , Andy Berkheimer wrote: Much of this discussion has focused on the careless server operator. What about the careful ones? Given the past history of content sniffing and security warts, it is useful - or at least comforting - to have a path for the careful server to indicate I know this file really is intended to be handled as this type, please don't sniff it. This is particularly true for a server handling sanitized files from unknown sources, as no sanitizer will be perfect. Today we approximate this through accurate use of Content-Type and a recent addition of X-Content-Type-Options: nosniff. Never sniffing sounds idyllic and always sniffing makes life a bit riskier for careful server operators. The proposals of limiting video/audio sniffing to a few troublesome Content-Types are quite reasonable. I think I agree. The minimum I can think of is sniff when (a) suspect types are supplied and (b) they are 'auto-generated' (e.g. by a web server). If either are not true, you shouldn't need to sniff. Someone who writes source ... type=video/frubotziger ... / causes both tests to fail and deserves to be believed (and get the consequences). (Have you SEEN frubotziger format video :-)) -Andy On Thu, Sep 9, 2010 at 3:07 AM, Philip Jägenstedt phil...@opera.com wrote: I think we should always sniff or never sniff, for simplicity. Philip David Singer Multimedia and Software Standards, Apple Inc.
