- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 21 Nov 2007 17:12:13 +0100
- To: public-wsc-wg@w3.org
Minutes from our meeting on 2007-11-05 were approved and are
available online here:
http://www.w3.org/2007/11/05-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Face-to-Face
5 Nov 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
Hal Lockhart, Rachna Dhamija, Luis Barriga, Maritza Johnson,
Johnathan Nightingale, Bruno von Niman, Ian Fette, Tyler Close,
Mary Ellen Zurko, Bill Doyle, Yngve Pettersen, Phillip
Hallam-Baker, Thomas Roessler
Protocols and Formats Working Group members (present for
[4]accessibility discussion)
Janina Sajka, Kenny Johar
Observers
Amit Parashar, Bede McCall, Dave Raggett
Chair
MEZ
Scribe
Rachna, tlr, ifette, hal
Contents
* [5]Topics
1. [6]agenda bashing
2. [7]success criteria review
3. [8]ISSUE-130 - Trust Anchor Consistency Across Devices?
4. [9]Accessibility discussion
5. [10]ISSUE-115 - Mixing of security information and content in
non-visual environments?
6. [11]ISSUE-39 - cooperate with WAI-ARIA 'politeness' (from
public comments)
7. [12]ISSUE-41 - limited guidance on presentation OK (public
comment)
8. [13]ISSUE-59 - challenge and recover are essential; one
presentation fits all -NOT (pubic comment)
9. [14]ISSUE-109 - Should there be recommendations against
favicons?
10. [15]ISSUE-116 - Should users be able to reconfigure primary
chrome?
11. [16]ISSUE-120 - Audio "logotypes"
12. [17]ISSUE-125 - Safe Form Bar: on screen masking phrased in
terms of visual user agents
13. [18]ISSUE-126 - Define "picture-in-picture attack"
14. [19]identity signal
* [20]Summary of Action Items
__________________________________________________________________
agenda bashing
Mez: it has been a year, refer back to goals
... rest of agenda will be discussion of Issues (if time we'll get to
new ones) ...
... lunch with accessibility group - we should figure out which issues
are about accesibility ...
<Mez>
[21]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0204.html
<johnath> audio's cutting in and out - could easily be my side of
things though
<johnath> (we're swapping internet providers)
... after lunch, crossover sessions with other group ...
... WAF will talk about access control draft ...
... We can be observers of that WAF session ...
<johnath> audio just got better here - maybe Mez was just too far from
the mic before, and it was cutting out?
... read access control document before participating ...
... Tues is another overlapping session, 8:30-10 XML security working
group ...
... will talk about canonicalization issues ...
... we can up with a general topic to discuss while Hal, PHB and tlr
are in XML security session ...
... if you want to visit another WG, ask Mez ...
... We expect to get a late start at 10:30 ...
... 10: 30 tomorrow we will discuss next f2f ...
... Tues 3:30 another crossover session with TAG ...
Success Criteria Review
<tlr> [22]http://www.w3.org/2007/11/07-TechPlenAgenda.html
Mez: summarizing foundational criteria for success...
... one criteria is that we generate a W3C recommendation ...
... 2) uptake by browsers, site developers and app developers ...
Yngve: it is only possible to measure the browser uptake
Ian: how long will be around after the rec?
Mez: if true success can't be measured while we are around, fine
Hal: chances are that we won't be able to measure any of these in our
lifetime
Mez: expect that we can see some uptake in Browsers e.g. SSL warnings,
identity stuff
... criteria 3- capture current best practice which is "old skool"
standards ...
... criteria 4- a recommendation is demonstrably better at aiding trust
decisions than it was at the start of the WG ...
phil: would also add reduce the collatoral damage added by security
Mez: disagrees with Phil, can we take that out and still be a success
Phil: end users act on things that are pain points and incompatibility
is a pain point
Ifette: think it is important to know what we put out is adopted
... buyin and uptake are both important
<Zakim> ifette, you wanted to #2 bash
Hal: If we don't have buy in it is serious
Ifette: want to know if we have problems before we make a rec
yngve: it might be possible to measure uptake by automatic testing, but
probably not well (e.g., a spider might be able to quantify uptake)
mez: not saying we need to quantify uptake, but it is possible to
measure it
yngve: some parts of spec might be measureable (e.g. mixing of secure
and insecure parts)
mez: showing T.V Raman remarks "What makes Standards Succeed?"
from slides "successful standards say what you can do while staying
silent on what you can't"
mez: both security and usability are better at saying what does not
work, than what does
hal: seems like he is saying you need requirements but shouldn't use
them
... 40% of success factors of a group are outside the control of the
group
<Zakim> tlr, you wanted to talk about CR
phb: i've been in working groups that have a separate group that votes
recommendations in or out and votes ones out that don't meet a
requirement
tlr: would like to add one more angle
... some are when are we claiming succces, what criteria do we *need*
to go through, which we *want* to go through
... this discussion should lead to better idea of what we expect to put
in our CR and our call for implementation
... adoption criteria include e.g "we want to see this implemented in %
of market penetration" vs. "we want implemented by certain websites"
ifette: number 2 as written can't be in critical path
tlr: what variant of number 2 is on the critical path, up to WG what
the CR criteria
ifette: what something measure before we declare a rec to be final
... if we come up with a spec that is too onerous than would consider
it a failure
rachna: question about more specifics on 4
mez: rec inlcudes "musts"
<tlr> rachna: what's "better"?
<tlr> mez: at aiding trust decisions
mez: demonstrably means "there is a consensus on demonstrably"
... start means from when we started, set the bar low ...
hal: does this imply testing?
ifette: it could be better, but if people don't use it, it is not
better
rachna: agrees with ian that "in a way users will use or be pleased
with" is part of criteria
hal: does demonstrably include testing?
mez: would find testing compelling, but not the only compelling factor
rachna: anticipates that 4 will be difficult because there are
different interpretations of studies that exist
mez: that why it is important that working group buys into the set up
of the user testing
... asks phb "what does collateral damage mean?"
phb: when someone is building a web page that meets standards, can they
predict blah
... we have a lot of ad hoc solutions, point solutions that are
warnings
<Zakim> ifette, you wanted to ask phil
ifette: phb wants browser to identify warning dialogs to users.
... to be useful, would have to be retroactive, for a website to rely
on this would have to have the same thing for older browsers
phb: tell website developers what they need to know about browsers to
protect their users
... we want website developers to have a set of expectations, not just
a list of things to do
... an example of 2 is to tell web "use EV certificates"
... what I am talking about is talking to app developer community
... here's what you need to do to make your user safe, and ...
mez: straw poll, wants consensus on each point
ifette: if we achieve two of these is it sufficient?
mez: trying to define the set of what to include
... declares consensus on first one
luis: want to understand #2 in more detail, does this mean will be
available in commercial release
... what level of buy in?
ifette: buyin would include that browsers meet with us and say "we will
put it in"
hal: would we feel that this is a success? buyin would be a good
indicator that uptake will happen
... we might not be able to measure uptake, but buyin is evidence
... we won't be able to determine with accuracy, not so worried if we
can measure these in a year or not
<Mez> 2) There is buy in and uptake of the recommendation by browsers,
web application developers, and web site administrators
poll: do people agree with 2?
mez: declare consensus on 2
ifette: question about how to capture best practice
hal: is there going to be a doc or section that is labeled "current
best practice"
mez: ian thinks 3 is unnecessary
... thinks that capturing best practices is necessary, and part of what
standards bodies do
... if there is no place to put best practices, new people repeat old
mistakes
ifette: it should say "capture best practices that are relevant to our
recommendation"
<Mez> 3) Capture relevant current best practice
poll, do we agree that 3 is part of success criteria?
<Mez> agree
<ifette> abstain
<hal> yes
<PHB> agree
<yngve> agree
<tlr> yep
<bill-d> agree
<luis> yes to 3) best practices
abstain
<johnath> phone cut out there, but judging from irc I would support 3
as a criteria of success
<Mez> 4) The recommendation is demonstrably better at aiding trust
decisions than the state before the wg started
Poll on 4
<yngve> agree
<Mez> agree
agree
<luis> agree
<ifette> disagree
<hal> agree
<PHB> agree
<bill-d> agree
<ifette> The thing I disagree with is that we're demonstrably better at
aiding trust decisions, as opposed to creating an environment in which
users make better trust decisions
<tlr> agree, with the qualification is that I'd like to better
understand what "demonstrably" means
<ifette> If we create something that can help, but users don't use it
and/or don't want to use it, then I think we've failed
<tlr> ifette: would like to have a system that people want to use
<tlr> rachna: if the system isn't used, it's not "demonstrably" better
ifette: There might be things that are demonstrably better if people
are forced to use them.
... but they wouldn't take them if they had a choice ...
rachna: do we have a choice now?
ian: Google Toolbar vs PII bar?
rachna: this is bigger than just this. Does something cut out other
options?
yngve: if we have buy-in followed by uptake by browsers, app developers
and web sites, it will follow that it's demonstrably better
<rachna> yngve: if we have uptake, buyin, it will follow that is
demonstrably better
phb: I would also like to be more explicit and have less wiggle room
tlr: agrees. we can have experiment that shows something
... but experimental criteria might not match reality
<Mez> 4) There is concensus by the WG that the recommendation is
demonstrably better at aiding trust decisions than the state before the
wg started
mez: asks for alternative phrasing
<Mez> the recommendation demonstrably leads users to make better trust
decisions
phb: how about the "recommendation demonstrably leads users to make
better trust decisions"
... tweak so that it capture it is no use unless they accept it
phil: there is tech like smime, it is in email clients, deployed, but
users don't use it
phb: add 5th bullet "users use it"
rachna: add "uptake by users" to 2
<Mez> 04 012) There is buy in and uptake of the recommendation by
browsers, web application developers, web site administrators, and
users
<Mez> 04 014) There is consensus by the WG that the recommendation is
demonstrably better at aiding trust decisions than the state before the
wg started
ifette: not thrilled.
... still talking about things forced on users..
... buyin is not a good metric if users are forced to use it...
tlr: there is a user interaction that does not allow user options
... and there is a user interaction that forces user to jump through
hoops
... these are two different issues ...
... peole are dealing with beneficial and legitimate apps, but have to
go through another interaction....
... we can benignly force users to secure them that is not a nuiscance
ifette: even benign stuff that is not a road block can be annoying e.g.
if it takes screen real estate
<Mez> 2) There is buy in and uptake of the recommendation by browsers,
web application developers, web site administrators, and users
<Mez> 4) There is concensus by the WG that the recommendation is
demonstrably better at aiding trust decisions than the state before the
wg started
rachna: how to get buying from users?
ifette: one measurement is that they don't switch browsers
phb: or they don't turn it off
hal: the problem is that you are using buyin in the other three
categories in a different way
... more consistently would be a criteria like "influential trade press
articles encouraging it.."
... it is misleading to use buyin
<Mez> 2) There is buy in and uptake of the recommendation by browsers,
web application developers, web site administrators, and users
<PHB> agree
is there consensus on new 2 and 4?
<ifette> agree
<yngve> agree
<Mez> agree
<bill-d> agree
agree
<hal> agree
<tlr> agree
<ifette> (with the caveat that I like Hal's point about buy-in being a
wierd application of the verb in multiple different ways, but I haven't
seen a better wording)
<Mez> 4) There is concensus by the WG that the recommendation is
demonstrably better at aiding trust decisions than the state before the
wg started
<johnath> agree
<ifette> There is concensus by the WG that the recommendation is
demonstrably better at aiding users in making trust decisions than the
state before the WG started
<Mez> agree
<bill-d> agree
<ifette> half-heartedly agree
<hal> agree
<yngve> agree
<tlr> can live with
<luis> agree
agree, knowing that there will be much debate on what "demonstrably"
means
<PHB> agrrreee
tlr: where do we put this?
<tlr> ACTION: mzurko to drop success criteria into wiki [recorded in
[23]http://www.w3.org/2007/11/05-wsc-minutes.html#action01]
<trackbot-ng> Sorry, couldn't find user - mzurko
<tlr> ACTION: mez to drop success criteria into wiki [recorded in
[24]http://www.w3.org/2007/11/05-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-324 - Drop success criteria into wiki [on
Mary Ellen Zurko - due 2007-11-12].
<tlr> it's 10:27
<tlr> [25]http://www.w3.org/2006/WSC/track/issues/open
<luis> Next item: [26]http://www.w3.org/2006/WSC/track/issues/130
<luis> Summary is in:
[27]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0228.html
<luis> Johnathan proposed a recommendation I support. See the end of
his email:
<luis>
[28]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0001.html
<johnath> Which Luis then tweaked
<luis> Ian has objections:
[29]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0004.html
<johnath> I think ifette echoed most of my objections to the original
proposal language, and added the point that he considers it unlikely
that site authors will read our document
<johnath> If we think he's right, then I agree that we shouldn't make
recommendations that target them excusively (sorry I'm not on the call,
lots going on around here atm)
<luis> ... we haven't started yet Johnath .. hold a moment ... i was
just preparing
<johnath> luis: :) K
<johnath> Figured I'd get my thoughts out while waiting for this thing
to compile. :)
mez: first issue 130.
ISSUE-130 - Trust Anchor Consistency Across Devices?
luis: posted improvements to the proposal in Nov
<Mez>
[30]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0002.html
<luis> My "tweaked" version:
[31]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0002.html
luis: it keeps the essence, but adds clarifications
mez: reads new language
ian: we shouldn't do anything on this because browser manufactures are
responsible and users don't care
... what can we say that is meaningful?
luis: we dropped common set of trust anchors
ian: my point stands for web owners.
... for anything to matter, website owners must read this doc...
billd: are website owners included in our scope?
mez: administrators might include website owners
tlr: like the luis is pointing out that there is a problem
<Mez> link to our charter, fyi
[32]http://www.w3.org/2005/Security/wsc-charter
tlr: particularly for mobile devices....
... strikes me as intro material to a chapter ...
... am supportive of what is said there ...
... where is mobile on the rec trac? ...
<tlr> [33]http://www.w3.org/2005/MWI/BPWG/
tlr: it might be useful to talk to them about what belongs in their vs.
our rec
mez: do we have overlapping membership?
tlr: bruno
luis: one argument is that web admins won't read this doc
... in that case, we shouldn't give any recs at all for web authoring.
is that in scope?
tlr: yes in scope.
luis: so that argument fails then
ian: don't understand utility of making recs to website owners
... big ones already follow it, and little ones won't read it
tlr: what is the damage? isn't there more damage in not capturing it?
ian: e.g. when we say "website owners should not use certs" could be
anti-competive
tlr: should point out that different classes of devices can use
different ones, it does not need to be harmonized
luis: steven mentioned this should be non-normative
... one prob is trust anchors ...
... another is that for example yahoo uses TLS, but mobile site does
not.
mez: do we have a place where we grapple with using TLS to protect
anything, or is that in TAG area
tlr: you are thinking of chapter 9
<tlr> [34]http://www.w3.org/TR/wsc-xit/#authoringAndDeployment
<tlr> [35]http://www.w3.org/TR/wsc-xit/#tls-login-pages
mez: how does this language exclude mobile case?
luis: talking about consistency of mobile and web TLS for same service
mez: are those blank conformance sections going to include diff
experiences, e.g. web, mobile, screen scraped?
tlr: yes. however.
... we mix different conformance classes for different types of devices
mez: wants draft text in those sections to help us understand
yngve: 9.2 says login should be TLS protected.
... maybe should say "strongly TLS protected" because requires cert
mez: website might claim conformance because web version is compliant
and mobile is not compliant
... luis wants to exclude that possibility...
ian: so mobile page is not compliant
luis: *both* have to be consistent across devices or it is not
conformant
... one can't conform with out both conforming
bill: is it devices only or also application interfaces- do all need to
be consistent so that all are HTTPs protected?
mez: if you are using the same password, the exposed variant eliminates
the protection of the unexpected variant
tlr: there is a problem if we adopt yngve version of "strongly
protected" because don't know who user will trust
... site must pick a CA, but there is no universal understanding of
trust roots ...
... doesn't say "strong" now, but agree that sites should pick CAs that
are trusted broadly
... add language "if you are developing for broad classes of devices
..."
yngve: should use "user agent" instead of device
... suggest "if website is intended for multiple user agents, security
should be equivalent across multiple user agents"
luis: use device instead of user agent because device manufacturer of
phones decided which trust anchors will be used
yngve: could expand wording to include mobile phones as examples
bill: what is the reason why?
luis: they may believe network is protected
mez: yngve has normative statement
<yngve> Suggestion for addition: If a website is intended for use
across multiple user agents, the security experience MUST be equivalent
across these user agent.
ifette: this is still open to interpretation, because we don't know if
it is the same website, it is same presence, but not website
yngve: proposes "web service"
hal: too much confusion already between web server and web service
yngve: maybe something like "aspects of a sensitive website"
<ifette> -1
tlr: problem is tie back into trust roots
... suggest change to yngve wording " the security experience must be
designed to be equivalent"
... and "must be tested across devices" ...
otherwise, we throw conformance language to mobile device manufacturers
ifette: worried about having test across devices, because forcing
develpment for mobile devices
<tlr> [36]http://www.w3.org/TR/mobile-bp/#test
ifette: should not suggest that people must develop sites that work on
phones
bill: "user agents" can be anything, not just normal browsers
yngve: what is definition of user agents?
<tlr> [37]http://www.w3.org/TR/wsc-xit/#def-UA
mez: likes the idea of leveraging what experts in wg are doing ...
... like that there is a statement about testing in Mobile best
practices doc
ian: not all sites are tested to be consistent across mobile devices
... if you are only expecting one type of device, with one browser, why
the need to test across all devices?
tlr: we might want to fight desirability of developing for one device
and one browser
... might address ian's concerns with "should" vs. "must"
mez: we have action to put in non-normative actions. do we need
anything else?
tlr: will concoct language.
luis: two problems: 1) trust anchor problem and 2) tls consistency
... think these are 2 sep probs. should we address both together?
mez: didn't we give up on trust anchor problem
tlr: yngve's suggested language captures both
luis: so we will capture both.
tlr: yes, but we are more circumspect in our approach
breaking for lunch
mez: we'll try to meet with accessibility folks during lunch
1-3pm meeting with WAF room re access control
Accessibility discussion
<Mez> The WAI folks will be joining us this afternoon; I'm going to
look over the Issues list for accessibility related issues
<Mez> [38]http://www.w3.org/2006/WSC/track/issues/115, which we did in
part over lunch
<Mez> [39]http://www.w3.org/2006/WSC/track/issues/39
<Mez> [40]http://www.w3.org/2006/WSC/track/issues/41
<Mez> [41]http://www.w3.org/2006/WSC/track/issues/59
<Mez> [42]http://www.w3.org/2006/WSC/track/issues/109
<Mez> [43]http://www.w3.org/2006/WSC/track/issues/116
<Mez> [44]http://www.w3.org/2006/WSC/track/issues/120
<Mez> [45]http://www.w3.org/2006/WSC/track/issues/125
<Mez> [46]http://www.w3.org/2006/WSC/track/issues/126
mez: two guests
... from a11y
mez introduces herself
mez: Has listed open issues that are a11y related
... more than she thought we would have, URLs have been pasted
... Starting with issue 115
ISSUE-115: Mixing of security information and content in non-visual
environments?
BillD: you put 116 in earlire
mez: no, 115
confusion erupts
<Mez> [47]http://www.w3.org/2006/WSC/track/issues/115
Mez: Currently have material on mixing of security context and content
in non-visual environments. What are the issues?
... How far did we get over lunch
Janina: Trying to remember what we covered
Mez: @tlr, when you generated issue, you were looking for guidelines?
Where are we looking for this to go
tlr: Part of question - currently having some language saying "For
visual interfaces, do X"
BillD: A lot of decisions based on chrome
tlr: right
... one of themes of [48]section 8, is the part of robustness, do not
mix content and security indicators
... rehashes section
... basic question: is there anything useful along these lines to say
about the kinds of things that assistive technologies expose?
... how can you establish way for user to discern what info comes from
UA vs content
mez: taking step back to simpler part of issue
... reads out loud 8.1.2
... is that requirement about parts intended to convey trust... does
that make sense in non-visual interfaces
Janina: Asks question about what is meant by area conveying security
context
Hal: Right
Janina: No problem, other than that a large part of a11y is whatever is
the most commonly used UI doesn't work for somebody, will have to be
represented differently for blind user differently between blind user +
asssitive technology, others will want to magnify an area of screen
reliably
... assistive technology can work with it so long as data is
programatically exposed
mez: hold that thought, phb on queue
phb: two issues
... same principle applies, separate content channel from secure
channel
... for voice browsers, can imagine male vs female voice etc
... star wars reference
... that works nicely. Interesting tweak in that often, a11y and voice
browsing go in parallel
... distinction in that one way, a11y will be easier
... easier to create a secure chrome channel in voice
... tailor cues to user
... different voices etc
mez: Associated with other issue @tlr brought up re personalizing
trusted channel
... do we need to dive moreon this?
tlr: one thing is that recognizing voices much be a much more
conspicuous trusted channel than recognizing screen patterns
... if james earl jones starts talking, and it starts talking with my
voice...
... better cue than pattern change
mez: ok... so... should we be going somewhere on the API or
programmability side that we're not going to yet?
... in terms of making info avail. in non-visual UAs
... are there problems?
... are there reasonable specs already?
... how to think about the issue
janina: At end of day, happier result if you can negotiate that with...
mez: whom?
... mr. Raggett group?
janina: ubiq. web, multi-modal, etc
daver: have to figure out who are the stake holders etc
janina: If you come up with a particular mapping, I don't think one
size fits all
... in anything
mez: Still trying to figure what foundation exists for doing this work
kenny: Web APIs are well through their course of development
... strong foundation
tlr: The window object?
kenny: Their work in general
mez: not familiar. what does that mean. WG? Spec?
janina: WAF group
tlr: Also webapi group
... most people here were at WAF
... charles chairs WebAPI
more confusion erupts
tlr: exposing prog. interface means two things
... programmatic interface to what? States, interactions, how you got
there, etc
... tls are an effect to create such an ontology
... shouldn't that be available to whatever interface is the right
place to have it
... writing and deciding that interface might best be done by UWA and
web api
... doubts that right people are on this group to write DOM APIs
... reluctance. Not right group...
... right group for ontology level, ontology of notion that we are
expressing our stuff in anyways ...
... not talking about formal ontology
mez: if it makes sense that this info should be made avail to UAs that
get that info through APIs, then how do we communicate to UAW and
WebAPI that that's an issue?
tlr: by... probably by way of hypertext cg
janina: Wont have hard time convincing people
mez: Looking to make others do more work
... action on me to get coord with hypertext
<scribe> ACTION: Mez to coordinate with hypertext CG re a11y issues
[recorded in
[49]http://www.w3.org/2007/11/05-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-325 - Coordinate with hypertext CG re a11y
issues [on Mary Ellen Zurko - due 2007-11-12].
janina: Idea is to get users to trust based on browser/client behavior,
have that trust with reasonable confidence appropriately placed
... seems to me that if we rely on different implementations, harder to
spoof
... than if there is a common look + feel across everyone's browser
mez: yes
... other thread in context of this issue was the trusted path part
... that @tlr brought up
... not in doc, right?
more confusion
somewhere in wiki
<Mez> [50]http://www.w3.org/2006/WSC/wiki/RobustSharedSecret
mez: MAY under good practice
... reads current draft
tlr: says "so" and then silent for a minute
more confusion re: action items
<tlr> ACTION: tlr to transfer RobustSharedSecret into section 8.2
[recorded in
[51]http://www.w3.org/2007/11/05-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-326 - Transfer RobustSharedSecret into
section 8.2 [on Thomas Roessler - due 2007-11-12].
mez: 115 like a dead cow
tlr: 115 at this point resolved by doing nothing?
mez: action to talk about stuff at HTCG
... yeah
... sup?
tlr: have this recurring theme
... there is a value to using different voices etc. is that something
that should go in as technique?
kenny: If available in dom, perhaps one of the browsers could translate
that as voices
tlr: Should this spec call out approach of voices?
agreement in room
mez: not much non-normative text
tlr: what?
mez: so where would you put that
more confusion
tlr: 8.1.3... 8.1.2 limits the ... confusion
... 8.1.2 currently in terms of visual user interfaces
mez: not the actual MUST NOT statement
tlr: says display
... aiming to make this part more generic? q2: are we aiming to add
techniques in audio space?
... other a11y technologies
... known attacks?
... flash applet capturing sound, etc
rachna: y/y/y
mez: y/n/y
... agree 8.1.2 not specific to visual
... second one
<tlr> ACTION: tlr to generalize 8.1.2 to be not specific to visual
interfaces [recorded in
[52]http://www.w3.org/2007/11/05-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-327 - Generalize 8.1.2 to be not specific
to visual interfaces [on Thomas Roessler - due 2007-11-12].
mez: want to see where we already have visual techniques to understand
... just re favicons
janina: visual techniques maliable for people w/ some disabilities.
background might not be good etc
mez: right now, mostly normative
... rather surprised that @tlr suggests we insert examples
janina: specify that I prefer secure context in voice X, or bold Y in
deep maroon BG, etc
... sits in registry somewhere
... script finds that
mez: nothing like that right now
... ex pii bar
tlr: normative re: techniques
... except 8.3 needs to be more contentful
... call out audio
mez: 8.3.2 re UAs shouldn't allow web content to do
janina: UAs should be relied on to not display any content in a way
that looks like user's content
mez: we say, don't allow someone to put up a little window here...
janina: can't prevent malware
mez: non-goal
... normal interaction is that when you go to a SSL page, you get a
note in a special voice?
janina: At this time, no voice change
mez: basically, could I put sth in my webpage?
janina: sure
... same text that reader says
mez: at the top of the content, just say "There is a padlock"
... said you got other stuff on transition. number of urls etc
janina: UA dependant
cacophony
mez: something like, "Make sure content cannot emulate exactly the same
phrasing in same place..."
janina: Think that's a good course
... time is precious
mez: wants to give AA to rob/bill
janina: Todays process is non-optimal.
ifette: self signed certs etc
tlr: Two things. Have HTTPS, use different voice
mez: usability, security, or both?
ifette: cant you spoof the voices?
janina: if I say "This is my voice for HTTPs, trust nobody else can use
that voice"
... earcons etc
... only gives you onset or termination
... value of voice is continuous
mez: what followups? 8.3.2 text?
... where follow-on conversations should go
... voice config / earcon is close to 8.2
... robust shared secret etc
digressions
janina: relying on UAs to honor spec
mez: a11y stated that typical user population does a lot of
configuration
janina: vendors will have deafult scheme?
kenny: build into a11y technology
mez: targeted to UAs, assistive technologies, or both
janina: same thing
mez: 2 followups, 8.2 and 8.3.2?
... and give to bill
... techniques for not obviously spoofable audio presentation
... and info about making sure that techniques for establishing trusted
path between UA and user are also auditory
kenny: stuff in webapi?
mez: no clue
keny: what could be built into DOM that could not be deduced from URL
mez: trying to get better about communicating identity
tlr: dont want to expose history in dom, private information
questions re: wether the dom is the appropriate way to expose info
<tlr> [53]http://www.w3.org/TR/Window/
yngve: dom cannot be trusted
kenny: if x509 cert exposed to dom, can query
DaveR: Can be exposed to screen reader, but not through DOM
yes...
cacophony
<tlr> PROPOSED ACTION: eburn to propose techniques for not obviously
spoofable audio presentation based on discussion above
<tlr> ACTION: eburn to propose techniques for not obviously spoofable
audio presentation based on discussion above suitable for 8.3.2
[recorded in
[54]http://www.w3.org/2007/11/05-wsc-minutes.html#action06]
<trackbot-ng> Created ACTION-328 - Propose techniques for not obviously
spoofable audio presentation based on discussion above suitable for
8.3.2 [on William Eburn - due 2007-11-12].
<tlr> ACTION: bruno to review 8.2 to ensure suitability of language in
non-visual contexts [recorded in
[55]http://www.w3.org/2007/11/05-wsc-minutes.html#action07]
<trackbot-ng> Created ACTION-329 - Review 8.2 to ensure suitability of
language in non-visual contexts [on Bruno von Niman - due 2007-11-12].
mez: 115 killed?
ISSUE-39 - cooperate with WAI-ARIA 'politeness' (from public comments)
<Mez> [56]http://www.w3.org/2006/WSC/track/issues/39
mez: Issue 39 next
... both read review of use case note?
janina: contributed to writeup, kenny has reviewed
... cooperate with quest for assured presentation
... verbosity control
... filter/buffer events
... reads text about event politeness
... user agent not content, does this still hold?
janina: may be r2, live regions, as in portions of a page being updated
on fly
... parts may be secure, parts may not
mez: not yet grappled specifically, but we need to, re iframe and
mashup type issues
... central question is what should we be doing with at live thing re
politeness
janina: in sequential UI, spech, failure of too many things talking at
once
... author may have suggested levels, user can say "Always interrupt me
etc"
... "only if I haven't done anything in this region"
mez: think this is only pertinent re conveying variable security
context?
janina: probably
mez: pessimism about understanding of segmented info, might move to
lowest common denominator
ISSUE-41 - limited guidance on presentation OK (public comment)
<Mez> [57]http://www.w3.org/2006/WSC/track/issues/41
mez: next issue is 41 also from Al
... limited guidance on presentation ok
mez: reads issue 41
... fails over to API.
janina: Want to know why you trust it. drill-down.
... parse it, structure it.
<Mez>
[58]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
mez: 6.2 page info summary
... still feels like it's the API conversation, different context
yngve: opera's current UI allows going through certs item by item
... usually info applies to page, not elements
<Mez> [59]http://www.w3.org/2006/WSC/track/issues/59
janina: sounds like more reasons for structured information
ISSUE-59 - challenge and recover are essential; one presentation fits all
-NOT (pubic comment)
mez: reviews issue
... all of our rec track text so far is abstract about what's in error
messages
... look at section 5
<Mez> [60]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tlsforweb
<Mez>
[61]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
tlr: need to look at [62]section 6.4
mez: here's an example
[63]section 6.4.2 three things
mez: I think we are not running into the problems Al was worried about
... we are avoiding specifics about UI
tlr: PII may have that problem
mez: explains intent of safe web form editor
tlr: [64]7.4 is an example
... the concern is that section is intended to be generic
... to distinguish btw content and stuff not under control of web
server
mez: is this something that we can only ask for review?
... issue 59 is turning out to be a non issue
ISSUE-109 - Should there be recommendations against favicons?
mez: did we already do this to death?
... skip this
ISSUE-116 - Should users be able to reconfigure primary chrome?
<Mez> [65]http://www.w3.org/2006/WSC/track/issues/116
mez: can we drop this?
ISSUE-120 - Audio "logotypes"
<Mez> [66]http://www.w3.org/2006/WSC/track/issues/120
mez: is there an accessability issue here?
tlr: yes, time is more precious resource than screen real estate
... need to be sure we are not playing long audio too frequently
ifette: not being used
yngve: CA's cant figure out how to vet
janina: music is not a problem, talk is
tlr: are there guidelines for length of audio?
???: not known
tlr: need 3 things
... optional
... limit length
... not spoken words
<trackbot-ng> Created ACTION-344 - Propose normative material on audio
logotypes; ISSUE-120 [on Thomas Roessler - due 2007-11-22].
ISSUE-125 - Safe Form Bar: on screen masking phrased in terms of visual user
agents
<Mez> [67]http://www.w3.org/2006/WSC/track/issues/125
<Mez>
[68]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-onscreen
mask
<tlr> attack scenario applies to voice as well
<tlr> phrase text more generically
<Mez> [69]http://www.w3.org/2006/WSC/track/issues/126
ISSUE-126 - Define "picture-in-picture attack"
mez: pic in pic fools people, is it possible to do the same sort of
thing in audio only?
janina: attack may not be worth trouble
tlr: propose we discuss identity signal
<Mez>
[70]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
identity signal
Identity signal might be difficult in non-visual UI
tlr: what would be non-visual equiv of warning message?
janina: want to be similar to visual UI
... if was a frequently accessed site might be annoying
tlr: would it be useful to have voice only at transition
janina: yes
<tlr> transitions important, static state less so. Different voices
could help
<tlr> different verbosity levels in typical screen readers
<tlr> advanced verbosity
<tlr> certain level of flexibility
<tlr> consistent data for the AT
Summary of Action Items
[NEW] ACTION: bruno to review 8.2 to ensure suitability of language in
non-visual contexts [recorded in
[71]http://www.w3.org/2007/11/05-wsc-minutes.html#action07]
[NEW] ACTION: eburn to propose techniques for not obviously spoofable
audio presentation based on discussion above suitable for 8.3.2
[recorded in
[72]http://www.w3.org/2007/11/05-wsc-minutes.html#action06]
[NEW] ACTION: Mez to coordinate with hypertext CG re a11y issues
[recorded in
[73]http://www.w3.org/2007/11/05-wsc-minutes.html#action03]
[NEW] ACTION: mez to drop success criteria into wiki [recorded in
[74]http://www.w3.org/2007/11/05-wsc-minutes.html#action02]
[NEW] ACTION: mzurko to drop success criteria into wiki [recorded in
[75]http://www.w3.org/2007/11/05-wsc-minutes.html#action01]
[NEW] ACTION: tlr to generalize 8.1.2 to be not specific to visual
interfaces [recorded in
[76]http://www.w3.org/2007/11/05-wsc-minutes.html#action05]
[NEW] ACTION: tlr to transfer RobustSharedSecret into section 8.2
[recorded in
[77]http://www.w3.org/2007/11/05-wsc-minutes.html#action04]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [78]scribe.perl version 1.128
([79]CVS log)
$Date: 2007/11/21 16:06:15 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0201.html
3. http://www.w3.org/2007/11/05-wsc-irc
4. http://www.w3.org/2007/11/05-wsc-minutes.html#Accessibil
5. http://www.w3.org/2007/11/05-wsc-minutes.html#agenda
6. http://www.w3.org/2007/11/05-wsc-minutes.html#item01
7. http://www.w3.org/2007/11/05-wsc-minutes.html#First
8. http://www.w3.org/2007/11/05-wsc-minutes.html#item02
9. http://www.w3.org/2007/11/05-wsc-minutes.html#Accessibil
10. http://www.w3.org/2007/11/05-wsc-minutes.html#ISSUE-115
11. http://www.w3.org/2007/11/05-wsc-minutes.html#ISSUE-39
12. http://www.w3.org/2007/11/05-wsc-minutes.html#item03
13. http://www.w3.org/2007/11/05-wsc-minutes.html#item04
14. http://www.w3.org/2007/11/05-wsc-minutes.html#item05
15. http://www.w3.org/2007/11/05-wsc-minutes.html#item06
16. http://www.w3.org/2007/11/05-wsc-minutes.html#item07
17. http://www.w3.org/2007/11/05-wsc-minutes.html#item08
18. http://www.w3.org/2007/11/05-wsc-minutes.html#item09
19. http://www.w3.org/2007/11/05-wsc-minutes.html#item10
20. http://www.w3.org/2007/11/05-wsc-minutes.html#ActionSummary
21. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0204.html
22. http://www.w3.org/2007/11/07-TechPlenAgenda.html
23. http://www.w3.org/2007/11/05-wsc-minutes.html#action01
24. http://www.w3.org/2007/11/05-wsc-minutes.html#action02
25. http://www.w3.org/2006/WSC/track/issues/open
26. http://www.w3.org/2006/WSC/track/issues/130
27. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0228.html
28. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0001.html
29. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0004.html
30. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0002.html
31. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0002.html
32. http://www.w3.org/2005/Security/wsc-charter
33. http://www.w3.org/2005/MWI/BPWG/
34. http://www.w3.org/TR/wsc-xit/#authoringAndDeployment
35. http://www.w3.org/TR/wsc-xit/#tls-login-pages
36. http://www.w3.org/TR/mobile-bp/#test
37. http://www.w3.org/TR/wsc-xit/#def-UA
38. http://www.w3.org/2006/WSC/track/issues/115
39. http://www.w3.org/2006/WSC/track/issues/39
40. http://www.w3.org/2006/WSC/track/issues/41
41. http://www.w3.org/2006/WSC/track/issues/59
42. http://www.w3.org/2006/WSC/track/issues/109
43. http://www.w3.org/2006/WSC/track/issues/116
44. http://www.w3.org/2006/WSC/track/issues/120
45. http://www.w3.org/2006/WSC/track/issues/125
46. http://www.w3.org/2006/WSC/track/issues/126
47. http://www.w3.org/2006/WSC/track/issues/115
48. http://www.w3.org/TR/2007/WD-wsc-xit-20071101/#Robustness
49. http://www.w3.org/2007/11/05-wsc-minutes.html#action03
50. http://www.w3.org/2006/WSC/wiki/RobustSharedSecret
51. http://www.w3.org/2007/11/05-wsc-minutes.html#action04
52. http://www.w3.org/2007/11/05-wsc-minutes.html#action05
53. http://www.w3.org/TR/Window/
54. http://www.w3.org/2007/11/05-wsc-minutes.html#action06
55. http://www.w3.org/2007/11/05-wsc-minutes.html#action07
56. http://www.w3.org/2006/WSC/track/issues/39
57. http://www.w3.org/2006/WSC/track/issues/41
58. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
59. http://www.w3.org/2006/WSC/track/issues/59
60. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tlsforweb
61. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
62. http://www.w3.org/TR/2007/WD-wsc-xit-20071101/#error-handling
63. http://www.w3.org/TR/2007/WD-wsc-xit-20071101/#errors-mitm
64. http://www.w3.org/TR/2007/WD-wsc-xit-20071101/#safebar-reliabletext
65. http://www.w3.org/2006/WSC/track/issues/116
66. http://www.w3.org/2006/WSC/track/issues/120
67. http://www.w3.org/2006/WSC/track/issues/125
68. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-onscreenmask
69. http://www.w3.org/2006/WSC/track/issues/126
70. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#IdentitySignal
71. http://www.w3.org/2007/11/05-wsc-minutes.html#action07
72. http://www.w3.org/2007/11/05-wsc-minutes.html#action06
73. http://www.w3.org/2007/11/05-wsc-minutes.html#action03
74. http://www.w3.org/2007/11/05-wsc-minutes.html#action02
75. http://www.w3.org/2007/11/05-wsc-minutes.html#action01
76. http://www.w3.org/2007/11/05-wsc-minutes.html#action05
77. http://www.w3.org/2007/11/05-wsc-minutes.html#action04
78. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
79. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 21 November 2007 16:12:37 UTC