Web Security Context Working Group Teleconference
02 Jul 2008

 

 

<trackbot> Date: 02 July 2008

<Mez> we need a scribe

Yngve or Johnath or

possibly myself

<Mez> can't be johnath; he's the talent for the meeting

so Yngve or me, I guess

<johnath> Mez: my nemesis: http://www.calphalon.com/calphalon/consumer/products/productGroup.jhtml?catId=CLCat100485

<scribe> ScribeNick: tlr

Convene

all there

<Mez> http://www.w3.org/2008/06/25-wsc-minutes.html

so apporved

action items

nothing spectacular

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jun/0101.html

ACTION-478?

<trackbot> ACTION-478 -- Joe Steele to pull together UT background on 7.1.1 robustness recommendation (shared secret) -- due 2008-07-17 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2006/WSC/track/actions/478

mez: ACTION-478 looks like it lacks activity

joe: yeah, that's fine; I'll do it anyway

firefox 3.0 and conformance

johnath: Is it the plan as a group to undertake conformance testing for third party implementations?
... i.e., any interest in evaluating other browsers

tlr: careful, a bit, about conformance testing -- I'm not sure we're getting to a test suite that exercises all possible states
... and enables conformance claims just based on a test suite ...
... the more the merrier, but we probably need less to get through CR ...

johnath: so, plans to third-party test other implementations?

mez: nobody has broached that topic yet
... I have vague and scary plans ...
... and i'll call it "implementation testing" in the future ...

<johnath> alert! The scribe is taking liberties!

<johnath> http://www.w3.org/2006/WSC/wiki/Firefox_3.0_Conformance_with_June_LC

<johnath> section 6.4

johnath: seems like the best way is section by section
... 6.4.1 is tricky. We're kind of getting there, but it's a bit hard
... to make a clear assertion ...
... we don't do "solely in terms of art" ...
... do enable users to go back to prior state ...
... there''s always a back button ...
... not sure if there's subtlety implied
... think this is all fine with us ...
... error interactions should have advanced user option ...
... we're doing error codes for security errors ...
... so you can go and look them up in the big binder ....
... error code can be used to search for details, but we don't do separate interaction
... for things like network timeouts, we don't do the precise error codes ...

mez: error codes only for security?

johnath: not by policy, but that's what we done
... most of the other ones have distinctive titles ...
... but SEC_ERROR_SERIAL_NUMBER_REUSED ...

yngve: would like to mention that opera has sth similar
... more difficult to get to explanation
... for SSL errors, include TLS error code ...
... sometimes with additional information ...
... or flags ...
... useful to narrow down where the problematic code sits ...
... similarly, don't have these kinds of error codes on "can't connect to server" and the like ...

johnath: seems like Opera's and FF's approaches are same.
... might be worth clarifying language ...

mez: admit imagining that as we go through CR, we'll grapple with those issues
... don't mind grappling right away, though ...
... but not encouraging us to do this ...

johnath: 6.4.2 - status indicator is site identity button ...
... for some other stuff, non-modal indicators ...
... persist in primary chrome till interacted with ...
... think pop-up blocking ...
... check ...
... warning/caution ...
... quite a mouthful ...
... we don't say "caution" or "warning", but visual signals ...
... might not be conformant ...
... there's a MUST here that refers to words ...
... could be a point of non-conformance ...
... recommended option, we have ...
... often "try again"...
... for security, "get me out" - known safe page ..
... also "add exception" for an override ...
... not creating situation where only thing is to dismiss warning and move on
... noted before that "danger" is easier than "caution". Odd.
... creates weird situation where "danger" is easier to conform with than "warning"
... our security errors actually match this ...
... if cynical, would recast conformance in terms of "danger" ...

yngve: note that TLS has two levels of warning
... had possibility to open warning dialogues to ask whether continue or not for a long time ...
... recently changed to fatal error for everything ...
... except for some fatal cases ...
... warning or fatal in the protocol ...
... server could say it's a warning, it's not fatal ...
... there are some cases on that, could send warning about not having certificate ...
... in previous versions of SSL; TLS 1.0 changed that to sending empty cert ...
... warning about closing connection (not passing to user) ...
... anything that's warning is really an error and treated as fatal ...
... reason for going fatal is that choices aren't usefully possible for user

