Fw: Transition announcement: Third LC of wsc-ui

We will have a meeting on Wednesday to go over this LC feedback. Prep work 
beforehand is appreciated. 

          Mez


----- Forwarded by Mary Ellen Zurko/Westford/IBM on 03/25/2010 03:17 PM 
-----

From:   timeless <timeless@gmail.com>
To:     public-usable-authentication@w3.org
Date:   03/24/2010 08:09 AM
Subject:        Re: Transition announcement: Third LC of wsc-ui
Sent by:        public-usable-authentication-request@w3.org



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"