[whatwg] Synchronized play/seek of multiple audio elements?
Hi, Over at koblo.com we're working on online music collaboration. Html 5's ability to handle audio will be a great help, freeing us from having to rely on Flash. However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Any audio editing, mixing or multi-track application will need the ability to start several audio tracks (elements) at excatly the same time. As an example, consider a simple music mixing application where the user can control the volume of the separate tracks (drums, guitar, vocal, etc). Seek and play must done all tracks together in a synchronized way. Does the html 5 specification provide any way to to this? Emil Tin Koblo
Re: [whatwg] hashchange only dispatched in history traversal
I think Ian has misunderstood, so I dare repeat: For bookmark navigation (scrolling), generate a reveal event. For AJAX hacking (no scrolling), generate a hash update event. This means the page has changed semantically. In particular, I never said the hash update event should be dropped. The only way I can understand the relevance of Ian's text is that he thinks the reveal event would not be useful. I think it can be an advantage to special designs with floating windows and such. HTH, Chris
Re: [whatwg] Synchronized play/seek of multiple audio elements?
On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hashchange only dispatched in history traversal
On Wed, 18 Feb 2009, Kristof Zelechovski wrote: I think Ian has misunderstood, so I dare repeat: For bookmark navigation (scrolling), generate a reveal event. For AJAX hacking (no scrolling), generate a hash update event. This means the page has changed semantically. In particular, I never said the hash update event should be dropped. The only way I can understand the relevance of Ian's text is that he thinks the reveal event would not be useful. I think it can be an advantage to special designs with floating windows and such. I do not understand your proposal. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Michal Zalewski wrote: Problem definition: a malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as delete all items, click to add Bob as a friend, etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it. Although the examples above are naive, this is clearly a problem for a good number of modern, complex web applications. Proposed fixes: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken - Can't be used for cases where IFRAME content mixing has a legitimate purpose (for example, cross-domain gadgets, certain types of mashups) In particular, this breaks Image Search tools from various vendors as well as navigation aids like the Reddit toolbar. - Adds yet another security measure (along with cross-domain XHR, MSIE8 XSS filters, MSIE P3P cookie behavior, Mozilla security policies) that needs to be employed correctly everywhere to work - which is very unlikely to consistently happen in practice - Along with the aforementioned security features, threatens to result in HTTP header or HTML HTTP-EQUIV size bloat that some sites may care about. This solution is what IE8 has apparently chosen to use. Specifically, IE8 will recognise an HTTP header or meta pragma directive with the name X-Frame-Options, and will process it as follows: If the value is a case-insensitive match for deny and the browsing context being navigated is not a top-level browsing context, replace the document with a UA-defined error message. If the value is a case-insensitive match for sameorigin and the browsing context being navigated is not a top-level browsing context and the origin of the top-level browsing context is not the same as the origin of the document in question, replace the document with a UA-defined error message. (The sameorigin rule seems like it should check all ancestor browsing contexts, not just the top-level one, because otherwise a site X, e.g. images.google.com, showing a frame with a document on site Y, e.g. hostile.example.com -- which might happen e.g. on something like Google Image Search -- would be able to embed another page from site X, e.g. your image search preferences, and do clickjacking on it.) This feature could also be extended to apply to other resources, e.g. scripts, images, style sheets, fonts, to prevent them from being used cross-origin. This would help, e.g., with securing scripts that contain private data. 2) Add a document-level mechanism to make if nested show this else show that conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited. This is an interesting idea, though it would be subsumed by Hallvord's suggestion with Origin given below, in conjunction with idea 1 above in the absence of Origin information. 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and browser vendors seem reluctant to go down this road. 4) Enforce a click-to-work mechanism (resembling the Eolas patent workaround) for all cross-domain IFRAMEs. Experience with the Eolas patent workaround suggests this wouldn't be popular, to put in mildly. 5) Rework everything we know about HTML / browser security models to make it possible for domains and pages to specify very specific opt-in / opt-out policies for all types of linking, referencing, such that countering UI redress attacks would be just one of the cases controlled by this mechanism. This seems like it would still basically need one of the other mechanisms as well. Without a more concrete proposal here it's hard to tell what exactly this would be. On Thu, 25 Sep 2008, Collin Jackson wrote: 6)
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Ian Hickson wrote, On 18/02/2009 12.43: 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and browser vendors seem reluctant to go down this road. Incidentally, NoScript's ClearClick is a working implementation of this difficult approach, effective also with same-origin plugin content (like in the original Clickjacking PoC by RSnake Grossman). http://noscript.net/faq#clearclick -- G Ian Hickson wrote, On 18/02/2009 12.43: On Thu, 25 Sep 2008, Michal Zalewski wrote: Problem definition: a malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as delete all items, click to add Bob as a friend, etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it. Although the examples above are naive, this is clearly a problem for a good number of modern, complex web applications. Proposed fixes: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken - Can't be used for cases where IFRAME content mixing has a legitimate purpose (for example, cross-domain gadgets, certain types of mashups) In particular, this breaks Image Search tools from various vendors as well as navigation aids like the Reddit toolbar. - Adds yet another security measure (along with cross-domain XHR, MSIE8 XSS filters, MSIE P3P cookie behavior, Mozilla security policies) that needs to be employed correctly everywhere to work - which is very unlikely to consistently happen in practice - Along with the aforementioned security features, threatens to result in HTTP header or HTML HTTP-EQUIV size bloat that some sites may care about. This solution is what IE8 has apparently chosen to use. Specifically, IE8 will recognise an HTTP header or meta pragma directive with the name X-Frame-Options, and will process it as follows: If the value is a case-insensitive match for deny and the browsing context being navigated is not a top-level browsing context, replace the document with a UA-defined error message. If the value is a case-insensitive match for sameorigin and the browsing context being navigated is not a top-level browsing context and the origin of the top-level browsing context is not the same as the origin of the document in question, replace the document with a UA-defined error message. (The sameorigin rule seems like it should check all ancestor browsing contexts, not just the top-level one, because otherwise a site X, e.g. images.google.com, showing a frame with a document on site Y, e.g. hostile.example.com -- which might happen e.g. on something like Google Image Search -- would be able to embed another page from site X, e.g. your image search preferences, and do clickjacking on it.) This feature could also be extended to apply to other resources, e.g. scripts, images, style sheets, fonts, to prevent them from being used cross-origin. This would help, e.g., with securing scripts that contain private data. 2) Add a document-level mechanism to make if nested show this else show that conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited. This is an interesting idea, though it would be subsumed by Hallvord's suggestion with Origin given below, in conjunction with idea 1 above in the absence of Origin information. 3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks. This seems difficult to get right in practice, and
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
On Thu, 25 Sep 2008, Michal Zalewski wrote: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken Right. And really no different from: script if (window != window.top) window.top.location.href = window.location.href; /script in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. There _is_ an issue here if script is disabled, of course. In that case, are there still situations where the parent frame can effectively mislead the user? 2) Add a document-level mechanism to make if nested show this else show that conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited. Right, addressing the concern above. The pro is that it ties information directly to the document. The con is that it's harder to deploy site-wide Is that a concern? -Boris
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Boris Zbarsky wrote on 2/18/2009 9:27 AM: On Thu, 25 Sep 2008, Michal Zalewski wrote: 1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes that permits a web page to inhibit frame rendering in potentially dangerous situations. Pros: - Super-simple Cons: - Opt-in, i.e. currently vulnerable sites remain vulnerable unless action is taken Right. And really no different from: script if (window != window.top) window.top.location.href = window.location.href; /script in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. Supposedly, a future release of IE8 will fix this (see Issue #4): http://ha.ckers.org/blog/20081007/clickjacking-details/ There _is_ an issue here if script is disabled, of course. In that case, are there still situations where the parent frame can effectively mislead the user? One solution I've seen is to position a giant div over the page so that nothing is clickable when JavaScript is disabled: scriptif (top != self) top.location = location/script noscriptdiv style=position:absolute;left:0;top:0;z-index:999;width:1px;height:1px;background-color:black;color:white;This page requires JavaScript/div/noscript Of course, that breaks the site for anyone surfing without JavaScript. - Bil
Re: [whatwg] Dealing with UI redress vulnerabilities inherent to the current web
Bil Corry wrote, On 18/02/2009 21.31: Boris Zbarsky wrote on 2/18/2009 9:27 AM: And really no different from: script if (window != window.top) window.top.location.href = window.location.href; /script in effect, right? This last already works in all browsers except IE, which is presumably why IE felt the need to add another way to do it. Supposedly, a future release of IE8 will fix this (see Issue #4): http://ha.ckers.org/blog/20081007/clickjacking-details/ I doubt we'll see a fix for iframe security=restricted ;) -- G
Re: [whatwg] document.cookies
On Sun, 12 Oct 2008, Garrett Smith wrote: Excerpt: prevents script from reading the document.cookies DOM attribute. http://www.whatwg.org/specs/web-apps/current-work/#sandboxed-origin-browsing-context-flag Should this be |document.cookie| instead of document.cookies? Thanks, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] URL parsing and same-document references [was: Re: Citing multiple blockquote elements in HTML5]
On Wed, 3 Dec 2008, Calogero Alex Baldacchino wrote: My concern is, a character-by-character comparison between an id value and a fragment identifier may fail several ways. What for href=#foo bar and id=foo bar ? Actual rules would strip the trailing space only for the href, so the matching would fail (but we might survive broken links). Escaping both, then comparing would succed, as well as first escaping then unescaping the href value before comparing (should it be pointed out, somewhere, that a fragment identifier must be unescaped before comparing to an id or a name? is it and I've missed it? - having space characters in the unreserved production means thy don't need to be escaped, but does it mean also they must be decoded from their pct-production, after parsing and for resolving?). The behavior specced now may change, but as it stands now unescaping is defined for fragment-identifier-to-id= matching. In general, though, the behaviour is constrained by what IE does and more to the point by what is needed by content that depends on what IE does. (You sent another couple of e-mails on the topic; I understand -- mostly -- the points you make therein, and would like to refer you to the recent thread on the topic: http://lists.w3.org/Archives/Public/public-html/2009Feb/thread.html#msg407 ...where the same issues were discussed with more concrete reference to actual implementations and constraints placed on us by legacy content.) What terminology would you prefer rather than subtree? (We can't say document, since we are also trying to define conformance rules for disconnected subtrees handled from scripts.) Uhm, it may depend on what kinds of manipulations you have in mind, whether the disconnected subtree must be anyway a whole document to fulfil the uniqueness rule, and perhaps also on what the subtree concept might be turned into by future DOM Core versions, so maybe just a clarification on what a subtree is with respect to both the document (as a tree) and the scripts handling possibilities might be enough, instead of searching a new terminology, just to 'scope' the id visibility. I mean, if the ID matching is relevant for scripts accessing the matching element through the getElementById() method, actually a document tree is always overlapping the concept of subtree, and a disconnected subtree must be a document without a browsing context; otherwise, if other dom manipulations are involved the concept of subtree may change, for instance a script might implement its own scanning routine, treating an id attribute as any other attribute and leading to the concept that any non-leaf node may be the root of a subtree (that is identifying a subtree with any possible document fragment); furthermore, a possible future version of DOM Core interfaces might move the getElementById method to the Node interface, leading to the same result. Thus, a generic definition of 'subtree' (or no definition, or a definition relying upon a specific DOM feature or on script handling) might result in a variable concept with a variable scope for the ID uniqueness, but might make sense in a working draft until at least a first definition of the Web DOM Core specification, or waiting for any reason arising to restrict or enlarge the concept; otherwise, if that's been stated with a large consensus that a subtree is always a document tree, the term might be changed into the expression a document, with or without a browsing context, or (equivalently) be defined as a document subtree having a node of type document as its root (to cover the case of dynamically created documents). Otherwise, if a subtree can be either a whole document, or a document subtree detached from its owner document (i.e. a node removed from a document with its descendants, or a tree of nodes whose ownerDocument property is not defined or null), it might be defined just as such, leaving the term 'subtree' wherever it is now (but would such a manipulation be consistent with the - authoring - uniqueness rule when the subtree is inserted into an actual document?). My brain got lost partway through reading the above, so I apologise if I missed a key point you were making. Anyway, the spec now has the term home subtree, which is defined in more detail than subtree was before. I hope this helps. On Sat, 13 Dec 2008, Nils Dagsson Moskopp wrote: Am Freitag, den 12.12.2008, 20:36 +0100 schrieb Calogero Alex Baldacchino: The above (but the 'double check' I was suggesting) is about the way Firefox (2.x and 3.0.4) behaves (both href=#foo%20bar and, in a different page, href=./example.html#foo%20bar match id=foo bar), while IE7 and Opera 9.x perform an exact comparison, and show, in the address bar, an url with eventual blank spaces, thus applying the relaxation allowed by URL parsing rules, but not conforming to RFC 3986, as a complete URI string. Whenever I
Re: [whatwg] Synchronized play/seek of multiple audio elements?
At 10:20 + 18/02/09, Ian Hickson wrote: On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. Yes. We felt it would be a major complication to the spec., and wanted to keep things simple for the first iteration. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Synchronized play/seek of multiple audio elements?
However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. I wish this exist for VIDEO tag also. On Firefox nightly the situation is even worse due to https://bugzilla.mozilla.org/show_bug.cgi?id=476371 One solution is watching timeupdate event on all items and .pause() and .play() to make every thing in sync. Cheers Biju
[whatwg] Invitation from Silvia Pfeiffer
See my latest photos, updates and friends on Bebo. Click to view my profile. http://www.bebo.com/in/8704689475a133136566b135 .. This email was sent to you at the direct request of Silvia Pfeiffer silviapfeiff...@gmail.com. You have not been added to a mailing list. If you would prefer not to receive invitations from ANY Bebo members please click here - http://www.bebo.com/unsub/8704689475a133136566 Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
[whatwg] Invitation from Silvia Pfeiffer
See my latest photos, updates and friends on Bebo. Click to view my profile. You also have the following outstanding friend requests: Scott McDaniel sc...@scottopic.com You can accept or reject all of these invitations at once by clicking below: http://www.bebo.com/in/7667589444a823042039b135 .. This email was sent to you at the direct request of Silvia Pfeiffer silviapfeiff...@gmail.com. You have not been added to a mailing list. If you would prefer not to receive invitations from ANY Bebo members please click here - http://www.bebo.com/unsub/7667589444a823042039 Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.
