LC-2381
timeless <timeless@gmail.com> (archived comment) |
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"
|
> 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") |
tocheck |
|---|