- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 4 Jul 2008 09:36:46 +0200
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2008-06-25 were approved and are
available online here:
http://www.w3.org/2008/06/25-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
WSC WG weekly
25 Jun 2008
[2]Agenda
See also: [3]IRC log
Attendees
Present
PHB, MaryEllen_Zurko, joesteele, bill-d, dans, yngve, claudio,
ifette, anil, tyler, Mike_McCormick
Regrets
Johnathan_N, Maritza_J, Thomas_R, Jan_Vidar_K, Serge_E
Chair
Mez
Scribe
anil
Contents
* [4]Topics
* [5]Summary of Action Items
__________________________________________________________________
<Mez> gm joesteele
<Mez> gm bill-d
<joesteele> gm!
<bill-d> gm
<bill-d> and a fine day it is here in NJ
<Mez> it's pretty nice in MA
<Mez> we had a super hail storm yesterday
<bill-d> eek - damage?
<Mez> no, luckily pea size
<Mez> at least, none to us
<joesteele> it's pretty dismal here -- yellow smoky air -- can't go
outside much
<Mez> wow, what's up?
<joesteele> 800+ fire across CA today
<joesteele> fires
<Mez> wow!
<joesteele> and my whole family with asthma :-(
<Mez> gm tlr; you're not supposed to be here
<Mez> you're supposed to be chairing something somewhere
<tlr> I'm not attending the meeting
<tlr> (this was IRC autojoin; chairing anohter one)
<Mez> ScribeNick: anil
<Mez> [6]http://www.w3.org/2008/06/18-wsc-minutes.html
MEZ: minutes approved
<Mez>
[7]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jun/0088.html
Mez: weekly completed action items - Phil, Johnathan and tlr thanks
... open action items
<scribe> ... closed action items due to inactivity - none
MEZ: continue with conforming impl
... jvkrey could not make it
... next meeting is next week. If we get done with Opera, then we
continue with firefox.
... looking if anybody will be absent for July 2nd meeting
<Mez>
[8]http://www.w3.org/2006/WSC/wiki/Opera_9.50_Conformance_with_June_LC
Mez: checked previous minutes to see where we left off with opera and
see where the risks existed (2 conforming impl)
... section 6.3
... tls indicators
... 1st para. it has to SHOULD
<Mez> opera does not do:
<Mez> web user agents SHOULD indicate the interaction was not TLS
protected.
yngve: The TLS indicator MUST present a distinct state that is used
only for TLS-secured Web pages.
... we do show a padlock in yellow. if there is a problem, we show a
different indicator unless there is a danger
... The user agent MAY accomplish this by using a third state in the
TLS indicator, or via another mechanism (such as a dialog, infobar, or
other means).
... we DO
Mez: so u indicate users if they access content thru weak tls?
yngve: yes we do. Unless when we have a certificate problem, we throw a
dialog
Mez: that is end of 6.3
yngve: 6.4?
...
6.4.1 Common Error Interaction Requirements
scribe: Error signalling that occurs as part of primary chrome SHOULD
be phrased in terms of threat to user's interests, not technical
occurrence.
... we do that
... "Primary chrome error messages MUST NOT be phrased solely in terms
of art, e.g., jargon. They SHOULD NOT refer 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
user agent state prior to initiation of the last us
... we do not phrase error messages solely on art. we allow them to
return to previous state.
... typo - For advanced users......
... "For advanced users, error interactions SHOULD have an option for
advanced users to request a detailed description of the condition that
caused the interaction to occur."
... exists a typo
Mez: 6.4.2
yngve: "Notifications and status indicators are used when the browser
cannot accurately determine a security risk based on the current
security context information available. These indicators SHOULD also be
used for situations in which the risk level may vary based on user
preference."
claudio: If user preferences change, the notification indicator will
display the change.
... example, risk level may vary on user preferences. Script got from
http site, will lower the rating from the https site. If the user pref
has "execute no scripts", then there will be no scripts coming from
http connection
yngve: " For visual user agents, notifications and status indicators
MUST be displayed in the user agent's persistent primary chrome. These
indicators MAY include user interaction (e.g., forcing the user to
click a button to continue the primary task). They MUST include a
succinct textual description of their meaning."
... we do
... we do not do notification. the security status bar is the
indicator.
<Mez> opera does not : These indicators MAY include user interaction
(e.g., forcing the user to click a button to continue the primary task)
yngve: status indicator in the primary chrome. But does not have the
description that may be available in the secondary chrome
... clicking on padlock etc, u will get more information
Mez: 6.4.3
yngve: "Warning / Caution messages MUST be used when the system has
good reason to believe that the user may be at risk based on the
current security context information, but a determination cannot
positively be made. These warnings SHOULD be used if the likelihood of
danger is present, but cannot be confirmed."
... we have warning/caution messages displayed in primary chrome as
dialog.
... that takes care of next one also ""Warning / Caution messages MUST
interrupt the user's current task, such that the user must acknowledge
the message.
Mez: we are doing exercise - how opera conforms to the spec text rather
than discuss. Issues etc go to email list
yngve: "For user agents with a visual user interface, headings of these
warnings MUST include words meaning "caution" or "warning". The
headings of these warnings MUST be the locus of attention."
<Mez> Opera does : Warning / Caution messages MUST provide the user
with distinct options how to proceed
yngve: we DO in opera
Mez: u provide users with distinct options to proceed?
yngve: yes.
Mez: u have one recommended option
yngve: the recommended option is to cancel or not proceed
<Mez> Opera does: hese warnings SHOULD include one recommended option,
and a succinct text component denoting which option is recommended.
Mez: 6.4..4
yngve: "Danger Messages MUST be used when there is a positively
identified danger to the user (i.e., not merely a risk)."
... we do and users cannot go past the current one
claudio: there is it for third party referring to phishing/malware
protection. It may have an effect on user browsing to wait until 3rd
party response
... when 3rdparty response comes, the user will be asked to interact
Mez: 6.5
yngve: " If a Web User Agent permits the user to administratively
reconfigure the primary user interface in such a way as to suppress any
of the displays required by this specification, then it MUST provide a
simple administrative mechanism, such as a single button in a
configuration menu, to reset the display to be in conformance with this
specification."
... we do
Mez: 7.1.1
yngve: "A trusted path can be established between a web user agent and
the user through the use of a secret shared between the user and the
agent. The shared secret may be an image selected by the user, or can
be another type of secret (e.g., text or audio) to meet accessibility
requirements. If the shared secret is difficult to guess, it is
difficult to exactly emulate, so robust against that aspe
... we do not do it. But there are ways to do it.
claudio: there are parts of UI that can be configured
yngve: some like it in the community. some hate it.
Mez: 7.1.2
claudio: "For visual user agents, browser chrome SHOULD always be
present to signal security context information. This requirement does
not apply when UI is explicitly dismissed by the user."
<Mez> [9]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Conformance
Mez: if opera would be comply at basic level, if u do not honor the
SHOULD
claudio: we do conform to the default setup. we cannot do anything when
users configure something and we have no control with that.
Mez: if an extension developer breaks any MUST, then they have broken
the entire conformance
claudio: "This requirement is scoped to a specific interaction: When
multiple Web pages might be displayed, security critical chrome MAY be
not present for those with which the user is not currently interacting.
However, chrome used to communicate security context information that
relates to the currently interacted Web page MUST always remain on the
screen."
... same as previous point. Depends on user configuration. Default
setup conforms.
... a security chrome is tied to a page.
<Mez> in tiled or cascaded mode, opera does not do : When multiple Web
pages might be displayed, security critical chrome MAY be not present
for those with which the user is not currently interacting.
<Mez> in the default setup, then they do: When multiple Web pages might
be displayed, security critical chrome MAY be not present for those
with which the user is not currently interacting.
Mez: 7.2
[10]http://www.w3.org/2006/WSC/drafts/rec/#sec-tls-indicator
<Mez>
[11]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#site-identifying
yngve: " In particular, Web User Agents SHOULD NOT use a 16x16 image in
chrome to indicate security status if doing so would allow the favorite
icon to mimic it."
<Mez> opera says comply with all 7.2 2119 lang
Mez: 7.4
yngve: "User agents commonly allow web content to perform certain
manipulations of agent UI and functionality such as opening new
windows, resizing existing windows, etc. to permit customization of the
user experience. These manipulations need to be constrained to prevent
malicious sites from concealing or obscuring important elements of the
browser interface, or deceiving the user into performing dangerous acts
... web content cannot do manipulations in opera.
<joesteele> can skins be applied directly from the web page?
s/¿interacaiton/interaction
<joesteele> claudio: requires user interaction
Mez: is the security UI always visible
claudio: yes it is
s/acts to/acts too
Mez: 7.4.2
claudio: opera conforms to 7.4.2
... "Web user agents MUST inform the user and request consent when web
content attempts to install software outside of the browser
environment. The interaction used MUST follow the requirements in 6.4.3
Warning/Caution Messages . Web user agents SHOULD NOT provide features
which can be used by web content to install software outside of the
browser environment without the user's consent. Web us
... we do that
... "Web user agents MAY inform the user when web content attempts to
execute software outside of the agent environment, and MAY also request
user consent, but SHOULD NOT do so unconditionally for all types of
content or software. If the agent chooses to do this then it SHOULD do
so for specific content types, software types, or security context
based on risk. "
... we conform
yngve: user must select the application from a dialog to handle the
type of data (such as PDF)
<Mez> opera does not ever choose to notify the user abuot any class of
content or application
Mez: 7.4.3
yngve: "Web user agents MUST NOT expose programmatic interfaces that
allow bookmarking without explicit user consent. That consent MUST
follow the requirements from 6.4.2 Notifications and Status Indicators
."
<Mez> we're at
[12]http://www.w3.org/2006/WSC/wiki/Opera_9.50_Conformance_with_June_LC
yngve: we do not allow bookmarking from content.
claudio: there is always a user interaction for bookmarking
yngve: 7.4.4
... "With visual user interfaces that use a windowed interaction
paradigm, Web user agents SHOULD restrict the opening of pop-up windows
from web content, particularly those not initiated by user action.
Creating excessive numbers of new popup windows is a technique that can
be used to condition users to rapidly dismissing dialogs. This can be
employed in interaction flooding attacks."
... we do have popups. the default mode has these popups
... "Web user agents which offer this restriction SHOULD offer a way to
extend permission to individual trusted sites. Failing to do so
encourages users who desire the functionality on certain sites to
disable the feature universally."
<MikeM> hi! thanks
yngve: we do allow configuration
Mez: thanks a lot. When we get to the testing part, we will check your
assertions. At least ahead of time, we will know the gaps.
... does opera have tests that exercise this?
claudio: we have several tests that cover most of the aspects
Mez: can u make the information about opera testing available to the
group?
claudio: we can check and tell u.
Mez: we are done with agenda.
... need to check with johnath whether he will be available next week.
<Mez> [13]http://www.w3.org/2006/WSC/Group/cheatsheet#Scribing
Summary of Action Items
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [14]scribe.perl version 1.133
([15]CVS log)
$Date: 2008/07/04 07:36:17 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jun/0089.html
3. http://www.w3.org/2008/06/25-wsc-irc
4. http://www.w3.org/2008/06/25-wsc-minutes.html#agenda
5. http://www.w3.org/2008/06/25-wsc-minutes.html#ActionSummary
6. http://www.w3.org/2008/06/18-wsc-minutes.html
7. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jun/0088.html
8. http://www.w3.org/2006/WSC/wiki/Opera_9.50_Conformance_with_June_LC
9. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Conformance
10. http://www.w3.org/2006/WSC/drafts/rec/#sec-tls-indicator
11. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#site-identifying
12. http://www.w3.org/2006/WSC/wiki/Opera_9.50_Conformance_with_June_LC
13. http://www.w3.org/2006/WSC/Group/cheatsheet#Scribing
14. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
15. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Friday, 4 July 2008 07:37:22 UTC