- From: Thomas Roessler <tlr@w3.org>
- Date: Sat, 1 Sep 2007 14:51:46 +0200
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2007-08-15 were approved and are
available online here:
http://www.w3.org/2007/08/15-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Teleconference
15 Aug 2007
[2]Agenda
See also: [3]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
* [4]Topics
1. [5]Pick a scribe
2. [6]Approve minutes from last meeting
3. [7]Newly completed action items
4. [8]Action items closed due to inactivity
5. [9]Agenda bashing
6. [10]Meta-discussion about whether page info summary is a goal
or non-goal
7. [11]Rec track document conformance language discussion, Sec. 5
of rec track draft, Page Info Summary
8. [12]Next Meeting topics of discussion
* [13]Summary of Action Items
__________________________________________________________________
<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> [14]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>
[15]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:
[16]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
[17]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> [18]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tlsforweb
<tlr>
[19]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
[20]http://www.w3.org/2007/08/15-wsc-minutes.html#action01]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [21]scribe.perl version 1.128
([22]CVS log)
$Date: 2007/08/16 09:11:05 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0117.html
3. http://www.w3.org/2007/08/15-wsc-irc
4. http://www.w3.org/2007/08/15-wsc-minutes.html#agenda
5. http://www.w3.org/2007/08/15-wsc-minutes.html#item01
6. http://www.w3.org/2007/08/15-wsc-minutes.html#item02
7. http://www.w3.org/2007/08/15-wsc-minutes.html#item03
8. http://www.w3.org/2007/08/15-wsc-minutes.html#item04
9. http://www.w3.org/2007/08/15-wsc-minutes.html#item05
10. http://www.w3.org/2007/08/15-wsc-minutes.html#item06
11. http://www.w3.org/2007/08/15-wsc-minutes.html#item07
12. http://www.w3.org/2007/08/15-wsc-minutes.html#item08
13. http://www.w3.org/2007/08/15-wsc-minutes.html#ActionSummary
14. http://www.w3.org/2007/07/08-wsc-minutes.html
15. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
16. http://www.w3.org/2007/02/dmdwa-ws/
17. http://www.w3.org/2007/08/15-wsc-minutes.html#action01
18. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#tlsforweb
19. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
20. http://www.w3.org/2007/08/15-wsc-minutes.html#action01
21. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
22. http://dev.w3.org/cvsweb/2002/scribe/
Received on Saturday, 1 September 2007 12:51:55 UTC