W3C home > Mailing lists > Public > www-tag@w3.org > February 2015

Re: Follow-up to TAG meeting on Powerful Features

From: Yan Zhu <yzhu@yahoo-inc.com>
Date: Tue, 17 Feb 2015 19:52:58 +0000 (UTC)
To: Brad Hill <hillbrad@gmail.com>, Daniel Appelquist <dan@torgo.com>, Wendy Seltzer <wseltzer@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, TAG List <www-tag@w3.org>
Message-ID: <1567154101.5608037.1424202778209.JavaMail.yahoo@mail.yahoo.com>
I am happy with Brad's proposal that the TAG review new CRs against the criteria in the Powerful Features document [1] and raise objections with the working groups accordingly. I have no opinion on whether the language is normative or not.

As Daniel Appelquist mentioned, I volunteered on behalf of TAG to become a co-editor of the Powerful Features document if that is what webappsec would prefer. I am also fine with just shepherding recommendation reviews through the TAG.
[1] http://www.w3.org/TR/powerful-features/#is-feature-powerful

On Tuesday, February 17, 2015 10:07 AM, Brad Hill <hillbrad@gmail.com> wrote:

That's not exactly how I remembered it, and I'm not sure if that will address Mozilla's concerns.  

I think that Mozilla is correct that controversies will almost certainly arise around this kind of decision, and there is a very real tension to resolve.  It's not unreasonable to be concerned about normative language coming from a group from a self-selected group with a very particular point of view being applied to override hard-fought consensus from other groups.

I think this is exactly the kind of issue that the TAG is designed to address, and which, as a group elected by the membership at large, has the legitimacy to do so. 

I believe it makes sense for this to be delivered as a joint deliverable with the TAG, to help ensure it receives the widest possible review and "puts on notice" the W3C community that new Recommendations will be assessed against these criteria so that they can have these discussions in their own groups, early in their process.  

I think the expectation should be that, while non-normative, the TAG will review new Candidate Recommendations against these criteria and may object or ask a group to revisit a decision to make a feature available in insecure contexts, if it believes that the group has not diligently applied the rubric.  And that the WebAppSec WG (and Security and Privacy IGs!) may be called on to assist the TAG as subject matter experts, but will not be responsible for the final decision.

The language of the document will not be normative, but the consensus of the community in behalf of the Web, as represented by the TAG, will.


On Tue Feb 17 2015 at 7:30:54 AM Daniel Appelquist <dan@torgo.com> wrote:

Hi Wendy - 
>As captured in our raw minutes (http://www.w3.org/2015/02/12-tagmem-minutes.html) I believe Yan stepped forward to play that role. I think it’s up to the WebAppSec group chairs to determine whether that should be a co-editorship. My suggestion was to use the packaging spec (http://www.w3.org/TR/web-packaging/) as a template for what a joint deliverable could look like (check out the Status section of that document).
>On 16 Feb 2015, at 10:07, Wendy Seltzer <wseltzer@w3.org> wrote:
>>Hi Dan and TAG, cc WebAppSec,
>>Thanks for inviting discussion on "Requirements for Powerful Features"
>>at the recent TAG meeting.
>>As a proposed way forward, I heard TAG express interest in working with
>>WebAppSec on the specification, to edit a joint product in which the
>>requirements for "Is [insert feature here] powerful?" could be
>>normative. That way, we'd combine the TAG's insight on architectural
>>considerations with WebAppSec's security expertise.
>>If that's a correct recollection, who from the TAG would be interested
>>in working with WebAppSec, and how can I help to bring you on-board?
>>Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
>>Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
>>http://wendy.seltzer.org/        +1.617.863.0613 (mobile)
Received on Tuesday, 17 February 2015 19:55:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:10 UTC