See also: IRC log
<trackbot-ng> Date: 15 August 2007
<tlr> Scribe: Ian Fette
<scribe> ScribeNick: ifette
mez: Did not see any issues raised
when minutes sent out
... approved
<tlr> http://www.w3.org/2007/07/08-wsc-minutes.html
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
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
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
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
<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.
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