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
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 a
...
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
verification.
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 keygen attribute, all this is done in a
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
[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
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
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:
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:
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 they
Hi All,
The Access-Control spec [1] adds an 'Origin' header that is submitted
with all requests. I propose that we specify that form 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
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
I'll reply to this in more detail in due course, but I'm still interested
in the browser-button 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,
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 that is
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
15 matches
Mail list logo
