[whatwg] keygen 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 this element (at least, the documentation I could find, not much). I don't understand why this isn't an standard yet, and from what I can see, it doesn't look good for this element in HTML5 either. 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. Netbanks and other heavy security sites should/are using this. I have setup a system like this, and I'm more than happy to provide info and examples of how its done. I know that the documentation on element is almost non-existing. Microsoft (IE) doesn't support this tag, but Firefox and Opera does. Microsoft have info about why here: http://support.microsoft.com/kb/190282. Is there any hope for this element? What information does which people want to make this an HTML5 standard? Thanks Lars
Re: [whatwg] keygen 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 a vast set of test cases that demonstrate how this feature is implemented today. Ideally from those testcases we can write up a proposal that can then be incorporated into HTML5. I believe this is all that is blocking the inclusion of this feature at this point. (Though it might also be delayed slightly because Web Forms 2.0 is not integrated yet, but that might happen soon.) Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] keygen 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 verification. Netbanks and other heavy security sites should/are using this. ... Is there any hope for this element? What information does which people want to make this an HTML5 standard? Hi, how is this better than SSL/TLS? Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] keygen 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 keygen attribute, all this is done in a clean more secure way. The browser is generating everything, sends the public key with SPKAC (http://www.openssl.org/docs/apps/spkac.html) to the server. So as you see, its not an replacement of TLS/SSL in any way. Its just a better way to do it. -- Lars On Wed, Jul 9, 2008 at 2:35 PM, Rimantas Liubertas [EMAIL PROTECTED] wrote: ... 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. Netbanks and other heavy security sites should/are using this. ... Is there any hope for this element? What information does which people want to make this an HTML5 standard? Hi, how is this better than SSL/TLS? Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] keygen 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
[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 Link Fingerprints, which was a way to embed the hash of a file in a link to that file, thereby ensuring that the link user got only the exact file the link creator was referring to. http://www.foo.com/file.zip#!sha256:09F9... Implementing this idea was a Summer of Code project for Mozilla in 2007, but the draft RFC received a chilly reception on various IETF mailing lists. I have therefore reformulated Link Fingerprints as a simple extension to HTML. This makes it useful in a smaller set of contexts, but still hits the major use cases. a href=http://www.foo.com/file.zip; checksum=sha256:09F9...File/a The updated spec is here: http://www.gerv.net/security/link-fingerprints/ Please read it for more detailed aims, rationale and behaviour. It is now very similar to the microformat proposals here: http://microformats.org/wiki/hash-examples Would the WHAT-WG be interested in looking at standardising this? Gerv [0] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/thread.html#7825
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 hard to use. The ranges must be added by script, can't be supplied with the media, and the callbacks are awkward to handle. The only way to identify the range a received callback applies to is by creating not one but two separate functions for each range: one for enter, one for exit. While creating functions on-demand is easy in JavaScript it does fall under advanced techniques that most authors will be unfamiliar with. One of the features proposed for the next version of the video API is chapter markers and other embedded timed metadata, with corresponding callbacks for authors to hook into. Would that resolve the problem you mention? It may be that if we can define a way to embed cue-range-generating meta-data in the media resource, with an abstract 'api' to get it out, we'd deal with the only add by script issue here, yes. The others, not so much. Using elements makes ranges identifiable, traversable and modifiable by using familiar APIs and concepts. However it is true that there are other ways to get some of the same functionality. Unless the elements have some non-scripting functionality (like linking) the case is perhaps not totally compelling. Instantiating ranges from custom markup using script is a possibility. Overall, we remain concerned that typically it is the media author who would define what the ranges are, not really the page or particularly the script author. Media authors tend not to be happy writing scripts. This kind of feature is also not available in all languages that might provide access to the DOM API. JavaScript is really the only concern from HTML5's point of view; if other languages become relevant, they should get specially-crafted APIs for them when it comes to this kind of issue. The problem is that the current API more or less requires use of closures and currying except for trivial cases. We don't think that is good API design even for languages that have them. Perhaps at the very least a cookie could be passed? Secondly this mechanism is not very powerful. You can't do anything else with the ranges besides receiving callbacks and removing them. You can't modify them. They are not visible to scripts or CSS. You can't link to them. You can't link out from them. I'm not sure what it would really mean to link to or from a range, unless you turned the entire video into a link, in which case you can just wrap the video in an a href= element for the duration of the range, using script. Linking into a cue-range would be using its beginning or end as a seek point, or its duration as a restricted view of the media (only show me cue-range called InTheBathroom). Linking out of a cue-range would be establishing a click-through URL that would be dispatched directly if the user clicked on the media during that range (dispatched without script). We agree that neither of these should be in scope now, but it would be nice to have a framework that could be extended to cover these, in future. Thirdly, a script is somewhat strange place to define the ranges. A set of ranges usually relates closely to some particular piece of media content. The same set of ranges rarely makes much sense in the context of some other content. It seems that ranges should be defined or supplied along with the media content. For in-band data, callbacks for chapter markers as mentioned earlier seem like the best solution. For out-of-band data, if the ranges are just intended to trigger script, I don't think we gain much from providing a way to mark up ranges semi- declaratively as opposed to just having HTML-based media players define their own range markup and have them implement it using this API. It wouldn't be especially hard. This seems to conflict with the answer (1) above, doesn't it? Fourth, this kind of callback API is pretty strange creature in the HTML specification. The only other callback APIs are things like setTimeout() and the new SQL API which don't have associated elements. Events are the callback mechanism for everything else. Events use callbacks themselves, so it's not that unusual. I don't really think events would be a good interface for this. Consistency is good, but if one can come up with a better API, it's better to use that than just be consistent for the sake of it. It does seem strange that events are right in the spatial domain (mouse enter/exit), but not in the temporal domain. Yet the basic semantic of the english word event, let alone the web meaning, is pretty well exactly matched by what is happening here -- crossing a temporal boundary! Events are well-known and design uniformity suggests
[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/#requirements Any feedback would be greately appreciated, especially from authors involved in large Web applications who would make significant use of such a feature, and from implementors of browsers that may support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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.org/Archives/Public/public-geolocation/ As far as I can tell, all the feedback that had been sent to this list has already been taken into account by that list, so I will not forward all the feedback to the W3C as I sometimes do when feedback that was sent to the WHATWG list becomes more relevant for another specification. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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 they find they can no longer communicate with their origin server - access to read and write cookies. We have found that some workers want to be able to modify the cookies for their origins - access to some sort of printline/console debugging facility I still think you should be able to pass JSON-style objects between workers without needing to do the serialization yourself. This allows the implementation to pick a fast way to do the copy without having to go to a string. More importantly, it makes more sense if we're going to allow passing end points between workers too. Without this, you'd have to first pass a message to a worker as a string, then pass the end point. It makes more sense for callers to be able to build up an object parameter that includes strings, booleans, numbers, arrays, objects, and end points, along with any other datatypes we dream up that make sense to be passable. The API is more future-proof this way. Another idea (and something that is present in Gears) is the ability to load workers from another origin. This provides a way to do controlled cross-origin communication that is more lightweight than loading an iframe and doing postMessage() with it. - a On Wed, Jul 9, 2008 at 6:30 PM, Ian Hickson [EMAIL PROTECTED] wrote: 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/#requirements Any feedback would be greately appreciated, especially from authors involved in large Web applications who would make significant use of such a feature, and from implementors of browsers that may support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Origin header and forms
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 than in the application layer. This way servers could be configured to reject all POST requests that have an Origin header from a different site. This wouldn't replace the normal CSRF protections sites need to do for now, but eventually enough UAs implement this that servers can just reject POSTs that doesn't have 'Origin' set. This would be especially true if we can get this feature backported into old browsers (we'll likely backport it to FF3). / Jonas [1] http://dev.w3.org/2006/waf/access-control/
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 JavaScript still the primary client side scripting vehicle in HTML5? David - Original Message - From: Ian Hickson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 9:30 PM Subject: [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/#requirements Any feedback would be greately appreciated, especially from authors involved in large Web applications who would make significant use of such a feature, and from implementors of browsers that may support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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 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, or icon, or some such, and which invokes
user agent features. Something like:
browserbutton type=makeapp
...where type has a value to provide the page as a standalone Web
app, a value to make the browser perform feed autodetection on the
page and subscribe to the relevant feed, a value to print the page,
etc.
This is an interesting idea. However, traditionally the Web platform has
exposed hooks into UA functionality through APIs rather than custom
controls. For example, window.print(), history.back(),
history.forward(), location.reload(), window.stop(), window.prompt().
One could equally argue the opposite -- a href=, link rel=feed,
button type=submit, there are plenty of completely declarative browser
mechanisms that are exposed to authors too.
One could certainly imagine a custom element that can expose these kinds
of operations without the need for script, and with automatic
enable/disable. However, this would require a lot more complexity than a
method, as the element would need to be able to have different style for
the enabled and disabled cases (if custom look is done through literal
contents of the element, this is awkward), an API to query, and events
to hook in both before and after the special action.
Here's a proposal that seems relatively simple:
The syntax would just be an empty element:
browser-button
...with a few attributes, in particular one to specify the kind of
functionality being exposed (type=), and one to say whether the element
should be hidden or disabled if the feature isn't available.
The visual browser would then render this as an inline element, applying
all of CSS as appropriate, with just a single image 1em high being the
only content of the element, as if the element was:
spanimg src=.../span
Styling would then be done something like this:
browser-button::after {
content: Save as standalone application.;
color: blue;
text-decoration: underline;
}
...or:
browser-button {
appearance: button;
}
...or:
browser-button { border: solid outset; }
browser-button:active { border: solid inset; }
I think this may be a good idea, but I am not sure this feature should
be the test case for designing it.
Well, that's what people always say. If we only use unimportant features
to introduce ideas like this, they'll never see the light of day. :-)
Adding an API does not preclude also supporting a more declarative
mechanism in the future.
I'm very worried about adding yet another API that can spawn a dialog.
And if the new element ends up being just for this one feature, then to
my design taste it would seem like overkill to add an HTML element for
such a narrow purpose.
There are other things that need addressing too. One, for instance, is
HTTP logout:
browser-button type=logout onlogout=removeAuthUI()
It would clear the HTTP credentials for this origin, thus logging the user
out from an HTTP site. (We'd still need an inline HTTP authentication
mechanism, maybe something on form method.)
To be fair though, for completeness the API mechanism still needs a way
to report whether the UA supports a standalone Web app feature (perhaps
this can just be indicated by whether the method is present) and also
whether the user has already saved this particular page as a Web app (in
which case the Web app's UI should not further hector them).
Right, those are other reasons we would benefit from this being
declarative.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Origin header and forms
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 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 than in the application layer. This way servers could be configured to reject all POST requests that have an Origin header from a different site. This wouldn't replace the normal CSRF protections sites need to do for now, but eventually enough UAs implement this that servers can just reject POSTs that doesn't have 'Origin' set. This would be especially true if we can get this feature backported into old browsers (we'll likely backport it to FF3). / Jonas [1] http://dev.w3.org/2006/waf/access-control/
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 If the video's pixel ratio override's is none, then the video's intrinsic width is the width given by the resource itself. If the video has a pixel ratio override other than none, then the intrinsic width of the video is the width given by the resource itself, divided by the pixel ratio given by the resource itself, multiplied by the video's pixel ratio override. This is a pixel ratio *override*, suggest changing it to: If the video's pixel ratio override's is none, then the video's intrinsic width is the width given by the resource itself multiplied by the pixel ratio given by the resource itself. If the video has a pixel ratio override other than none, then the intrinsic width of the video is the width given by the resource itself multiplied by the video's pixel ratio override. The idea is that if you set the override to a 1:2 ratio, then each pixel of video data will be rendered 1:2. So you first have to normalise the width, getting rid of the influence of the official pixel ratio. No? I understand what the intention is, but think the terminology is confusing: - width given by the resource itself - height given by the resource itself - pixel ratio given by the resource itself I had thought that these 3 were actually orthogonal, such that the pixel ratio does not affect the width or the height. Instead, it seems that width/height is supposed to be aspect ratio pre-multiplied. This doesn't sit well with my intuition of what the self-given width/height of video is supposed to mean. If you open video in common media players the dimensions or width/height will be the physical width/height, not aspect-corrected width/height. Unless my intuition is severely broken, I think other will also assume what I have assumed. So again, I suggest that the paragraph be changed: If the video's pixel ratio override's is none, then the video's intrinsic width is the width given by the resource itself multiplied by the pixel ratio given by the resource itself. If the video has a pixel ratio override other than none, then the intrinsic width of the video is the width given by the resource itself multiplied by the video's pixel ratio override. Yes, it implicitly redefines width/height given by the resource itself to mean what they sound like. Strictly this really only matters to implementors, but less confusing language is good. Incidentally it is more in line with how it would actually be implemented -- one would hardly waste floating point calculations by multiplying by pixel ratio, dividing by pixel ratio and then multiplying it by override pixel ratio. -- Philip Jägenstedt Opera Software
