W3C

Web Security Context Working Group Teleconference

15 Aug 2007

Agenda

See also: IRC log

Attendees

Present
Ian Fette, Mary Ellen Zurko, Thomas Roessler, Tyler Close, Jan Vidar Krey, Hal Lockhart, Anil Saldhana, Chuck Wade, Tim Hahn, Audian Paxson, Rachna Dhamija
Regrets
Johnathan Nightingale, Shawn Duffy, Bill Doyle, Chuck Wade(probable), Audian (will come late)
Chair
Mez
Scribe
Ian Fette

Contents


<trackbot-ng> Date: 15 August 2007

Pick a scribe

<tlr> Scribe: Ian Fette

<scribe> ScribeNick: ifette

Approve minutes from last meeting

mez: Did not see any issues raised when minutes sent out
... approved

<tlr> http://www.w3.org/2007/07/08-wsc-minutes.html

Newly completed action items

mez: Thank mez, serge, thomas, mike, et al for completing action items this week
... more completed, havent closed yet, will be in next one
... did not hear of any issues

Action items closed due to inactivity

mez: do anything about the action items closed due to inactivity?

<tlr> no objection from me, as I think both have actually simply been overtaken by events

Agenda bashing

mez: Thomas sent an update, thank and approve
... item on agenda is conformance language items on rec track, today is page info summary part
... other item is to talk about what will be discussed next week
... any bashing from anyone?

tlr: A quick note about link: way HTML was created, random number looking IDs being used, change every time document is regenerated, not stable IDs.
... if you need a stable ID, email tlr and he will take care of it

tyler: wouldn't mind having meta discussion about proposal in general before diving in to conformance language

mez: Found out late that Jonathan wouldn't be here

Meta-discussion about whether page info summary is a goal or non-goal

tyler: When users making decisions, don't consult secondary dialogs etc
... info presented there doesn't effect user decisions, is a non goal for this WG
... in sec 3.1 of note, call out presentation of all security info is not a goal for this WG
... don't think this WG needs to or should standardize

mez: in terms of goals / non goals aspect

<Zakim> Chuck, you wanted to present an alternative point of view to Tyler's

mez: non goals might come out of the work but won't expend collective resources in tackling them, in line with deprioritizing compared to other items

chuck: Make the point that there is a self defeating cycle to this argument
... the info that gets presented is geeky to the extreme, hard to follow, inconsistent etc., therefore not important throw it out
... troubled by argument, deja-vu
... related is that we will never get an approach working for all users. Only small subset of users will investigate
... those who do are important to overall ecosystem, track problems, identify bogus sites etc

<tjh> yes Mez

chuck: if we don't achieve improvement, we are undermining ability to have collective community observing, even if those paying attention are small subset. Room for improvement, hate to give up on it

mez: in response to Chuck, mez personally agrees about support ecosystem that needs secondary info, attempted to argue several times, not much support for that point of view at time mez argued
... second, since we said non-goals could fall out, makes sense to mez for something to be part of our rec
... if we agreed something was non-goal, it would be silly to have meeting entirely around it unless it was optional meeting

tyler: hears what Chuck is saying, emphasize points that it's a feature we expect to be used by very few (awfully small) number
... even he rarely consults info summary
... emphasize it is a non-goal, if slipping schedule, working on non-goals not best use of time, work on things that are clearly our goals first

<Zakim> Chuck, you wanted to make some other on-topic points

Chuck: has trepidation, doesnt want misinterpretation
... process has largely been driven by browser developers
... concerned that people who have provided a UI... understand business cases etc, but... constant failure to include adequate info or ability to get at adequate info about authentication details relating to websites
... because browser community has across board not delivered capability, we're in a circle of people outside of community saying "if useful, we'd use it", people within circle saying "but nobody uses it"
... would like to say that we really need for anyone to be able to access this info in a rational way,
... including new info, not only cert, but was OCSP used etc
... doesn't care how small the population who would use it is, still contend that it's valuable
... enough people to inform larger community, do not lose sight of need to equip those few with tools they need
... also mechanisms to report problem

tlr: hears one person saying non-goal, others saying is a goal
... also have an agenda that has this topic, presumably people have read material we have
... propose to move ahead and start talking about it
... otherwise risk we waste entire call discussing whether to discuss, propose to move on

<Chuck> I think that what we've discussing is a proposal to drop this "non-goal"

mez: don't close discussion without followup

