See also: IRC log
<trackbot-ng> Date: 13 February 2008
<scribe> ScribeNick: johnath
<tlr_> apologies for minutes lateness re face-to-face
<jvkrey> yeah, me 2
<Mez> http://www.w3.org/2008/01/30-wsc-minutes
Mez: We're going on to approve minutes from last distributed meeting
<Mez> Regret+ Bill E
Mez: previous distributed
meeting, january 30th?
... approved
<tlr_> http://www.w3.org/2008/01/30-wsc-minutes.html
Mez: whole bunch from various editors, thank you all
tlr_: have we heard anything from
Serge about his actions taken at the face to face
... I am blocking on some of those
... I take the silence as a no
Mez: anything else on closed action items?
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0009.html
<tlr_> ACTION-370?
<trackbot-ng> ACTION-370 -- Bill Doyle to draft language to reference RFC 3766 or successors in a useful way -- due 2008-03-01 -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/actions/370
bill-d: question on
action-370
... want clarification on what we are trying to nail down,
can't really determine action
Mez: yes, we often lose context over time
<Mez> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/att-0011/wsc20080116.html
Mez: tlr thoughts?
tlr_: loading
... this is the convergence of the "what do we reference for
'strong' cryptography"
... so the action on Bill was to wrap language around this RFC
as being the reference of choice
bill-d: I looked into that and
the rfc named seems to be about VPNs
... I've sent something to the list, if that's the general
direction we want, I can work on the text
<Mez> http://www.w3.org/2006/WSC/track/issues/128
Mez: any other issues on other actions?
Mez: I basically threw in continuations from the face to face
Mez: my memory of sections we
didn't discuss are 7, 8.1, 8.2 and I was fuzzy on 9
... we had strong agreement that we needed a lo-fi prototype of
anything going into last call
... even if we have consensus that it is otherwise ready
... with the exception of robustness recs that would only
really have a "non-compliance" prototype
... I don't think we'll get to sec.9 today, but that's okay
because I think it's critical to have Rachna here for
that
... comments, changes?
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#ceremonies
Mez: I haven't had time to prep,
has anyone else on the call (particularly those who were at
F2F) opinions on sections to take to last call, from this
section
... my general intuition is that things in section 7 with
affinity to other sections, anything that relies on the input
editor, would be unprepared for last call
ifette: I still have huge concerns about adoption impact of this text
Mez: I think that would be based on what subset we choose to take to last call
ifette: Basically, I don't think any text here with "MUST" is ready for last call
Mez: much of the text was massaged during the f2f
<_tlr> I wonder what the scope of "here" is in ifette's statement
Mez: scrolling down, one thing
that catches my eye is "petnames"
... section 7.4
... I see overlap with identity signal there
yngve: question - are you
intending to have the entire section in the requirements
document
... the problem with that entire section is that it presumes
the safe form editor, it might stick out like a sore thumb to
include it
Mez: I hear you saying that you
don't think there's a subset there to extract
... but I think we still can
<stephenF> +1 to ian/ynvge concerns, but would like to see an edited verison of this before I decide
tyler: I can take an action to define out petname
<_tlr> johnath: question to tyler is... Plan to define petname so it can be extract?
<_tlr> tyler: i'll do it independent of the safe form editor
<_tlr> mez: that sounds useful
Mez: the next thing that came to
mind was 7.8 and 7.9 as having overlap with other
sections
... so somewhere in robustness, covered the customization
aspect
... I feel like the parts of 7.8 that overlap with robustness
are already taken care of
hal: are we using the wrong definition of picture in picture here? I thoguht it involved chrome being overlaid by web content
tyler: I think it involves content within the browser, chrome within chrome
Mez: is a contact button an existing thing in some subset of user agents?
tyler: new concept
Mez: right, I know we had some of that content in a prior discussion, but now I can't find it
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-tls-state
Mez: anyone remember where this
"remembering certificates" text was?
... I think we probably can
... I think we probably *can't* integrate 7.9 with that text,
though
tyler: In this case, you have an additional piece of information. The user has already told you that it trusts a particular cert chain
Mez: Right - might even want to consider that issue when extracting out petname text for your action
<scribe> ACTION: tyler to extract out petnames content, provide definition independent of section 7 [recorded in http://www.w3.org/2008/02/13-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-391 - Extract out petnames content, provide definition independent of section 7 [on Tyler Close - due 2008-02-20].
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#techniques-dontmix
<Mez> issue-109?
<trackbot-ng> ISSUE-109 -- Should there be recommendations against favicons? -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/109
ifette: 8.1.3 the first bullet
just seems very strange to me
... agents like Firefox 3 don't even have a lock in the
location bar any more, favicons are very useful to me
... I can't see this MUST NOT, even SHOULD NOT seems strong to
me
<stephenF> +1 to comment that this text is liable to be overtaken by new browser versions
johnath: I thought I proposed alt-text here?
<ifette> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html
Mez: ah, your text does include a proposal for 8.1.3
bill-d: I don't mind favicons, they just shouldn't be used in secure chrome
<Mez> > - Web User Agents MAY ignore favorite icon [FAVICON] references
<Mez> > that are part of Web content.
<Mez> > - Web User Agents SHOULD NOT use a 16x16 image in chrome to
<Mez> > indicate security status if doing so would allow the FAVICON to
<Mez> > mimic it.
<Zakim> ifette, you wanted to say that secure chrome in FF2 is not the same as secure chrome in FF3 and that we dont want to say the location bar will always be secure chrome
Mez: pasting text in channel for consideration
ifette: My problem with the
current wording is that it treats the location bar as secure
chrome, and that's a bad assumption
... I like johnathan's second proposed bullet - don't let the
favicon spoof your security indicator
<stephenF> +1 to jonath's 8.1.3 replacement
Mez: okay, so I think we have a proposal in play, I think that would be the text to consider for the LC document
tlr: I'll take an action to merge that text
<_tlr> ACTION: thomas to merge http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html [recorded in http://www.w3.org/2008/02/13-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-392 - Merge http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0005.html [on Thomas Roessler - due 2008-02-20].
Mez: sounds like that is text we
can take to last call in June, and our editors will put that
in
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-trustedpath
Mez: did we discuss this at the face to face
tlr: I think we discussed this on Feb 5
Mez: where did we get with it?
tlr: it was mentioned
Mez: yes, I added it to the agenda because it was touched but not resolved
<Mez> Web user agents that proactively present security context information to the user (or a channel presumed to eventually lead to the user, such as accessibility aides) MAY accept some presentation information from the user, and associate that information with parts of the user interface that are intended or commonly used to communicate trust information to users.
Mez: I believe the only normative
text is what I've pasted
... it's pretty weak
<Mez> In these user agents, the editor bar MUST be displayed using a theme customized to the user. The user selects this theme at browser installation time. Changes of this theme MUST involve a user interaction that is focused on this specific task. The icon for the Contacts button MUST also be selected by the user at installation time.
Mez: not nearly as strong as the text in 7.8
<stephenF> looks ok to me
Mez: in its current state, I
think we can take it to last call
... lobbies for something stronger?
... Alright, we're on track to take that to LC in June
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#authoringAndDeployment
Mez: did we do 9.1 in the f2f
<Mez> This specification requires that web pages MUST NOT include trust indicating images such as padlocks in the web content.
tyler: we did not
<stephenF> what if I sell (physical) padlocks?
<jvkrey> or images of padlocks?
<tlr> http://www.flickr.com/search/?q=padlock&w=all
<tlr> (was the objection at the face-to-face)
yngve: a bit more background text
might be a good idea
... with extra text, it could be in LC
Mez: what kind of background text are you talking about?
<_tlr> I think the headline is better than the full text -- it's not about "use trust indicator like images", but rather about "don't use them to engineer trust"
<stephenF> +1 to tlr
bill-d: I think of padlocks and favicons - people are going to do whatever they want with them. If we have an area reserved for secure chrome, then I don't think we care about restricting content outside of that
tlr: Having been the one who
raised the objection, I think the intent is a good one - don't
use these kinds of images to engineer trust
... "don't use trust indicators in content, don't teach them to
look in content instead of chrome for trust indication"
<stephenF> other than help text on web pages?
<tlr> right
<yngve> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/0002.html
<Mez> This specification requires that web pages MUST NOT include trust indicators from existing user agent chrome in the web content as an indication of web content trust.
tlr: I think that's what we mean,
I think we can get there without difficulty
... that text looks good, maybe with more background text
Mez: what background text
<Zakim> stephenF, you wanted to ask if that MUST NOT is testable or not
tlr: call out the education implication, explain the consequence
<scribe> ACTION: tlr to draft replacement text for section 9.1 (trust indicators in content) [recorded in http://www.w3.org/2008/02/13-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-393 - Draft replacement text for section 9.1 (trust indicators in content) [on Thomas Roessler - due 2008-02-20].
<Mez> web pages MUST NOT include trust indicators from existing user agent chrome in the web content as an indication of web content trust.
stephenF: does this rule need to be testable? Is it currently?
<stephenF> audio is bad
<stephenF> +1 to it being testable, but hard here when we're talking about content
Mez: does anyone think things *shouldn't* be testable
yngve: it may be a question of what testable means
Mez: yes, you're right, but
certainly lack of compliance is something a person can point
to
... even if it can't be automated
<stephenF> what if UA picks a new icon that some site was using for N years before?
<yngve> http://lists.w3.org/Archives/Member/member-wsc-wg/2008Jan/att-0002/unsecure_europcar.PNG
yngve: I linked to a screenshot
that I sent to the list a month ago
... this site is an example of what we're trying to prevent
Mez: yes, this is an example of the problem
yngve: they've since changed the site around
bill-d: I have another example
<bill-d> http://www.chase.com/
bill-d: the practice is widespread
<stephenF> and credentials in clear is more easily testable
Mez: okay, I think we've got some
examples. This is a challenging notion to test, no doubt
... it's not clear to me how we'll argue that the rule applies
to particular things
<yngve> http://my.opera.com/yngve/blog/show.dml/281609
<Zakim> johnath, you wanted to ask if Larry is a trust indicator
johnath: Larry is a trust indicator, but so are things like VeriSign siteseals, or "HackerSafe" certification. Do we intend to ban those? We should be explicit
yngve: wanted to point out that
Larry (passport icon in Firefox 3) could be a trust
indicator
... also some of those badges are hosted on http
Mez: we're not concerned here with whether the site is "actually" secure, so hosting of the content is beside the point - we are talking about content co-opting trust indicators
hal: I don't think we have to spend time on direct copying of copyright content, since that's already against the law
Mez: so far I'm not hearing a request to drop this from last call, just discussion
ifette: what precisely is the text we're talking about
Mez: there's only one line of normative text there
johnath: isn't thomas rewriting it
<hal> web pages MUST NOT include trust indicators from existing user agent chrome in the web content as an indication of web content trust.
Mez: no, that's just background
tlr: background and possibly editorial stuff
Mez: sounds like this can go to last call, though I am concerned about how we'll establish pass/fail here
An unsecure web page MUST NOT embed a form meant for the user to login. All login pages MUST be served from secure servers ie. login pages must be TLS protected. An unsecure page MAY carry a link for the user to click to be taken to a secure page to enter login information. This link MUST NOT carry a padlock along with it.
tyler: we did a version of 9.2 at the face to face
<stephenF> did new variation of 9.2 mention javascript?
Mez: we did the redirect stuff, right?
tyler: we didn't come to a conclusion
<stephenF> ok, I'll ask later
<stephenF> also on this, the 2nd sentence should say user again (to leave out server-server logins)
<stephenF> fine by me
stephenF: Want to know if the login form being described can include javascript that logs in
Mez: so back to 9.4, redirects
Web Sites that require their users to be redirected from an unsecure web page to a secure web page MUST do it as a single step rather than multi-step (redirect to an unsecure page and then redirect again to a secure page). This specification recommends that the web page MUST use direct links to a secure page rather than using redirects.
<Mez> issue-163?
<trackbot-ng> ISSUE-163 -- Make (sure) 9.4 is internally consistent -- OPEN
<trackbot-ng> http://www.w3.org/2006/WSC/track/issues/163
<stephenF> why dislike multiple re-directs?
ifette: I'm a little bit concerned that this might be too strict
<_tlr> the concern is redirect chains from https through http back to https
<tjh> does this impede something like WS-Federation passive?
<stephenF> that was me I guess
<stephenF> no I'm ok that was before
ifette: I understand that we don't want people bouncing from a to b to c, but if there are several http redirects on the same site before landing on https
tyler: I think the concern was that for UIs for EV certs, there is an implied continuity of secure connection, and that's not the case if there are http steps
<stephenF> +1 to ian's question, same one I wondered about
ifette: 9.4 to me sounds like it
deals with people starting on something insecure, ending on
something secure, and how to handle the redirects in that
process
... I think we agree on the continuity of an already-secure
connection
yngve: The concern is heightened attack surface
<stephenF> "attack surface" arugment seems too vague to justify a MUST
yngve: for instance at bank of america when you click a login button
<stephenF> tinyurl
ifette: nothing here is about login buttons, it's just about redirect-on-load from insecure to secure
stephenF++
ifette: bouncing around in one domain doesn't seem substantially less safe
yngve: we hardcoded our security indicators to only allow one redirect
<Zakim> johnath, you wanted to surface stephen's point
<Mez> yngve's point seems to be that the redirects make it most difficult for the browser developer to get the security indicator right
<stephenF> would a MUST rule out OpenID+Yadis? (not sure, probably not HTTP re-directs)
<Mez> Web Sites that require their users to be redirected from an unsecure web page to a secure web page SHOULD do it as a single step rather than multi-step (e.g. redirect to an unsecure page and then redirect again to a secure page). This specification recommends that the web page SHOULD use direct links to a secure page rather than using redirects.
johnath: I think the content authors that declare themselves compliant are a pretty keen bunch, and would be fine with MUST, but I'm happy to change to SHOULD if that means we move along - I think the important point is to provide guidance to those designers that multiple bounces is a bad practice
<stephenF> if we say "SHOULD" there then it'd be nice to give an example where its reasonable to not adhere (e.g. tinyurl)
tyler: I think the content
authors will look to this spec to clarify the expectations of
browser developers
... so if SHOULD deviates from, say, Opera's expectations, we
violate that assumption
Mez: does anyone object to SHOULD
yngve: I can survive it
Mez: yngve, are you proposing alternate text?
<Zakim> ifette, you wanted to ask yngve a question
Mez: I assume from silence that we'll leave it SHOULD for now
ifette: just to be clear on something yngve said earlier. If I go http->http->https, I don't get a padlock in opera?
yngve: that's correct
Mez: we have 12 minutes left
<yngve> Perhaps add "Websites SHOULD consider that some clients may use stricter determinations of security in non-TLS protected redirects that terminate at a TLS-protected site
<Mez> Web content SHOULD be designed to enable the a consistent security user experience across different user agents and devices. Web site owners SHOULD perform tests of the TLS security and trust features of their site on various devices.
<Mez> Web site owners operating TLS-protected sites should anticipate the use of those sites from mobile devices which may have constrained capabilities e.g. diverging sets of trust anchors or limited cryptographic mechanisms.
Mez: I don't see any issues
against it in the current text
... I'm going to suggest this is LC-ready
<stephenF> 9.5 2nd sentence: is that a new sort of requirement...
<tyler> "the a "
<stephenF> ...asking owner (and not developer) to do stuff?
<stephenF> (but I'm ok with the text)
<_tlr> ACTION: thomas to fix grammar error in 9.5 [recorded in http://www.w3.org/2008/02/13-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-394 - Fix grammar error in 9.5 [on Thomas Roessler - due 2008-02-20].
johnath: this seems like straightforward best practices text to me
tyler: grammar error noted in IRC
yngve: I wrote something recently (to the list?) that might be relevant
Mez: not hearing any objections
<Mez> Web content SHOULD be designed to enable the a consistent security user experience across different user agents and devices. Web site owners SHOULD perform tests of the TLS security and trust features of their site on various devices.
<Mez> Web site owners operating TLS-protected sites should anticipate the use of those sites from mobile devices which may have constrained capabilities e.g. diverging sets of trust anchors or limited cryptographic mechanisms.
<Mez> Audio logotypes embedded with certificates should be designed to minimize possible listener confusion and the time that their rendering takes. Specifically, audio logotypes SHOULD NOT include spoken text. Audio logotypes MAY include short musical phrases.
<stephenF> seems fine to me
Mez: I feel like the state of the
text is pretty good, done in conjunction with the accessibility
group
... going once, going twice
<stephenF> that'd be ok with "SHOULD NOT" since they've a reason to do it
ifette: if somebody's audio-jingle has their company name it, does that create a problem?
Mez: for answers on that, we'd have to coordinate with the accessibility folks
hal: does the spoken text include singing?
Mez: take it to the public email list and we'll get their expertise in
<stephenF> syggest adding: stephenF MUST NOT sing in audio logotypes
tjh: As I read the text, it occurred to me whether we should be synchronizing visual and audio cues, if both are present
Mez: I think it's worth drafting something, and we probably won't finish it in the 3 minutes remaining
<scribe> ACTION: tjh to draft elaborated text to section 9.6 re: synchronization of cues [recorded in http://www.w3.org/2008/02/13-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-395 - Draft elaborated text to section 9.6 re: synchronization of cues [on Tim Hahn - due 2008-02-20].
Mez: that's it
