- From: <mzurko@us.ibm.com>
- Date: Fri, 23 Apr 2010 12:31:56 +0000
- To: timeless <timeless@gmail.com>
- Cc: public-usable-authentication@w3.org
Dear timeless ,
The Web Security Context Working Group has reviewed the comments you sent
[1] on the Last Call Working Draft [2] of the Web Security Context: User
Interface Guidelines published on 9 Mar 2010. Thank you for having taken
the time to review the document and to send us comments!
The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/2006/WSC/drafts/rec/rewrite.html.
Please review it carefully and let us know by email at
public-usable-authentication@w3.org if you agree with it or not before 30
April 2010 (Arbor Day). In case of disagreement, you are requested to
provide a specific solution for or a path to a consensus with the Working
Group. If such a consensus cannot be achieved, you will be given the
opportunity to raise a formal objection which will then be reviewed by the
Director during the transition of this document to the next stage in the
W3C Recommendation Track.
Thanks,
For the Web Security Context Working Group,
Thomas Roessler
W3C Staff Contact
1.
http://www.w3.org/mid/bb9848a71003240506x2cfde36frdcb5a0205f2e76b7@mail.gmail.com
2. http://www.w3.org/TR/2010/WD-wsc-ui-20100309/
=====
Your comment on :
> This is a public version of an email which was original sent on March
> 10th.
>
> http://www.w3.org/TR/2010/WD-wsc-ui-20100309/
> 4.2.1 Common User Interface elements
> ...
> > Examples of... include the... "Security Properties" dialogue...
>
> You use "dialogue" and "dialog" inconsistently, I'd suggest/request
> that you only use one.
>
> > We occasionally use the term [Definition: chrome] to refer to the
> representation through which the user interacts with the user agent
> itself, as distinct from the web content accessed.
>
> "web content accessed" is awkward, "accessed web content" sounds better
> to me.
>
> > This includes primary and secondary user interface.
>
> i think you need 'both' or 'interfaces'
>
> > A trust anchor represents an authoritative entity represented via a
> public key and associated data.
>
> 'via' here seems odd, i think 'by' is more appropriate.
>
> > by enforcing the constraints expressed in the associated data.
>
> i think either "in their" or "by their"
>
> > Note that trust anchor update is therefore often handled as part of
> user agent or operating system software updates.
>
> "trust anchor updates" or "updating trust anchors"
>
> > to a agent's store
>
> an agent's
>
> > of trust roots
>
> "trust roots" is used 3 times but not defined. I think you should use
> some other defined term.
>
> > that certificate is not considered accepted interactively.
>
> "interactively accepted" (this is a defined term)
>
> 5.1.2 Augmented Assurance Certificates
>
> > Some trust anchors adhere to documented broadly accepted practices
>
> the lack of punctuation between documented and practices troubles me.
>
> > (e.g. [EVTLSCERT]) that involve some level of guarantee that
> certificates
>
> i think you want 'which' instead of 'that'
>
> > chaining up to those roots embody augmented assurance
>
> 'augmented assurance' is not a defined term, and in this context it's
> missing an indication of what it's assuring.
>
> > and can therefore be treated more favorably in terms of the primary
> security indicators.
>
> note: you're spelling favorably according to en-US, as such, you
> should spell dialog according to en-US.
>
> > an augmented assurance specification supported by the user agent.
>
> I don't understand this. I think you're trying to say that it
> satisfies some EV specification, but for some reason it doesn't read
> well.
>
> > The certificate chain for such a certificate MUST be validated up to
> a trust root that is recognized as augmented assurance qualified by the
> user agent.]
>
> What happens If it fails to validate up to such a trust root? This
> really should have been incorporated into your defining sentence --
> not added as a secondary sentence that's just included in your
> brackets.
>
> > This specification does not define what an "augmented assurance
> qualified trust root" is,
>
> that's true, but it doesn't use that quoted phrase anywhere else at
> all, which means it's a useless statement. Your document should be
> self consistent and is not.
>
> > except to note that this designation is made by user agents through
> an out of band mechanism consistent with the relevant underlying
> augmented assurance specification.
>
> As written you're requiring that there be precisely one such
> specification ('the...specification'). That seems problematic as it
> essentially endorses EV as the one and only.
>
> > Implementations MUST NOT enable users to designate trust roots as
> augmented assurance qualified as part of a different interaction.
>
> "different interaction" is odd, i'd suggest "unrelated interaction" or
> rewriting the sentence entirely.
>
> Implementations MUST only allow users to designate trust roots as
> augmented assurance qualified via direct interaction for that purpose.
>
> > In both situations, use of TLS provides confidentiality protection
> services against passive attackers.
>
> This is an objectionable overstatement. "In both situations, TLS is
> used in an attempt to provide confidentiality protection services
> against passive attackers."
>
> > Simply put, if a Web site consistently presents the same self-signed
> certificate ... then this can be strong evidence that protection against
> an active attacker has been achieved as well.
>
> Unless of course the attacker has taken over the remote server. Please
> qualify the attacker as not having attained local access/control on
> the machine.
>
> > Conversely, a change of certificates for the same site can be
> evidence that a man in the middle attack occurs -- or it can be a
> symptom that the legitimate site has changed to a different
> certificate.
>
> "symptom" is a really odd word, "or it can merely indicate"
>
> > [Definition: A Web page is called TLS-secured if the top-level
> resource and all other resources that can affect or control the page's
> content and presentation have been retrieved through strongly TLS
> protected HTTP transactions. ]
>
> If the user adds content, this isn't content that was retrieved via
> TLS and it does affect the page's content....
> This would also apply to HTML5 storage concepts.
>
> > This definition implies that inline images, stylesheets, script
> content, and frame content for a secure page need to be retrieved
> through strongly TLS protected HTTP transactions in order for the
> overall page to be considered TLS-secured.
>
> You should probably mention plugins....
>
> > strongly TLS-protected interactions.
>
> you've overloaded 'interactions' to include both user-content
> interaction and client-server, this is unfortunate.
>
> > and the certificate chain presented was not pinned to the destination
> at hand
>
> I'd suggest avoiding colloquialisms such as "at hand".
>
> > unless it is attested to.
>
> ending a sentence with a preposition should be considered poor form
> for a technical document.
>
> > certificates... are... revoked,... Danger Messages... MUST be used.
> > certificates... are... expired,... Danger Messages... MUST be used.
>
> While I would generally agree, I think that this policy results in
> more harm than good. I know my employer can't get this right, and for
> Mozilla, I worked very hard to improve the latter without promoting it
> to be a DANGER message. Often the cause with our product is user error
> (incorrectly configured system clock).
>
> > On the other hand, a user agent such as a smart phone, individual
> entertainment screen in an airplane seat back, or TV set which has a
> usage mode that makes minimal (but visible) chrome elements available
> does need to preserve security indicators in such a mode.
>
> This would make MicroB on the n900 non conformant. It has minimal
> chrome but does not show security indicators in the primary user
> interface. I think this decision was actually the correct one.
>
> *****
> I've been instructed to be careful about my wording, so I'd request
> time to get back to you with a more appropriately phrased statement
> regarding this item.
> *****
>
> > User agents with a visual user interface MUST show the Identity
> Signal in a consistent visual position. Web Content MUST NOT obscure
> security user interface, 7.4.1 Obscuring or disabling Security User
> Interfaces.
>
> Does not showing it at all satisfy this requirement? MicroB in the
> n900 shows security information in an animated transient manner.
>
> > During... The identity signal MUST include human-readable
> information
>
> This seems to indicate that a simple lock icon (or any other form of
> pure iconography) is insufficient. In some browsers with space
> constraints, it's likely that all you'd see is a favicon with a
> special background color. Additional information is available in
> secondary ui, but I believe "identity signal" was used to mean
> primary.
>
> > an validated
>
> 'a'
>
> > If the identity signal does not include ... information ... then it
> MUST include an applicable DNS name
>
> Otherwise?
>
> > User agents MAY shorten such a DNS name by displaying only a suffix.
>
> So I can shorten
>
thisiswaytoolongtofitonanyreasonablecomputerscreenbecauseiintentionallywroteitjustlikethat.co.uk
> to "co.uk"? great, thanks.
>
> > Subject logotypes [RFC3709] derived from certificates MUST NOT
> be rendered, unless the certificate used is an augmented assurance
> certificate.
>
> Since most vendors don't support logotypes, I'm not going to cry (I
> did try adding logotype support somewhere once about 5 years ago
> iirc).
>
> > Note that this behavior does not apply when self-signed certificates
> or certificate chains that chain up to an untrusted root certificate are
> used.
>
> What does "does not apply" mean?
>
> > site identity information exceeding those
>
> exceeding? perhaps "beyond"? those => that which is
>
> > During interactions with mixed content, user agents MUST NOT render
> any logotypes [RFC3709] derived from certificates.
>
> Given how rare logotype support is, I don't think it's particularly
> appropriate to regulate its use. Let the market play out. So far, it
> played out by killing them.
>
> > Web user agents provide additional security context information as
> described in this section.
>
> Odd statement. Web user agents provide additional security context
> information as they please. If you want to make a request with a
> SHOULD or MAY, then do so, but don't write a declaration of fact that
> oversteps your bounds.
>
> > 3. Whether the user has visited the site in the past.
>
> Useragents can't tell a user if he's used another agent or another
> device to visit a site. Please don't ask them to do the impossible.
>
> > The [Definition: TLS indicator] MUST be part of primary user
> interface during usage modes which entail the presence of signaling to
> the user beyond only presenting page content.
>
> i still object
>
> > Web content MUST NOT obscure security interface, 7.4.1 Obscuring or
> disabling Security User Interfaces.
>
> this isn't really a sentence.
>
> > Primary user interface error messages MUST NOT be phrased solely in
> terms of art.
>
> the term 'art' here is odd and unhelpful.
>
> > They SHOULD NOT refer the user to enter the destination site that
> caused the error,
>
> I'd suggest "tell" instead of "refer". "refer" would be used if the
> object is a person not an action.
>
> > user agents SHOULD enable the user to easily return to the user agent
> state prior to initiation of the last user interaction that led to the
> error signal.
>
> If a web page involves submitting a form (POST) to a broken site, or
> if the previous page the user was on is the result of a POST, then
> trying to let the user return to the previous state is hard, risky,
> dangerous, or perhaps simply impossible. SHOULD is perhaps too strong
> given this. It's also possible that the last "user" action happened
> long before the web page randomly contorted itself and then redirected
> to the broke site, in which case "returning" to the state where the
> user last interacted is impossible (javascript doesn't support
> rollblack...).
>
> > For advanced users ... have an option for advanced users
>
> Please don't repeat yourself.
>
> > to request a detailed description of the condition that caused the
> interaction to occur.
>
> this is odd the "condition"-"interaction" is "you clicked on a link to
> a bad server", do you want a detailed explanation for the user showing
> exactly how they managed to click on a link to a bad server? I
> wouldn't call an error state an "interaction" -- it seems like you
> did here.
>
> > The error interactions characterized in this section typically
> involve communication of security context information.
>
> "characterized" is strange....
>
> > Warning / Caution messages MUST interrupt the user's current task,
> such that the user must acknowledge the message.
>
> there's a second "must" in this sentence which is not in RFC form.
> There's also a huge risk of desensitizing the user if this is done
> wrong. There is already evidence that users ignore these messages and
> blame browsers for interrupting their task.
>
> > distinct options how to proceed
>
> this sounds wrong grammatically
>
> > their meanings can be understood
>
> I find the plural "meanings" awkward, perhaps you can avoid using the
> plural form?
>
> > Danger Messages are intended for situations when there is a
> positively identified danger to the user (i.e., not merely a risk).
>
> This is odd, if a site's certificate expired yesterday, how is that a
> positively identified danger? It's an indication of a careless site
> admin (of which my employer is a good example, but so are most sites).
>
> [http://www-10.lotus.com/ldd/nflsblog.nsf/dx/RecertifyingIDs] is
> vaguely interesting.
> http://venafiblog.com/?p=178 is also amusing.
> http://venafiblog.com/?p=24 is depressing.
>
> > The interactions communicating these messages MUST be designed such
> that the user's task is interrupted.
>
> Yeah, I'd like to congratulate JAL, they sure interrupted the task of
> all those people trying to fly all over the world.
>
> > These interactions MUST be presented in a way that makes it
> impossible for the user go to or interact with the destination web site
> that caused the danger situation to occur, without first explicitly
> interacting with the Danger Message.
>
> I'm unsure that this truly helps the check-in agents. I understand
> that there's a huge danger and that obviously no one should ever fly
> JAL again, but....
>
> > For visual user agents, agent chrome SHOULD always be present to
> signal security context information.
>
> This SHOULD is annoying for minimal chrome agents. A user of a mobile
> browser doesn't care about the fact that many of the pages have or
> don't have valid certificates. Sadly, it makes more sense for such
> agents to enable the user to ask the browser "is it safe for me to
> enter information" at the time the user enters information instead of
> when the user visits pages. It might actually make sense in some case
> for a browser to allow interaction with sites but refuse to allow
> downloads. I'm not saying that I want my browser to do this, but I'm
> wondering if perhaps a browser should be allowed to make this choice.
>
> Note that desktop browsers such as IE now show security information
> when presenting downloads, so the idea of a minimal user agent doing
> the same isn't so far fetched.
>
> Asking MicroB to add extra chrome makes it harder for it to compete
> with Firefox for Mobile which has 0 visible chrome while browsing. It
> would essentially force us to change to a system where our chrome DOES
> NOT constitute a PRIMARY USER INTERFACE and is instead some strange
> "SECONDARY INTERFACE".
>
> > 7.2 Do not mix content and security indicators
>
> If an iframe contains a link to a site with an expired certificate and
> the user clicks the link, do you want the user agent to destroy the
> outer browsing context just to show the security indicator alone? This
> does not seem ideal
>
> > attentive user might look for.
>
> please avoid ending sentences with prepositions
>
> > Web User Agents MUST NOT communicate trust information using user
> interface elements which can be mimicked within chrome under the control
> of web content.
>
> MicroB supports full screen flash, in such a mode, the flash content
> can mimic all user interface elements, and demanding that full screen
> flash not work is a violation of our ability to deliver Flash. There's
> a distinction in that if the user wants security information there are
> certain keys the user can press which ensures trusted content, similar
> to the use of CONTROL-ALT-DELETE on Windows.
>
> > User interfaces used to inform users about security critical events
> or to solicit input
> > MUST employ techniques that prevent immediate dismissal of the user
> interface,
> > e.g., by using a temporarily disabled "OK" button on user interfaces
> that make such
> > an interaction paradigm available.
>
> Every time we force users to use such interfaces, they complain very
> loudly.
>
> https://bugs.maemo.org/show_bug.cgi?id=6436#c0 (there are about 5 or
> perhaps even 10 complaints about our UI for this case).
>
> Note that we don't make it easy for users to dismiss the error state,
> and as a result they complain. I'm not saying our UI or UE is
> wonderful, but we are compliant with your MUST and the result is
> annoyed users.
>
> > interactions caused by Web content MUST NOT be granted control of the
> user agent's interaction.
>
> the word 'interactions' here is unfortunate, can you try to use some
> other words or phrases? In this case, merely dropping "interactions
> caused by" would probably be the best course of action.
>
> > A Web User Agent SHOULD NOT display a modal security dialog related
> to a web page which does not currently have focus.
>
> Showing a modal dialog doesn't necessarily mean showing it to the
> user. If I have two windows and the user is browsing in one, and the
> other redirects to a page which triggers a window modal dialog, which
> the user does not see, then i have shown a modal security dialog for a
> web page that does not have focus, but as long as the dialog does not
> get focus, because it is merely window modal and not application
> modal, it might not be a problem.
>
> Please be careful not to overstep, and don't rely on SHOULD to protect
> you from overstepping.
>
> > User agents MUST restrict window sizing and moving operations
> consistent with 7.1 Keep Security Chrome Visible.
>
> This doesn't read as a sentence. Perhaps "keeping"
>
> > User agents MUST NOT allow web content to open new windows with the
> agent's security UI hidden.
>
> MicroB has a user preference for whether windows open full screen or
> with chrome, in neither case do we show security UI, we don't
> specifically allow the web page to control whether it is opened in
> full screen or not, but when it asks for a page to be opened, the
> security UI is hidden.
>
> Your requirement here is burdensome and unreasonable. I understand
> your intent, but you're going to cause more harm than good by
> structuring it this way.
>
> > Allowing this operation facilitates picture-in-picture attacks
>
> Typically does. For MicroB it does not, because of the way the ui
> actually works. To trigger menus, you either use:
> 1. Power Key (not trappable by web content)
> 2. Ctrl-Backspace (not trappable by web content)
> 3. Camera cover / button (not trappable by web content)
> 4. a full screen indicator which appears whenever you interact with a
> web page while in full screen (either by tapping the screen, or by
> pressing a key -- the latter sadly annoys customers, there's a bug
> reference for that if you want it).
> 5. if not in full screen, pressing the menu area, which would do
> something that would violate 4 if the page was trying to trick the
> user.
>
> > Web user agents MUST NOT expose programming interfaces which permit
> installation of software without a user intervention.
>
> This is a good requirement, sadly we have a management requirement to
> the contrary, and while I personally hate it, they've overruled me,
> and I don't think that your requirement will help anyone in the face
> of management pressure. What it means is that management will ask
> about the spec, we'll say "we can't satisfy it because of _this
> point_", and they'll say, "ok, so ignore the whole spec". The user is
> then offered a browser which isn't compliant with this specification.
> How does that help the user?
>
> > User agents MUST inform the user and request consent when the user
> agent is attempting to install software outside of the agent environment
> as a result of web content. The interaction used MUST follow the
> requirements in 6.4.2 Warning/Caution Messages .
>
> You have a random space before your period.
>
> Again, your requirements here while noble are likely to result in us
> ignoring you. We already have complaints about how invasive our
> downloading/saving/opening story is (I believe I can find bug
> references for this too).
>
> > Web user agents MUST NOT permit Web content to add URIs to the user's
> bookmark collection that do not match the URI of the page that the user
> currently interacts with.
>
> This is annoying. If I use http://delicious.com/ or Google to save my
> bookmarks as a set, why shouldn't I allow them to provide a way to add
> pages I'm not currently at? Obviously I'd have to design it so that
> the user can review the content in some safe manner, but....
>
> A competitor (Firefox for Mobile) offers an API, "Weave", which allows
> a web server (weave) to add URIs to the user's bookmark collection. We
> have already received customer requests demanding this feature. In
> reality, Weave doesn't quite act as web content, however, I don't
> think users care about the distinction.
>
> 7.4.4 Pop-up Window APIs
>
> > This can be employed in interaction flooding attacks.
>
> Google for "interaction flooding attacks" shows only 8 hits, most of
> which relating to your document. I'd request that you consider using
> industry terminology instead of inventing grammatically poor terms of
> your own.
>
> > 5.4.1 TLS errors leads
>
> lead
>
> > to an additional
>
> drop 'an'
>
> > the user's flow of interaction,
>
> "flow of interaction" is oddly enough an extant expression, however
> none of the Google top 10 hits seem to be contextual matches. I'd
> suggest you avoid it.
>
> > behaviour
>
> this is en-GB which is inconsistent with favorably en-US earlier.
>
> > require user agents to treat
>
> drop "to"
Working Group Resolution (LC-2381):
> You use "dialogue" and "dialog" inconsistently, I'd suggest/request
> that you only use one.
Done; the latter.
> "web content accessed" is awkward, "accessed web content" sounds better
to me.
Done.
> i think you need 'both' or 'interfaces'
used 'both'
> 'via' here seems odd, i think 'by' is more appropriate.
done
> > by enforcing the constraints expressed in the associated data.
>
> i think either "in their" or "by their"
changing to:
by enforcing the constraints expressed in the associated certificate data
> "trust anchor updates" or "updating trust anchors"
used the latter.
> an agent's
done
> "trust roots" is used 3 times but not defined. I think you should use
> some other defined term.
It's used as a natural language phrase; it's the root in a trust chain; a
chain of certificates leading back to a root that is a trusted certificate.
"trust root" also seems to have plenty of hits on the web.
> "interactively accepted" (this is a defined term)
done.
> the lack of punctuation between documented and practices troubles me.
My Strunk and White says:
In a series of three or more terms with a single conjunction, use a comma
after each term except the last.
The sentence has two terms (with three words).
> i think you want 'which' instead of 'that'
Strunk and White agrees. done.
> 'augmented assurance' is not a defined term, and in this context it's
> missing an indication of what it's assuring.
changed "that" to "These". The "documented broadly accepted practice" in
the first sentence is what they assure.
> > an augmented assurance specification supported by the user agent.
>
> I don't understand this. I think you're trying to say that it
> satisfies some EV specification, but for some reason it doesn't read
> well.
Satisfying an EV spec is one way (and the one way currently implemented by
the participating user agents) of doing that, so even with the difficult
reading it does seem to be getting the point across.
> > The certificate chain for such a certificate MUST be validated up
> to a trust root that is recognized as augmented assurance qualified
> by the user agent.]
>
> What happens If it fails to validate up to such a trust root? This
> really should have been incorporated into your defining sentence --
> not added as a secondary sentence that's just included in your
> brackets.
Then it's not considered an augmented assurance certificate. It's a two
sentence definition encased in []'s. We've made it two sentences instead of
one to try to increase clarity.
> > This specification does not define what an "augmented assurance
> qualified trust root" is,
>
> that's true, but it doesn't use that quoted phrase anywhere else at
> all, which means it's a useless statement. Your document should be
> self consistent and is not.
We have a number of sentences that do talk about "augmented assurance
qualified" "trust roots" (sometimes in that order and sometimes with that
order switched). And the quoted phrase is used elsewhere (just not with
quotes).
> > except to note that this designation is made by user agents
> through an out of band mechanism consistent with the relevant
> underlying augmented assurance specification.
>
> As written you're requiring that there be precisely one such
> specification ('the...specification'). That seems problematic as it
> essentially endorses EV as the one and only.
The word "relevant" is in the phrase for just that reason; to allow for
multiples in the universe, but one being used. So we are not endorsing one
and only one specification.
> "different interaction" is odd, i'd suggest "unrelated interaction"
done
> > In both situations, use of TLS provides confidentiality protection
> services against passive attackers.
>
> This is an objectionable overstatement. "In both situations, TLS is
> used in an attempt to provide confidentiality protection services
> against passive attackers."
The phrasing is not particularly absolutist. TLS does provide (some)
confidentiality protection services.
> Unless of course the attacker has taken over the remote server. Please
> qualify the attacker as not having attained local access/control on
> the machine.
The phrase "strong evidence" allows for situations where the evidence is
not absolute. Attempts to enumerate those cases will always fall short. A
partial list is likely to imply things about what's included or not
included that we do not intend.
> "symptom" is a really odd word, "or it can merely indicate"
changed.
> If the user adds content, this isn't content that was retrieved via
> TLS and it does affect the page's content....
> This would also apply to HTML5 storage concepts.
Have clarified with an addition to the Overview:
"In interactive Web applications, the presentation to the user might also
depend on state that is local to the client - be it local storage of
structured data, or be it recent interactions with the Web page. The
security properties of those data will depend on the security properties of
the client computer itself, and are out of scope for this specification."
> I'd suggest avoiding colloquialisms such as "at hand".
done
> ending a sentence with a preposition should be considered poor form
> for a technical document.
preposition dropped.
> > certificates... are... revoked,... Danger Messages... MUST be used.
> > certificates... are... expired,... Danger Messages... MUST be used.
>
> While I would generally agree, I think that this policy results in
> more harm than good. I know my employer can't get this right, and for
> Mozilla, I worked very hard to improve the latter without promoting it
> to be a DANGER message. Often the cause with our product is user error
> (incorrectly configured system clock).
The revocation is not a system clock sort of thing.
We've discussed the expiration message extensively, and the wg believes
the policy results in more good than harm. As do the implementers in the
three draft implementation reports.
> > User agents with a visual user interface MUST show the Identity
> Signal in a consistent visual position. Web Content MUST NOT obscure
> security user interface, 7.4.1 Obscuring or disabling Security User
> Interfaces.
>
> Does not showing it at all satisfy this requirement?
Not showing it at does not satisfy the requirement to show it in a
consistent visual position.
> > During... The identity signal MUST include human-readable information
>
> This seems to indicate that a simple lock icon (or any other form of
> pure iconography) is insufficient. In some browsers with space
> constraints, it's likely that all you'd see is a favicon with a
> special background color. Additional information is available in
> secondary ui, but I believe "identity signal" was used to mean
> primary.
If the user agent supports some form of AA, then it must do that. A
complying user agent can not support any form of AA at all as an
alternative.
> > an validated
>
> 'a'
changed.
> > If the identity signal does not include ... information ... then
> it MUST include an applicable DNS name
>
> Otherwise?
Otherwise the user agent does not conform.
> > User agents MAY shorten such a DNS name by displaying only a suffix.
>
> So I can shorten
>
thisiswaytoolongtofitonanyreasonablecomputerscreenbecauseiintentionallywroteitjustlikethat.co.uk
> to "co.uk"? great, thanks.
Yes. That's why it's a MAY. While at least one implementation (Mozilla) is
actually maintaining a list of "public" suffixes, the right level of
truncation really depends on specifics of that suffix's administration. The
MAY is our way of dealing with that lack of a useful reference.
> What does "does not apply" mean?
We're restating that these requirements that apply to validated
certificates do not apply to self-signed certificates or certificate chains
that chain up to an untrusted root certificate.
> exceeding? perhaps "beyond"? those => that which is
yes, changed.
> Given how rare logotype support is, I don't think it's particularly
> appropriate to regulate its use. Let the market play out. So far, it
> played out by killing them.
The logotype items in the specification are consistent with both best
practice and with lack of support, must like the AA items.
> > Web user agents provide additional security context information as
> described in this section.
>
> Odd statement. Web user agents provide additional security context
> information as they please. If you want to make a request with a
> SHOULD or MAY, then do so, but don't write a declaration of fact that
> oversteps your bounds.
Changed to:
Additional security context provided by some web user agents is described
in this section.
> Useragents can't tell a user if he's used another agent or another
> device to visit a site. Please don't ask them to do the impossible.
We're not. And the draft implementation reports indicate that Chrome and
Firefox do it. We considered the addition of "with this user agent", but
that is arguably redundant.
> this isn't really a sentence.
added "see" before the reference.
> the term 'art' here is odd and unhelpful.
The sentence after that one provides additional helpfulness.
> I'd suggest "tell" instead of "refer".
done.
> > user agents SHOULD enable the user to easily return to the user
> agent state prior to initiation of the last user interaction that
> led to the error signal.
>
> If a web page involves submitting a form (POST) to a broken site, or
> if the previous page the user was on is the result of a POST, then
> trying to let the user return to the previous state is hard, risky,
> dangerous, or perhaps simply impossible. SHOULD is perhaps too strong
> given this. It's also possible that the last "user" action happened
> long before the web page randomly contorted itself and then redirected
> to the broke site, in which case "returning" to the state where the
> user last interacted is impossible (javascript doesn't support
> rollblack...).
We've clarified as follows:
They SHOULD NOT tell the user to enter the destination site that caused
the error, e.g., to provide feedback or obtain assistance. For error
messages that interrupt the user's flow of interaction, user agents SHOULD
enable the user to easily return to the page that the user was previously
interacting with. Note that this ideally implies returning to the previous
user agent state -- including the results of user input and dynamic
processing --; however, this may not be feasible under all circumstances.
> Please don't repeat yourself.
fixed
> this is odd the "condition"-"interaction" is "you clicked on a link to
> a bad server", do you want a detailed explanation for the user showing
> exactly how they managed to click on a link to a bad server? I
> wouldn't call an error state an "interaction" -- it seems like you
> did here.
Changed "the interaction" to "the error interaction".
> "characterized" is strange....
changed to "discussed"
> there's a second "must" in this sentence which is not in RFC form.
> There's also a huge risk of desensitizing the user if this is done
> wrong. There is already evidence that users ignore these messages and
> blame browsers for interrupting their task.
changed second "must" to "has to"
Warning fatigue is discussed in 8.5.
> this sounds wrong grammatically
changed to "distinct options for how to proceed"
> I find the plural "meanings" awkward, perhaps you can avoid using the
> plural form?
We didn't come up with a suitable change.
> This is odd, if a site's certificate expired yesterday, how is that a
> positively identified danger?
We did discuss this in some detail in the wg at various points. Expiration
indicates that the certificate is invalid for any of a number of reasons,
and are much like revoked certificates in intention and management. See:
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0130.html
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0131.html
> Asking MicroB to add extra chrome makes it harder for it to compete
> with Firefox for Mobile which has 0 visible chrome while browsing. It
> would essentially force us to change to a system where our chrome DOES
> NOT constitute a PRIMARY USER INTERFACE and is instead some strange
> "SECONDARY INTERFACE".
The spec would potentially apply to both. It might make sense for a
category of user agents to target the basic conformance but not the
advanced conformance (or only a subset of the advanced conformance).
> If an iframe contains a link to a site with an expired certificate and
> the user clicks the link, do you want the user agent to destroy the
> outer browsing context just to show the security indicator alone? This
> does not seem ideal
We've clarified as follows:
Web User Agents MUST NOT communicate +positive+ trust information using
user interface elements which can be mimicked within chrome under the
control of web content.
> MicroB supports full screen flash, in such a mode, the flash content
> can mimic all user interface elements, and demanding that full screen
> flash not work is a violation of our ability to deliver Flash. There's
> a distinction in that if the user wants security information there are
> certain keys the user can press which ensures trusted content, similar
> to the use of CONTROL-ALT-DELETE on Windows.
This falls under the "only presenting page content" mode that is
explicitly called out elsewhere.
> the word 'interactions' here is unfortunate, can you try to use some
> other words or phrases? In this case, merely dropping "interactions
> caused by" would probably be the best course of action.
done.
> Showing a modal dialog doesn't necessarily mean showing it to the
> user. If I have two windows and the user is browsing in one, and the
> other redirects to a page which triggers a window modal dialog, which
> the user does not see, then i have shown a modal security dialog for a
> web page that does not have focus, but as long as the dialog does not
> get focus, because it is merely window modal and not application
> modal, it might not be a problem.
>
> Please be careful not to overstep, and don't rely on SHOULD to protect
> you from overstepping.
The term "modal dialog" is used in this spec, and widely in the area, as
blocking the entire application. If the modality is tied to just one web
page, then the clause in the specification isn't applicable.
> This doesn't read as a sentence. Perhaps "keeping"
added "section" to clarify that it's a reference.
> Typically does. For MicroB it does not, because of the way the ui
> actually works.
Full screen mode initiated by the user is allowed by the spec.
> This is a good requirement, sadly we have a management requirement to
> the contrary, and while I personally hate it, they've overruled me,
> and I don't think that your requirement will help anyone in the face
> of management pressure. What it means is that management will ask
> about the spec, we'll say "we can't satisfy it because of _this
> point_", and they'll say, "ok, so ignore the whole spec". The user is
> then offered a browser which isn't compliant with this specification.
> How does that help the user?
It turns out to be very hard in this area to hit the right level of
protection and realism. As you yourself have pointed out elsewhere.
> You have a random space before your period.
thanks. It's an artifact of XML processing, which is difficult to remove
now, but will be addressed in the final spec.
> This is annoying. If I use http://delicious.com/or Google to save my
> bookmarks as a set, why shouldn't I allow them to provide a way to add
> pages I'm not currently at? Obviously I'd have to design it so that
> the user can review the content in some safe manner, but....
It's generally difficult to get users to review things in a safe manner,
and there doesn't seem to be any pattern to base such solutions on that has
worked effectively. For the threat, see
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0197.html
> Google for "interaction flooding attacks" shows only 8 hits, most of
> which relating to your document. I'd request that you consider using
> industry terminology instead of inventing grammatically poor terms of
> your own.
We have nothing better to suggest.
> lead
added "Section" to clarify.
> drop 'an'
done
> "flow of interaction" is oddly enough an extant expression, however
> none of the Google top 10 hits seem to be contextual matches. I'd
> suggest you avoid it.
We were unable to come up with a suitable alternative.
> this is en-GB which is inconsistent with favorably en-US earlier.
done
> drop "to"
>
done (and inserted "that" before "user")
----
Received on Friday, 23 April 2010 12:32:03 UTC