tyler: more than just remaining hour of the call, will consume more than the next hour
... if we decided to drop from rec proposal, significant time saving for WG
... for chuck, dispute notion that current browsers don't provide enough info for experts
... if we're talking about small subset of experts, can make due with status quo. he can.

mez: might be overestimating kind of person who calls help desk
... her proposal: not same as tlr's, in fact, not hearing anyone argue with process point tyler raised
... given current note, not finalized yet but close, in fact, page info is a non goal so we should not spend concentrated time on it when we have many other things to do
... if everyone agrees, we should record that, falls under non-goal, but since nothing else queued up today, make as much progress as we can today, and then it takes its place w.r.t. team resources as a non goal, see what happens

tlr: not disagreeing, looking at note, we say as a non-goal presentation of all security
... what was meant is that we will not suggest or standardize the presentation for all conceivable security information
... conclusion: any presentation in secondary chrome is outside of our goals. That is far from obvious, leaning towards saying the note and the dicussions earlier don't decide whether this specific proposal is a goal/non-goal, It's within our scope, to extent note doesn't answer whether or not to prioritize, will see answered by amount of energy people putting in to it
... current proposal: entertain the proposal named page info summary, go through it on this call, see level of energy and see what happens
... goal/non-goal not obvious, inclined to say it is a goal meriting time
... suprised the argument comes up now

mez: hearing different opinions
... inclination on meta discussion would be

<tyler> sounds like we need a straw poll once more of us are present

mez: if tyler or someone wanted to clarify whether secondary info is a non-goal, which has some possibility, we should either do it in email or as agenda item
... tyler, want action item?

tyler: no, take straw poll when we have more participants

mez: went through her mind as well, with lack of discussion etc

tyler: moz people not here

mez: are you suggesting agenda for next time?

tyler: y

mez: ok next

Rec track document conformance language discussion, Sec. 5 of rec track draft, Page Info Summary

<tlr> Since I said I'd shut up on the meta discussion, this is on IRC only: There are other things concerning secondary UI that we are talking about. I don't think we want to imply that all of that is out of scope; I would certainly argue against it, and strongly so.

<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary

mez: starts to read intro for section
... first task seems understandable

tjh: page info or identity information, doesn't give impression that it's info about stuff coming at me from security perspective
... page info is about stuff coming at me, privacy / identity about info going elsewhere
... suggest that conformance language be softened, appropriate name, suggestive of that this is info about stuff coming at me and source

mez: security context info to end user, current context information

tjh: right

<Chuck> The place where "direction" of information flow gets mixed up is that some pages request information from users, while others do not.

mez: should be accessible from primary chrome
... must include relevant site identity information including domain name, owner name etc

<Chuck> There is also the potential for hidden fields that might be autofilled without the user's direct knowledge.

tlr: first remark is clearly domain name of high level, "web page" in sense of definition in document
... text vague about owner, verifying authority's name, useful to say useful info in org. attribute of subject field of entity certificate if trusted CA...
... by the way, should be information about trust root as opposed to issuer
... can have long chain of CAs
... refinement to be done around owner name etc
... take point from identity signal discussion

chuck: wanted to pick up on point timothy was making
... good point, section mixes up direction of information flow. emphasize that one piece of info that could be presented is, "does this page ask for information?" have form fields etc
... can see messy page and have no idea if page is asking for info or not
... uses a browser that provides signaling every time a page has forms on it, suprised how many times he runs across hidden form fields etc
... think info is usable context etc

<Zakim> Thomas, you wanted to note that that can't be easily answered

tlr: problem is that cannot conclude from absence of forms, that no data is being sent to the page / that no info will be submitted
... particularly when JS is present
... undecidable what particular piece of JS code does
... halting problem, don't know what is injected etc
... need declaritive way, pages constrain what they can do etc
... not possible in current environment to say what info a site will submit
... only way to know is abence of JS, CSS AND forms, small fraction of pages out there

mez: relevant history context information
... mez reads bullets from 5.2

<Chuck> I vote for banning all javascript. ;-)

<Audian> funny (banning all js)

