Meeting record: WSC WG weekly 2007-11-21

Minutes from our meeting on 2007-11-21 have been approved and
are available online:

  http://www.w3.org/2007/11/21-wsc-minutes

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




   [1]W3C 

               Web Security Context Working Group Teleconference
                                  21 Nov 2007

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
          Maritza  Johnson;  Mary Ellen Zurko; Phill Hallam-Baker; Thomas
          Roessler;  Tim  Hahn; Anil Saldhana; Tyler Close; Dan Schutzer;
          Hal Lockhart; Ian Fette; Johnathan Nightingale; Jan Vidar Krey;
          Stephen Farrell; Yngve Pettersen

   Regrets
          Luis_B, Rachna_D

   Chair
          Mary Ellen Zurko

   Scribe
          Stephen Farrell

Contents

     * [4]Topics
         1. [5]Minutes from past meetings
         2. [6]completed actions
         3. [7]open actions
         4. [8]closed items
         5. [9]agenda bash
         6. [10]favicons (issue 109)
         7. [11]terminology wrt trusted certs
         8. [12]that site
         9. [13]tyler's teaser
     * [14]Summary of Action Items
     _________________________________________________________________



Minutes from past meetings

   <Mez>
   [15]http://www.w3.org/2007/11/05-wsc-minutes.htmlhttp://www.w3.org/200
   7/11/06-wsc-minutes.htmlhttp://www.w3.org/2007/11/14-wsc-minutes

   <Mez> [16]http://www.w3.org/2007/11/05-wsc-minutes.html

   <Mez> [17]http://www.w3.org/2007/11/06-wsc-minutes.html

   <Mez> [18]http://www.w3.org/2007/11/14-wsc-minutes

   minutes approved; jonathon was only present for one day of the F2F

completed actions

   yngve has been good

open actions

   december 9th due date for review of wsc-xit

closed items

   none but threatening noises

agenda bash

   swap favicons & certs in agenda & yngve/tyler if time

