See also: IRC log
<trackbot> Date: 16 February 2012
<jar> scribe: Jonathan Rees
<jar> scribenick: jar
Future regrets as recorded in agenda (none recorded for today)
HT can scribe on the 23rd, until quarter past
Minutes of the 9th approved by acclaim
<noah> http://www.w3.org/2001/tag/2012/02/09-minutes
RESOLUTION: http://www.w3.org/2001/tag/2012/02/09-minutes accepted as a true record
Announcement needed for the two notes (HTML/XML and client-side state) - Yves to do
noah: Actions to close?
Yves: Will check later
(agenda review)
Going over Jeff's email...
JJ asks, who should be doing what on CA issue?
<masinter> I had an off-list discussion about SSL and privacy which I can summarize some time, if there's interest, but I won't bring up the topic unless others want to open it.
<noah> Our note to Jeff: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0049.html
<noah> Response from Jeff: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0054.html
<noah> Regarding the Certificate Authority system, Jeff asks:
<noah> "While this is clearly a problem for the Web, it is less clear to me who the
<noah> TAG thinks should be addressing the topic. If the issues are SSL security,
<noah> it would presumably be addressed at the IETF. Did the TAG decompose the
<noah> problem enough to identify who should be doing what?"
<masinter> Short answer to Jeff's question is: no
<masinter> We did not decompose the problem enough to identify who should be doing what
yves: Followup on www-tag: email from Mike Belshe. Even if we are decomposing, the main issue is the way centralization of trust in key mgmt system works, and that goes beyond technical. Huge topic
<masinter> My opinion is that W3C Security activity should engage with the TAG, IETF security directorate, W3C WebAppSec, and IETF WebSec groups should engage in this.
<Yves> http://lists.w3.org/Archives/Public/www-tag/2012Feb/0053.html
lm: [as entered in IRC, see above;] Whether the problem can be addressed by those groups, I don't think we can analyze, as much as encourage, and agree to review plans if some arise
<Yves> +1 to Larry
<Ashok> +1
<darobin> +1 too
<noah> Proposed text: The TAG did not "decompose" the question in the sense you mean. We do agree that most of the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible.
noah: Drafting...
<noah> AM: remove first sentence
ashok: remove the first sentence
<masinter> The IETF is pursuing DANE: https://datatracker.ietf.org/wg/dane/charter/ which might be a solution
yl: mention the security directorates liaison
<masinter> We should ask the liaison group to make sure this topic is covered
<noah> "We agree that most of the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. We note that there is active liaison between the security directorate at IETF and the Security Activity
lm: There's an overall liaison between IETF and W3C, maybe a more specific security one too. Philippe & Thomas?
<noah> "We agree that most of the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. We note that there is active liaison between the security directorate at IETF and the Security Activity at
jar: I would remove "most of"
<noah> "We agree that the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. We note that there is active liaison between the security directorate at IETF and the Security Activity at W3C, and
<masinter> Last sentence is incomplete
<masinter> "We note that ..."
<noah> "Part one: We agree that the technical work will likely happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible. "
<noah> part 2: "We note that there is active liaison between the security directorate at IETF and the Security Activity at W3C, and of course there is also overall W3C to IETF corrdination, which is managed on the W3C side by Philippe le Hegaret and Thomas Roessler, and for IETF by Mark Nottingham."
<masinter> we did hear about DANE but didn't analyze it
<JeniT> +1
<plinss> +1
<masinter> +1
No objection to using Noah's text in response to Jeff. Moving on:
<noah> Jeff further wrote: "Among many other important concerns, the impact on the W3C specifications
<noah> level needs to be assessed."
(looking at the reasons we care about CA issue, and Jeff's comment)
noah: The WGs should take the lead on reviewing W3C specs.
<noah> OK, Yves +1 is to what JAR just scribed me [Noah] saying
<masinter> is there an interaction with SPDY?
<masinter> i dont' actually know what it means, "impact on W3C specifications level"
yves: SPDY is orthogonal to CA question.
... doesn't enter in here
<noah> I'm guessing that the word "level" should not be emphasized in understanding Jeff's question.
<masinter> I don't know what he means
<masinter> I don't think there is any impact on W3C specs, personally
<JeniT> "We agree that the impact on W3C specifications should be assessed, and propose that this should be done by the appropriate WGs"
<masinter> I can't think of any off hand.
<masinter> I don't even know what WGs I would ask
<noah> Proposed response: we agree. We expect that individual working groups should take the lead in dealing with impact on particular specifications, and as noted above, the TAG will continue to play an oversight role, being alert for new issues, or for impact on specifications that others are missing.
<Yves> it has an impact on trust-related things, like provenance, but it's up to the group who are designing things based on trust to assess the impact
<masinter> Or what I would ask them to assess
<masinter> I don't think this affects digital signatures
<masinter> The analysis I got from internal Adobe security consultants is that this doesn't affect digital signatures
<masinter> I think the previous statement covers this too
noah: Send out a general request - if you think your WG's work is affected please look into it?
LM: That's not a clear instruction
noah: Consider potential impact...
<masinter> How about "b, and to work with IETF and others to ensure that the solutions are as satisfactory as possible, and impact on W3C specs considered."
<noah> Possible note to chairs: "We note there have recently been compromises to the CA system; there will likely be more. You should assess whether such compromises will affect the technologies for which your WGs are responsible."
<masinter> Until there are proposed solutions, there's no benefit to assessing impact of the problem.
noah: Is it clear that this is mainly an IETF thing, that sec domain is responsible regarding impact on W3C specs?
<noah> Proposed response: we agree. We expect that individual working groups should take the lead in dealing with impact on particular specifications, and as noted above, the TAG will continue to play an oversight role, being alert for new issues, or for impact on specifications that others are missing.
lm: That's fine
<JeniT> +1
<plinss> +1
general agreement
<noah> Possible note to chairs: "We note there have recently been compromises to the CA system; there will likely be more. You should assess whether such compromises will affect the technologies for which your WGs are responsible."
<masinter> ask Security activity to sponsor this
plinss: Did that agreement include note to chairs?
<plinss> +1
(scribe: I don't think note to chairs was agreed)
<masinter> i'd rather ask Thomas to alert chairs and manage responses.
<masinter> just trying not to put the TAG into the loop if it's not needed
<JeniT> +1 to Larry, think Thomas should be able to frame appropriate message
<noah> Part 1: We agree that the technical work will happen outside the TAG and much of it will be outside the W3C. The TAG, and perhaps those in the Security Activity in W3C, need to continue to monitor the impact of these threats to the health of the Web, and to work with IETF and others to ensure that the solutions are as satisfactory as possible.
<noah> Part 2: We note that there is active liaison between the security directorate at IETF and the Security Activity at W3C, and of course there is also overall W3C to IETF corrdination, which is managed on the W3C side by Philippe le Hegaret and Thomas Roessler, and for IETF by Mark Nottingham. We suggest that the W3C Security Activity ensure that other concerned WG's are aware of the problems with the CA system.
<JeniT> +1
<masinter> +1
agreement
<noah> AGREED WITHOUT OBJECTION
Next item from JJ's email - mobile
<noah> Jeff's comment on mobile Web vs. native mobile:
<noah> "This is a key area of concern. Did the TAG produce a specific list of
<noah> features that would be appropriate for the Web platform to help it catch up
<noah> in areas where it is currently behind?"
jenit: There is a list, at a high level, in the note we sent
rb: Not detailed, but it says something. Not sure we can be specific
lm: It's as specific as it should be.
... PhoneGap ?
<masinter> PhoneGap is an example of bridging technology
<noah> Proposed response: Only insofar as we included a high-level list in our note to you. We believe the Mobile Web Activity is tracking these things in detail, and they have more domain expertise than we do. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed.
<masinter> http://phonegap.com/
rb: Do we still have a mobile web activity? Now split over ubiweb and the other one (webapps)?
<masinter> PhoneGap is open source platform that might mitigate some of these
noah: There's no list of activities?
<Ashok> I had another thought - Platform apps are typically vetted by the platform, WebApps are not
lm: This topic came from Robin, yes? But we didn't talk about it much.
<noah> http://www.w3.org/2007/uwa/Activity.html
lm: I wonder if PhoneGap fills some of these gaps?
noah: PhoneGap-using apps install like native apps
... Mixed bag, because not linkable
lm: Linkability of native apps is the problem then
noah: Big part of what we mean by "web app".. phonegap is useful but different
<noah> Mobile Web Initiative Activity
(attempt to untangle w3 activity situation)
<noah> Proposed response: Only insofar as we included a high-level list in our note to you. We believe the Mobile Web Initiative Activity is tracking these things in detail, and they have more domain expertise than we do. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed.
rb: Don't specifically mention MWA?
<darobin> replace "Mobile Web Initiative Activity is" with "people in charge of groups relating to mobile Web applications are"
<masinter> I don't "believe MWI is tracking these things in detail" since I have no idea what they're doing
<masinter> MWI *should* be tracking these things in detail
<masinter> And if I don't know who the "people in charge .." are, how can I have a belief about what they're doing?
<Yves> well, it's more the "Ubiquitous Web Applications Activity" that should be tracking things in details in that area
<Yves> as the topic is really... Web Applications
<noah> Proposed response: Only insofar as we included a high-level list in our note to you. We believe the people in charge of groups relating to mobile Web applications should be tracking these things in detail, and they have more domain expertise than we do. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed.
<masinter> they report to Jeff, he can make sure they're doing what they should be doing
<Ashok> Remove -> and they have more domain expertise than we do
<masinter> +1
<noah> Proposed response: Only insofar as we included a high-level list in our note to you. We believe the people in charge of groups relating to mobile Web applications are tracking these things in detail. Our goal in this note was to signal that, at a high level, there is both reason for concern about the likely success of our overall effort, and reason for optimism that a focused effort can succeed.
<noah> AGREED WITHOUT OBJECTION
<noah> (Moving on) Relating to distributed extensibility and vendor prefixes, Jeff wrote:
<noah> "Did the TAG discuss solutions? My instincts is that there is an opportunity to address this by speeding up the pace of standardization. If everyone is using the same approach - why should everyone call it "webkit", why can't we just agree?"
<noah> Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. The TAG is not discussing more general solutions, and it's not clear that there is some generic approach that would be broadly applicable.
<darobin> +1
<masinter> There isn't only webkit, every implementation has its own selection of features
rb: Most mobile browsers are webkit-based... webkit- prefix is hurting other browsers who are trying to gain ground
<masinter> This is part of the versioning/distributed extensibility mess
noah: Jeff is saying, why not just drop the prefix?
<masinter> a vendor prefix is a kind of 'version number'
rb: The prefix thing is rather broken. Would be nice if CSS WG sorted this out. Not sure we (TAG) need to dive into this
<noah> Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.)
<noah> [CONTINUED] The TAG is not discussing more general solutions, and it's not clear that there is some generic approach that would be broadly applicable.
<masinter> http://www.w3.org/2001/tag/2011/12/evolution/Identifiers.html has a section on vendor prefixes
lm: Count vendor prefix as part of topic we've been working on (but not now) - think there might be a general approach, we're just not working on it now
... Too broad for us to take on right now
<masinter> I'm putting my bets on PhiloWeb at WWW 2012 as a venue for making progress on the fundamentals.
jt: It would be more accurate to say that the TAG's focus is currently on other things
<masinter> vendor prefix is not so different from a namespace
<noah> Proposed resolution: In the particular case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.) The TAG has at times started work in related areas, so far we have not succeeded [truncated]
yves: media types, HTTP headers... it's not really technical but social, how to deploy, market share, experimental feature how to move to standard,... bigger topic than just vendor prefix
lm: How different from an XML namespace?
<masinter> this is related to the issues around "x-" and the difficulties of putting metadata in names
noah: Details of implementation, environment. Easier to have redundant properties in CSS, than redundant NSes in XML
rb: You could have it in XML, and it would show the same problems. Attributes, elements
<noah> Part 1: Proposed resolution: In the particalur case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.)
<noah> Part 2: The TAG has at times started work in related areas, so far we have not succeeded in finding a focused conclusion that would be of value to the community.
rb: If you allow people to add extensions in other namespaces, you end up with the same mess
<masinter> this is related to http://www.w3.org/2001/tag/doc/metaDataInURI-31.html use of metadata in URIs. in this case, the metadata is in the tag that the vendor prefix is metadata "this is only implemented by this vendor"
noah: Worse with elements because in CSS you can specify both, but 3 elements remain different
<masinter> this is a 'version number for forking'
noah: Workarounds maybe, but not same as CSS. E.g. XSL rules
<masinter> because the backward compatibility requirements only work for a single "fork"
<JeniT> "The TAG has at times started work in related areas, but our current focus is not on this work."
jar [in IRC]: "The TAG has at times started work in the general area of extensibility, but we are not currently pursuing this."
<JeniT> +1
<noah> +1
<Ashok> +1
lm: not focusing (instead of pursuing)
<masinter> "we are not currently focusing on this"
lm: so we are pursuing, just not in foreground
<noah> "The TAG has at times started work in the general area of extensibility, but versioning and extensibility is a known hard problem in computer science, and right now we are not focusing on it."
ashok:
<noah> Part 1: In the particular case cited, which is CSS, there is very active work in the working group to improve the situation. If successful, that effort should settle the question of when to use -webkit and when not (we note that Webkit engines have 90+% market share on mobile, and that's contributing to the confusion between vendor-specific and ubiquitous features.)
<noah> Part 2: The TAG has at times started work in the general area of extensibility, but we are not currently focusing on this."
lm: not currently a priority item.
... ok
no objection
<noah> AGREED WITHOUT OBJECTION Part 1 and (the last) PART 2
noah: I will send a response
<JeniT> +1
<masinter> +1
<masinter> I think this dicussion was useful
<noah> ACTION: Noah to respond to Jeff Jaffe, on the public list, using the text agreed on the telcon of 16 Feb 2012 [recorded in http://www.w3.org/2012/02/16-tagmem-irc]
<trackbot> Created ACTION-671 - Respond to Jeff Jaffe, on the public list, using the text agreed on the telcon of 16 Feb 2012 [on Noah Mendelsohn - due 2012-02-23].
<noah> ACTION-563?
<trackbot> ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 -- due 2012-01-31 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/563
ht: June is too soon for next one
<noah> ACTION-563?
<trackbot> ACTION-563 -- Noah Mendelsohn to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 -- due 2012-09-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/563
<noah> Can we get links to pertinent documents for the minutes?
<noah> HT: I've given you feedback on the UDDP(?) document. Mostly you can respond later, but there was one typo you need to address before publishing
<JeniT> http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
<ht> http://www.w3.org/2001/tag/doc/uddp/
<noah> scribenick: noah
<jar> JAR will read HT's email on the subject
HT: I think this is the right next step in a judiciously planned process of trying to wind up in a better place than last time, i.e. to have more buy in.
<jar> ht: This is the next step in a judiciously planned process to try to end up better off than we were last time
<scribe> scribenick: jar
ht: [afterwards maybe it would be] time to move into a community process, I think that's appropriate
... If it doesn't work, we have a basis for creating a new effort, community group maybe
<noah> I heard Henry say that the time to move to a community process is >after< feedback is received from Jonathan's call
jar: yes
<ht> Noah is correct
<ht> Step 1: Call for change proposals
<ht> Step 2: Use the result as the basis for moving to some form of community process, exact form TBD, emphasis on getting broad consensus
<ht> That's just my memory of what JAR already proposed
noah: Any objections to proceeding as planned? ... Seems not.
<ht> IOW, I'm happy for JAR to go ahead and Call for Proposals
noah: JAR, go ahead and publish the call.
(discussion of agenda)
Discussion started 2nd Feb (see agenda)
<noah> Discussion on 2 February: http://www.w3.org/2001/tag/2012/02/02-minutes#item08
<noah> Proposal from Robin to expand the scope: http://www.w3.org/2001/tag/2012/02/02-minutes#item08
rb: Audience. People *currently* writing specs?
<noah> Proposal from Robin to expand the scope: http://lists.w3.org/Archives/Public/www-tag/2012Feb/0021.html
<noah> Draft product page from robin: http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
<noah> From the draft product page:
<noah> "This covers multiple related approaches to preserving users' privacy:
<noah> * User-mediated enumeration.
<noah> * Device-triggered access.
<noah> * API minimisation
rb: The initial product page was focused on minimization. I broadened it slightly, not to boil ocean, but just to include fingerprinting. The two are hard to separate
... Minimization only looks at information you give away when returning from a method call, as opposed to info you give away right at the start
<masinter> remember GeoLocation vs. GeoPriv controversy over API design that wasn't minimimization
rb: There are 4 WGs looking at fingerprinting. I don't think it's a huge broadening, just more coherent, and more relevant
<Zakim> ht, you wanted to agree that it's time to move from bilateral discussion to something which gets the parties to engage on pain of being vulnerable to a "you had your chance"
<Zakim> JeniT, you wanted to encourage the TAG to let Robin work on this
<masinter> one of the questions about SPDY and privacy was whether use of SSL improved ability to fingerprinting
jt: I wanted to say that this sounded useful, we can get somewhere when someone is enthusiastic on topics, so Robin needs to be encouraged
<Zakim> masinter, you wanted to remind about GeoLocation vs. GeoPriv
lm: There was a controversy between geolocation and geopriv. Policy re private data APIs saying duration and rights should always be included. Please add as a use case.
<masinter> it's an API design issue
<masinter> i'm not asking you to look at the issue all over again, but rather consider the use case where additional policy information in the API might be useful
rb: I want to steer clear of that, it's bait for flame throwing. Most of the proponents of geopriv have moved on to other solutions. CDT
lm: I didn't want to revisit, just to look at increasing API design is a precedent on API design advice (?)... don't revisit, just use as use case
noah: Sounds like people are supportive of Robin's plan. Can we look at product page?
<masinter> topics and products should be defined by their center rather than their boundaries
http://www.w3.org/2001/tag/products/apiminimization.html
<masinter> Note that the success criteria don't explicitly require 'minimization' in the solution space
<darobin> http://www.w3.org/2001/tag/doc/APIMinimization.html
http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
noah: We could treat this as a new document with new schedule
rb: Lots of good stuff in what Dan did.
noah: You're proposing a draft for the April F2F.
<masinter> i'm willing to do early review of other people's documents
noah: Propose to adopt RB's draft
<noah> . PROPOSED RESOLUTION: The TAG agrees to work on a "product" on Privacy by Design as described in http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
<noah> RESOLUTION: The TAG agrees to work on a "product" on Privacy by Design as described in http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
<noah> Agreed without dissent
<noah> http://www.w3.org/2001/tag/products/
noah: Increase priority after seeing next draft?
(maybe)
<noah> NM: We will keep this as "Other Active Project" for this round, hope to move it up.
ADJOURNED