Meeting record: 2008-05-13

• From: Thomas Roessler <tlr@w3.org>
• Date: Fri, 6 Jun 2008 17:09:45 +0200
• To: public-wsc-wg@w3.org
• Message-ID: <20080606150945.GA35758@iCoaster.does-not-exist.org>

Minutes from our meeting on 2008-05-13 were approved and are
available online here:

   http://www.w3.org/2008/05/13-wsc-minutes.html

A text version is included below the .signature.

-- 
Thomas Roessler, W3C  <tlr@w3.org>




   [1]W3C

                              WSC WG face to face

13 May 2008

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
          Mary Ellen Zurko, Ian Fette, Johnathan Nightingale, Joe Steele,
          Jan Vidar Krey, Anil Saldhana, Thomas Roessler, Yngve Pettersen,
          Phillip Hallam-Baker, Luis Barriga

   Regrets
   Chair
          Mez

   Scribe
          ifette,johnath,jvkrey,yngve,tlr

Contents

     * [4]Topics
         1. [5]Introductions
         2. [6]Agenda Bashing
         3. [7]ISSUE-133
         4. [8]ISSUE-134
         5. [9]ISSUE-192
         6. [10]ISSUE 193
         7. [11]ISSUE-193
         8. [12]ISSUE-194
         9. [13]ISSUE-195
        10. [14]ISSUE-188
        11. [15]ISSUE-200
        12. [16]wrap-up for the day
     * [17]Summary of Action Items
     __________________________________________________________________

   <ifette> ScribeNick: ifette

Introductions

   Mez: does a roll call

