See also: IRC log
<ifette> ScribeNick: ifette
Mez: does a roll call
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?
<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?
<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?
<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
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?
<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].
<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?
<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
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].
<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 ...
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