Meeting record: WSC WG f2f 2007-11-05

Minutes from our meeting on 2007-11-05 were approved and are
available online here:

A text version is included below the .signature.

Thomas Roessler, W3C  <>


                Web Security Context Working Group Face-to-Face
                                   5 Nov 2007


   See also: [3]IRC log


          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

          Amit Parashar, Bede McCall, Dave Raggett


          Rachna, tlr, ifette, hal


     * [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
         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
        10. [15]ISSUE-116 - Should users be able to reconfigure primary
        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 ...


   <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]

   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

   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
   ... 40% of success factors of a group are outside the control of the

   <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

   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

   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

   <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

   ifette: it should say "capture best practices that are relevant to our

   <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


   <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


   <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

   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

   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

   <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
   ... 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


   <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"

   <PHB> agrrreee

   tlr: where do we put this?

   <tlr> ACTION: mzurko to drop success criteria into wiki [recorded in

   <trackbot-ng> Sorry, couldn't find user - mzurko

   <tlr> ACTION: mez to drop success criteria into wiki [recorded in

   <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]

   <luis> Next item: [26]

   <luis> Summary is in:

   <luis> Johnathan proposed a recommendation I support. See the end of
   his email:


   <johnath> Which Luis then tweaked

   <luis> Ian has objections:

   <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


   <luis> My "tweaked" version:

   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

   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]

   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

   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

   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]

   <tlr> [35]

   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
   ... 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]

   ifette: should not suggest that people must develop sites that work on

   bill: "user agents" can be anything, not just normal browsers

   yngve: what is definition of user agents?

   <tlr> [37]

   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], which we did in
   part over lunch

   <Mez> [39]

   <Mez> [40]

   <Mez> [41]

   <Mez> [42]

   <Mez> [43]

   <Mez> [44]

   <Mez> [45]

   <Mez> [46]

   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

   BillD: you put 116 in earlire

   mez: no, 115

   confusion erupts

   <Mez> [47]

   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

   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
   ... 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
   ... 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
   ... 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

   <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
   ... 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]

   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

   <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

   <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


   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


   janina: relying on UAs to honor spec

   mez: a11y stated that typical user population does a lot of

   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]

   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



   <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

   <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

   <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]

   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

   janina: in sequential UI, spech, failure of too many things talking at
   ... author may have suggested levels, user can say "Always interrupt me
   ... "only if I haven't done anything in this region"

   mez: think this is only pertinent re conveying variable security

   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]

   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: 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]

   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
   ... look at section 5

   <Mez> [60]


   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

   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]

   mez: can we drop this?

ISSUE-120 - Audio "logotypes"

   <Mez> [66]

   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

   <Mez> [67]


   <tlr> attack scenario applies to voice as well

   <tlr> phrase text more generically

   <Mez> [69]

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


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
   [NEW] ACTION: eburn to propose techniques for not obviously spoofable
   audio presentation based on discussion above suitable for 8.3.2
   [recorded in
   [NEW] ACTION: Mez to coordinate with hypertext CG re a11y issues
   [recorded in
   [NEW] ACTION: mez to drop success criteria into wiki [recorded in
   [NEW] ACTION: mzurko to drop success criteria into wiki [recorded in
   [NEW] ACTION: tlr to generalize 8.1.2 to be not specific to visual
   interfaces [recorded in
   [NEW] ACTION: tlr to transfer RobustSharedSecret into section 8.2
   [recorded in

   [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 $



Received on Wednesday, 21 November 2007 16:12:37 UTC