Re: [whatwg] HTMLMediaElement: more issues and ambiguities

Thanks for addressing all of my questions, there is only one issue below which I think deserves a second round. On Wed, 2008-07-09 at 00:05 +, Ian Hickson wrote: > On Thu, 3 Jul 2008, Philip Jägenstedt wrote: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#adjusted

Re: [whatwg] Origin header and s

Adam Barth, John Mitchell, and I have written an academic paper in support of the Origin header as a CSRF defense: http://crypto.stanford.edu/websec/csrf/ On Wed, Jul 9, 2008 at 6:59 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote: > Hi All, > > The Access-Control spec [1] adds an 'Origin' header tha

Re: [whatwg] Proposed additions to ClientInformation interface

I'll reply to this in more detail in due course, but I'm still interested in the idea, and would like to discuss that further: On Tue, 8 Jul 2008, Maciej Stachowiak wrote: > > > > One possibility for addressing these requirements would be an element > > that acts as a link, button, or icon, o

Re: [whatwg] Workers

I'm not sure what it means when you say: a.. URLs: Workers should be spawned from URLs, not from strings, since script rarely has access to its own source. could you elucidate a bit more? Doesn't JavaScript usually have access to its own source? I'm not sure when it doesn't. and isn't JavaScr

[whatwg] Origin header and s

Hi All, The Access-Control spec [1] adds an 'Origin' header that is submitted with all requests. I propose that we specify that POSTs should do the same. This would be a very powerful mechanism to prevent CSRF attacks as it would allow CSRF prevention to happen in the server, rather than in

Re: [whatwg] Workers

Wh! How about: - synchronous network access - storage access in general - synchronous db access - access to a subset of the capabilities from the window.location object, for example the "href" property and the "reload" method. We have found that some workers want to reload themselves when the

Re: [whatwg] Geolocation API Proposal

Various proposals over the years have been made for a Geolocation API in HTML5. Since the W3C has now started work on a Geolocation API specification, I do not intend to add such an API to HTML5. If you are interested in this work I recommend following this mailing list: http://lists.w3.or

[whatwg] Workers

Based on popular demand (and threats that without a spec implementations would proceed regardless) I have started collecting use cases and requirements for a specification for background worker scripts ("threads") in JavaScript: http://www.whatwg.org/specs/web-workers/current-work/#requir

Re: [whatwg] re-thinking "cue ranges"

OK, some comments back on the cue range design. Sorry for the summer-vacation-induced delay in response! At 1:00 + 12/06/08, Ian Hickson wrote: > In the current HTML5 draft cue ranges are available using a DOM API. This way of doing ranges is less than ideal. First of all, it is ha

[whatwg] Link Fingerprints (HTML version) take 2

[I posted this message in March; hixie asked me to go away and read the previous discussion[0]. I have now done so. The two issues raised seemed to be "it's like Content-MD5" and "people will just switch browsers". Both are addressed in the updated spec.] Some WHAT-WG participants may be aware of

Re: [whatwg] element

On Jul 9, 2008, at 5:19 AM, Lars wrote: Microsoft (IE) doesn't support this tag, but Firefox and Opera does. Microsoft have info about why here: http://support.microsoft.com/kb/190282. Safari also supports this element. - Maciej

Re: [whatwg] element

Hi This is using TLS/SSL. Example: You tell your webserver that under directory /secure/ the client must have a certificate signed by CA1. For the client to get this certificate you normally make it, sign it, and them import it to the browser. With the attribute, all this is done in a clean more

Re: [whatwg] element

<...> > For those of you who doesn't know what this element is doing; Its for > generating a private/public certificate keypair. The browser keeps the > private one, and the server gets the public one which it signs and > then sends back to the browser. This is extremely useful for secure > verific

Re: [whatwg] element

Hi, On Wed, 09 Jul 2008 14:19:09 +0200, Lars <[EMAIL PROTECTED]> wrote: Is there any hope for this element? What information does which people want to make this an HTML5 standard? It seems we have similar interests :-) I haven't gotten around to doing it, but what needs to be done is having

[whatwg] element

Hi I've been searching around in old mail in this mailing list to try to find this answer, but all I could find about this html element is http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-November/thread.html#5092, which isn't that good. I have been reading a lot of documentation about th