mez: odd that it falls out that way given concern about habituation
... maybe we need to take another look at this point ...

johnath: At any rate, 6.4.4 is really easier.
... 6.5, chrome reconfiguration
... yes, we have that ...
... except that there are add-ons ...

mez: add-ons, incredibly important

johnath: they can hook into "restore default" button

<joesteele> are the APIs those add-ons can use exposed to a webpage?

joe: These APIs.... exposed to web page?

johnath: no no no
... categorically, no ..

joe: install process?

johnath: exactly
... 7.1.1 - this sounds like security skins ...
... I needed to know background to understand it ...
... useful to say "e.g. security skins" ...

yngve: side remark - in some apps you can change user agent string in HTTP ...
...

mez: would like to have a bit of experience with this kind of context
... are we going to see this tested with Opera?
... don't think we've anything direct, except you can skin opera ...
... no connection to user agent string or stuff like that ...
... if we have implementation experience, details interesting
... without any, difficult ...

yngve: of two minds about whether to mention possibility
... sort of implied,

mez: not sure this is going to make it if nobody implements

<MikeM> yngve: that chameleon agent string feature causes problems for sites (like wellsfargo.com) that need to identify the browser for security & other reasons.

johnath: walking further through spec
... visibility of chrome ...
... yes
... tabbed browsing and site identity button ...
... next one, padlock and mimicking ...
... people could use padlock as favicon ...
... we don't use icons to signal trust info ...
... add-on installation
... disable ok buttons in installation ...
... multi-step ui for certificate exceptions ...
... no synthetic button clicks from content ...]

s/content...

s/content...]//

johnath: we do prevent web content from hiding certain buttons
... also, moving / resizing windows in ways that would cause them to be hidden...
... I'll claim that there's no way for content to override ...
... we do prevent window sizing and he like ...
... there's a bit in javascript, but not off the screen ...
... we don't allow web content to override security chrome ...
... re "overlay" - have titles in tab bar, don't overlay ...

johnath; software installation - request consent for add-on and plugin install

scribe: don't do installation of software ouside the browser ..
... pre-consent ...
... trivially conformant here ...
... only thing I can think of -- if web site just tries to install add-on, we block it ...
... you can chose to say that site is permitted to install add-on ...
... user interaction involved, not pre-consenting ...
... MAY on software install ...
... don't provide mechanisms for content to execute software
... in a direct fashion ..
... but hand off things to plugins or external handlers ...
... discussion of download manager ...
... some stuff that we don't do automatically ...
... 7.4.3 - no programmatic bookmarking ...
... don't do that, full stop ...
... second sentence here is weird, btw ..
... pop-up windows: do restrict ...
... permit pop-ups that *are* result of user interaction.
... we don't restrict them globally, though

johnath: most implementors will read this and understand what it's getting at
... there's some ambiguity, but not very serious ...

mez: think we've got raw material to see where we'll have challenges in CR
... we can now start looking at features at risk.

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

mez: I'd love feed-back, but be scared, it's work in progress

<yngve> Maybe 7.4.4 should be rephrased to "SHOULD be careful", "SHOULD control" opening of popups, or something similar, or as johnathan suggested saying restrict to only those initiated by user interaction

tyler: add columns for add-ons?

mez: hopefully!
... anything where we don't even have a single implementation, will give us pause

tyler: wait - two columns saying CI?

mez: I think this is going to be useful - any row that doesn't have two implementations, can't be required
... should seriously consider whether we want MAY with no implementation experience ...
... anything in a column that has "N" means we don't ahve single implementation that would even start claiming that it might be conforming ...

tyler: yngve -- does opera have an add-on API?

yngve; sorry, no

mez: think I'm clear on most things at this point, no double-checking
... that's it for this agenda item ...
... in terms of what's next -- should work on how to do testing ...
... unclear how to structure that discussion ...
... tlr - can you help?

tlr: I think anybody can go through implementation info for existing RECs
... maybe UAAG -- and btw, regrets for next week

mez: umh.... maybe take a week off?

joe: also regrets

tlr: as a thought, you might want to talk about the idea of content best practices

mez: number of topics
... to get us through July ..

yngve: btw, I'm on vacation most of August

mez: I had been warned that these things happen
... btw, appreciate some advance warning ...