tlr: think there is info listed uner MAY that fundamentally belongs under MUST
... what info at a minimum needs to be communicated to people
... what needs to go under MUST is a possibility to drill down into cert. validity, w.r.t TLS and error handling we will discuss a proposal that makes some of the validity notions more complex than they are now
... that needs a secondary UI backdrop that gives expert users opportunity to see what is going on
... anything about cert validity MUST be made available
... mixed content is important, may turn into why am i not seeing any positive indicators
... suggest host name resolution source is either out of document
... lower layer info
... may have caching resolver etc
... localhost depends on how your machine is maintained
... info there lends itself to problems
... wants to drop dns related part, promote TLS related parts
... needs to be available to users
... entire section re-written not in terms of specific widget but in terms of info that must be available to users
... guidance w.r.t. cert info: what to display and when

chuck: agrees w.r.t. DNS issues
... good goal, maybe not practical

<tlr> The DNS issue is essentially orthogonal to the security achieved.

chuck: raise point: lots of good issues, important question not appearing here though: what elements are required to render a page?
... what plugins, for instance
... does use flash, real media, etc?
... image decoder?
... that info is relevant
... version number of plugins etc
... flash has a mechanism to get version info
... also issue about cookies - useful to know about, but what kind of cookies?

<tlr> yep, precisely

chuck: some state info maintained outside of browser
... need more structure

<Zakim> ifette, you wanted to talk about cookies

<tlr> ifette: just wanted to say that, even with Cookies, not entirely clear which are harmful and which are benign ...

<tlr> ... even if long-lived ...

<Zakim> Thomas, you wanted to note that "no cookies" at this point is no guarantee for anything

ifette: hard to figure out whether cookie is benign

tlr: many mechanisms to keep state on client - js code with cache control headers etc
... many ways to keep state, keep careful not to recommend anything that just says "tells user no state kept if there are no cookies" b/c that conclusion doesn't hold
... cookie might actually be more privacy friendly when just have a bit of preference info, store on client rather than giving a unique id to client etc
... nontrivial issue

<Chuck> Agree with comments on cookies, and cookie-like objects. This also gets to the issue that a page display may also be surreptitiously moving information about the user from one site to subsequent sites the user visits.

mez: walked through conformance language, lots of points raised, inclined to run straw polls, see where we are on key points

<tlr> chuck, indeed. You know the a:visited info leak in CSS?

mez: first item: something about spirit of first line
... first one is deconstructed in terms of details
... emphasis on single widget (e.g. part)
... second half phrased to talk about how this is security context info available to user
... seems to mez that first half encapsulates spirit of section
... phrased "user agents must provide a user-accessible information source"
... wants round of straw polls, whether people think that having a MUST line on conformance language for this kind of information is good / live with

tlr: doesn't understand question

mez: Question is: having conformance language around user agents MUST provide user accessible information source around security context information, which is what first line seems to be about

tlr: alternative is...?

mez: dont know, straw poll

tlr: asking b/c his answer for one depends on alternative

mez: nobody has put forth alternative

tlr: are we talking MUST/SHOULD/MAY, talking "somehow available", "must be avail in secondary chrome", "should be avail in pri. chrome"

<Chuck> My input: We "MUST" improve the information available to users about the site and page security context. The devil is, unfortunately, in the details.

mez: must/should/may secondary chrome

tlr: pref would be MUST be provided in some way

<Chuck> Unfortunately, I have to sign off, as I've got another meeting.

tlr: proposal for section would be to turn it into a ranked list of security context info
... some info MUST be presented, some SHOULD, some MAY
... goes away from prescribing particular widget style

mez: wants check-in with group here

tlr: question: should section stay in current mode (widget), or turned into a set of sec. context info that MUST/SHOULD/MAY be avail to user, without saying whether primary or secondary chrome
... set of alternatives that would help tlr in editing this part

mez: is confused

<jvkrey> +1

+1 tlr

tjh: preference is that we have language that says "info MUST be provided", can't dictate widgets, exactly how provided etc
... can dictate one click away
... user agents that don't have 1024x768
... trepidation for one click
... primary/secondary OK

<tlr> w3.org/2006/WSC/drafts/rec/rewrite.html#def-primary-chrome

<tlr> w3.org/2006/WSC/drafts/rec/rewrite.html#def-secondary-chrome

ifette: comments about reduced chrome mode

tlr: would have question to tim - did he hear tim say that he would not want a list of prioritized things, but would rather just say "there should be some standard drill down possible, leave it at that"?

tjh: must be a way to get at this detail
... if we could agree on prioritized list, set that would be available, would be OK with conf. language about M/S/M in that prioritized list

rachna: do browsers today that make cert dialogs avail, would that comply?

mez: perhaps not

