Re: [filter-effects] shader security model


On Mar 6, 2013, at 11:35 AM, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2013-03-06 11:26 -0800, Dirk Schulze wrote:
>> 
>> On Mar 6, 2013, at 11:23 AM, "L. David Baron" <dbaron@dbaron.org> wrote:
>> 
>>> On Wednesday 2013-03-06 11:00 -0800, Dirk Schulze wrote:
>>>> I wanted to resolve on a new working draft not only because of the changes to custom filters, but more because of a lot of clarifications for the other filter primitives and shorthand filters. At this point I do not see shaders blocking the standardization process of the whole spec. Should people still be concerned about the implementation status of shaders later in the process, we can put shaders on the risk list before going to CR. It may go into the next level of Filter Effects at this point.
>>>> 
>>>> Do you disagree with this strategy?
>>> 
>>> Yes.
>>> 
>>> I think trying to postpone dealing with objections is a bad
>>> strategy.
>> 
>> I would like to understand your concerns more. Your objection in the CSS WG meeting were mainly based on the security concerns that you had. I hope I could clarify this point.
> 
> My objection in the CSS WG meeting was based on the 10 seconds I had
> to consider an agenda item that was raised at the last minute
> (during the meeting), and was not carefully thought out.

It was a request to preserve the current state of the editors draft as working draft to reflect the changes that we made in the last months. I added this request to the FXTF agenda as well. Not enough people called in to discuss this step why I need to bring it up on each working group.

I am absolutely in favor for the request of Tab to move resolution process on publication to the mailing list. I think this would address your request of asynchronous decision making.

> 
> I think the features that you're proposing to add rope in a large
> new area of functionality that adds a lot of complexity to the Web
> platform (pulling in additional file formats that define shaders).
> I don't think there's consensus that the value of this functionality
> matches the complexity it adds.

The specification is based on existing file formats defined by other specifications and supported by Firefox and WebKit based browsers.

> 
> (Note that consensus requires not only lack of objection, it also
> requires wide support.)

I agree. 

> 
> That said, I've only had a few minutes to think through *this*
> response so I might say something else after longer consideration.
> 
> Discussions like this are the reason I would prefer to see the CSS
> working group operate using asynchronous decision making, like many
> other W3C working groups do.

I am absolutely fine with giving more time for a review of the specification. I do not want to rush the specification progress more than necessary.

Greetings,
Dirk

> 
> -David
> 
> -- 
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Wednesday, 6 March 2013 19:55:29 UTC