favicons (issue 109)

   <Mez> [19]http://www.w3.org/2006/WSC/track/issues/109

   <Mez>  Actual  implementation  work  currently  assumes  that favicons
   remain  in primary chrome, and might (e.g. for firefox) be used as the
   widget  that users interact with to raise an identity signal. The spec
   currently says that favicons are a positively bad idea.

   <Mez>  This  sounds  like we might have new information to consider on
   this  point,  or  at  least  need  to  understand  the reasons for the
   divergence.

   <ifette> yes

   phb: 2 issues; squelch favicons entirely and 2ndly should we recommend
   not to confuse with securiy signals

   <Zakim>   tyler,   you  wanted  to  point  out  that  favicons  aren't
   significantly more dangerous than hostnames, or HTML page titles

   tyler: be careful about more than just these (hostnames, etc.)

   tyler: doesn't see favicons as significantly different

   <johnath>   fwiw   -   I   believe   this   is   the  normative  text:
   [20]http://www.w3.org/TR/wsc-xit/#techniques-dontmix

   <johnath> afaik, that's the only normative text on the subject

   <tlr> johnath, it is

   phb: agrees with tyler, but proceeds to disagree
   ... images have more impact
   ... title bar similar but users more aware in that case
   ...  thinks  we  can  explain area around address/menu bar is "secure"
   other stuff isn't
   ... dislikes different status of address bar bits

   ian: 1st part ok, 2nd part (2ndary UI) not so good

   <Mez> [21]http://www.w3.org/TR/wsc-xit/#site-identifying

   ian: thinks users don't know as much as phb thinks they do
   ... leery about explaining title bar no-ok; address bar ok

   jonath: have some data; ask users they say content is what they heed

   <tlr> ifette, I don't think I got what precisely your concern with the
   second part is

   jonath:  implicit  assumption  is  that  favicon is in contention with
   other security icons
   ... rejects that - let's get away from 16x16 security indicators
   ... problem is singling out favicons doesn't make much sense

   <tlr> 8.1.2

   jonath: difficulties with conforming with normative text as-is
   ... agrees graphics help

   phb:
   ...  happy  to  conceed  favicon  on tab bar; can explain as title bar
   related

   <tlr> favicons may be displayed. However, they are ANDed with 0x00

   phb: wants to clearly distinguish favicon vs. security iconography
   ... wants to recommend security indicators to be bigger
   ... 32x32 for example
   ... EV uses more (sort of?)
   ...suggests:  rec=distinguished  security  experienced  that's hard to
   spoof

   dan: agree that fvicons are useful
   ... helpful to take a shot at: what are the favicons that we think are
   ok/important
   ... in chrome
   ... so people could get used to it
   ...suggests: a constructive rec, what should eb there

   <johnath> I know dan's not in IRC, but I disagree with that direction

   tlr: jonath said, general req ok specific technique not
   ... reminder some section nubers

   <Mez>  Web  User  Agents  MUST  NOT display material controlled by Web
   content  in  parts of the user interface that are intended or commonly
   used to communicate trust information to users.

   <johnath>   [22]http://www.w3.org/TR/wsc-xit/#requirement-dontmix   is
   what TLR is referencing

   tlr: ...suggests: security stuff MUST win when conflict

   <Mez> it's good that we're all looking at the same thing
   ...suggests: 8.1.3 2nd bullet

   <Mez>  Web  User  Agents  MUST NOT display favorite icons [FAVICON] in
   secondary user interface intended to enable users' trust decisions.
   ...suggests: idea is competing with security stuff again

   <johnath>  ACTION:  johnath to propose alternate text to section 8.1.2
   which  captures the need to prevent spoofing, without over-restricting
   [recorded in
   [23]http://www.w3.org/2007/11/21-wsc-minutes.html#action01]

   <trackbot-ng>  Created  ACTION-346 - Propose alternate text to section
   8.1.2   which   captures   the   need  to  prevent  spoofing,  without
   over-restricting [on Johnathan Nightingale - due 2007-11-28].

   <Mez> many thanks johnathan

   <Mez> reminder to link ISSUE-109 with ACTION-346

   ian: reserach has shown lock anywhere gets the same effect
   ...  if  we're  successful  in  chrome,  does that matter if locks are
   elsewhere too
   ... FF3 may be killing lock in chrome in any case
   ...worried:  don't  want  to  specify exceptions, 'cause don't want to
   kill potential innovation

   <Zakim>  johnath,  you wanted to say (in case it's not obsolete by the
   time  we get to me) that yes, language about spoofing prevention makes
   sense
   ...worried: prefers spec'ing things to not do

   jonath: ... phb wants security/chrome to win & that makes sense
   ...  in  this  doc,  should  not  allow  any content to subvert chrome
   messaging
   ... we're too focused, damaging document
   ...  w.r.t.  ian's  point vs. dan; agrees with ian - rec against dodgy
   stuff but don't try build list of ok things for chrome
   ... took action on 8.1.2/8.1.3

   <tlr> I wouldn't make that exhaustive list, but I'd like to understand
   better what the dodgy *characteristics* are

   jonath: FF3 is killing padlock in location bar (Still in status bar)

   phb: ... at the moment hard to give users messages on what they should
   do
   ... wants wsc to help there
   ... as (he says) EV does
   ... cleaning up security message is important for wsc
   ... question is: how to establish effective signals
   ... part of that: eliminate ambiguity where possible

   <yngve> [24]http://ssl.securesites.com/s13951/cart.pl

   yngve: example URL

   (scribe misses point)

   <hal> plus the dns starts with ssl

   scribe: has a key as favicon or some other bad thing

   <tlr> and there's "secure" in the domain name

   yngve: thinks there'll be big pushback on getting rid of favicvon
   ...  maybe  jonath/phb approach of changing security indicators to win
   is only option

   <Zakim>  ifette,  you  wanted  to  ask  if  we should postpone further
   conversation until we get some text as a result from johnath's action,
   as we're getting away from the concrete right now

   ian: proposes a punt

   phb:  whatever  we  do  has  to be educational & good enough that kids
   train parents
   ... left good/right bad isn't such a message

   mez: there's an action on this so it'll pop back again

   tlr:  thinks phb outlined a possible good paragraph about how to avoid
   the overlap
   ... does phb want to take a chinese whispers action

   phb: ok

   <tlr>   ACTION:  hallam-baker  to  propose  "chinese  whispers"  proof
   messaging for section 8.1 [recorded in
   [25]http://www.w3.org/2007/11/21-wsc-minutes.html#action03]

   <trackbot-ng>  Created ACTION-347 - Propose \"chinese whispers\" proof
   messaging for section 8.1 [on Phillip Hallam-Baker - due 2007-11-28].

   <Mez> [26]http://www.w3.org/2006/WSC/track/actions/284

terminology wrt trusted certs

   <Mez>
   [27]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0108.htm
   l

   tlr: current text includes some language about tls certs & situations
   ... defines "trusted" augmented etc.
   ... weak ground on trusted/secure

   (SF ditched out immediately:-)

   phb: picked up action from SF
   ... says "trusted" is a state & "trustworthy" is an adjective
   ... trusted/secure terms misued in similar ways

   <Mez> TRUSTED = Any certificate that is in the clients circle of trust
   for whatever reason

   <Mez>  TRUSTWORTHY = A certificate issued in accordance with practices
   that  reliably  establish  a  degree  of  Identity/accountability that
   sufficiently mitigates risk for a particular purpose. Examples include
   Augmented Assurance.

   phb: phb suggests text mez just copied in

   <Zakim>   ifette,   you  wanted  to  say  that  trusted  should  imply
   trustworthy, but not vice-versa

   phb: and trusted!=trustworthy

   ian: hard to comment without text
   ...  if  user has made decision about trusted, it should automatically
   be trustworthy
   ... so wants trusted=>trustworthy

   phb: the opposite

   <Mez> the wordsmithing seems to be about "trusted by what"

   phb: wants distinction for different types of CA

   <Mez> term for "trusted by user agent"

   <Mez> term for "trusted by AA authority"

   <ifette>  Phil, can you give an example of where in the text you would
   swap in this new "trustwrothy" terminology?

   <Mez> trusted by user agent != trusted by AA authority

   <tlr>  I think we can talk in terms of "denoted as trusted to the user
   agent", but can't talk about trustworthy.

   <tlr> Trustworthiness might come out in court.

   yngve: wonders whether or not other terms exist

   hal: trusted has history as a term

   <Mez> trusted == relied on

   <Mez> I don't always actually trust what I rely on....

   hal: client machine has to be trusted even if that's not ideal

   phb: agrees with hal about history
   ... need to be careful to use terminology accurately

   <tlr> "trusted" = "the thing that you have no reason to trust"

   phb:  wsc  doesn't  define trusted but refers to a decision to be made
   later
   ... whether or not trustworthy is a separate question
   ... wants less sloppiness

   <Mez> let's not re use terms that are confusing

   <tlr> -1 to trustworthy as well

   phb: main thing is to be v. clear about "trusted"

   <tlr>  ACTION:  stephen  to  propose  new  language  for 5.3.7 Trusted
   Certificates  and  surrounding  terminology  issues  -  due 2007-12-06
   [recorded in
   [28]http://www.w3.org/2007/11/21-wsc-minutes.html#action04]

   <trackbot-ng>  Created  ACTION-348  -  propose  new language for 5.3.7
   Trusted  Certificates  and  surrounding terminology issues [on Stephen
   Farrell - due 2007-12-06].

   <tlr> ISSUE-113

that site

   <yngve> [pointed out a flash-only site with mixed content]

   yngve: ...starts loading secure but then starts posting unsecure

   <Mez> is it covered here?
   [29]http://www.w3.org/TR/wsc-xit/#sec-change-level

   yngve: incl. subitting login info unsecurely from secure page
   ... might be covered by that URL

   <tlr> [30]http://www.w3.org/2006/WSC/track/actions/320

   <tlr> ISSUe-107

   <Zakim> Thomas, you wanted to note ACTION-320 is probably relevant

   tlr: observes that we discussed authoring BCP
   ... lead to action 320 due 20071130
   ... from austin f2f
   ... same for issue-107

   yngve: not sure if CC# sent (un)seecure

   mez: other notable things here?

   yngve: generates lots of warnings

   <tlr>  We define user agent to be broad enough that it would encompass
   flash.

   yngve: point is entire thing is flash

   phb: says don't show indicators on pages with/that-are flash

   tlr: early on we defined the UA, but didn't say anything wrt flash etc
   ... deliberately left broad
   ... maybe there's a question as to whether we should have additiona
   ... warning (in UA or text, dunno)
   ... how to react to a site that takes form data and ...

   (sribe didn't get tlr's point very well)

   phb: might be something to do here
   ... part of the problem is a page displaying mixed (in)secure content
   ... also when form loaded from secure but destination isn't
   ... also flash/object embedding could preserve security indicator

   <tlr> ... by constraining what the plugin can do

   phb: potential to tell flash about that but how?

   yngve: opera removes padlock when it sees unsecure submit
   ... doesn't happen in other browsers (some anyway)
   ...suggests: that if stuff arrives secure it should talk out secure

   tim: thinks usage modes recommendation might cover this

   mez:  doesn't  think we've an action that would cover UA running flash
   and how to handle security indicators

   yngve: has written on that

   mez: does that mean a proposal for the doc?

   <tlr> +

   mez: when you review, bring it up as an issue

   yngve: ok

   tlr: suggest action on yngve

   <tlr>   ACTION:   yngve   to   verify  that  normative  material  from
   WhatIsASecurePage  was  fully incorporated in wsc-xit - due 2007-12-09
   [recorded in
   [31]http://www.w3.org/2007/11/21-wsc-minutes.html#action05]

   <trackbot-ng> Created ACTION-349 - verify that normative material from
   WhatIsASecurePage   was   fully  incorporated  in  wsc-xit  [on  Yngve
   Pettersen - due 2007-12-09].

   yngve: has time due to ietf scheduling ineffiencies

tyler's teaser

   tyler:  has  taken a look at browser attacks that we might, but don't,
   address.
   ... attacks on the clipboard, web page can monitor cut'n'paste

   tyler: we could say if that's good/bad; tyler was surprised
   ...another: windows can overwrite href attribute for one another

   <tlr>  yngve,  apparently  if  you  make a selection, that causes some
   event. NY Times triggers ads if you select text.
   ...another:  web  site  with mainly iframe ; link from there; 2nd site
   can re-direct iframe (is that right?)
   ... with no change in chrome

   <Mez> another wow ick
   ...another: and this is in the wild
   ...  rules  for  this  aren't  spelled out from w3c, seems like a UI &
   security issue & hence wsc relevant

   <tlr> why aren't iframes not covered by the mixed content part?
   ...another:  another  example:  even  if  I  type  URL in address bar,
   previous site can navigate me back

   <Mez>  it  seems  to  be  more about robustness to me, to the extent I
   understand from the oral description
   ...another: and I might miss changes in chrome

   <tlr> I'm not sure I'm getting the last scenario

   <tlr> +1 to touching on this stuff

   +1 from SF to going there too

   tyler:  unsure  if this is in scope since it may end up with suggested
   changes to javascript apis

   <yngve>
   [32]http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-al
   l-ev

   <tjh> +1 that these seem relevant to our group.

   yngve: iframe stuff - has an article related to EV

   <Zakim> Thomas, you wanted to speak to javascript API part

   yngve:   problem  -  sites  with  an  EV  that  include  non-EV  stuff
   (images/frames etc.) can be similarly vulnerable

   tlr: 2 points
   ...1:  iframe  might  be  covered  in mixed-content but may need to be
   explicit
   ...2: APIs in/out of charter is an interesting point
   ...  suggests  we  think  about  what we'd like and then figure how it
   could be done
   ... could be via request to other WGs, we'll see (after consideration)
   ... would like to see these problems described in an email

   tyler:  similar  to  mixed-content  effects,  but  don't require mixed
   content for these attacks

   <tlr> my mixed content remark only referred to iframes

   <tlr> and I might be wrong

   mez: echoes tlr about other WGs

   tyler:  example,  normal  browser,  nothing odd, create a pop-up ; the
   pop-up can navigate
   ... the browser back to the bad guy

   mez: has tyler time to write up?

   tyler: might be a paper in the offing, should we wait
   ... submitted to oakland next few months

   mez: browser vendors would like info if poss

   chorus: in scope, actions might involve other bits of w3c

   tlr: have you tried across browsers?

   tyler: yep

   <tlr> document.onselectstart

   <Mez> oakland notification jan 25

   <Mez> [33]http://www.ieee-security.org/TC/SP2008/oakland08-cfp.html

   yngve: members list could be used if want to keep stuff close

   mez: time to go home kids

   <tlr> ACTION: tyler to report about browser security model discussions
   - due 2008-02-01 [recorded in
   [34]http://www.w3.org/2007/11/21-wsc-minutes.html#action06]

   <trackbot-ng> Created ACTION-350 - report about browser security model
   discussions [on Tyler Close - due 2008-02-01].

Summary of Action Items

   [NEW]   ACTION:  hallam-baker  to  propose  "chinese  whispers"  proof
   messaging for section 8.1 [recorded in
   [35]http://www.w3.org/2007/11/21-wsc-minutes.html#action03]
   [NEW] ACTION: johnath to propose alternate text to section 8.1.2 which
   captures  the  need  to  prevent  spoofing,  without  over-restricting
   [recorded in
   [36]http://www.w3.org/2007/11/21-wsc-minutes.html#action01]
   [NEW] ACTION: pbaker to propose "chinese whispers" proof messaging for
   section 8.1 [recorded in
   [37]http://www.w3.org/2007/11/21-wsc-minutes.html#action02]
   [NEW]  ACTION:  stephen  to  propose  new  language  for 5.3.7 Trusted
   Certificates  and  surrounding  terminology  issues  -  due 2007-12-06
   [recorded in
   [38]http://www.w3.org/2007/11/21-wsc-minutes.html#action04]
   [NEW] ACTION: tyler to report about browser security model discussions
   - due 2008-02-01 [recorded in
   [39]http://www.w3.org/2007/11/21-wsc-minutes.html#action06]
   [NEW]   ACTION:   yngve   to   verify  that  normative  material  from
   WhatIsASecurePage  was  fully incorporated in wsc-xit - due 2007-12-09
   [recorded in
   [40]http://www.w3.org/2007/11/21-wsc-minutes.html#action05]

   [End of minutes]
     _________________________________________________________________


    Minutes  formatted  by  David  Booth's [41]scribe.perl version 1.128
    ([42]CVS log)
    $Date: 2007/11/28 16:08:40 $

References

   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0095.html
   3. http://www.w3.org/2007/11/21-wsc-irc
   4. http://www.w3.org/2007/11/21-wsc-minutes.html#agenda
   5. http://www.w3.org/2007/11/21-wsc-minutes.html#item01
   6. http://www.w3.org/2007/11/21-wsc-minutes.html#item02
   7. http://www.w3.org/2007/11/21-wsc-minutes.html#item03
   8. http://www.w3.org/2007/11/21-wsc-minutes.html#item04
   9. http://www.w3.org/2007/11/21-wsc-minutes.html#item05
  10. http://www.w3.org/2007/11/21-wsc-minutes.html#item06
  11. http://www.w3.org/2007/11/21-wsc-minutes.html#item07
  12. http://www.w3.org/2007/11/21-wsc-minutes.html#item08
  13. http://www.w3.org/2007/11/21-wsc-minutes.html#item09
  14. http://www.w3.org/2007/11/21-wsc-minutes.html#ActionSummary
  15. http://www.w3.org/2007/11/05-wsc-minutes.htmlhttp://www.w3.org/2007/11/06-wsc-minutes.htmlhttp://www.w3.org/2007/11/14-wsc-minutes
  16. http://www.w3.org/2007/11/05-wsc-minutes.html
  17. http://www.w3.org/2007/11/06-wsc-minutes.html
  18. http://www.w3.org/2007/11/14-wsc-minutes
  19. http://www.w3.org/2006/WSC/track/issues/109
  20. http://www.w3.org/TR/wsc-xit/#techniques-dontmix
  21. http://www.w3.org/TR/wsc-xit/#site-identifying
  22. http://www.w3.org/TR/wsc-xit/#requirement-dontmix
  23. http://www.w3.org/2007/11/21-wsc-minutes.html#action01
  24. http://ssl.securesites.com/s13951/cart.pl
  25. http://www.w3.org/2007/11/21-wsc-minutes.html#action03
  26. http://www.w3.org/2006/WSC/track/actions/284
  27. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0108.html
  28. http://www.w3.org/2007/11/21-wsc-minutes.html#action04
  29. http://www.w3.org/TR/wsc-xit/#sec-change-level
  30. http://www.w3.org/2006/WSC/track/actions/320
  31. http://www.w3.org/2007/11/21-wsc-minutes.html#action05
  32. http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev
  33. http://www.ieee-security.org/TC/SP2008/oakland08-cfp.html
  34. http://www.w3.org/2007/11/21-wsc-minutes.html#action06
  35. http://www.w3.org/2007/11/21-wsc-minutes.html#action03
  36. http://www.w3.org/2007/11/21-wsc-minutes.html#action01
  37. http://www.w3.org/2007/11/21-wsc-minutes.html#action02
  38. http://www.w3.org/2007/11/21-wsc-minutes.html#action04
  39. http://www.w3.org/2007/11/21-wsc-minutes.html#action06
  40. http://www.w3.org/2007/11/21-wsc-minutes.html#action05
  41. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
  42. http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 28 November 2007 16:13:26 UTC