Agenda Bashing

   mez: walks people through agenda
   ... overall desire is to get WSC-XIT to last call, which she at least
   finds exciting
   ... day 2 is life after last call
   ... candidate recommendation (entry and exit criteria, testing,
   websites to test things against, conformance testing)
   ... if we have time and go really fast, what's after june? time to open
   up, are we doing wsc-xit or are there other things we want to do
   ... one request to move ISSUE-133 to front

   <tlr> issue-133?

   <trackbot-ng> ISSUE-133 -- How do our definition of Web Page and the
   Robustiness section interact? -- OPEN

   <trackbot-ng> [18]http://www.w3.org/2006/WSC/track/issues/133

   mez: trying to get easy ones front-loaded
   ... mez wants to manipulate all of us
   ... we will have a MSFT observer tomorrow
   ... mez compliments scribe

   <asaldhan> ACTION: anil to take care of luis's email [recorded in
   [19]http://www.w3.org/2008/05/13-wsc-minutes.html#action01]

   <trackbot-ng> Created ACTION-429 - Take care of luis's email [on Anil
   Saldhana - due 2008-05-20].

   <johnath> ACTION: luis to write up grammar/spelling edits for anil
   [recorded in
   [20]http://www.w3.org/2008/05/13-wsc-minutes.html#action02]

   <trackbot-ng> Created ACTION-430 - Write up grammar/spelling edits for
   anil [on Luis Barriga - due 2008-05-20].

   Mez: more agenda bashing?

ISSUE-133

   ISSUE-133?

   <trackbot-ng> ISSUE-133 -- How do our definition of Web Page and the
   Robustiness section interact? -- OPEN

   <trackbot-ng> [21]http://www.w3.org/2006/WSC/track/issues/133

   Mez: Joe has been toiling on this issue

   <Mez>
   [22]http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0035.html

   Mez: latest proposed text from Joe
   ... have a statement on what it means for a plugin to claim conformance
   to WSC-XIT
   ... have content about what a site must do to be conformant, so it's
   reasonably clear which parts of the text address websites vs UAs
   ... haven't really addressed plugins
   ... issue originally said plugins could mess up UA conformance if they
   are bad

   <scribe> ... new text from Joe has a list of proposals for what it
   means for a UA plugin to conform

   UNKNOWN_SPEAKER: first talk about the direction of the issue

   joe: Realize this is late in process
   ... bunch of text
   ... if want to back out, it's ok

   mez: realize it's late, but like the idea

   johnath: Agree that if it's worthwhile text... go for it
   ... a lot of it is small text
   ... thinking about mozilla plugins
   ... standard talks about how the standard install should perform, but a
   plugin should be able to say that plugin + firefox is still conformant
   ... didn't think there was a need to call that out separately
   ... thoguht it was sufficient to say "This is firefox + flash, it can
   make its own claims independent of what firefox does"
   ... strange for plugin to claim conformance outside of browser
   ... either it's standalone and is a UA, or its embedded and can only be
   gauged within that context
   ... more in favor of approach that talks about plugin in context,
   rather than talking about plugins independently

   mez: another aspect will be conformance testing
   ... maybe it's more appropriate as part of test design and conformance
   testing...?

   johnath: sucks to do a bunch of different tests

   <joesteele> that is a really big test grid I think

   johnath: legit to say that if your UA typically ships with these
   plugins, worthwhile to make statements that include the plugins
   ... dont think you should have to do a NxM test
   ... Mozilla would probably say FX4 compliant as default, and with the
   following big plugins

   joe: have to test to a certain extent how plugins interact with each
   other

   johnath: dont think it scales infinitely

   mez: what claims do plugins want to claim?

   johnath: if we take joe's text as is, we create a third audience
   ... bunch of scope creep, maybe legit, but new

   yngve: issue w/ plugins that can patch their own data independent of
   browsers
   ... might tell plugin to load data insecurely in some manner... could
   be an issue
   ... may cause some potential problems

   joe: exactly the point
   ... flash and reader as plugins both make their own network requests
   ... flash uses the browser's network stack
   ... reader does also (?)
   ... are conditions under which they don't though
   ... how will they deal with TLS error conditions

   ifette: I guess the concern I have is that for the most part none of
   these plugins exist outside of the browser

   joesteele:I think you're wrong there - flash and acrobat

   ifette:acrobat sure, I think it's rare for people to launch flash
   outside the browser. I agree that they exist outside the browser, but I
   don't think users interact with them much that way
   ... so it seems strange to me to talk about plugin conformance outside
   the realm of the user agent
   ... if it's outside the browser, then it's not a plugin, it's just
   another app

   yngve: maybe the point is that even with flash and acrobat activated
   inside the client, they can call each other outside of what the browser
   is aware of

   ifette:again, that still seems that the plugins are operating within
   the browser

   joe: not sure I understand where that is going
   ... concerned about how these plugins behave within the browser and
   also when they are not using the browser's network stack

   mez: Ian's point is like johnathan's point
   ... which is that if a plugin is "plugged in" it's part of the user
   agent
   ... if it's not, it's a separate UA and can be evaluated either way
   without additional text
   ... and if we had a set of statements addressing plugins in particular,
   how would you conformance test them without them being plugged into a
   UA

   joe: Agree that if a plugin is acting stand alone outside of UA, then
   it's just another UA
   ... concerned about a case where a plugin is inside a UA
   ... in that case, plugin may or may not be using browser's network
   stack
   ... plugin doesn't have its own chrome in gneral
   ... could choose to obscure what browser is putting up
   ... whether they do or not should be the determining factor

   mez: Are you imagining some way, having discussed this, not sure of
   practicalities around declaring a plugin conformant, without making
   that statement in the context of a specific UA
   ... declare that in general it's conformant?
   ... tlr, anyone, are there specs specifically on plugins?

   yngve: have NPAPI

   ifette: and ActiveX, for what it's worth

   mez: goes to queue

   <johnath> (joesteele - yngve is drawing on the whiteboard, explaining
   that plugins can connect to the net independent of browsers)

   <asaldhan> |UA| <------------------------ (Net)

   <asaldhan> ^

   <asaldhan> |

   <asaldhan> |Flash| < ---------------------- (Net)

   johnath: queued up when mez was speaking to say that he agrees with her
   characterization

   <asaldhan> |UA| <---> |Flash|

   johnath: idea that Ian brought up which you elaborated upon
   ... hard to understand plugin in absence of UA
   ... joe's concern is plugin in context of UA
   ... ian's point is that we should consider UA + Flash as another UA
   that is or is not conformant
   ... still like text calling that out
   ... make claims in the context of plugins
   ... maybe even encourage claims about UA + typical plugins

   ifette:I think my preference is definitely to talk about the
   conformance of the UA with the plugin, lump them together and say that
   UA is either conformant or not
   ... wrt to the outside connections issue - if a plugin is making
   outside connections which break the spec with, e.g., ssl errors, then
   that combination is not conformant

   tlr: What he read in joes email goes beyond that
   ... there is this separate product class, plugins, and plugin is
   conformant if notional UA that includes that plugin will be conformant
   ... that is a notion which is separately useful
   ... real difference between the two
   ... entire thing behaves well, vs doesn't degrade the behavior of the
   entire thing
   ... leaning towards finding it useful
   ... might be nightmare for plugin vendor
   ... if plugin doesn't degrade the overall expeirence, that's a useful
   thing to capture

   phb: Can't expect a plugin to enforce conformance
   ... dont have technology to do that
   ... can expect plugin API to provide sufficient features
   ... such that combo can be conformant
   ... a browser that allows a plugin extension, should be treated the
   same as browser that allows reconfiguration of browser
   ... yes a user can extend as to make it nonconformant
   ... doesn't mean that when people are producing extensions or whatever,
   that plugins themselves can't meet conformance requirments
   ... what you might eventually see as firefox extension bar is that the
   things are differentiated as to whether they conform to spec or not
   ... if you have a plugin that removes chrome completely, that's not a
   conformant extension

   johnath: plugins traditionally use NPAPI and extensions use firefox
   mechanisms

   <tlr> "separate things that change browser behavior"

   phb: from point of view of spec, we should look at from end user's POV
   ... no differnece between extension and plugin

   <tlr> I don't care whether they are themes, plugins, add-ons,
   extensions or anything else.

   joe: gonna skip for now, thinking

   ifette:so I totally agree that we should look from user's perspective
   ... I think what that means, from the user's perspective, is "Is what
   I'm using right now, UA+plugins, conformant or not?"
   ... users are not going to independently gauge or look for conformance
   on plugins

   <PHB2> me in my role as CA

   <PHB2> Conformance might well be a requirement for having your applet
   signed

   <joesteele> +1

   <Zakim> Mez, you wanted to ask if a plug in can make a UA conformant
   with a non conformant browser

   johnath: language that might cause conformance could lead us to
   pressure flash

   <PHB2> Or at least a statement to the extent that conformance is
   attempted might be a requirement for some certification

   mez: Can see enterprises and customers potentially pressuring plugins
   to remain conformant
   ... by customers she means enterprises
   ... its an IBM thing

   <johnath> :)

   mez: so, customers may be interested in check-listy things
   ... wanted to ask if a plugin/extension/whatever can combine with
   non-conformant UA to make a conformant UA

   johnath: sure
   ... comes back to idea of testing UA + plugin as a big circle

   <Mez> tlr

   tlr: take a step back

   <johnath> ifette: :)

   tlr: like to talk about packaged changes to UA
   ... whatever they are
   ... two different properties. Does the combination (packaged change to
   a given UA) change that UA's conformance
   ... what joe is getting at
   ... we define a packaged change set to a browser as conformant if it
   doesn't adversely affect the UA's conformance
   ... other question is can a packaged change set using whatever API
   render the result conformant when the previous ua was not conformant
   ... not the same thing
   ... a plugin like firebug is probably trivially conformant

   <joesteele> +1 tlr

   tlr: not obscure UI or change browser,
   ... joe's notion is probably useful
   ... doesnt render a conformant browser nonconformant
   ... also, require about baseline browser being conformant
   ... plugins which specifically render a browser conformant where it
   wasn't previously conformant
   ... drifts

   mez: moving on

   phb: in terms of who cares about plugin is conformant, role of CA when
   doing code signing
   ... folks that want to have their code signed required to state
   conformance of plugin
   ... maybe not w.r.t. whole spec, but critical portions
   ... future versions of plugin APIs
   ... certain features of extension mechanism might require code that is
   signed with certain extensions
   ... phb talks about changes to npapi
   ... think there are some people who care

   <Zakim> ifette, you wanted to talk about somthing because i am sure i
   will want to be on queue

   phb: dont need to assume current practices will persist in perpetuity

   ifette:tlr's point is that it's useful to say whether a plugin will
   degrade the conformance of a UA
   ... my concern is that it may be difficult, because there's no real
   notion of a "nominal UA", it might be difficult to say that,
   generically
   ... but even then, we still keep talking about it in the context of the
   UA

   <Zakim> Mez, you wanted to make a proposal

   mez: proposal is that she spend lunchtime coming up with
   introduction-level text for section 4-ish text, to restate the core of
   what she thinks we said about plugins and browsers being a user agnet

   <johnath> "When this specification speaks of a "Web user agent" to
   describe the application through which a user interacts with the Web,
   then this term is used on a conceptual level: No assumption is made
   about implementation details; the "Web user agent" may denote a
   combination of several applications, extensions to such applications,
   operating system features, and assistive technologies."

   mez: and plugins not causing problems in terms of this spec and user
   agents
   ... and maybe even retaining joe's good work with non-2119 language
   ... and plugins may want to pay particular care to these sections
   ... proposal is that mez comes up with text that reflects that subset
   of this dicussions, and consdier that proposal for last call

   mez: if we actually have time today, might discuss
   ... also on table for early tomorrow

   <joesteele> yes!

   <Zakim> johnath, you wanted to make an alternate proposal

   johnath: super
   ... as incidental point, quoted paragraph from 4.1 which says that this
   spec is agnositc about UA, if UA is combination of extensions that's
   fine
   ... neatly expresses what he feels about this
   ... conformance is whatever combination of software you choose to talk
   about

   mez: wants to give it a crack

   ifette:I am trying to understand what text Mez is planning to craft
   ... are you crafting "big bubble" text? i.e. UA+Plugin as a single
   entity
   ... are we still talking about the "this plugin will not degrade
   conformance" from thomas
   ... so I will be happy to read your text

   mez: Joe, anything else you want us to prioritize?

   joe: no

   <johnath> ACTION: Mez to draft plugin-related elaboration text (section
   4ish?) [recorded in
   [23]http://www.w3.org/2008/05/13-wsc-minutes.html#action03]

   <trackbot-ng> Created ACTION-431 - Draft plugin-related elaboration
   text (section 4ish?) [on Mary Ellen Zurko - due 2008-05-20].

   <johnath> mez, you have ACTION-431

   mez: 20m till break
   ... let us continue on to the wonderful wizzard of oz

ISSUE-134

   ISSUE-134?

   <trackbot-ng> ISSUE-134 -- Let others besides industry define AAC
   criteria -- OPEN

   <trackbot-ng> [24]http://www.w3.org/2006/WSC/track/issues/134

   <Mez>
   [25]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0062.html

   mez: reads her email proposal

   <tlr> issue-134?

   <trackbot-ng> ISSUE-134 -- Let others besides industry define AAC
   criteria -- OPEN

   <trackbot-ng> [26]http://www.w3.org/2006/WSC/track/issues/134

   <Mez> Some trust anchors adhere to broadly accepted standards from
   industry or

   <Mez> other organizations (e.g. [EVTLSCERT])

   tlr: we are so deep into semantics we agree on what we want ot say
   ... there are some broadly accepted practices
   ... they do have this property, they are written up, involve a level of
   guarantee, and that's it
   ... proposal is to simply replace industry standards by guidelines or
   whatever other waffling term we choose
   ... "adhere to broadly accepted and documented practices"

   <Mez> Some trust anchors adhere to broadly accepted and documented

   <Mez> practices (e.g. [EVTLSCERT])

   <tlr> "adhere to documented, broadly accepted practices"

   <johnath> "Some trust anchors adhere to documented, broadly accepted
   practices (e.g. [EVTLSCERT]) that involve some level of guarantee that
   certificates chaining up to those roots embody augmented assurance and
   can therefore be treated more favourably in terms of the primary
   security indicators. "

   anil: if there are some practices, what about competing standards

   mez: vote on this text
   ... sticking to alphabetical scheme

   <Mez> A) replace with text typed by johnath

   mez: A is to replace with text typed by johnath

   <Mez> B) leave as is

   mez: B is to leave as is

   <Mez> C) abstain

   mez: C is to abstain

   <johnath> A

   <Mez> zakim's, who's here?

   ifette: i vote A

   <luis> B

   <Mez> A

   ifette: running tally A 3 B 1

   <joesteele> A

   <tlr> A

   <jvkrey> a

   <PHB2> a

   ifette: A7 b 1

   <yngve> A

   ifette: A8 B1

   <asaldhan> A) but very confused (dilemma) - many times industry
   standards are good but they are usually in draft stage. :)

   ifette: A9 B1

   RESOLUTION: going with changed text

   <scribe> ACTION: anil to incorporate the changed industry standard to
   practices text [recorded in
   [27]http://www.w3.org/2008/05/13-wsc-minutes.html#action04]

   <trackbot-ng> Created ACTION-432 - Incorporate the changed industry
   standard to practices text [on Anil Saldhana - due 2008-05-20].

   mez: 11m left
   ... move on

ISSUE-192

   ISSUE-192?

   <trackbot-ng> ISSUE-192 -- Keep Chrome visible if its used for SCI --
   OPEN

   <trackbot-ng> [28]http://www.w3.org/2006/WSC/track/issues/192

   ifette: this text is circular

   tlr: two extremes
   ... one example, for a usage mode in which one could say that chrome is
   not used to signal SCI - one is opera in full screen mode doing
   presentation
   ... what was meant when written

   <Mez> Web user agents MUST make information about the [[identity]] of
   the Web site that a user interacts with available. This [Definition:
   [[identity signal]] ] SHOULD be part of primary user interface during
   usage modes which entail the presence of signalling to the user beyond
   only presenting page content. Otherwise, it MUST at least be available
   through secondary user interface. Note that there may be usage modes
   during which this requirement does not apply: For exampl

   tlr: the mode Ian is reading is someone moved the padlock off the
   screen. is that a usage mode where this doesn't apply
   ... not meant to be accomodated

   johnath: text is over convoluted
   ... what it should say is "Visual UAs should always keep SCI chrome
   available"
   ... but then we had to complicate to talk about kiosk / presentations
   ... side stepping has gotten us confused

   mez: here we are
   ... current text
   ... proposed change

   <Mez> For visual user agents, browser chrome SHOULD always be present
   to signal security context information,

   <Mez> unless explicitly dismissed by the user. Examples of explicit
   dismissal include switching to full screen mode.

   ifette:+1

   tlr: +1

   johnath: making edit

   <joesteele> +1 (applies to plugins as well :-) )

   <johnath> alternate:

   <johnath> "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, e.g. by
   switching to full screen mode."

   ifette:+1

   tlr: wants to cross-refernece from 6.1.1

   <joesteele> and 6.3?

   <tlr> append ", see <specref
   ref="robustness-apis-obscure-security-ui"/>.

   <tlr> -> to 6.1.1 and 6.3

   <johnath> proposal: "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,
   e.g. by switching to full screen mode." AND append the 7.1.2 specref to
   6.1.1 and 6.3

   <Mez> A) make this change

   <Mez> B) keep same

   <Mez> C) abstain

   ifette:I vote D

   <joesteele> a

   <johnath> A

   <jvkrey> a

   <yngve> A

   ifette:A

   <tlr> a

   <PHB2> a

   <luis> C

   <asaldhan> A

   ifette: A8 C1

   RESOLUTION: going with the text in IRC

