W3C

WSC WG face to face

13 May 2008

Agenda

See also: 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


<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> 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 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 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> http://www.w3.org/2006/WSC/track/issues/133

Mez: Joe has been toiling on this issue

<Mez> 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 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> http://www.w3.org/2006/WSC/track/issues/134

<Mez> 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> 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 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> 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 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 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> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisible-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: http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisible-goodpractice

<tlr> not: 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 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> http://www.w3.org/2006/WSC/track/issues/194

ISSUE-194?

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

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

Mez: I am proposing that we change SHOULDs to MUST

section 7.4.1

<Mez> 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 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> http://www.w3.org/2006/WSC/track/issues/195

<Mez> 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 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> http://www.w3.org/2006/WSC/track/issues/169

<Mez> 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> 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> 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> 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> 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> 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> http://www.w3.org/2006/WSC/track/issues/169

<johnath> re-dialing in

<Mez> 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> 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> http://www.w3.org/2006/WSC/track/issues/198

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

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

Mez: here are 3 proposals

<ifette> +1 johnath

<johnath> 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> http://www.youtube.com/watch?v=Nnzw_i4YmKk

<Mez> B) Johnathan's text

<Mez> C) Thomas' text

<Mez> D) abstain

<Mez> 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> http://www.w3.org/2006/WSC/track/issues/200

Mez: tlr, please type in your strawpoll

<Mez> total straw poll

<Mez> 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 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> http://www.w3.org/2006/WSC/track/issues/190

<Mez> issue-190?

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

<trackbot-ng> 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> 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> 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 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> 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> http://www.w3.org/2006/WSC/track/issues/196

Mez: ok, next issue

<johnath> 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 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> 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> 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> 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> 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> http://www.w3.org/2006/WSC/track/issues/74

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

<tlr> ISSUE-74?

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

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

<johnath> ACTION: tlr to draft list of workgroups in response to ISSUE-74 [recorded in 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> 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> 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> 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> 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> http://www.w3.org/2006/WSC/track/issues/169

<ifette> ISSUE-197

<ifette> ISSUE-197?

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

<trackbot-ng> 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> 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> 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 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> 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> 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> 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 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> 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> http://www.w3.org/2006/WSC/track/issues/200

<ifette> ISSUE-201?

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

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

<johnath> ACTION: tlr to take XHR-over-https questions to webapi [recorded in 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, 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> 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 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> 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> http://www.w3.org/2006/WSC/track/issues/202

<tlr> http://lists.w3.org/Archives/Public/public-webapi/2008May/0176.html

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 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> 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> 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> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#def-validated-cert

<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 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 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 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 http://www.w3.org/2008/05/13-wsc-minutes.html#action04]
[NEW] ACTION: anil to remove Conformance Labels section 3.2 [recorded in http://www.w3.org/2008/05/13-wsc-minutes.html#action12]
[NEW] ACTION: anil to remove relaxed path validation section and references [recorded in 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 http://www.w3.org/2008/05/13-wsc-minutes.html#action17]
[NEW] ACTION: anil to rephrase 5.1.6 as described [recorded in http://www.w3.org/2008/05/13-wsc-minutes.html#action14]
[NEW] ACTION: anil to take care of luis's email [recorded in 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 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 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 http://www.w3.org/2008/05/13-wsc-minutes.html#action08]
[NEW] ACTION: luis to write up grammar/spelling edits for anil [recorded in http://www.w3.org/2008/05/13-wsc-minutes.html#action02]
[NEW] ACTION: Mez to draft plugin-related elaboration text (section 4ish?) [recorded in 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 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 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 http://www.w3.org/2008/05/13-wsc-minutes.html#action18]
[NEW] ACTION: tlr to take XHR-over-https questions to webapi [recorded in http://www.w3.org/2008/05/13-wsc-minutes.html#action16]
 
[End of minutes]

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