Re: [whatwg] sic element
Bjartur Thorlacius wrote: Þann þri 2.ágú 2011 09:04, skrifaði Henri Sivonen: [...] From time to time, people want to take printed matter an publish it on the Web. In practice, the formats available are PDF and HTML. HTML works more nicely in browsers and for practical purposes works generally better when the person taking printed matter to the Web decides that the exact line breaks and the exact font aren't of importance. They may still consider it of importance to preserve bold, italic and underline [...] So you're arguing that a subset of HTML should be favored over presentational markup languages for marking up digital retypes of printed matter, with , , , , and be redefined to their HTML 3 typographical meanings. I can't speak for Henri, but agree with his point quoted above. There are of course other options as well, such as images and word processor file formats, but they have the same problem as PDF: they preserve too much of the formatting. Please note that this isn't about favoring HTML over presentational markup languages; none of the alternatives mentioned is a markup language at all. HTML has always been a presentational markup language, too, and HTML as officially defined (HTML 4.01, XHTML 1.0) still has presentational features, so the question is whether they should be taken away, not about "redefining" them. It is the WHATWG & HTML5 work that is proposing a redefinition. (I say "proposing", since from the viewpoint of implementor, author, and user communities as well as the W3C, they are proposals, not a standard. In many parts of HTML, the proposal has widely been or is being accepted in practice, but I see little signs of such things happening with the new meanings for and friends.) And perhaps standardized to mean indent. I wouldn't object to that, but _that_ would mean a change to the tradition of HTML specifications, and although mostly means "indent", it fairly often means a block quotation. Moreover, the situations where an HTML author needs to say "this text is indented in the printed original" without presenting any fixed interpretation of the intended meaning of indentation appear to be rather rare, as compared with situations where one needs to say e.g. "this text appears in italics in the printed original". If you simply retype print without any interpretation of the typography used, a valid speech rendering would e.g. cue bold text with "bold" and "unbold" marks to convey the meaning: this text was bold. It could, and that would actually reflect the authors intentions: he wishes to convey the idea of bolding, leaving it to the reader to infer or guess the meaning of bolding. (At the extreme, you might have a page that discusses a printed document in general and the use of bolding in it in particular, and then it is surely relevant to indicate the bolding - as "pure bolding".) In practice, speech rendering doesn't behave that way, but even if it did, it would constitute an argument in favor of the typographic markup, not against it. If all you want is to suggest original typographic rendering, then (save for Excerpt/Blockquote, Nofill/Pre and Lang/@lang) CSS does the job, better - and is vastly more powerful. This isn't about suggesting, this is about reproducing aspects of printed material that may be essential. It is comparable to making a distinction between lowercase and uppercase, which may be purely presentational or may carry essential information. The case distinction can be made by the simple choice of letters at the character level, or it may be delegated to CSS if it is regarded as purely presentational. For bolding etc., the character-level alternative does not exist or it is highly impractical (and e.g. mathematical italics letters are, in addition to being present in a few fonts only, intended for mathematical use rather than common use of italics). So all I'm asking is to preserve the existing features of HTML or, more exactly, preserve them without declaring them as obsolete. Yucca
Re: [whatwg] WebVTT feedback (was Re: Video feedback)
On Mon, Jun 27, 2011 at 6:07 PM, Silvia Pfeiffer wrote: > On Mon, Jun 27, 2011 at 5:34 PM, Anne van Kesteren wrote: >> On Mon, 27 Jun 2011 09:32:04 +0200, Silvia Pfeiffer >> wrote: >>> >>> Note that where his implementation differs from the spec, he has made >>> a note. There are only two such notes. I'd like to see these >>> addressed, too. >> >> Could you please post these to the list so that we not all have to read >> those documents? > > Good point. :-) (Just search for "differs"). Here they are - with some > additional descriptions: > > 1. [text track cue] size: > "this document differs from specs in that way that [text track cue] is > as width (for horizontal, height for vertical) as the widest (for > horizontal, highest for vertical) [text track cue line] within" > > What Ronny says there is that in his implementation the default > display size of the cue (i.e. the dark box that the cue is displayed > in) is only as wide as the longest line in the cue (or high where > we're dealing with vertical direction). Currently, the spec puts as a > default S:100%. > > I personally also prefer this smaller default cue width because it > covers less content of the video. > > > 2. Cue voice tag: > "this differs from specs in the way that opened voice tags should > be closed with " > > Ronny's point is that the element is expected to be closed, > because it makes it easier to parse. So, instead of: > > 00:01:07.395 --> 00:01:10.246 > Hey! > Hello! > > he expects: > > 00:01:07.395 --> 00:01:10.246 > Hey! > Hello! > > I think the same is true for his implementation of the class tags. > > > Cheers, > Silvia. > Adding one more to the list of things I've come across with the WebVTT spec. I am right now trying to figure out how vertical growing left cues (i.e. cues with a cue rendering setting of "D:vertical") are rendered. If nothing else is set on the cue, my expectation would be that the cue would be rendered on the right side of the video viewport, since it's growing to the left. As I follow through the algorithm at http://www.whatwg.org/specs/web-apps/current-work/webvtt.html#webvtt-cue-text-rendering-rules , I find that the default settings are: * the text track cue line position default is "auto", * the snap-to-lines flag is "true" by default, * block flow is left to right and in step 9 we get: "If the text track cue writing direction is vertical growing left, and the text track cue snap-to-lines flag is set, let x-position be zero". I think this is incorrect and should be "..., let x-position be 100" so as to allow the text boxes to flow onto the video viewport from the right boundary, rather than off its left border. Note that step 9 for vertical growing right is correct: "If the text track cue writing direction is vertical growing right, and the text track cue snap-to-lines flag is set, let x-position be zero." and the text should grow from the left boundary of the video viewport to the right. Cheers, Silvia.
Re: [whatwg] making dfn.js work for multipage spec [was: Spec references in multipage]
On Sat, 6 Aug 2011, Michael[tm] Smith wrote: > > It works -- and would also work for the full spec -- but I suspect there > probably has to be a better way to implement it than the way I did. > Because the way I did it very slow; it adds several minutes to the > anolis part of the document-building process. On the host I use for > building the author view of the spec, I think it causes the build to > take 6 minutes or so to run (compared to only a minute or two without > it). If Anolis is idempotent and can be run just again as part of the multipage generation, we could just have Philip and Anne add it to their splitters, if they're interested. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] TLS Logout - was: window.cipher HTML crypto API draft spec
Henry:
Please pardon my ignorance and thank you for the example. crypto.logout() is
probably the least known window API of the bunch. In 10 years of web
development I have never encountered its use. I knew there was a logout()
method, I was unsure how it was used.
Regards,
David
- Original Message -
From: "Henry Story"
To: "David Dahl"
Cc: whatwg@lists.whatwg.org, public-ident...@w3.org
Sent: Saturday, August 6, 2011 10:27:15 AM
Subject: Re: TLS Logout - was: window.cipher HTML crypto API draft spec
On 6 Aug 2011, at 17:01, David Dahl wrote:
> Henry,
>
> Your login and logout concept is a perhaps parallel to the sessions
> functionality in Mozilla's Identity work:
> https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-Session
David,
the logout() method I am speaking of is not a concept. It is part of Mozilla
and Internet Explorer and works. The Javascript is the following
-
function logout(elem) {
if (document.all == null) {
if (window.crypto) {
try{
window.crypto.logout();
return false; //firefox ok -- no need to follow the link
} catch (err) {//Safari, Opera, Chrome -- try with tis session
breaking
}
} else { //also try with session breaking
}
} else { // MSIE 6+
document.execCommand('ClearAuthenticationCache');
return false;
};
return true
}
function login(elem) { logout(elem) }
-
Then you can just put the following html in your page
Joe|logout
And Firefox and I believe MS will logout. I will have a server up demonstrating
that in the next few days.
This is the right way to close a TLS session. The browser then can ask the user
to choose a new certificate, certain that this was indeed what the user wanted.
So the above is at a different layer from what Mozilla is doing with the
verified e-mail protocol, since Mozilla is working on the verified e-mail
protocol but already has the logout() method.
If the verified e-mail protocol is the same as what is now known as BrowserId,
then I also support work in that area. But there are many organisations that
would find TLS client certificate usage dramatically improved if they could
just help the browser log out cleanly at the TLS layer. Specifying this can't
be that much work, and would help guide people in the right direction here.
Henry
>
>
> Cheers,
>
> David
>
> - Original Message -
> From: "Henry Story"
> To: "David Dahl"
> Cc: whatwg@lists.whatwg.org, public-ident...@w3.org
> Sent: Saturday, August 6, 2011 9:05:15 AM
> Subject: Re: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft
> spec
>
>
> On 6 Aug 2011, at 16:01, David Dahl wrote:
>
>> Henry:
>>
>> There is no reason a login and logout (that work properly) cannot be added
>> to window.crypto, however, the scope and focus of 'DOMCrypt' is as
>> narrowly-defined as possible. Adding features like this would only slow
>> progress.
>
> David, this is a really essential feature. If you are worried that one method
> call can slow progress of DOMCrypt, then where do you think that should be
> standardised?
>
> Or perhaps someone else has an opinion here?
>
> Henry
>
>>
>> Regards,
>>
>> David
>>
>> - Original Message -
>> From: "Henry Story"
>> To: "David Dahl"
>> Cc: whatwg@lists.whatwg.org, public-ident...@w3.org
>> Sent: Saturday, August 6, 2011 6:16:22 AM
>> Subject: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft spec
>>
>> Hi,
>>
>> I have been looking at how a client can logout from a TLS session recently,
>> so that if a user
>> sends the wrong certificate to the server, the server can propose a way for
>> the user to choose a
>> different one.
>>
>> The correct way to do this would be to build it right into the browser, so
>> that at all times the user is in control of his Persona, i.e. to extend Aza
>> Raskin's work to the TLS layer [1].
>>
>> The second best way is to have a Javascript API to logout the user, that web
>> page authors can use to offer this feature. Firefox and Internet explorer
>> have such an API. The Firefox one is described in the WebCrypto API [2] by
>> Channy Yun, which was discussed on this list recently.
>>
>> The code to run both in IE and Firefox is quite simple. I submitted a bug
>> report to Chrome with the
>> code to suggest that they could implement this there too
>>
>> http://code.google.com/p/chromium/issues/detail?id=90676
>>
>> But they want the DOMCrypt spec approval before implementing. Is that
>> something that could be added to DOMCrypt? Or should one look somewhere
>> else?
>>
>> This is a really simple function, but it is so useful.
>>
>> Henry
>>
>>
>> [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
>> [2] http://html5.creation.net/webcrypto-api/
>> (the login method does not work currently in Firefox, on has to use
>> logout, where the connection then
Re: [whatwg] TLS Logout - was: window.cipher HTML crypto API draft spec
On 6 Aug 2011, at 17:01, David Dahl wrote:
> Henry,
>
> Your login and logout concept is a perhaps parallel to the sessions
> functionality in Mozilla's Identity work:
> https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-Session
David,
the logout() method I am speaking of is not a concept. It is part of Mozilla
and Internet Explorer and works. The Javascript is the following
-
function logout(elem) {
if (document.all == null) {
if (window.crypto) {
try{
window.crypto.logout();
return false; //firefox ok -- no need to follow the link
} catch (err) {//Safari, Opera, Chrome -- try with tis session
breaking
}
} else { //also try with session breaking
}
} else { // MSIE 6+
document.execCommand('ClearAuthenticationCache');
return false;
};
return true
}
function login(elem) { logout(elem) }
-
Then you can just put the following html in your page
Joe|logout
And Firefox and I believe MS will logout. I will have a server up demonstrating
that in the next few days.
This is the right way to close a TLS session. The browser then can ask the user
to choose a new certificate, certain that this was indeed what the user wanted.
So the above is at a different layer from what Mozilla is doing with the
verified e-mail protocol, since Mozilla is working on the verified e-mail
protocol but already has the logout() method.
If the verified e-mail protocol is the same as what is now known as BrowserId,
then I also support work in that area. But there are many organisations that
would find TLS client certificate usage dramatically improved if they could
just help the browser log out cleanly at the TLS layer. Specifying this can't
be that much work, and would help guide people in the right direction here.
Henry
>
>
> Cheers,
>
> David
>
> - Original Message -
> From: "Henry Story"
> To: "David Dahl"
> Cc: whatwg@lists.whatwg.org, public-ident...@w3.org
> Sent: Saturday, August 6, 2011 9:05:15 AM
> Subject: Re: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft
> spec
>
>
> On 6 Aug 2011, at 16:01, David Dahl wrote:
>
>> Henry:
>>
>> There is no reason a login and logout (that work properly) cannot be added
>> to window.crypto, however, the scope and focus of 'DOMCrypt' is as
>> narrowly-defined as possible. Adding features like this would only slow
>> progress.
>
> David, this is a really essential feature. If you are worried that one method
> call can slow progress of DOMCrypt, then where do you think that should be
> standardised?
>
> Or perhaps someone else has an opinion here?
>
> Henry
>
>>
>> Regards,
>>
>> David
>>
>> - Original Message -
>> From: "Henry Story"
>> To: "David Dahl"
>> Cc: whatwg@lists.whatwg.org, public-ident...@w3.org
>> Sent: Saturday, August 6, 2011 6:16:22 AM
>> Subject: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft spec
>>
>> Hi,
>>
>> I have been looking at how a client can logout from a TLS session recently,
>> so that if a user
>> sends the wrong certificate to the server, the server can propose a way for
>> the user to choose a
>> different one.
>>
>> The correct way to do this would be to build it right into the browser, so
>> that at all times the user is in control of his Persona, i.e. to extend Aza
>> Raskin's work to the TLS layer [1].
>>
>> The second best way is to have a Javascript API to logout the user, that web
>> page authors can use to offer this feature. Firefox and Internet explorer
>> have such an API. The Firefox one is described in the WebCrypto API [2] by
>> Channy Yun, which was discussed on this list recently.
>>
>> The code to run both in IE and Firefox is quite simple. I submitted a bug
>> report to Chrome with the
>> code to suggest that they could implement this there too
>>
>> http://code.google.com/p/chromium/issues/detail?id=90676
>>
>> But they want the DOMCrypt spec approval before implementing. Is that
>> something that could be added to DOMCrypt? Or should one look somewhere
>> else?
>>
>> This is a really simple function, but it is so useful.
>>
>> Henry
>>
>>
>> [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
>> [2] http://html5.creation.net/webcrypto-api/
>> (the login method does not work currently in Firefox, on has to use
>> logout, where the connection then asks the client for a certificate)
>>
>>
>>
>>
>>
>> On 20 May 2011, at 17:04, David Dahl wrote:
>>
>>> Hello WHATWG members,
>>>
>>> With user control and privacy in mind, I have created a spec and an
>>> implementation for an easy to use cryptography API called DOMCrypt. This
>>> API will provide each web browser window with a 'cipher' property that
>>> facilitates:
>>>
>>> * asymmetric encryption key pair generation
>>> * public key encryption
>>> * decryption
>>> * signature generation
>>> * signature
Re: [whatwg] TLS Logout - Re: window.cipher HTML crypto API draft spec
Henry, Your login and logout concept is a perhaps parallel to the sessions functionality in Mozilla's Identity work: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-Session Cheers, David - Original Message - From: "Henry Story" To: "David Dahl" Cc: whatwg@lists.whatwg.org, public-ident...@w3.org Sent: Saturday, August 6, 2011 9:05:15 AM Subject: Re: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft spec On 6 Aug 2011, at 16:01, David Dahl wrote: > Henry: > > There is no reason a login and logout (that work properly) cannot be added to > window.crypto, however, the scope and focus of 'DOMCrypt' is as > narrowly-defined as possible. Adding features like this would only slow > progress. David, this is a really essential feature. If you are worried that one method call can slow progress of DOMCrypt, then where do you think that should be standardised? Or perhaps someone else has an opinion here? Henry > > Regards, > > David > > - Original Message - > From: "Henry Story" > To: "David Dahl" > Cc: whatwg@lists.whatwg.org, public-ident...@w3.org > Sent: Saturday, August 6, 2011 6:16:22 AM > Subject: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft spec > > Hi, > > I have been looking at how a client can logout from a TLS session recently, > so that if a user > sends the wrong certificate to the server, the server can propose a way for > the user to choose a > different one. > > The correct way to do this would be to build it right into the browser, so > that at all times the user is in control of his Persona, i.e. to extend Aza > Raskin's work to the TLS layer [1]. > > The second best way is to have a Javascript API to logout the user, that web > page authors can use to offer this feature. Firefox and Internet explorer > have such an API. The Firefox one is described in the WebCrypto API [2] by > Channy Yun, which was discussed on this list recently. > > The code to run both in IE and Firefox is quite simple. I submitted a bug > report to Chrome with the > code to suggest that they could implement this there too > > http://code.google.com/p/chromium/issues/detail?id=90676 > > But they want the DOMCrypt spec approval before implementing. Is that > something that could be added to DOMCrypt? Or should one look somewhere else? > > This is a really simple function, but it is so useful. > > Henry > > > [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ > [2] http://html5.creation.net/webcrypto-api/ >(the login method does not work currently in Firefox, on has to use > logout, where the connection then asks the client for a certificate) > > > > > > On 20 May 2011, at 17:04, David Dahl wrote: > >> Hello WHATWG members, >> >> With user control and privacy in mind, I have created a spec and an >> implementation for an easy to use cryptography API called DOMCrypt. This API >> will provide each web browser window with a 'cipher' property that >> facilitates: >> >> * asymmetric encryption key pair generation >> * public key encryption >> * decryption >> * signature generation >> * signature verification >> * hashing >> * easy public key discovery via meta tags >> >> I have created a Firefox extension that implements all of the above, and am >> working on an experimental patch that integrates this API into Firefox. >> >> The draft spec is here: >> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >> >> The project originated in an extension I wrote, the home page is here: >> http://domcrypt.org >> >> The source code for the extension is here: >> https://github.com/daviddahl/domcrypt >> >> The Mozilla bugs are here: >> https://bugzilla.mozilla.org/show_bug.cgi?id=649154 >> https://bugzilla.mozilla.org/show_bug.cgi?id=657432 >> >> You can test the API by installing the extension hosted at domcrypt.org and >> addons.mozilla.org, and going to http://domcrypt.org >> >> Best Regards, >> >> David Dahl >> >> Firefox Engineer, Mozilla Corp. > > Social Web Architect > http://bblfish.net/ > Social Web Architect http://bblfish.net/
Re: [whatwg] TLS Logout - Re: window.cipher HTML crypto API draft spec
On 6 Aug 2011, at 16:01, David Dahl wrote: > Henry: > > There is no reason a login and logout (that work properly) cannot be added to > window.crypto, however, the scope and focus of 'DOMCrypt' is as > narrowly-defined as possible. Adding features like this would only slow > progress. David, this is a really essential feature. If you are worried that one method call can slow progress of DOMCrypt, then where do you think that should be standardised? Or perhaps someone else has an opinion here? Henry > > Regards, > > David > > - Original Message - > From: "Henry Story" > To: "David Dahl" > Cc: whatwg@lists.whatwg.org, public-ident...@w3.org > Sent: Saturday, August 6, 2011 6:16:22 AM > Subject: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft spec > > Hi, > > I have been looking at how a client can logout from a TLS session recently, > so that if a user > sends the wrong certificate to the server, the server can propose a way for > the user to choose a > different one. > > The correct way to do this would be to build it right into the browser, so > that at all times the user is in control of his Persona, i.e. to extend Aza > Raskin's work to the TLS layer [1]. > > The second best way is to have a Javascript API to logout the user, that web > page authors can use to offer this feature. Firefox and Internet explorer > have such an API. The Firefox one is described in the WebCrypto API [2] by > Channy Yun, which was discussed on this list recently. > > The code to run both in IE and Firefox is quite simple. I submitted a bug > report to Chrome with the > code to suggest that they could implement this there too > > http://code.google.com/p/chromium/issues/detail?id=90676 > > But they want the DOMCrypt spec approval before implementing. Is that > something that could be added to DOMCrypt? Or should one look somewhere else? > > This is a really simple function, but it is so useful. > > Henry > > > [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ > [2] http://html5.creation.net/webcrypto-api/ >(the login method does not work currently in Firefox, on has to use > logout, where the connection then asks the client for a certificate) > > > > > > On 20 May 2011, at 17:04, David Dahl wrote: > >> Hello WHATWG members, >> >> With user control and privacy in mind, I have created a spec and an >> implementation for an easy to use cryptography API called DOMCrypt. This API >> will provide each web browser window with a 'cipher' property that >> facilitates: >> >> * asymmetric encryption key pair generation >> * public key encryption >> * decryption >> * signature generation >> * signature verification >> * hashing >> * easy public key discovery via meta tags >> >> I have created a Firefox extension that implements all of the above, and am >> working on an experimental patch that integrates this API into Firefox. >> >> The draft spec is here: >> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >> >> The project originated in an extension I wrote, the home page is here: >> http://domcrypt.org >> >> The source code for the extension is here: >> https://github.com/daviddahl/domcrypt >> >> The Mozilla bugs are here: >> https://bugzilla.mozilla.org/show_bug.cgi?id=649154 >> https://bugzilla.mozilla.org/show_bug.cgi?id=657432 >> >> You can test the API by installing the extension hosted at domcrypt.org and >> addons.mozilla.org, and going to http://domcrypt.org >> >> Best Regards, >> >> David Dahl >> >> Firefox Engineer, Mozilla Corp. > > Social Web Architect > http://bblfish.net/ > Social Web Architect http://bblfish.net/
Re: [whatwg] TLS Logout - Re: window.cipher HTML crypto API draft spec
Henry: There is no reason a login and logout (that work properly) cannot be added to window.crypto, however, the scope and focus of 'DOMCrypt' is as narrowly-defined as possible. Adding features like this would only slow progress. Regards, David - Original Message - From: "Henry Story" To: "David Dahl" Cc: whatwg@lists.whatwg.org, public-ident...@w3.org Sent: Saturday, August 6, 2011 6:16:22 AM Subject: TLS Logout - Re: [whatwg] window.cipher HTML crypto API draft spec Hi, I have been looking at how a client can logout from a TLS session recently, so that if a user sends the wrong certificate to the server, the server can propose a way for the user to choose a different one. The correct way to do this would be to build it right into the browser, so that at all times the user is in control of his Persona, i.e. to extend Aza Raskin's work to the TLS layer [1]. The second best way is to have a Javascript API to logout the user, that web page authors can use to offer this feature. Firefox and Internet explorer have such an API. The Firefox one is described in the WebCrypto API [2] by Channy Yun, which was discussed on this list recently. The code to run both in IE and Firefox is quite simple. I submitted a bug report to Chrome with the code to suggest that they could implement this there too http://code.google.com/p/chromium/issues/detail?id=90676 But they want the DOMCrypt spec approval before implementing. Is that something that could be added to DOMCrypt? Or should one look somewhere else? This is a really simple function, but it is so useful. Henry [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ [2] http://html5.creation.net/webcrypto-api/ (the login method does not work currently in Firefox, on has to use logout, where the connection then asks the client for a certificate) On 20 May 2011, at 17:04, David Dahl wrote: > Hello WHATWG members, > > With user control and privacy in mind, I have created a spec and an > implementation for an easy to use cryptography API called DOMCrypt. This API > will provide each web browser window with a 'cipher' property that > facilitates: > > * asymmetric encryption key pair generation > * public key encryption > * decryption > * signature generation > * signature verification > * hashing > * easy public key discovery via meta tags > > I have created a Firefox extension that implements all of the above, and am > working on an experimental patch that integrates this API into Firefox. > > The draft spec is here: > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest > > The project originated in an extension I wrote, the home page is here: > http://domcrypt.org > > The source code for the extension is here: > https://github.com/daviddahl/domcrypt > > The Mozilla bugs are here: > https://bugzilla.mozilla.org/show_bug.cgi?id=649154 > https://bugzilla.mozilla.org/show_bug.cgi?id=657432 > > You can test the API by installing the extension hosted at domcrypt.org and > addons.mozilla.org, and going to http://domcrypt.org > > Best Regards, > > David Dahl > > Firefox Engineer, Mozilla Corp. Social Web Architect http://bblfish.net/
[whatwg] TLS Logout - Re: window.cipher HTML crypto API draft spec
Hi, I have been looking at how a client can logout from a TLS session recently, so that if a user sends the wrong certificate to the server, the server can propose a way for the user to choose a different one. The correct way to do this would be to build it right into the browser, so that at all times the user is in control of his Persona, i.e. to extend Aza Raskin's work to the TLS layer [1]. The second best way is to have a Javascript API to logout the user, that web page authors can use to offer this feature. Firefox and Internet explorer have such an API. The Firefox one is described in the WebCrypto API [2] by Channy Yun, which was discussed on this list recently. The code to run both in IE and Firefox is quite simple. I submitted a bug report to Chrome with the code to suggest that they could implement this there too http://code.google.com/p/chromium/issues/detail?id=90676 But they want the DOMCrypt spec approval before implementing. Is that something that could be added to DOMCrypt? Or should one look somewhere else? This is a really simple function, but it is so useful. Henry [1] http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ [2] http://html5.creation.net/webcrypto-api/ (the login method does not work currently in Firefox, on has to use logout, where the connection then asks the client for a certificate) On 20 May 2011, at 17:04, David Dahl wrote: > Hello WHATWG members, > > With user control and privacy in mind, I have created a spec and an > implementation for an easy to use cryptography API called DOMCrypt. This API > will provide each web browser window with a 'cipher' property that > facilitates: > > * asymmetric encryption key pair generation > * public key encryption > * decryption > * signature generation > * signature verification > * hashing > * easy public key discovery via meta tags > > I have created a Firefox extension that implements all of the above, and am > working on an experimental patch that integrates this API into Firefox. > > The draft spec is here: > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest > > The project originated in an extension I wrote, the home page is here: > http://domcrypt.org > > The source code for the extension is here: > https://github.com/daviddahl/domcrypt > > The Mozilla bugs are here: > https://bugzilla.mozilla.org/show_bug.cgi?id=649154 > https://bugzilla.mozilla.org/show_bug.cgi?id=657432 > > You can test the API by installing the extension hosted at domcrypt.org and > addons.mozilla.org, and going to http://domcrypt.org > > Best Regards, > > David Dahl > > Firefox Engineer, Mozilla Corp. Social Web Architect http://bblfish.net/
[whatwg] making dfn.js work for multipage spec [was: Spec references in multipage]
Ian Hickson , 2011-07-29 00:36 +: > On Mon, 2 May 2011, Glenn Maynard wrote: > > > > This is probably a known issue, but the reference lists in the multipage > > version of the specs only list references within the same section of the > > spec. Clicking "submitted" in [1] shows only two references. Clicking > > the same thing in the single-page version shows nine. It would be very > > helpful if external references were included. > > > > [1] > > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit > > Yeah, this is the result of the dfn.js script only looking in the current > document. If anyone is interested in fixing this, let me know and I can > try to explain the problem space. (One solution is to change the spec > splitter to output data that a new dfn.js can use.) I did make the dfn.js stuff work for the "Edition for Web Authors" subset of the spec: http://dev.w3.org/html5/spec-author-view/ Example: click on the phrase "space characters" here: http://dev.w3.org/html5/spec-author-view/common-microsyntaxes.html#space-character I did it by patching both anolis (to add a new filter) and the splitter code: http://dev.w3.org/cvsweb/html5/spec-author-view/patch.anolis?rev=HEAD;content-type=text%2Fplain http://dev.w3.org/cvsweb/html5/spec-author-view/patch.spec-splitter.1?rev=HEAD;content-type=text%2Fplain It works -- and would also work for the full spec -- but I suspect there probably has to be a better way to implement it than the way I did. Because the way I did it very slow; it adds several minutes to the anolis part of the document-building process. On the host I use for building the author view of the spec, I think it causes the build to take 6 minutes or so to run (compared to only a minute or two without it). --Mike -- Michael[tm] Smith http://people.w3.org/mike/+