tlr: one of ways to approach, look at dialog, what's wrong with it? one of wrongness is confusion re: encryption, authentication, lack of info re: cert status checks, lack of user friendliness
... drill down into more detail

tjh: respond to rachna
... would cert dialogs conform?

<tlr> understanding "cert dialogue" as the doubleclick on a padlock

tjh: thought of popup dialog boxes indicating problems as opposed to double click on padlock
... former would not be conformant

rachna: meant the latter

tjh: would consider that as part of what this is trying to convey

rachna: seems like that info + history + creds is what we have listed

<Mez> User agents MUST provide security context information through one ore mor user-accessible information sources

mez: rewrote first line
... with typo or two
... is it the case that that form of conformance language is in fact obvious?
... not sure it's obvious

tjh: in reading that watered down version, seems that every UA he knows of would conform

mez: trying to work through it, follow up with number of statements about where and what

tjh: opinion is that if we're trying to narrow in, watered down isn't enough

mez: keep hearing about mobile challenges

ifette: possibly, mobile is important

jvkrey: most are compliant, not quite as you would see on desktop
... have to navigate a lot more, but it's there

tlr: looking at https page on mobile using Blazer, sees padlock, isn't touchable

<Zakim> Thomas, you wanted to add a data point

tlr: nowhere near compliant
... data point
... propose drill down

mez: wants a sense of room on that

<asaldhan> umute me

<Mez> User agents MUST provide security context information through one or more user-accessible information sources

<tjh> +1 to Thomas's remarks

MEZ can you state the question?

asaldhan: distributed mobile group tlr probably knows about, might give some info on mobile devices and their conformance

tlr: not sure he knows which group

asaldhan: the one that had a meeting in Dublin
... recently
... will look it up

tlr: ubiq. application working group
... across multiple devices, expertise about device profiles, backing from vendors
... ubiquitous web applications working group
... UWA
... on W3C website hopefully

<Mez> a section starting with language like "User agents MUST provide security context information through one or more user-accessible information sources", which includes conformance language on what information, and where

mez: wants a sense of the room
... typed in something else (thanks ;-) )

<tlr> +1 to that proposal

<asaldhan> The group I was referring to was: http://www.w3.org/2007/02/dmdwa-ws/

+1 to taking a straw poll on what mez typed

<tlr> my +1 was to the material proposal, not just to having the straw poll. ;-)

<tlr> +1

mez: straw poll on that statement
... responses would be YES / CAN LIVE WITH / NO

ifette: YES

<tlr> tlr:YES

<Mez> mez: yes

mez: yes

tlr: yes

<jvkrey> jvkrey: yes

tyler: abstain

<hal> Yes

<asaldhan> yes

tjh: yes

<tlr> tjh: yes

<tlr> rachna: yes

rachna: yes

mez: hour was not wated
... her understanding that editors will go off and update conformance language

<tlr> yes

mez: thomas and asaldhan

<rachna> clarification: rachna: yes but we should make sure that the information is usable, not just that we make more info available

<tlr> ACTION: thomas to update 5.2 according to call's discussion [recorded in http://www.w3.org/2007/08/15-wsc-minutes.html#action01]

<trackbot-ng> Created ACTION-281 - Update 5.2 according to call's discussion [on Thomas Roessler - due 2007-08-22].

<tlr> rachna, excellent point.

Next Meeting topics of discussion

tlr: in terms of material that could use discussion, we have area around minimizing trust decisions and error handling
... current text includes proposal based on some discussion, briefly, 3 distinct modes: positive indicators, no indicators, strong error pages
... proposal for edge conditions
... discussion around whether that captures the sense of the group, other circumstances, general approach...
... wants to ask what should come after that
... would determine what gets folded in to document next, wants to keep ahead of curve

mez: unclear on references for that document

tlr: section 4 and section 5.3

<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tlsforweb

<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling

tlr: also curious to check in on the state of the usability discussion around PII bar proposal
... something to spend time on now or whatever
... prime suspect for next thing to fold in

mez: who is point on usability for PII

rachna: rachna is

mez: ready to have that discussion next week?

rachna: needs go around with tyler, but sure

mez: it's going on the agenda

<tlr> sounds excellent, and the "needs a go-around" was the status update I was looking for for today. :)

mez: thanks, bye

Summary of Action Items

[NEW] ACTION: thomas to update 5.2 according to call's discussion [recorded in http://www.w3.org/2007/08/15-wsc-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/08/16 09:11:05 $