ISSUE 193

   mez: break

   <tlr> ACTION: anil to change robustness-apis-obscure-security-ui to
   include 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, e.g. by switching to full
   screen mode." [recorded in
   [29]http://www.w3.org/2008/05/13-wsc-minutes.html#action05]

   <trackbot-ng> Created ACTION-433 - Change
   robustness-apis-obscure-security-ui to include 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, e.g. by switching to full screen mode.\" [on
   Anil Saldhana - due 2008-05-20].

   <scribe> ScribeNick: johnath

   <tlr> ACTION: anil to add robustness-obscuring xrefs to identity signal
   and TLS signal [recorded in
   [30]http://www.w3.org/2008/05/13-wsc-minutes.html#action06]

   <trackbot-ng> Created ACTION-434 - Add robustness-obscuring xrefs to
   identity signal and TLS signal [on Anil Saldhana - due 2008-05-20].

   Mez: back at 11

   <Mez> back to here, on the hour, in 26 minutes

   Mez: we're back

   <ifette> Close ACTION-423

   <trackbot-ng> ACTION-423 incorporate DangerWillRobinson closed

ISSUE-193

   ISSUE-193?

   <trackbot-ng> ISSUE-193 -- Make multiple web pages chrome section rfc
   2119ed -- OPEN

   <trackbot-ng> [31]http://www.w3.org/2006/WSC/track/issues/193

   Mez: this is another case where I am upcasing words to make them 2119'd

   ifette: what is this about, tabs?
   ... I'm trying to find this text in section 7
   ... oh, 7.1.2

   <Mez>
   [32]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisibl
   e-goodpractice

   ifette: so I'm having trouble decoding this - is it referring to
   multiple tabs

   yngve: it would apply to cases with multiple tabs cascaded

   ifette: can we get some clearer text then

   yngve: what is says is that you don't need chrome for inactive tabs

   ifette: can that happen - where you see chrome for an inactive tab
   ... what would help me would be if we rewrote it to say "When multiple
   web pages may be displayed, security critical chrome need not be
   present for those which are not visible to the user."

   Mez: is there rfc2119 language there?

   PHB2: in the case of tabs, I don't think you are displaying multiple
   pages
   ... I may have 6 tabs open but only 1 displayed

   ifette: does my suggestion fix that for you?

   PHB2: no, your text still doesn't work for me - I think we need to
   distinguish between a page being open and displayed to the user

   yngve: (displays his screen on projector, which includes multiple pages
   displayed in separate, cascaded windows)

   <tlr> anil?

   <tlr> When I pasted anchors into IRC before the break, I think they
   were to the wrong section.

   <tlr> should be:
   [33]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisibl
   e-goodpractice

   <tlr> not:
   [34]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis-
   obscure-security-ui

   NOTE: we dropped connection

   <Mez> we're calling back in folks

   dialing back in

   we're back

   ifette: Yngve is showing a screen with MDI-style cascaded windows
   ... you can see multiple windows open at the same time inside of opera
   ... if you can see the content of the window, you should see the SCI
   content
   ... I think my text communicates that, but phil seemed to disagree?

   "When multiple web pages may be displayed, security critical chrome
   need not be present for those which are not visible to the user."

   "When multiple web pages might be displayed, security critical chrome
   MAY NOT be present for those which are not visible to the user."

   "When multiple web pages might be displayed, security critical chrome
   MAY NOT be present for those which are not visible to the user.
   Security critical chrome MUST be present for those which are visible to
   the user."

   jvkrey: I would expect MAY NOT to be SHOULD NOT

   PHB2: I'm still having difficulty with "when multiple web pages might
   be displayed"
   ... I think it needs some other wording, not sure what

   Mez: "open" was what you suggested

   ifette: can we just drop that clause?

   "Security critical chrome MAY NOT be present for those which are not
   visible to the user. Security critical chrome MUST be present for those
   which are visible to the user."

   tlr_: are we saying that in the case where I have multiple windows, and
   the background window gets partially obscured, the indicator should
   disappear?

   ifette: if we keep it with MAY NOT that's okay

   Mez: but why would we include that much

   yngve: <points to example of fixed address bar that reacts to currently
   selected MDI window>

   Mez: can someone remind me why we think it's a good thing to mention

   ifette: for me it was the notion that we shouldn't require UAs to
   display SCI for backgrounded tabs

   "Security critical chrome MAY NOT be present for those pages which are
   not visible to the user. Security critical chrome MUST be present for
   those pages which are visible to the user."

   tlr_: is this stronger than we had before

   <ifette> +1 to my text

   <ifette> 2 men enter. 1 man leave.

   <Mez> A) for that change

   "When multiple Web pages might be displayed, security critical chrome
   need not be 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."

   <Mez> B) for no change

   <Mez> C) abstain

   tlr_: hold on
   ... my question is that before the break, we added a SHOULD in the
   first paragraph, but now we are adding a MUST in the second for what
   appears to be the same requirement

   Mez: why have both paragraphs?

   tlr_: the first one states the broad requirement, and the second scopes
   it down to the current page

   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, e.g. by switching to full
   screen mode.

   Security critical chrome MAY NOT be present for those pages which are
   not visible to the user. Security critical chrome MUST be present for
   those pages which are visible to the user.

   proposal - drop last sentence of that conjoined paragraph

   proposal: "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, e.g. by
   switching to full screen mode. Security critical chrome MAY NOT be
   present for those pages which are not visible to the user. "

   as the entire section 7.1.2.

   <ifette> +1

   <ifette> A

   <Mez> A) the proposal

   <Mez> b) keep what's there which is a mess

   <Mez> C) abstain

   <ifette> I vote to have the new A mess

   <PHB2> +1 thomas

   modified proposal:

   <PHB2> a

   "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, e.g. by switching to full
   screen mode. Security critical chrome MAY be absent for those pages
   which are not visible to the user. "

   as the entire section 7.1.2

   <luis> A

   <Mez> A

   tlr votes A

   <joesteele> a

   <ifette> A

   johnath:A

   <anil> A

   <jvkrey> a

   <joesteele> I am on my way out -- see you all tomorrow on IRC

   <scribe> ACTION: anil to update 7.1.2 to contain the proposed text
   (superceding earlier changes) [recorded in
   [35]http://www.w3.org/2008/05/13-wsc-minutes.html#action07]

   <trackbot-ng> Created ACTION-435 - Update 7.1.2 to contain the proposed
   text (superceding earlier changes) [on Anil Saldhana - due 2008-05-20].

ISSUE-194

   <Mez> issue-194?

   <trackbot-ng> ISSUE-194 -- Window sizing a must -- OPEN

   <trackbot-ng> [36]http://www.w3.org/2006/WSC/track/issues/194

   ISSUE-194?

   <trackbot-ng> ISSUE-194 -- Window sizing a must -- OPEN

   <trackbot-ng> [37]http://www.w3.org/2006/WSC/track/issues/194

   Mez: I am proposing that we change SHOULDs to MUST

   section 7.4.1

   <Mez>
   [38]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis-
   obscure-security-ui

   johnath:+1 to the proposal

   <PHB2> [off topic, how about browsers must not allow content to steal
   my scroll bars? Fed up with pages that don't work because the content
   overruns the display and there are no scroll bars]

   <Mez> I'm not sure that's sci

   <Mez> so I'm not sure that's in charter, phb

   ifette: doesn't firefox allow you to do that, e.g. google
   presentations?

   johnath: not in ff3?

   Mez: time to vote?

   <Mez> A) change shoulds to musts

   <Mez> B) keep 'em shoulds

   <Mez> C) abstain

   A

   <jvkrey> a

   <yngve> A

   ifette: this language would block the possibility of opening in full
   screen mode, even with user consent

   Mez: technically, how do you implement that without risking a version
   without user prompting?

   ifette: propose appending "without explicit consent" to SHOULD NOT
   sentence

   <ifette> "without explicit user consent"

   <ifette> and making SHOULD NOT to MUST NOT

   Mez: anyone want to discuss that change?

   <Mez> Web user agents MUST restrict window sizing and moving operations

   <Mez> consistent with 7.1.2 Keep Security Chrome Visible. This prevents
   attacks

   <Mez> wherein browser chrome is obscured by moving it off the edges of
   the

   <Mez> visible screen.

   <Mez> Web user agents MUST NOT allow web content to open new windows
   with the

   <Mez> browser's security UI hidden without explicit user consent.
   Allowing this operation facilitates

   <Mez> picture-in-picture attacks, where artificial chrome (usually
   indicating a

   johnath: I'm fine with it - even if we do end up implementing the hard
   stop

   <Mez> positive security state) is supplied by the web content in place
   of the

   <Mez> hidden UI.

   <Mez> A) that text

   <Mez> B) what we got

   <Mez> C) abstain

   <yngve> A

   <luis> A

   johnath:A

   <jvkrey> a

   <Mez> A

   <anil> A

   <ifette> 0x41

   <PHB2> a

   <PHB2> [phill was looking up 0x41 in his hex chart]

   <scribe> ACTION: anil to update section 7.4.1 with the proposed text
   [recorded in
   [39]http://www.w3.org/2008/05/13-wsc-minutes.html#action08]

   <trackbot-ng> Created ACTION-436 - Update section 7.4.1 with the
   proposed text [on Anil Saldhana - due 2008-05-20].

ISSUE-195

   issue-195?

   <trackbot-ng> ISSUE-195 -- use SHOULD on popup restrictions -- OPEN

   <trackbot-ng> [40]http://www.w3.org/2006/WSC/track/issues/195

   <Mez> [41]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#popups

   <Mez> A) SHOULD

   <Mez> B) MAY

   <Mez> C) abstain

   <ifette> 0101

   <luis> A

   <yngve> A

   johnath:A

   <PHB2> a

   <Mez> A

   <anil> A

   <jvkrey> a

   <scribe> ACTION: anil to update 7.4.4 to use SHOULD instead of
   [MAY|SHOULD] [recorded in
   [42]http://www.w3.org/2008/05/13-wsc-minutes.html#action09]

   <trackbot-ng> Created ACTION-437 - Update 7.4.4 to use SHOULD instead
   of [MAY|SHOULD] [on Anil Saldhana - due 2008-05-20].

   <Mez> issue-169?

   <trackbot-ng> ISSUE-169 -- Section 5.5.3 creates a burden on browsers
   to remember past certificates -- OPEN

   <trackbot-ng> [43]http://www.w3.org/2006/WSC/track/issues/169

   <Mez>
   [44]http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0026.html

   Mez: the text as is caused some amount of consideration/confusion
   ... no one proposed counter-text

   johnath: Thomas and Stephen did reply saying that had the expectation
   that Firefox 3's behaviour would be non-conformant

   (various people hunting for language)

   <Mez>
   [45]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

   <Mez> last paragraph

   ifette: it does say that UAs needn't store it "longer than they
   otherwise would"

   johnath: but then it goes on to say that they can't expire it before
   other browsing history

   <Mez>
   [46]http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0026.html

   Mez: johnath's proposal is in the second last paragraph of that email

   <ifette> +1

   (people are reading)

   Mez: we can't do this issue now actually, tlr requested we not do these
   while he's absent

   johnath: tlr had objections

   <Mez> issue-188?

   <trackbot-ng> ISSUE-188 -- xit needs an acknowlegements section -- OPEN

   <trackbot-ng> [47]http://www.w3.org/2006/WSC/track/issues/188

ISSUE-188

   ifette: strawman proposal is to include anyone who showed up at a face
   to face

   Mez: would also like to include anyone who contributed text

   johnath: are those sets disjoint?

   ifette: I don't understand the meaningfulness of the distinction
   between f2f attendance and text contribution

   Mez: text contribution is necessary to the existence of a spec, whereas
   attendance isn't
   ... any counter proposals to "2 lines, text contributors, f2f
   contributors"

   <Mez> A go with this

   <Mez> B continue with the meaner algorithm

   <Mez> C abstain

   <ifette> I vote C

   <ifette> C

   <PHB2> a

   <luis> B

   johnath:A

   <yngve> c

   anil: can we have a D option to include "general contributions" e.g. by
   email?

   <Mez> vote is on hold

   Mez: who volunteers to build that list?

   <Mez> another option on the table

   tlr: it makes me feel uneasy to not include people who discuss, but
   don't get text in

   ifette: I think there are 3 options
   ... a) list only text contributors
   ... b) list everyone
   ... c) list text contributors and other contributors distinctly
   ... arguably no one is arguing for a)

   okay, votes:

   <Mez> C

   <PHB2> c

   <ifette> B

   <luis> C

   <yngve> abstain

   <ifette> just to be clear, B is not list everyone but is editorial
   discretion

   <jvkrey> abstain

   <tlr_> b

   <anil> C

   <tlr_> And if somebody doesn't like the result, complain.

   <ifette> (B+C)/2? ;-)

   <jvkrey> ifette: b and a half?

   <ifette> 4C 2B 2abstain

   <ifette> so far

   johnath:abstain

   <Mez> back in 49 minutes

   <Mez> issue-133?

   <trackbot-ng> ISSUE-133 -- How do our definition of Web Page and the
   Robustiness section interact? -- OPEN

   <trackbot-ng> [48]http://www.w3.org/2006/WSC/track/issues/133

   <jvkrey> ScribeNick: jvkrey

   <ifette> ISSUE-169?

   <trackbot-ng> ISSUE-169 -- Section 5.5.3 creates a burden on browsers
   to remember past certificates -- OPEN

   <trackbot-ng> [49]http://www.w3.org/2006/WSC/track/issues/169

   Mez: left off on ISSUE-169

   <Mez> issue-169?

   <trackbot-ng> ISSUE-169 -- Section 5.5.3 creates a burden on browsers
   to remember past certificates -- OPEN

   <trackbot-ng> [50]http://www.w3.org/2006/WSC/track/issues/169

   <johnath> re-dialing in

   <Mez>
   [51]http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0026.html

   <Mez> phb2, we're back

   Mez: We have existing text, Jonaths proposed text
   ... discussions, or other proposals?

   tlr: proposal: browsers should keep history state

   johnath: browsers should keep state

   ifette: should not

   <johnath> correction: johnath: I believe tlr thinks browsers should
   keep state

   ifette: large burden, for every tls page, the tls state needs to be
   stored

   <Mez> 5.5.1, last paragraph

   <Mez> The requirements in this section do not require user agents to
   store information about past interactions longer than they otherwise
   would. Historical TLS information stored for the purposes of evaluating
   security relevant changes of behavior MAY be expunged from the user
   agent on the same schedule as other browsing history information.
   Historical TLS information MUST NOT be expunged prior to other browsing
   history information. For purposes of this requirement, brows

   <Mez> is what we have now

   tlr: (...)
   ... for sites not pinned, the way the current behaviour the two pieces
   of historic information that are used; whether the site have previously
   been seen with domain validated cert, and the certificate was pinned
   with the same cert.
   ... one other piece
   ... historical information for security checks, such as sucessfully
   being checked before

   ifette: 3 more bytes for every history entry?
   ... domain validated cert, self-signed cert, revokation

   johnath: revokation needs to be revisited
   ... in ff, we support pinning for security overrides

   tlr: proposal (to be typed in):
   ... don't need anything more for the pinning case

   johnath: sounds like a rewrite of the last paragraph

   ifette: how useful is this, really?

   tlr: unless you are in China?

   johnath: ettercap can do this

   <johnath> [52]http://ettercap.sourceforge.net/

   tlr: any open wireless access point is subjected to this

   ifette: do we have cases where the users can't proceed after the
   warning?
   ... i have a problem with that.

   <tlr> "User agents MUST record that a site shows a validated
   certificate."

   tlr: what ways around this are considered adequate?
   ... Pinning a cert is meant to be non-intrusive
   ... non-modal UI
   ... that increases the attack surface

   ifette: Everytime I go to a hotel, I get redirected to a self-signed
   cert site where I have to pay 15$ to continue. Is this a DANGER
   situation?
   ... this is not just man in the middle attack

   johnath: it's a benign mitm attack

   tlr: will not want my cookies to be intercepted by the AP

   johnath: the root for this is; Here is a way to reduce the number of
   bad tls warnings
   ... it is a burden for browsers to implement this

   tlr: is it OK for a browser (mumble) ?
   ... offer the user a way to return to the previous state

   tlr "User agents MUST record that a site shows a validated
   certificate."

   tlr: instead of the first sentence
   ... how to deal with danger messages for ettercapped portals is a
   separate question

   <Zakim> anil, you wanted to point to other continuous applications that
   may be potentially affected by ifette's concern

   anil: continous communication with a server, and an access point
   redirects all of the sudden. How do we handle this?

   tlr: Ajax applications should handle it separately
   ... keyword: TLS

   <anil> think about web conferencing

   <anil> applications

   tlr: separate issue, what should we tell the WebAPI group?

   Mez: putting together 3 proposals

   <ifette> ISSUE-198?

   <trackbot-ng> ISSUE-198 -- 6.4.4 Danger messages should not strictly
   forbid user agents from doing the user's bidding -- OPEN

   <trackbot-ng> [53]http://www.w3.org/2006/WSC/track/issues/198

   johnath: trying to look at this independently from how to deal with
   danger messages

   <Mez> [54]http://www.w3.org/2006/WSC/wiki/RecommendationProposals

   Mez: here are 3 proposals

   <ifette> +1 johnath

   <johnath>
   [55]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors is
   the whole section

   <Zakim> ifette, you wanted to say that I like johnathan's

   ifette: i like Jonathan's text
   ... this is a real use-case, I don't want a warning that looks
   significantly worse than it really is

   <PHB2> thomas please speak into the mike

   tlr: the current TLS error handling is fine, as it is

   Mez: sounds like we are ready to vote

   <Mez> A) current text

   <ifette> [56]http://www.youtube.com/watch?v=Nnzw_i4YmKk

   <Mez> B) Johnathan's text

   <Mez> C) Thomas' text

   <Mez> D) abstain

   <Mez> [57]http://www.w3.org/2006/WSC/wiki/RecommendationProposals

   <Mez> hold off on vote

   tlr: i would like to know more about Ian's argument

   ifette: it is more dangerous to see a self-signed cert in a case where
   you have seen a domain validated cert previously. But in most cases
   this is seen in many much less scenarios.
   ... If I open my browser and my start page is my Ebay page. What do you
   tell the user when presented with a self-signed cert?

   yngve: we see something in the wild that is not an attack situation,
   should we therefore whitewash it?
   ... wlan access point scenario should be outlawed

   ifette: it is nice to say it sucks, but we need to handle it

   johnath: the question is; are we confident enough in this solution to
   mandate it?

   ifette: this case is more bad, than self-signed cert on any random web
   site.
   ... it is not going to help the user making a useful decision

   johnath: concern; UI is the easy part for the browser changes, but the
   crypto stuff is the harder part to rework

   zakim is not here

   Mez: ready to vote?
   ... strawpoll

   <ifette> ISSUE-200?

   <trackbot-ng> ISSUE-200 -- Should an AA security indication include all
   elements in the evaluation, or just the top document -- OPEN

   <trackbot-ng> [58]http://www.w3.org/2006/WSC/track/issues/200

   Mez: tlr, please type in your strawpoll

   <Mez> total straw poll

   <Mez> [59]http://www.w3.org/2006/WSC/wiki/RecommendationProposals

   <Mez> finger in the air, which of these do you lean towards?

   <Mez> a) current text

   <Mez> b) johnathan's text

   <Mez> c) thomas' text

   <johnath> strawpoll vote B

   <Mez> d) abstain

   <ifette> B

   <PHB2> b - ish

   <luis> B

   jvkrey:b

   <johnath> I suspect that stephen would vote C, for the record, but I
   also don't get to vote for him :)

   <yngve> c

   <Mez> d

   <tlr> c

   jvkrey:b, since it is not always possible to get this information with
   different TLS stacks from the UA's perspective.
   ... otherwise I would lean towards c

   <anil> D

   <tlr> hi ralph, zakim seems healthy here

   <Mez> B - johnath, ifette, phbish, luis, jvkrey - 5 ish

   <Mez> C - stephenf if he was here, yngve, tlr - 2 + 1

   <Mez> D- Mez, Anil - 2

   yngve: opera 9.5 is already storing protocol version for TLS
   connections to improve handshake performance

   johnath: unlike Ian, I find this somewhat useful

   ifette: there are two interactions, the first time you visit time, the
   n-th time you visit

   <Mez> I updated thomas' proposal in the wiki

   <Mez> is anyone seeing what jvkrey is typing?

   <Mez> is anyone seeing me?

   <johnath> see you mez

   <johnath> ACTION: tlr to draft alternate text around requiring saved
   SSL state [recorded in
   [60]http://www.w3.org/2008/05/13-wsc-minutes.html#action10]

   <trackbot-ng> Created ACTION-438 - Draft alternate text around
   requiring saved SSL state [on Thomas Roessler - due 2008-05-20].

   <ifette> ISSUE-190?

   <trackbot-ng> ISSUE-190 -- Relaxed Path Validation - optional,
   recommended? -- OPEN

   <trackbot-ng> [61]http://www.w3.org/2006/WSC/track/issues/190

   <Mez> issue-190?

   <trackbot-ng> ISSUE-190 -- Relaxed Path Validation - optional,
   recommended? -- OPEN

   <trackbot-ng> [62]http://www.w3.org/2006/WSC/track/issues/190

   <jvkrey2> ScribeNick: jvkrey2

   ifette: do cert checks like it is supposed to.

   yngve: never gotten to understand it properly

   <jvkrey> ScribeNick: jvkrey

   Mez: what does the minutes from the previous meeting say?

   <tlr>
   [63]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-pathval

   <ifette> ISSUE-190?

   <trackbot-ng> ISSUE-190 -- Relaxed Path Validation - optional,
   recommended? -- OPEN

   <trackbot-ng> [64]http://www.w3.org/2006/WSC/track/issues/190

   Mez: what was the result of this?

   tlr: remove the section I pointed to

   <Mez> A) remove

   Mez: no vote taken according to the minutes

   <Mez> B) leave as is

   <Mez> C) abstain

   <ifette> I vote for A

   <johnath> A

   <tlr> c

   jvkrey:a

   <luis> C

   <johnath> for the record again, stephen almost certainly votes B

   <anil> C

   <johnath> yngve votes A

   <tlr> yngve a

   <PHB2> a

   <Mez> A it is

   <johnath> ACTION: anil to remove relaxed path validation section and
   references [recorded in
   [65]http://www.w3.org/2008/05/13-wsc-minutes.html#action11]

   <trackbot-ng> Created ACTION-439 - Remove relaxed path validation
   section and references [on Anil Saldhana - due 2008-05-20].

   <tlr> RESOLUTION: drop relaxed path validation and the sentences that
   refer to it

   <Mez> issue-181?

   <trackbot-ng> ISSUE-181 -- Should there be an authoring practice
   suggesting http/https URI space consistency -- OPEN

   <trackbot-ng> [66]http://www.w3.org/2006/WSC/track/issues/181

   jvkrey:no, no no?

   tlr: past june issue.

   <Mez> issue-196?

   <trackbot-ng> ISSUE-196 -- Remove Conformance Labels section -- OPEN

   <trackbot-ng> [67]http://www.w3.org/2006/WSC/track/issues/196

   Mez: ok, next issue

   <johnath>
   [68]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#clabels

   <Mez> A) remove

   <Mez> B) keep with noting in it

   <tlr> a

   <Mez> C) abstain

   <ifette> I vote A

   <johnath> B!

   <Mez> a

   <yngve> A

   <johnath> Oops - A.

   <luis> A

   jvkrey:a

   <tlr> note: the third paragraph of what was 3.1 and will now be 1 needs
   some update

   <ifette> ;-)

   <anil> D

   <ifette> ISSUE-74

   <johnath> ACTION: anil to remove Conformance Labels section 3.2
   [recorded in
   [69]http://www.w3.org/2008/05/13-wsc-minutes.html#action12]

   <trackbot-ng> Created ACTION-440 - Remove Conformance Labels section
   3.2 [on Anil Saldhana - due 2008-05-20].

   <Mez> issue-74?

   <trackbot-ng> ISSUE-74 -- Dependencies on other wgs -- OPEN

   <trackbot-ng> [70]http://www.w3.org/2006/WSC/track/issues/74

   Mez: next issue will be, ISSUE-74

   <ifette> ISSUE-74?

   <trackbot-ng> ISSUE-74 -- Dependencies on other wgs -- OPEN

   <trackbot-ng> [71]http://www.w3.org/2006/WSC/track/issues/74

   Mez: think about this during the break
   ... back on the hour

   <Mez> break for 25 minutes

   <Mez> issue-199?

   <trackbot-ng> ISSUE-199 -- WebAPI does not specify any TLS error
   handling for XMLHttpRequest -- OPEN

   <trackbot-ng> [72]http://www.w3.org/2006/WSC/track/issues/199

   <ifette> ISSUE-198?

   <trackbot-ng> ISSUE-198 -- 6.4.4 Danger messages should not strictly
   forbid user agents from doing the user's bidding -- OPEN

   <trackbot-ng> [73]http://www.w3.org/2006/WSC/track/issues/198

   <scribe> ScribeNick: yngve

   <Mez> issue-74?

   <trackbot-ng> ISSUE-74 -- Dependencies on other wgs -- OPEN

   <trackbot-ng> [74]http://www.w3.org/2006/WSC/track/issues/74

   <Mez> [75]http://www.w3.org/2006/WSC/Group/cheatsheet

   <tlr> ISSUE-74?

   <trackbot-ng> ISSUE-74 -- Dependencies on other wgs -- OPEN

   <trackbot-ng> [76]http://www.w3.org/2006/WSC/track/issues/74

   <johnath> ACTION: tlr to draft list of workgroups in response to
   ISSUE-74 [recorded in
   [77]http://www.w3.org/2008/05/13-wsc-minutes.html#action13]

   <trackbot-ng> Created ACTION-441 - Draft list of workgroups in response
   to ISSUE-74 [on Thomas Roessler - due 2008-05-20].

   <ifette> ISSUE-75?

   <trackbot-ng> ISSUE-75 -- Relation to existing standards and related
   work -- OPEN

   <trackbot-ng> [78]http://www.w3.org/2006/WSC/track/issues/75

   <Mez> issue-75?

   <trackbot-ng> ISSUE-75 -- Relation to existing standards and related
   work -- OPEN

   <trackbot-ng> [79]http://www.w3.org/2006/WSC/track/issues/75

   yngve: known overlapping TLS, RFC 3280, Extended Validation

   tlr: Are there other specs overlapping. e.g does WAI overlap or how do
   we handle it?

   <ifette> close issue-75

   <ifette> code?

   <PHB2> you stopped already?

   <tlr> no

   <Mez> issue-185?

   <trackbot-ng> ISSUE-185 -- UI recommendations for URI handlers? -- OPEN

   <trackbot-ng> [80]http://www.w3.org/2006/WSC/track/issues/185

   <tlr> zakim dropped us

   <ifette> zakim topped us

   tlr: Noticed issues in HTML 5, related to protocol handlers, that may
   or may not have security related implications
   ... May be LC relevant

   jonath: It isn't our workgroup's responsibility to police HTML5-WG's
   language and charter

   <ifette> +1

   jonath: do not think WSC have an issue here

   <ifette> Close ISSUE-185

   <ifette> trackbot-ng, close issue-185

   <tlr> issue-196?

   <trackbot-ng> ISSUE-196 -- Remove Conformance Labels section -- OPEN

   <trackbot-ng> [81]http://www.w3.org/2006/WSC/track/issues/196

   <tlr> issue-169?

   <trackbot-ng> ISSUE-169 -- Section 5.5.3 creates a burden on browsers
   to remember past certificates -- OPEN

   <trackbot-ng> [82]http://www.w3.org/2006/WSC/track/issues/169

   <ifette> ISSUE-197

   <ifette> ISSUE-197?

   <trackbot-ng> ISSUE-197 -- Remove petnames -- OPEN

   <trackbot-ng> [83]http://www.w3.org/2006/WSC/track/issues/197

   <ifette> ISSUE-198?

   <trackbot-ng> ISSUE-198 -- 6.4.4 Danger messages should not strictly
   forbid user agents from doing the user's bidding -- OPEN

   <trackbot-ng> [84]http://www.w3.org/2006/WSC/track/issues/198

   <ifette> I vote for 198

   <ifette> or 197

   <Mez> issue-197?

   <trackbot-ng> ISSUE-197 -- Remove petnames -- OPEN

   <trackbot-ng> [85]http://www.w3.org/2006/WSC/track/issues/197

   ifette: [Walks through petname occurences in WSC-xit suggested to be
   removed for LC-june]

   <johnath> for the record, voting to drop this without Tyler will cause
   the issue to be revisited, imo

   ifette: Should be removed because ...

   <ifette> The first sentence says "For TLS-secured pages, the user MAY
   assign the authenticated entity a"

   <ifette> This makes it sound like ua's must allow users to enter
   petnames

   <ifette> my suggested change:

   ifette: does not want petnames to be required feature

   <ifette> "For TLS-secured pages, the user agent MAY allow the user to
   assign the authenticated entity a petname"

   ifette: alternatively, rephrase the section

   <Mez> A) make the change

   <Mez> B) don't

   <Mez> C) abstain

   <Mez> A

   <tlr> a

   <johnath> A

   <ifette> a

   yngve:A

   <jvkrey> a

   <luis> A

   <PHB2> a

   <anil> A

   <johnath> ACTION: anil to rephrase 5.1.6 as described [recorded in
   [86]http://www.w3.org/2008/05/13-wsc-minutes.html#action14]

   <trackbot-ng> Created ACTION-442 - Rephrase 5.1.6 as described [on Anil
   Saldhana - due 2008-05-20].

   <ifette> ISSUE-198?

   <trackbot-ng> ISSUE-198 -- 6.4.4 Danger messages should not strictly
   forbid user agents from doing the user's bidding -- OPEN

   <trackbot-ng> [87]http://www.w3.org/2006/WSC/track/issues/198

   <Mez> issue-198?

   <trackbot-ng> ISSUE-198 -- 6.4.4 Danger messages should not strictly
   forbid user agents from doing the user's bidding -- OPEN

   <trackbot-ng> [88]http://www.w3.org/2006/WSC/track/issues/198

   ifette: user agent should permit, possibly through a long number of
   hoops, to let the user do what they want, even if the client consider
   it dangerous

   johnath: example of danger message does not permit further navigation:
   revocation

   ifette: Usability studies show some users encountering warning messages
   copy paste into other browsers, ignoring the warning

   jonath: Making the change will make more people vulnerable
   ... Can't make user agents stop users from doing stupid things

   Mez: before change some users would not go to the dangeours site, some
   others would use other browser allowing the to go there
   ... with change, some users would not go to the site, some would
   interact with message going ot the site, and some would still go to
   other browser
   ... Do we believe the set of people that does not go to the site
   changes substantially?

   php: not convinced by usability tests

   <Mez> I'm trying to understand if we believe th enumber of people who
   go on to a dangerous situation is pretty much the same either way or

   php: That some will change change does not mean they always will (or
   can, such as with the iphone)

   <Mez> we believe that the number/percentage of people who go on to a
   dangerous situation changes notably, but that's the right tradeoff, to,
   for example, keep a larger number/percentage of people on the overall
   model which provides better security (or some other reason, like market
   share)

   johnath: Language of change lets vendors be more restrictive, but does
   not compel them

   mez: can the proposal be made more abstract?

   ifette: google lets users click through blocks

   tlr: There are cases where google does not allow click through (e.g
   content outlawed in germany)

   <johnath>
   [89]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-danger

   ifette: what is the difference between warning and danger? currently
   that user cannot click trough

   <Mez> here's an alternative to Ian's text:

   <Mez> These interactions MUST be presented in a way that does not allow
   the user go to or interact with the destination web site that caused
   the danger situation to occur, without explicit user interaction. User
   agents MAY not allow the user to go to or interact with the destination
   web site at all.

   yngve: By allowing click through "danger" becomes "warning"

   johnath: text in danger messages should be more omnious sounding

   <johnath> Mez: s/MAY not allow/MAY prevent/ ?

   ifette: mez proposal makes warning and danger similar

   tlr: distinction between warning and danger is that danger is more
   difficult to bypass

   <johnath> proposal:

   <johnath> The interactions communicating these messages MUST be
   designed such that the user's task is interrupted, and should be
   designed to appear distinct and of higher severity than Warning
   messages.

   tlr: then evaluate warning to see what fits where

   <johnath> These interactions MUST be presented in a way that does not
   allow the user go to or interact with the destination web site that
   caused the danger situation to occur, without explicit user
   interaction. User agents MAY not allow the user to go to or interact
   with the destination web site at all.

   tlr: the default for danger indication MUST NOT be "dismiss"

   <johnath> proposal v2:

   <johnath> The interactions communicating these messages MUST be
   designed such that the user's task is interrupted, and SHOULD be
   designed to appear distinct and of higher severity than Warning
   messages.

   <johnath> These interactions MUST be presented in a way that does not
   allow the user go to or interact with the destination web site that
   caused the danger situation to occur, without explicit user
   interaction. The default interaction MUST NOT be to bypass the warning.
   User agents MAY prevent the user from going to or interacting with the
   destination web site at all.

   <johnath> proposal v3 (comma fix):

   <johnath> The interactions communicating these messages MUST be
   designed such that the user's task is interrupted, and SHOULD be
   designed to appear distinct and of higher severity than Warning
   messages.

   <johnath> These interactions MUST be presented in a way that does not
   allow the user go to or interact with the destination web site that
   caused the danger situation to occur without explicit user interaction.
   The default interaction MUST NOT be to bypass the warning. User agents
   MAY prevent the user from going to or interacting with the destination
   web site at all.

   <jvkrey> no reason for the "Warning" to be capitalized

   <johnath> jvkrey: sorry, I meant it to be a link to the "Warning
   Messages" section

   <jvkrey> oh, ok

   <johnath> proposal v4:

   <johnath> The interactions communicating these messages MUST be
   designed such that the user's task is interrupted, and SHOULD be
   designed to appear distinct and of higher severity than Warning
   Messages [link to Warning Messages] section.

   <johnath> These interactions MUST be presented in a way that does not
   allow the user go to or interact with the destination web site that
   caused the danger situation to occur without explicit user interaction.
   The default interaction MUST NOT be to bypass the warning. User agents
   MAY prevent the user from going to or interacting with the destination
   web site at all.

   <Mez> A) new text

   <Mez> B) as is

   <Mez> c) abstain

   <ifette> A

   <Mez> tlr is stopping the vote

   tlr: bypass for danger should be significatly different from warning

   <johnath> proposal v5:

   <johnath> The interactions communicating these messages MUST be
   designed such that the user's task is interrupted, and SHOULD be
   designed to appear distinct and of higher severity than Warning
   Messages [link to Warning Messages] section.

   <johnath> These interactions MUST be presented in a way that does not
   allow the user go to or interact with the destination web site that
   caused the danger situation to occur without explicit user interaction.
   The default interaction MUST NOT be to bypass the warning. The
   interaction used to bypass the danger message SHOULD be different than
   those used to bypass other messages. User agents MAY prevent the user
   from going to or interacting with the destination web site

   <ifette> at all

   tlr: with this change what is the difference between warning and danger
   excpet that the interaction is different?
   ... what is an explicit user interaction?

   <johnath> proposal v6:

   <johnath> The interactions communicating these messages MUST be
   designed such that the user's task is interrupted, and SHOULD be
   designed to appear distinct and of higher severity than Warning
   Messages [link to Warning Messages] section.

   <johnath> These interactions MUST be presented in a way that does not
   allow the user go to or interact with the destination web site that
   caused the danger situation to occur without explicit user interaction.
   The default interaction MUST NOT be to bypass the warning. ...

   <johnath> The interaction used to bypass the danger message, if
   present, SHOULD be different than those used to bypass other messages.
   User agents MAY prevent the user from going to or interacting with the
   destination web site at all.

   johnath: think danger should warn each time, and not have a never warn
   again.

   <ifette> +1

   <ifette> vote?

   <Mez> a) new text

   <Mez> b) no change

   <Mez> c) abstain

   <ifette> A

   <johnath> A

   <tlr> a

   <Mez> a

   yngve:a

   <luis> A

   <PHB2> a

   <anil> A

   <jvkrey> a

   <johnath> ACTION: anil to include proposal v6 changes to 6.4.4
   [recorded in
   [90]http://www.w3.org/2008/05/13-wsc-minutes.html#action15]

   <trackbot-ng> Created ACTION-443 - Include proposal v6 changes to 6.4.4
   [on Anil Saldhana - due 2008-05-20].

   <Mez> issue-199?

   <trackbot-ng> ISSUE-199 -- WebAPI does not specify any TLS error
   handling for XMLHttpRequest -- OPEN

   <trackbot-ng> [91]http://www.w3.org/2006/WSC/track/issues/199

   yngve: about johnaths comment about danger: should danger be shown on
   each new visit to the site/document trigger a new danger message, even
   within same browsing session?

   <ifette> to yngve: up to implementation

   <johnath> johnath: I generally favour warning every time, if it's
   really a danger situation

   <johnath> but I don't think the spec needs to constrain there

   tlr: how should Webapi handle TLS error messages? Example when gmail is
   hit with a man in the middle attack selfsigned certificate
   ... May have to change section 5.5.1 to indicate that TLS error
   handling also includes errors on connections triggered by
   XMLHTTPrequest
   ... Have to get webapi group to agree
   ... not enough information in Webapi spec about error handling
   ... Ask webapi to specify what they want, interaction or no
   interaction?

   mez: does issue 199 block LC june?

   tlr: yes, uncomfortable about not knowing what they want

   [discussion about whether or not to decide for LC before or after
   having read the spec after all updated text have been inserted]

   <ifette> ISSUE-200?

   <trackbot-ng> ISSUE-200 -- Should an AA security indication include all
   elements in the evaluation, or just the top document -- OPEN

   <trackbot-ng> [92]http://www.w3.org/2006/WSC/track/issues/200

   <ifette> ISSUE-201?

   <trackbot-ng> ISSUE-201 -- Status recording for revocation checks? --
   OPEN

   <trackbot-ng> [93]http://www.w3.org/2006/WSC/track/issues/201

   <johnath> ACTION: tlr to take XHR-over-https questions to webapi
   [recorded in
   [94]http://www.w3.org/2008/05/13-wsc-minutes.html#action16]

   <trackbot-ng> Created ACTION-444 - Take XHR-over-https questions to
   webapi [on Thomas Roessler - due 2008-05-20].

   <tlr> johnath,
   [95]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors

   <tlr> second numbered list

   yngve: Opera tried danger level for OCSP failures. Got ugly due to
   server stability problems at several CAs.

   tlr: attacker may block OCSP

   <johnath> I propose removing all the following text from 5.5.1:

   <johnath> "When certificate status checks are attempted, but fail due
   to network errors or related error conditions, the following applies:"

   johnath: FF does not display EV for sites failing OCSP lookup due to
   network issues

   <johnath> 1. If a certificate check was successfully performed before,
   or if an Augmented Assurance Certificate is used, then error signalling
   of level danger (6.4.4 Danger Messages) MUST be used. 2. Otherwise,
   error signalling of level warning (6.4.3 Warning/Caution Messages )
   SHOULD be used.

   <johnath> yngve: What opera does in case of OCSP network failure is to
   lower the security level by one notch

   yngve: What Opera does in case of revocation network failure is to
   lower the security level by one, and implicilty no EV indication.

   <johnath> vote time?

   phb: if you try to do something more secure, but network issues prevent
   it, then the result should not be worse than as if the check had not
   been done

   <johnath> vote time?

   <PHB2> a

   <ifette> a

   <Mez> a) make the change

   <tlr> a

   <Mez> b) keep the text

   <Mez> c) abstain

   <johnath> A

   <Mez> c

   yngve:a

   <jvkrey> +1

   <luis> C

   <jvkrey> a

   <anil> a

   <johnath> A: 7, C: 2

   <Mez> issue-199?

   <trackbot-ng> ISSUE-199 -- WebAPI does not specify any TLS error
   handling for XMLHttpRequest -- OPEN

   <trackbot-ng> [96]http://www.w3.org/2006/WSC/track/issues/199

   <johnath> ACTION: anil to remove the quoted section of 5.5.1, concerned
   with failed status revocation checks [recorded in
   [97]http://www.w3.org/2008/05/13-wsc-minutes.html#action17]

   <trackbot-ng> Created ACTION-445 - Remove the quoted section of 5.5.1,
   concerned with failed status revocation checks [on Anil Saldhana - due
   2008-05-20].

   <ifette> Zakim is telling us we're done for the day

   tlr: [quotes drafted comment to webapi, gets a couple of correction,
   send off email]

   <johnath> issue-202?

   <trackbot-ng> ISSUE-202 -- Conformance model section makes outdated
   assumption about spec content -- OPEN

   <trackbot-ng> [98]http://www.w3.org/2006/WSC/track/issues/202

   <Mez> issue-202?

   <trackbot-ng> ISSUE-202 -- Conformance model section makes outdated
   assumption about spec content -- OPEN

   <trackbot-ng> [99]http://www.w3.org/2006/WSC/track/issues/202

   <tlr>
   [100]http://lists.w3.org/Archives/Public/public-webapi/2008May/0176.htm
   l

   tlr: Update section about how applications should conform to the use of
   MUST and SHOULDs in the document

   <johnath> Proposal: Give thomas an action to draft uncontroversial text
   here and put it in

   <johnath> ACTION: tlr to Draft uncontroversial text to update section
   3.1 and insert it [recorded in
   [101]http://www.w3.org/2008/05/13-wsc-minutes.html#action18]

   <trackbot-ng> Created ACTION-446 - Draft uncontroversial text to update
   section 3.1 and insert it [on Thomas Roessler - due 2008-05-20].

ISSUE-200

   <Mez> issue-200?

   <trackbot-ng> ISSUE-200 -- Should an AA security indication include all
   elements in the evaluation, or just the top document -- OPEN

   <trackbot-ng> [102]http://www.w3.org/2006/WSC/track/issues/200

   <johnath> Issue-200?

   <trackbot-ng> ISSUE-200 -- Should an AA security indication include all
   elements in the evaluation, or just the top document -- OPEN

   <trackbot-ng> [103]http://www.w3.org/2006/WSC/track/issues/200

   <tlr> ScribeNick: tlr

   ifette: I think we settled that one over dinner?
   ...
   ... sounds like relaxed path validation -- radically different things
   on the same site
   ... that's the point we're trying to standardize ...
   ... this is what you see regardless of what browser we're using ...
   ... we should take a stance on this ...

   johnath: I propose we use "domain-validated" in the sentence that Yngve
   suggested.

   <johnath> proposal: "A user agent that can display an AA indicator MUST
   NOT display this indicator unless all elements of the page are loaded
   from servers presenting a validated certificate."

   yngve: what does the user expect when he sees the AA indicator?
   ... I think he expects that all the content is AA ...

   johnath: user doesn't have the model that the web site has parts

   yngve: ...

   johnath: print metaphor
   ... user won't understand that "page" has parts ...
   ... won't even consider that ...
   ... arguably good reason for us to get this right...
   ... support language that EV indicator shouldn't be shown if HTTP in
   there ...

   ifette: If domain-validated, then all the subresources come from the
   place that the top-level resource intended

   johnath: that's enough

   ifette: it's the page that eBay means

   johnath: ebay has declared that they want to render the page this or
   that way, with this or that content
   ... if http, could be undermined ...
   ... could give that to the browser, but ARP and DNS cache poisoning
   could dupe browser ...
   ... but in case where DV-SSL or better, that's not an issue ...

   yngve: next level of possible issues -- if sensitive part of
   ... EV site that was not EV-authenticated is used to defraud user ...
   ... how's the liability issues for the client ...

   johnath: up to client to deal with ...

   tlr:jvkrey, he *meant* DV-SSL

   <jvkrey> ok

   phb2: another concern here is consistency
   ... it's clear that you want to have one rule for all browsers ...
   ... right now, if someone tries EV cert on IE, if it works there, think
   it's good ...
   ... what you want to do is have single criteria across browsers ...
   ... there's no mid-way ...
   ... the only viable ones are no checks on included content, or all be
   validated ...

   tlr: domain validated or extended?

   phb: extended

   yngve: so you support my proposed text?

   <johnath> PHB2: in other words, you support yngve's proposal?

   tlr:"A user agent that can display an AA indicator MUST NOT display
   this indicator unless all elements of the page are loaded from servers
   presenting an AA certificate."

   pbaker: yes

   ifette: If top-level page is EV
   ... image from ebaystaticcontent.com ...
   ... valid cert from trusted CA ..
   ... why is that not good?
   ... why does that undermine EV-ness of page?

   phb2: if you have paypal pointing to DV that's not on Paypal at all
   ... makes me somewhat more nervous ...
   ... we've got something that we said we have accountability for, but we
   go off to something we don't have that for

   johnath: it's something they decided to put there

   yngve: or just a web designer

   ifette: you overstimate the freedom that web designers have

   johnath: phil, I'm surprised you're taking that position
   ... still waiting for the explanation that Ian asked for
   ... how it undermines Paypal's EV-ness

   ifette: Google Analytics won't be EV, ad networks won't be EV
   ... so why should I be EV if I don't get the green bar ...

   johnath: If idea is that somehow using EV makes identity better, how
   does that make things better?

   <scribe> scribe: SIGHEADACHE

   johnath: I'm confused
   ... how this undermines EV-ness of top-level page ...

   phb2: are we in agreement on http without TLS?

   johnath: yes

   tlr:+1

   phb2: what it seems that we have here motivates that ...

   <ifette> johnath: If the top-level page includes an analytic script
   from Site B, and Site B has an EV cert, you're saying you're fine to
   show Paypal. But if it's an domain-validated SSL cert, you don't want
   to show paypal? why? It's no less secure, and it's still content from a
   third site

   phb2: EV is top level, that can be different from the others in the
   stack ...
   ... that's the only one that's displayed to the user ...
   ... that's the only one that makes representation of accountability to
   the user ...

   johnath: precisely

   phb2: can accept that as a reason

   <johnath> we just lost you phb

   <johnath> dialing back in

   <ifette> we lost ourselves

   <ifette> we're calling in

   <tlr-scribe> ScribeNick: tlr-scribe

   <johnath> "A user agent that can display an AA indicator MUST NOT
   display this indicator unless all elements of the page are loaded from
   servers presenting an AA certificate."

   <johnath> "A user agent that can display an AA indicator MUST NOT
   display this indicator unless all elements of the page are loaded from
   servers presenting a verified certificate."

   tlr:phil, do you still hear us?

   <PHB2> nooooo

   <joesteele> lost you guys again

   <johnath> phone hates us

   <PHB2> hellloooooo

   tlr:(yngve redialing)

   <Mez>
   [104]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#def-validated-c
   ert

   <johnath> "A user agent that can display an AA indicator MUST NOT
   display this indicator unless all elements of the page are loaded from
   servers presenting a validated certificate."

   <ifette> phb, what's your phone number?

   johnath: yes

   <PHB2> XXX XXX 4123

   <joesteele> how will I hear then?

   johnath: the discussion we're having is just whether the second last
   word there is 'AA' or 'verified'

   <Mez> wow; gm joe!

   <joesteele> gm again

   <joesteele> hehehe

   johnath: question whether "validated" is strong enough for your
   purposes

   phb2: I can justify that

   johnath: took me a moment to justify

   phb: overriding priority is consistency

   <Mez> I didn't get to drafting the proposal on issue-133; started; hope
   to finish tonight; sorry about that joe

   phb: what it is is less worrying ...
   ... we need to persuade everybody to do the same thing ...

   yngve: it's been going every time it's been raised
   ... need more information about what the user expects the EV indicator
   ...
   ... issue that really concerns me is frame content ...
   ... external scripting ...

   <johnath> welcome back!

   yngve: identity on both sources of content

   johnath: paypal would be primary certificate

   yngve:in the info panel, would be able to see all the scripts and
   frames ...

   johnath: ...
   ... if it's delivered, but identity doesn't match an expectation of
   identity, then could see the problem ...
   ... agee that in secondary chrome shouldn't make claims where the
   script comes from when you don't have that information

   yngve: my point is that, without EV certificate on the external scripts
   or the frames, you don't have the identity of everyone who provided
   content
   ... one scenario that I'm worried about ...
   ... don't know whether permitted by agreements between EV and others
   ...
   ... "just go here if you want the green bar"
   ... through framing ...

   johnath: If branding content is more powerful than EV indicator
   ... then ??
   ... understand the attack, not concerned by it

   yngve: If somebody does it, could lessen reliability on EV

   <joesteele> my EV Shack is quite reliable thank you!

   johnath: If EV didn't have a name, then fact that you could obtain it
   through framing would bother me
   ... in current situation, there's a way to brand yourself with somebody
   else's brand. Great.
   ... in that case, a DV SSL site and branding content would be more
   helpful

   luis: relationship between EV and stongly TLS protected?
   ... so with new formulation allow less strong protection?

   johnath, ifette: no

   johnath: it's just about validated vs AA -- strongly TLS protected is
   understood

   tlr: yes

   tlr:+1 to wrapping for the day

   johnath: people, like sellers, having web sites on ebay?

   yngve: yes

   johnath: absent of whether that's a good idea, don't think that would
   be changed

   yngve: similar to ??? check

   johnath: think j random seller can have ebay account and be totally
   ebay
   ... yes, they are j random seller, but neither of our text will fix
   that ...

wrap-up for the day

   mez: check in with ourselves whether we know of any other blockers
   ... that we are not going to resolve now ...
   ... then we are meant to swing into what we do after june ...
   ... test development ...
   ... plans, how do we get sites to test against?
   ... how to execute?
   ... do testing to exit CR
   ... next topic is conforming implementations in order to do the testing
   ... code that conforms
   ... if there is none, can't carry things forward
   ... talk about what we're gonna have
   ... that we can use in testing ...
   ... MUSTs and SHOULDs and what we think about that
   ... then, usability testing
   ... and what we expect to do then
   ... maritza said she'd call in at some useful time her time zone
   ... if nobody else does it, I'll have to
   ... talk about what that means ...

   <PHB2> byeeeeeee

   <ifette> bye phil

   <PHB2> off to zzzzzzzzzzz

   mez: also, do we think we're doing other stuff?

   <johnath> way to go phil and joe

   <joesteele> thank you

   <joesteele> lots of coffee

   <joesteele> cya tomorrow!

   <PHB2> lots of porridge

   <Mez> ta

   <Mez> phb2, you scare me sometimes

Summary of Action Items

   [NEW] ACTION: anil to add robustness-obscuring xrefs to identity signal
   and TLS signal [recorded in
   [105]http://www.w3.org/2008/05/13-wsc-minutes.html#action06]
   [NEW] ACTION: anil to change robustness-apis-obscure-security-ui to
   include 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, e.g. by switching to full
   screen mode." [recorded in
   [106]http://www.w3.org/2008/05/13-wsc-minutes.html#action05]
   [NEW] ACTION: anil to include proposal v6 changes to 6.4.4 [recorded in
   [107]http://www.w3.org/2008/05/13-wsc-minutes.html#action15]
   [NEW] ACTION: anil to incorporate the changed industry standard to
   practices text [recorded in
   [108]http://www.w3.org/2008/05/13-wsc-minutes.html#action04]
   [NEW] ACTION: anil to remove Conformance Labels section 3.2 [recorded
   in [109]http://www.w3.org/2008/05/13-wsc-minutes.html#action12]
   [NEW] ACTION: anil to remove relaxed path validation section and
   references [recorded in
   [110]http://www.w3.org/2008/05/13-wsc-minutes.html#action11]
   [NEW] ACTION: anil to remove the quoted section of 5.5.1, concerned
   with failed status revocation checks [recorded in
   [111]http://www.w3.org/2008/05/13-wsc-minutes.html#action17]
   [NEW] ACTION: anil to rephrase 5.1.6 as described [recorded in
   [112]http://www.w3.org/2008/05/13-wsc-minutes.html#action14]
   [NEW] ACTION: anil to take care of luis's email [recorded in
   [113]http://www.w3.org/2008/05/13-wsc-minutes.html#action01]
   [NEW] ACTION: anil to update 7.1.2 to contain the proposed text
   (superceding earlier changes) [recorded in
   [114]http://www.w3.org/2008/05/13-wsc-minutes.html#action07]
   [NEW] ACTION: anil to update 7.4.4 to use SHOULD instead of
   [MAY|SHOULD] [recorded in
   [115]http://www.w3.org/2008/05/13-wsc-minutes.html#action09]
   [NEW] ACTION: anil to update section 7.4.1 with the proposed text
   [recorded in
   [116]http://www.w3.org/2008/05/13-wsc-minutes.html#action08]
   [NEW] ACTION: luis to write up grammar/spelling edits for anil
   [recorded in
   [117]http://www.w3.org/2008/05/13-wsc-minutes.html#action02]
   [NEW] ACTION: Mez to draft plugin-related elaboration text (section
   4ish?) [recorded in
   [118]http://www.w3.org/2008/05/13-wsc-minutes.html#action03]
   [NEW] ACTION: tlr to draft alternate text around requiring saved SSL
   state [recorded in
   [119]http://www.w3.org/2008/05/13-wsc-minutes.html#action10]
   [NEW] ACTION: tlr to draft list of workgroups in response to ISSUE-74
   [recorded in
   [120]http://www.w3.org/2008/05/13-wsc-minutes.html#action13]
   [NEW] ACTION: tlr to Draft uncontroversial text to update section 3.1
   and insert it [recorded in
   [121]http://www.w3.org/2008/05/13-wsc-minutes.html#action18]
   [NEW] ACTION: tlr to take XHR-over-https questions to webapi [recorded
   in [122]http://www.w3.org/2008/05/13-wsc-minutes.html#action16]

   [End of minutes]
     __________________________________________________________________


    Minutes formatted by David Booth's [123]scribe.perl version 1.128
    ([124]CVS log)
    $Date: 2008/06/04 12:02:02 $

References

   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Member/member-wsc-wg/2008May/0004.html
   3. http://www.w3.org/2008/05/13-wsc-irc
   4. http://www.w3.org/2008/05/13-wsc-minutes.html#agenda
   5. http://www.w3.org/2008/05/13-wsc-minutes.html#item01
   6. http://www.w3.org/2008/05/13-wsc-minutes.html#item02
   7. http://www.w3.org/2008/05/13-wsc-minutes.html#item03
   8. http://www.w3.org/2008/05/13-wsc-minutes.html#item04
   9. http://www.w3.org/2008/05/13-wsc-minutes.html#item05
  10. http://www.w3.org/2008/05/13-wsc-minutes.html#item06
  11. http://www.w3.org/2008/05/13-wsc-minutes.html#item07
  12. http://www.w3.org/2008/05/13-wsc-minutes.html#item08
  13. http://www.w3.org/2008/05/13-wsc-minutes.html#item09
  14. http://www.w3.org/2008/05/13-wsc-minutes.html#item10
  15. http://www.w3.org/2008/05/13-wsc-minutes.html#item11
  16. http://www.w3.org/2008/05/13-wsc-minutes.html#item12
  17. http://www.w3.org/2008/05/13-wsc-minutes.html#ActionSummary
  18. http://www.w3.org/2006/WSC/track/issues/133
  19. http://www.w3.org/2008/05/13-wsc-minutes.html#action01
  20. http://www.w3.org/2008/05/13-wsc-minutes.html#action02
  21. http://www.w3.org/2006/WSC/track/issues/133
  22. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0035.html
  23. http://www.w3.org/2008/05/13-wsc-minutes.html#action03
  24. http://www.w3.org/2006/WSC/track/issues/134
  25. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Apr/0062.html
  26. http://www.w3.org/2006/WSC/track/issues/134
  27. http://www.w3.org/2008/05/13-wsc-minutes.html#action04
  28. http://www.w3.org/2006/WSC/track/issues/192
  29. http://www.w3.org/2008/05/13-wsc-minutes.html#action05
  30. http://www.w3.org/2008/05/13-wsc-minutes.html#action06
  31. http://www.w3.org/2006/WSC/track/issues/193
  32. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisible-goodpractice
  33. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisible-goodpractice
  34. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis-obscure-security-ui
  35. http://www.w3.org/2008/05/13-wsc-minutes.html#action07
  36. http://www.w3.org/2006/WSC/track/issues/194
  37. http://www.w3.org/2006/WSC/track/issues/194
  38. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-apis-obscure-security-ui
  39. http://www.w3.org/2008/05/13-wsc-minutes.html#action08
  40. http://www.w3.org/2006/WSC/track/issues/195
  41. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#popups
  42. http://www.w3.org/2008/05/13-wsc-minutes.html#action09
  43. http://www.w3.org/2006/WSC/track/issues/169
  44. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0026.html
  45. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
  46. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0026.html
  47. http://www.w3.org/2006/WSC/track/issues/188
  48. http://www.w3.org/2006/WSC/track/issues/133
  49. http://www.w3.org/2006/WSC/track/issues/169
  50. http://www.w3.org/2006/WSC/track/issues/169
  51. http://lists.w3.org/Archives/Public/public-wsc-wg/2008May/0026.html
  52. http://ettercap.sourceforge.net/
  53. http://www.w3.org/2006/WSC/track/issues/198
  54. http://www.w3.org/2006/WSC/wiki/RecommendationProposals
  55. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
  56. http://www.youtube.com/watch?v=Nnzw_i4YmKk
  57. http://www.w3.org/2006/WSC/wiki/RecommendationProposals
  58. http://www.w3.org/2006/WSC/track/issues/200
  59. http://www.w3.org/2006/WSC/wiki/RecommendationProposals
  60. http://www.w3.org/2008/05/13-wsc-minutes.html#action10
  61. http://www.w3.org/2006/WSC/track/issues/190
  62. http://www.w3.org/2006/WSC/track/issues/190
  63. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-pathval
  64. http://www.w3.org/2006/WSC/track/issues/190
  65. http://www.w3.org/2008/05/13-wsc-minutes.html#action11
  66. http://www.w3.org/2006/WSC/track/issues/181
  67. http://www.w3.org/2006/WSC/track/issues/196
  68. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#clabels
  69. http://www.w3.org/2008/05/13-wsc-minutes.html#action12
  70. http://www.w3.org/2006/WSC/track/issues/74
  71. http://www.w3.org/2006/WSC/track/issues/74
  72. http://www.w3.org/2006/WSC/track/issues/199
  73. http://www.w3.org/2006/WSC/track/issues/198
  74. http://www.w3.org/2006/WSC/track/issues/74
  75. http://www.w3.org/2006/WSC/Group/cheatsheet
  76. http://www.w3.org/2006/WSC/track/issues/74
  77. http://www.w3.org/2008/05/13-wsc-minutes.html#action13
  78. http://www.w3.org/2006/WSC/track/issues/75
  79. http://www.w3.org/2006/WSC/track/issues/75
  80. http://www.w3.org/2006/WSC/track/issues/185
  81. http://www.w3.org/2006/WSC/track/issues/196
  82. http://www.w3.org/2006/WSC/track/issues/169
  83. http://www.w3.org/2006/WSC/track/issues/197
  84. http://www.w3.org/2006/WSC/track/issues/198
  85. http://www.w3.org/2006/WSC/track/issues/197
  86. http://www.w3.org/2008/05/13-wsc-minutes.html#action14
  87. http://www.w3.org/2006/WSC/track/issues/198
  88. http://www.w3.org/2006/WSC/track/issues/198
  89. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-danger
  90. http://www.w3.org/2008/05/13-wsc-minutes.html#action15
  91. http://www.w3.org/2006/WSC/track/issues/199
  92. http://www.w3.org/2006/WSC/track/issues/200
  93. http://www.w3.org/2006/WSC/track/issues/201
  94. http://www.w3.org/2008/05/13-wsc-minutes.html#action16
  95. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors
  96. http://www.w3.org/2006/WSC/track/issues/199
  97. http://www.w3.org/2008/05/13-wsc-minutes.html#action17
  98. http://www.w3.org/2006/WSC/track/issues/202
  99. http://www.w3.org/2006/WSC/track/issues/202
 100. http://lists.w3.org/Archives/Public/public-webapi/2008May/0176.html
 101. http://www.w3.org/2008/05/13-wsc-minutes.html#action18
 102. http://www.w3.org/2006/WSC/track/issues/200
 103. http://www.w3.org/2006/WSC/track/issues/200
 104. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#def-validated-cert
 105. http://www.w3.org/2008/05/13-wsc-minutes.html#action06
 106. http://www.w3.org/2008/05/13-wsc-minutes.html#action05
 107. http://www.w3.org/2008/05/13-wsc-minutes.html#action15
 108. http://www.w3.org/2008/05/13-wsc-minutes.html#action04
 109. http://www.w3.org/2008/05/13-wsc-minutes.html#action12
 110. http://www.w3.org/2008/05/13-wsc-minutes.html#action11
 111. http://www.w3.org/2008/05/13-wsc-minutes.html#action17
 112. http://www.w3.org/2008/05/13-wsc-minutes.html#action14
 113. http://www.w3.org/2008/05/13-wsc-minutes.html#action01
 114. http://www.w3.org/2008/05/13-wsc-minutes.html#action07
 115. http://www.w3.org/2008/05/13-wsc-minutes.html#action09
 116. http://www.w3.org/2008/05/13-wsc-minutes.html#action08
 117. http://www.w3.org/2008/05/13-wsc-minutes.html#action02
 118. http://www.w3.org/2008/05/13-wsc-minutes.html#action03
 119. http://www.w3.org/2008/05/13-wsc-minutes.html#action10
 120. http://www.w3.org/2008/05/13-wsc-minutes.html#action13
 121. http://www.w3.org/2008/05/13-wsc-minutes.html#action18
 122. http://www.w3.org/2008/05/13-wsc-minutes.html#action16
 123. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
 124. http://dev.w3.org/cvsweb/2002/scribe/

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 6 June 2008 15:10:26 UTC