- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Mon, 4 Feb 2008 11:46:09 +0000
- To: "www-tag@w3.org" <www-tag@w3.org>, David Orchard <dorchard@bea.com>
David,
One or two comments on the recent draft:
Editorial:
==========
Section 2.
----------
Reword the start of:
"One example is placing a password on a page is a simple way to stop web crawlers
without really having to 'secure' the content."
as:
"One example is that placing a password on a page can be used as a simple way to stop..."
^^^^ ^^^^^^^^^^^^^^
Reword:
"Firstly, the user agent cannot determine what is sensitive."
as
"Firstly, the user agent cannot determine which data/information is sensitive."
^^^^^^^^^^^^^^^^^^^^^^
Reword:
"It is not always input using password masking, often for good reason.
as
"Sensitive information is not always input using password masking, often for good reason,
^^^^^^^^^^^^^^^^^^^^^
eg. user feedback when using non-keyboard iput devices."
Reword:
"Secondly, when javascript is enabled, the script can use the password in
the clear in many ways, which are too difficult for the browser to analyze.
as:
Secondly, when javascript is enabled, a script can be used to process a clear text
form field (possibly a password) for transfer in many ways, which are too difficult
for the browser to analyze.
Technical
=========
Section 2.1
-----------
"Digest Access Authentication[Digest]:
Digest Authentication acts as an extension to HTTP 1.0 and provides a way for authentication between parties without transmitting the password over the network. Instead the password is treated as a secret input to a digest algorithm. The resulting digest is transmitted and verified by the server. The Digest method requires that both parties have access to the same initial secret value. Many systems store passwords as a salted hash and it is not possible in practice for two parties using such systems to compute the same initial secret value."
I don't know what this is trying to tell me. It's not clear whether its saying that Digest Authentication is good or bad and whether or not it is desirable that system be able "...to compute the same initial secret value." I'd hope that Hal might be able to give us some clearer wording.
Section 3 last para:
--------------------
"This Good Practice does not contain a MUST because there are a few scenarios where password masking is not required. One example is that the user may request that the password be displayed in the clear in order to check the password as it is being entered. Another example is a password intended merely to stop web crawling and which consequently is not particularly sensitive. "
This para repeats advice and examples given earlier on section 2. I suggest deleting. I'd also suggest considering upgrading the SHOULD in the GPN to a MUST... on the basis that the UA chose the appropriate masking strategy ('trailing char visible', 'visible prior to submission - but obscured on 'back-button'). ie. the UA must honor a request to obsure a 'password' field in a manner that is appropriate to its interaction modalities.
"GPN: User agents MUST mask HTML password form fields in a manner consistent with their interaction modalities (keyboard, pen, speech...).
Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
(Tracker this is ISSUE-52).
> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
> On Behalf Of Norman Walsh
> Sent: 31 January 2008 19:07
> To: www-tag@w3.org
> Subject: Diff of passwords in the clear draft
>
> On 31 Jan, I took an action to diff Dave's most recent
> passwords in the clear draft with the previous draft. Here's
> the result:
>
> http://www.w3.org/2001/tag/doc/pw52-diff-20071108-20080124.html
>
> Be seeing you,
> norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | When teaching a rapidly changing
> http://nwalsh.com/ | technology, perspective is more
> | important than content.--R. Pattis
>
Received on Monday, 4 February 2008 11:48:41 UTC