Web Security Context Working Group Teleconference
21 Nov 2007

 

 

Minutes from past meetings

<Mez> 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

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

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

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

terminology wrt trusted certs

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Oct/0108.html

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 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? 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> 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 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> http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-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> 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 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].