See also: IRC log
<trackbot-ng> Date: 12 December 2007
<Mez> http://www.bam.org/events/08MACB/08MACB.aspx
<ifette> ScribeNick: maritzaj
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0048.html
<scribe> done.
<Mez> http://www.w3.org/2007/11/28-wsc-minutes
mez: I know a number of issues
were raised on the 11/28 minutes
... are they ready?
<jvkrey_home> I'm still missing from the attendees list ;)
ian: no my changes aren't in that version
mez: 11/28 not approved
<Mez> http://www.w3.org/2007/12/05-wsc-minutes.html
mez: we'll carry this over until
the next meeting
... do we approve the 12/5 minutes?
... 12/5 minutes approved
Yngve: I also competed two action items
mez: I'll put them on next week's agenda
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Nov/0151.html
mez: had to reclose Bruno's
... could use more feedback on non-visual interfaces
Issue 118
scribe: Issue 131 if we have time
mez: If we have more time we can
talk about Stephen's posting on 5.3.7
... also need to create an issue to track it
... reminder, the next meeting is Dec 19th
... issue 119 will be on that meeting
... Every active participant should have received WSC-XIT by
Dec 19t
... anything on agenda bashing
<Mez> http://www.w3.org/2006/WSC/track/issues/116
UNKNOWN_SPEAKER: should users be able to reconfigure primary chrome
Hal: The results of the email
discussion showed parts of my write up were either strongly
disagreed with or in the document somewhere else
... there should be a one step way to get back to the original
configuration
... no one really commented on that
<Mez> If the user agent does permit this, it MUST provide a mechanism to easily reset the user agent to display the all the required indicators in primary chrome.
hal: The would be the last sentence of 2B, so the agent permits reconfiguration
Ian: I like providing a way to
get back to the default state, if this is different than the
default compliant state, this should be clear
... but where would this be in the interface?
... if it's deep in a dialog box, can we say that's easy?
hal: I don't mind if it's in the options dialog, it just shouldn't be more than one button wherever it is
stephen: If i click this reset, if I previously deleted a root CA, would it then be reinstalled?
Hal: this is just for the
indicators
... this spec says you must indicate security information in a
specific way
... the discussion convinced me that browsers should ship with
this configuration, but users should be able to change their
primary chrome if they'd like, doesn't apply to trusted
roots
mez: in the final write up we should reference the spec it applies to
Hal: This means what does it mean
to normatively comply with our specs
... if users can change this, there should be an easy way for
them to go back to the original configuration
stephen: ok, this sounds like a good idea
hal: if we have agreement in the requirement, I can draft something and figure out where to put it in the document
ian: I like the idea in
principle
... but my question comes in, the browser doesn't come in the
shipped state the manufacturer intends, extensions installed by
the user or instances distributed by an OEM, if we have a
notion of a good state, is this state the configuration that
was defined by the OEM or the state that was defined by the
browser vendors?
<stephenF> tricky but good question
ian: if I want to get back to one state, and these two are different, what happens?
Yngve: I'd like to point out in opera you can right click on the skin and choose customize to make changes to the appearance, you can then revert to a previous skin if you haven't changed that one
Hal: Wouldn't a browser that complies with the WSC spec comply with it on all skins
Yngve: you haven't changed the configuration and then you go back to another skin, you can change between them quickly
<ifette> my question is still open re: what does it mean to go back? which state are they going back to...
Hal: the intent here is to say a compliant implementation must do XYZ, so I thought, ok we don't want users to change that, but people didn't like that, so if we allow them to change something, it must be easy for users to get back to the mode that is specified by our spec
<Mez> I think he's saying - it's compliant, not shipped, and not browser default
<stephenF> "compliant" being a useful label seems to imply some kind of branding
<jvkrey_home> sounds like a "panic button" :)
hal: I realize there are dozens of changes you can make to a browser, but you should be able to revert to the original configuration that is compliant in respect to the relevant specs
ian: Two cases, 1) the OEM ships
the browser in a way that conforms to the specs
... but a question arises if the OEM ships it in a state where
it isn't compliant
... what if you return to a compliant state that is different
than the shipped state?
<stephenF> presumably there'd also be enterprise-specific distros that could be +/- compliance
PHB: few points, one of them is we might not be able to make a non-configurable primary display
<ifette> +1
PHB: so if i have a plugin that suppresses the authorized security indicator, but I do it to present a stronger security indicator, so I don't see why we would prohibit this
hal: we dropped that aspect of the question
ian: if there was a firefox
shipped with secure letterhead that replaces the lock
icon
... then what happens
mez: how about if we have a
button that does something, it's clear what it does
... we shouldn't have buttons that do one thing and state they
do something else
Hal: I'm just saying there's more than one way to be compliant
mez: the plugin issue is a tough one
<stephenF> how about instead of going "back"/"reset" we "move to" compliance (automagically)
PHB: I think it comes down to suggesting a should, but people will demand more rope despite what we do
hal: the use case I have in mind, someone calls and has a problem, and someone can say, go to this page, click here and tell me what's going on
stephen: I think Ian's question is a good one, so what if instead of resetting to a previous state, it moves to to a compliant state, regardless of what the "original" state was
mez: it sounds like this is
something that could be turned into useful language
... but it seems like concrete language would be useful
... in a proposal for the spec
hal: and I will take into account the discussion
thanks, Ian
<ifette> ACTION: hal to propose language for ISSUE-116 based on last sentence of 2b and the discussion in 12/12's meeting [recorded in http://www.w3.org/2007/12/12-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-358 - Propose language for ISSUE-116 based on last sentence of 2b and the discussion in 12/12's meeting [on Hal Lockhart - due 2007-12-19].
jvkrey: Just thinking about the last use case, so someone reconfigured their browser and you want to know what's going on, so thinking about the browser lockdown mode and you disable all the plugins and only have the basics, then I was thinking hal's use case is a lot like browser lockdown
hal: I'm not sure where the proposal for browser lockdown is, but I thought it was limited to a subset of sites?
mez: I think once we have a concrete proposal we'll be able to see where the overlap is
I'm on mute
mez: anything else on issue 116
<Mez> http://www.w3.org/2006/WSC/track/issues/118
mez: great, we have an action item for next steps, so now issue 118
hal: this is one where I made a
comment and the issue landed on me
... if there was a non-browser UI, we ought to have a
consistent set of terms that refers to user actions across the
interaction models
... i don't really use a cell phone browser, so I'm not sure
what the user operations would be
... I'm also unsure of what the relevant user actions might
be
... we need someone who's familiar with user actions on these
different user agent
mez: i also found it difficult to
avoid only thinking about a user interacting with a
desktop/laptop user agent
... i've been less conscientious of small interfaces, and have
been relying on Luis to keep us honest
... also asked the nokia rep for a review
Hal: I was thinking of going
further and saying in general within this document, when we say
X it means Y for browser interaction and Z on another user
agent
... I don't see this being a huge piece of the document, just a
few examples of the major ones
mez: interesting that you want
this in the beginning of the document
... I'm still wondering what section 3 is doing in the document
and whether this might go there
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Conformance
mez: it might be completely
motivate by tlr and his concern with our spec might be used by
other models
... if you haven't done your review, maybe you could take a
first cut at a list
... which would give us an idea of the terms we need to come to
terms with
... I'm ok with letting the issue rest until we get the reviews
of Hal, Ericson and Nokia
... anything else on this one?
<Mez> http://www.w3.org/2006/WSC/track/issues/131
mez: comment by Ian is basically the browser must notify the user when trying to execute something outside the browser
ian: I agree we want to prevent
software being downloaded and run without the user's content,
we also want to stop something from running within the browser
without the user's consent, but how will the browser alert the
user when something is running outside the browser without
consent?
... but it's often the case that applications are running
outside the browser as a result of the actions in the
browser
... example of a browser with the abode plugin and a user
reading a pdf in the browser
... would we show a dialog every time the user opens a pdf in
the browser?
... second example of windows media player and playing a
video
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#techniques-robustness
<Mez> 3rd bullet
ian: can we change this so it's just when the software is new, or only when the user isn't expecting something external to be running
<stephenF> +1 to ian's concern
phb: I think we need to distinguish between inside and outside the browser
<Mez> "browser environment" not defined in spec right now - does it include plug ins?
phb: just like java knows what's internal to java and what's outside the sandbox
<Mez> ian's concern is I think only about the execute word, not the install word, yes?
phb: so the browser should know that it can operate within this sandbox model, and inform the user when something goes outside the sandbox
<ifette> mez, both
<ifette> but mostly execute...
<Mez> what's the example that motivates the install concern?
<ifette> codecs
phb: we need to define the line, then have verbage about what happens when something crosses the line
<Mez> not familiar with codecs; link?
<ifette> no good link to give you. Imagine though that you are trying to view a video, and media player tells you that you don't have the necessary codecs installed, and that it will download the DivX codec for you. Media player will hopefully warn you, but I have no idea if your browser will warn you (or even know that this is going on)
going to adobe, there are different versions of what can be done given what you've opened -- so you could be running adobe with different privileges depending on the mode
<ifette> no
hal: aren't we only concerned when it's come from the net
<Zakim> ifette, you wanted to say that the browser might actually might not know, if the active-x plugin just calls coinitializesecurity, starts up some new processes, does IPC etc, that
ian: to hal, if we assume if it's
already installed it's safe to run, no
... if active x is there, the majority of the installed options
shouldn't be run from a browser
<Mez> it's my understanding that Microsoft has said that the security model of ActiveX is not what they were hoping for, and they were not concentrating on it so much anymore.
ian: second, the browser doesn't
always know what's going on, the browser mostly starts the
process, but it doesn't know exactly what's going on, and if
it's forked to other processes
... so the browser might not know what's running outside the
environment
<Zakim> stephenF, you wanted to worry about bothering user so much they get trained to say "ok" always
stephen: wondering if getting in
the user's face is the right thing to do
... seems messy, which is a concern, not a suggestion
hal: I see this issue as saying
we see a bad case, can we define an implementable method for
distinguishing between the good and bad case
... maybe the issue isn't inside of outside the browser, but
did it or didn't it come from the browser
... don't want to say allow things you already don't
... what is the distinction we'd like to make and is it
implementable
<Mez> random restatement - Web user agents SHOULD inform the user and request consent when web content attempts to install software from the network.
<stephenF> is "install" sufficiently well defined?
hal: isn't auto adding a plugin just as bad?
<jvkrey_home> browser extensions?
yngve: I suspect what we're looking at is content that is not going to run in the configuration of the browser, but will be passed off to the OS, and out of the browser's ability to dictate policy and in this case, i'm including some plugins
<Mez> Web user agents SHOULD inform the user and request consent when web content attempts to execute software that is not installed within the the browser environment. This consent SHOULD be retained and honored across sessions.
<Zakim> asaldhan, you wanted to say that some plugins like the Adobe Flash do upgrades automatically. I am guessing that this is not a real concern.
anil: point of observation, some plugins update automatically, so i'm guessing this isn't a concern for us, right?
<ifette> probably for reader it reminds you...
mez: they do it automatically, i know adobe whines, but ?
<stephenF> "honored across sessions" might be tricky if the UA device changes network in the meantime
anil: the new web 2.0 environment, auto updates
mez: i don't know if upgrades are
considered installed
... you might need to be worried
hal: updating software of the user's system without giving the user anyway of getting involved with this, and there has been opposition to microsoft autoupdating
<Mez> that's why the text refers to browser environment
hal: i understand there might be
a mode to say give me all the updates automatically
... but there should also be other modes
<Zakim> ifette, you wanted to say we're ratholing
ian: we're getting into a rathole
on upgrading
... a lot of programs have upgraders that are always
running
... it feels tangential to things running outside the
browser
yngve: i think what we're looking
at in a download activated by content on a webpage
... it either tries to run outside the browser and in the os
without the sandbox
<Zakim> stephenF, you wanted to ask if the various browsers are sufficiently similar to have one definition of inside/outside
stephen: if we can't have a
definition across all browsers that works for defining inside
and outside
... then where are we?
... we can only say something tangible if we can say it across
browsers
mez: so we should be able to say generally what should be executable
<ifette> phb is breaking up
<ifette> or move in your room
<ifette> no
<ifette> yes
<ifette> kinda
<ifette> are you on voip or cell? cause i cant understand you
( can't hear well enough to scribe)
<Mez> right, don't sweat it maritza
<ifette> meow? ;-)
<PHB2> Its vonage
<PHB2> Ah, thats the problem, Premiere had finished compressing my podcast and started uploading it.
yngve: browsers currently have html and javascript, can't go outside, plugins can, and then you have content we don't know what to do with and we have to complete actions for it in outside applications, so we have content that needs to open in another application, and we have other content that we don't know how to handle -- the content the browser isn't sure how to handle could include the code that we wouldn't want to run automatically
ian: I think we should remove 8.2.3.3
mez: I'm not sure what the right process would be ...
ian: create an action on the editors to remove
<ifette> vote?
mez: we should do a straw poll or something first to show consensus
<ifette> remove / keep / reword?
<ifette> vote at next meeting?
mez: can we put that proposal in
mail, you proposal for resolution is to remove the text
... if no one says anything i declare consensus, and we'd have
to let it go through the holidays
... next next meeting
<ifette> ACTION: ifette to follow up on ISSUE-131 thread to propose removing 8.3.2.3 in email [recorded in http://www.w3.org/2007/12/12-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-359 - Follow up on ISSUE-131 thread to propose removing 8.3.2.3 in email [on Ian Fette - due 2007-12-19].
mez: if there isn't consensus we can do a straw poll
hal: is the rational that we can't implement a way of separating the good and bad?
ian: l'm saying in a lot of cases there's no way to know and a lot of browsers are doing this anyway, so any text around it would be more confusing than helpful
hal: be sure to tie some rational
to the action
... then depending on the expertise of the browser people we
have, i'm ok
mez: and we are looking at what browser's are currently doing for insights on our proposals
<PHB2> That is why I proposed that we tell browser providers that they must determine a boundary
ian: I think it's being done in that a browser won't take a tag and execute whatever's in it
<PHB2> ... even though we cannot codify one for them in the spec
ian: if someone can write this
up, i could accept it, but in the absence of that, i think we
should remove it
... i can't think of a way to write this that would work across
browsers
<PHB2> What does the boundary mean in a photo frame web browser
mez: so someone who cares enough
about retaining this should do that
... i don't know enough about what browsers actually do to
write the definition
<ifette> great
<Mez> http://www.w3.org/2006/WSC/track/actions/348
mez: stephen, you wanted to discuss this in a meeting before throwing it in the document
stephen: two concrete things in
this
... 1) got rid of the interaction cert idea, it's something
that could go back in if there's a referenceable spec
there was a definition of an attestation cert, which seems to overlap with the augmented cert idea, so i covered one of these and kept the augmented assurance idea
scribe: also cleaned up the
terminology
... aiming for consistency
... introduced a few abbreviations for terms, otherwise it's
mostly just an editorial reorganization
... people should read through and do a diff
mez: how to do a diff?
stephen: read old and new and say which you prefer
<ifette> cut and paste, save to files, and run diff...
<Mez> do you get something useful?
<ifette> depends ;-)
yngve: difference about the trust
root store?
... with attestation cert?
<Mez> attested cert
<Mez> attestation
<Mez> of course no one is sure what that was supposed to mean, other than being a trust root
<stephenF> i like the new one better:-)
mez: so we'll give people time to
review it
... stephen you should create an issue so we can track
this
... so we've covered our agenda
... meeting next week
<stephenF> there's an issue-113 already associated with that new text I think
mez: then we're off for two weeks until 2008